Re: Adding foreign_new_xdisplay for Gdk X11
- From: Ricardo Cruz <rpmcruz clix pt>
- To: Owen Taylor <otaylor redhat com>, gtk-devel-list gnome org
- Cc: Federico Mena Quintero <federico ximian com>, michael meeks novell com
- Subject: Re: Adding foreign_new_xdisplay for Gdk X11
- Date: Tue, 3 Apr 2007 17:42:03 +0100
Owen Taylor wrote (@ Saturday, 31 de March de 2007 17:12):
> On Fri, 2007-03-16 at 19:16 +0000, Ricardo Cruz wrote:
> > 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:
>
> [...]
Nice plan. Btw, I have been pointed to this project:
Metatheme: http://www.metatheme.org/
It's a pretty big architecture that includes their own style engine that gets
loaded by the toolkits using a wrapper style, together with a drawing vtable.
So, I guess it goes something like this: GtkStyle -> Gtk wrapper style ->
Meta engine -> Meta custom style -> Meta engine -> GDK/Cairo. And so on for
KDE/Qt and Java's Swing, which they also support. The drawing stuff seems to
be built in the Meta engine, it probably would be better to be a plugin like
the custom styles because now you need to recompile the all engine to install
a new backend.
Anyway, it's not very robust and seems to have required a lot of effort to
get where it is now (and it's visible it still needs more work). Something
simpler like you say would likely be better. But it would also be more
complex in the sense that you would need to have a thought through API with
quite some granularity to fit Windows/Mac style engines nicely. (If I
understood you correctly, you mean such a project should aim to be a
replacement of GtkStyle itself.)
It would be nice if you could tell your ideas over their mailing list...
(already registered there)
> 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.
>
I agree it's just a work around and obviously neither project benefits from
it. But the user does and it doesn't require a lot of effort to do, so if
that new function could be added, it would be great.
Cheers,
Ricardo
> - Owen
--
Fights between cats and dogs are prohibited by statute in Barber, North
Carolina.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]