On Fri, 2007-03-16 at 19:16 +0000, Ricardo Cruz wrote: [...] > > > So, can't we just have some function to wrap a Display connection to a > > > GdkDisplay whose only purposes is to send drawing commands. This surely > > > reduces the already small usefulness of it, but think about the style > > > wrappers like that of OpenOffice, who do all their work offscreen and > > > then clutter the connection to the server with it. Pretty inefficient. > > > > Really, all this Qt-theme-for-GTK+ GTK+-theme-for-Qt stuff is just a > > horrendously bad idea. A vale of tears. What needs to be done is to > > write a toolkit-independent theme engine system, hopefully less baroque, > > strange, and broken then what we ended up for GTK+, and write themes > > for that. > > > Yeah, I had the same thought, and I feel the same way regarding Qt and GTK+ > style framework and have some ideas on how they could be better... The > problem is that you would have to also come up with a graphics drawing API. > > Maybe not a big issue, but it adds up. We would need to be responsive to > people, fixing what they dislike and make sure what they dislike, etc, and > feel the framework is well supported, so we can get them to do styles for it. > I can't afford the time for that. > > But in fact, as a sub project, I have shaped Qt style framework to a much > easier to write styles for. If people started using it and working on it, it > would benefit the project, and them. And a style written for it would be much > easier to port than an ordinary one. > ( http://gtk4qt.sourceforge.net/qsimplestyle/ ) > Something like that could eventually turned in what you say (make a Cairo > backend for QPainter and more of such). > > > If written to exposing draiwng as pure drawing to a good graphics > > API (cairo, specifically) it would also get rid of a lot of really > > horrible things that the Mozilla folks are doing in the cairo > > versions of Firefox. > > > I guess we could write a Cairo backend for QPainter and so on. But I am sure > the KDE style authors won't like the idea, to say the least. If we do the > opposite (Qt4 supports for such), GTK+ people wouldn't like it either (would > you? :)). The question really isn't the theme designers ... if you want to design an artist-friendly theme system then it can't involve writing C/C++ code. But the question is what interface do you have between the toolkit and the implementation of a common theme system: - Pass Xlib drawables: doesn't support offscreen drawing, printing, etc, etc. - Design your own drawing vtable. Bad idea. - Use QPainter. QPainter wasn't designed to be used outside the context of the Qt library, AFAIK. - Use cairo. Cairo intentionally has a very small set of external dependencies. (fontconfig, libpng, zlib) and was designed for such usage. Now, if you had a cairo-based theme system, how would using it within Qt work: - Drawing to an Xlib drawable: no problem at all. (Just wrap the drawable in a cairo xlib surface) - Drawing to an offscreen image: not much of a problem; just wrap the image in a cairo image surface (assuming compatible formats) - Drawing to a printer; the combination of Qt => QPainter => ps Qt => Theme System => cairo => ps Doesn't work, so you'd have to do: Qt => QPainter => cairo => ps Qt => Theme System => cairo => ps The latter is a perfectly *reasonable* setup to have; QPainter could be backended off of cairo just as it is off of other drawing systems. But cairo probably isn't quite there for performance/features to make it *compelling*. (You could do it printing-only and escape most of the performance issue.) Well, of course, the other thing you could do would be to write a QPainter backend for cairo, and do: Qt => Theme => cairo => QPainter => ps But cairo doesn't publicly export the backend API, and is unlikely to do so in the near-term future. In any case, the situation is far better than trying to use GTK+ within a Qt program! I don't see GTK+ <=> Qt bridging of theme systems as making progress. - Owen
Attachment:
signature.asc
Description: This is a digitally signed message part