[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: Adding foreign_new_xdisplay for Gdk X11
From: Owen Taylor <otaylor () redhat ! com>
Date: 2007-03-31 15:11:11
Message-ID: 1175357577.2518.81.camel () localhost ! localdomain
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
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
["signature.asc" (application/pgp-signature)]
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic