I've been working on a charting library for a few weeks and am wondering whether their would be any interest in having a boost one. I'm not even sure that it makes sense for boost, as it seems a higher level library than most of libraries and also unrelated to other libraries. There would be many things to work out, like no graphics in Boost (that I'm aware of), my not being an expert C++ person, etc, so I'm just trying to get a feel whether it is worth pursuing more here or not, or if there would be another forum that would be better. By charting library, I mean something that you can give data to and that it plots it in a view port, with axis, labels, title etc like you would get with Excel charts, Gnu Plot, Pro-Essentials, etc Thanks, Brian
"Schrom, Brian T" <brian.schrom@pnl.gov> wrote in message news:42C7E766869C42408F0360B7BF0CBD9B01B4C3F6@pnlmse27.pnl.gov...
I've been working on a charting library for a few weeks and am wondering whether their would be any interest in having a boost one. I'm not even sure that it makes sense for boost, as it seems a higher level library than most of libraries and also unrelated to other libraries.
There would be many things to work out, like no graphics in Boost (that I'm aware of),
You mean no Graphical User Interface? Its true that this is sorely required in C++. See the following. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1781.pdf I would guess that a chart library is relatively simple once a GUI is in place but very difficult otherwise, however without seeing what you have done I'd better not make judgements! It would certainly be interesting to see your ideas, as they would be a concrete example application for any C++ GUI library which helps to focus any design. Do you have means to deal with the fact that there is currently no standard C++ GUI?. For example some sort of generic concepts or requirements? IOW how are you laying out your design without a GUI framework to fit it in? regards Andy Little
On Fri, 02 Sep 2005 08:47:18 -0700, Schrom, Brian T wrote
I've been working on a charting library for a few weeks and am wondering whether their would be any interest in having a boost one. I'm not even sure that it makes sense for boost, as it seems a higher level library than most of libraries and also unrelated to other libraries.
There would be many things to work out, like no graphics in Boost (that I'm aware of), my not being an expert C++ person, etc, so I'm just trying to get a feel whether it is worth pursuing more here or not, or if there would be another forum that would be better.
I think there would be interest and I believe there are solutions to the problems you raise. For example, you could integrate the chart lib so that it could use several different graphics packages that would be external to boost (iostreams, for example, can use various compression libs for compressing data). That said, if you are new to C++ meeting boost standards might be a monumental amount of work. I'd suggest you develop the ideas more, use them, and when you have something a bit further along ask again. Of course, folks here will certainly answer questions if you need help as you go... Jeff
Jeff Garland wrote:
I think there would be interest
agree
and I believe there are solutions to the problems you raise. For example, you could integrate the chart lib so that it could use several different graphics packages that would be external to boost
In general I do agree, however it should be recognized that there is a certain potential for a primitive graphics library in Boost. It would be better if the higher level library proposed by the OP could be based on such a standard grapichs API.
(iostreams, for example, can use various compression libs for compressing data).
Compresion library APIs are probably very different from graphic libraries with regard to the size of the API. A good example of the opposite approach is Boost.Threads. I strongly believe projects like the one proposed here will be a lot more attractive to write and maintain if we had a good and portable graphics library under Boost or the C++ standard. Alternatively an existing portable library could be used, but this add dependencies to other libraries that typically are not part of the target platforms and there are most likely issues with licences to most of these. The need for graphics primitive API was discussed as one of the first issues that had to be addressed when proposal for GUI library was discussed earlier on this list. Is there any work ongoing on this? It seems like this has stalled, I think this is a sign that the task of writing higher level graphics based libraries becomes overvelming in Boost since a single source of portable graphics foundation is not available. We have many good alternatives, but none of these meet all requirements as I see it, so the best we have is to advice developers to integrate to more than one graphics package. Not good for Boost nor for C++ in general. One thing C++ really need is something that is standard, is available and is free which in spirit provides for Standard C++ what Java2D and possibly Java3D provides for Java. A good source of inspiration is http://doc.trolltech.com/4.0/qt4-arthur.html . I would consider to help out with such an effort if somebody else took the lead, but I have limited time I can set aside for such work. ---- Bjørn Roald
On 9/6/05, Bjørn Roald <bjorn@4roald.org> wrote:
Jeff Garland wrote:
I think there would be interest
agree
and I believe there are solutions to the problems you raise. For example, you could integrate the chart lib so that it could use several different graphics packages that would be external to boost
In general I do agree, however it should be recognized that there is a certain potential for a primitive graphics library in Boost. It would be better if the higher level library proposed by the OP could be based on such a standard grapichs API.
(iostreams, for example, can use various compression libs for compressing data).
Compresion library APIs are probably very different from graphic libraries with regard to the size of the API. A good example of the opposite approach is Boost.Threads.
I strongly believe projects like the one proposed here will be a lot more attractive to write and maintain if we had a good and portable graphics library under Boost or the C++ standard. Alternatively an existing portable library could be used, but this add dependencies to other libraries that typically are not part of the target platforms and there are most likely issues with licences to most of these.
The need for graphics primitive API was discussed as one of the first issues that had to be addressed when proposal for GUI library was discussed earlier on this list. Is there any work ongoing on this? It seems like this has stalled, I think this is a sign that the task of writing higher level graphics based libraries becomes overvelming in Boost since a single source of portable graphics foundation is not available. We have many good alternatives, but none of these meet all requirements as I see it, so the best we have is to advice developers to integrate to more than one graphics package. Not good for Boost nor for C++ in general.
One thing C++ really need is something that is standard, is available and is free which in spirit provides for Standard C++ what Java2D and possibly Java3D provides for Java. A good source of inspiration is http://doc.trolltech.com/4.0/qt4-arthur.html .
I would consider to help out with such an effort if somebody else took the lead, but I have limited time I can set aside for such work.
Have you looked into AGG (http://www.antigrain.com)? It avoids use of the STL yes, but it's the highest quality graphics lib I've seen, and its license is less restrictive than the zlib/libpng license so there is no reason it couldn't be forked.
---- Bjørn Roald
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Cory Nelson http://www.int64.org
Cory Nelson said:
Have you looked into AGG (http://www.antigrain.com)? It avoids use of the STL yes, but it's the highest quality graphics lib I've seen, and its license is less restrictive than the zlib/libpng license so there is no reason it couldn't be forked.
Thanks for the link, I was not aware of this one. Looks promising from first look at their web pages and the license. I will look into it when I get time. -- Bjørn Roald
Bjørn Roald wrote:
Thanks for the link, I was not aware of this one. Looks promising from first look at their web pages and the license. I will look into it when I get time.
Also, Mozilla.org are planning on moving their rendering engine to use cairo (http://cairographics.org/) Not sure about the license or anything like that but might be worth a look. Cheers Russell
On Tue, Sep 06, 2005 at 01:09:37PM +0200, Bjørn Roald <bjorn@4roald.org> wrote:
Cory Nelson said:
Have you looked into AGG (http://www.antigrain.com)? It avoids use of the STL yes, but it's the highest quality graphics lib I've seen, and its license is less restrictive than the zlib/libpng license so there is no reason it couldn't be forked.
Thanks for the link, I was not aware of this one. Looks promising from first look at their web pages and the license. I will look into it when I get time.
Here is an interesting article about vector graphics with lots of links: http://dri.freedesktop.org/~jonsmirl/graphics.html I believe that industry standards like openGL and now openVG should be considered. Regards, Andreas
Andreas Pokorny wrote:
Thanks for the link, I was not aware of this one. Looks promising from first look at their web pages and the license. I will look into it when I get time.
Here is an interesting article about vector graphics with lots of links: http://dri.freedesktop.org/~jonsmirl/graphics.html
I believe that industry standards like openGL and now openVG should be considered.
Heh, speaking of industry standards, I think that chart library can be done much faster if it does not drawing at all, but writes SVG file. There are several SVG renderers (amount free C/C++: librsvg and KSVG), that produce nice antialised bitmaps. Trying to directly produce image would require either interfacing to some existing library, and the choice of library is tough, or writing a wrapper layer, which can be hard as well. - Volodya
On Mon, Sep 12, 2005 at 03:55:48PM +0400, Vladimir Prus <ghost@cs.msu.su> wrote:
Andreas Pokorny wrote:
Thanks for the link, I was not aware of this one. Looks promising from first look at their web pages and the license. I will look into it when I get time.
Here is an interesting article about vector graphics with lots of links: http://dri.freedesktop.org/~jonsmirl/graphics.html
I believe that industry standards like openGL and now openVG should be considered.
Heh, speaking of industry standards, I think that chart library can be done much faster if it does not drawing at all, but writes SVG file. There are several SVG renderers (amount free C/C++: librsvg and KSVG), that produce nice antialised bitmaps.
Trying to directly produce image would require either interfacing to some existing library, and the choice of library is tough, or writing a wrapper layer, which can be hard as well.
Oh no :)! If the chart problem gets solved that easy, who is then going to write a standard vector render library for c++ (or define a generic standard interface)? Regards, Andreas
participants (8)
-
Andreas Pokorny -
Andy Little -
Bjørn Roald -
Cory Nelson -
Jeff Garland -
Russell Hind -
Schrom, Brian T -
Vladimir Prus