On Wed, 11 Jan 2012 22:08:45 +0100, Pier Luigi wrote: > Have you ever eard of the Haiku Vector Icon Format [*]? Seems best > suited for icons than SVG.
No, but something like this would be fine. But the main issue is, that Qt doesn't offer a scalable paint device like a QImage - what we have today is QPicture or the combination of QSvgGenerator/QSvgRenderer. For a plot library - like my open source project Qwt ( http://qwt.sf.net ) - generating PDF documents is one of its key features. As PDF is a vector graphic format and the user wants to zoom in to analyze details in the PDF viewer, Qwt can't rasterize graphics ( f.e crosses marking the positions of a scatter plot ) like it does it on screen. The problem here is not about loading icons from files - it is more about having comfortable class APIs. Qwt is a library and many graphics might be defined on the application side. The solution today is, that Qwt needs to call application code through virtual methods, what sometimes leads to nasty dependencies between unrelated classes. It would be easier when the application paints its graphics to some scalable image class and passes it to the Qwt library - like everyone wants to pass a pixmap to a button instead of subclassing each button only for overloading some sort of drawButtonLabel method. That's why I started to implement a trivial paint device for Qwt 6.1, that records graphic primitives ( as QPainterPath ) and state changes in memory. But of course I'm not happy to have such a class in a plot library and I would love to throw it away, when Qt comes up with something better. Uwe _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
