GNOME Bugzilla – Bug 515600
Implement new GtkCairoStyle API to support cairo
Last modified: 2010-12-22 23:33:53 UTC
As mentioned at http://live.gnome.org/GtkCairoIntegration: "Gtk+ themes need to support Cairo surfaces so that e.g. insensitivity can be rendered without workarounds (e.g. insensitivity for a TreeView cellrenderer rendering Cairo image surfaces)". My idea would be to ceate a subclass of GtkStyle (e.g. GtkCairoStyle) which would define a new Interface for cairo-only based themes, which would allow to render to any cairo-based surface and introduce support for adanced rendering like antialiasing, rotation, alpha-painting, ... I would prefer not supporting older themes (because I would not count themes as application API/ABI because the interact deeper with GTK+ internals). This would mean if GTK+ > 2.x is installed that a new theme is provided. Furthermore it would lead to a much higher porting-rate of old and new themes. If this is not acceptable a function could be defined which would allow to query wether a cairo-theme is used or not - leading to duplicate codepaths in GTK+ and all gtk-themed apps that would like to use new Cairo features. What I've done so far: * Implemented a mock-up of the GtkCairoStyle class (thanks a lot to Kalle) * Cairo-fied all draw_xyz in GtkStyle (the GTK default theme) except draw_string and draw_layout. What needs to be done: * Define API for the new GtkCairoStyle class. Would need expert opinions ;) * Implement further APIs from GtkStyle into GtkCairoStyle which need to be cairo-fied. lg Clemens
Themes like Mozilla (beside java) also faces some problems with GtkStyle: https://bugzilla.mozilla.org/show_bug.cgi?id=405421
Created attachment 105738 [details] The initial work done to port GtkStyle to Cairo
It would be great if "we" could compile a list of the largest misconceptions/problems the current theming API has for non-gtk applications. I am only experienced with how Java uses GtkStyle, and those problems could be fixed by: - Render to cairo_t only What were the largest problems with mozilla? What I've read one problem was that there is no way to tell the theming-engine to not fill the background, right? Where would a fill_background parameter make sence?
(Randomly found this bug while I was looking at the OpenJDK Innovators) Have you posted on gtk-devel-list about this?
Hi Colin! Yes, I posted at gtk-devel about this, and one guy helped me a lot at the beginning (Kalle), but later when I was done with the initial port I did not get any feedback. The bug itself is still unconfirmed 2 months later. Maybe you could post about it, because it seems I am largly ignored :-/ Clemens
I did everything I could, worked hard but in the end I did not even find somebody looking into my code. I did not even get a response to the bug report. I asked on IRC, on the mailing list and even on the bug-reporter - nobody told me it was nonsence I was doing, or I should not care or whatever. So yes, I am angry and that rant is personal in nature of course. ... wait ... it seems there is just nobody there. QT has a clean design, its really object oriented (instead of writing 5 functions and 2 struct entries just to get the OO stuff done) and its *activly worked on*, whereas GTK's development seems to be focused on bug-fixing by developers paid by distributions. It basically seems to be unmaintained. After all, this shows why GTK is a load of ...., GTK2 was supposed to be a cleanup but when looking at the code I get bloody eyes. I also blame GTK and the development model it brought to Gnome for the low productivity of Gnome developers. Have you every compared Gnome applications with their KDE counterparts? I almost every case the KDE app has more features, looks more professional and took less time and less manpower to develop. GTK and its G-"Object" based design lead Miguel to create Mono ... oh ... or maybe it was just the wish to create another important project.
Dude, stop whining.
I handed in two different patches and never even got an opinion about them. I asked in a polite way for review on the list, on IRC and for this patch even in the bug tracker and nobody had a look at it. Not even "hey, this is crap, we don't need it" - just nothing. To me it looks like GTK+ is quite dead.
Clemens, I just took a look at the code. First let me point out that while I understand your frustration, this not how things should be solved, so try to hold your angry thoughts next time. This is how opensource community works, it has its drawbacks, code can get unreviwed and things might not go as nice as we all wished, but on the other hand people get the opportunity. Next time, if you are really willing to propose code, try to poke the gkt+ maintainers on IRC and send a few more emails with your progress, and do some noise about it. I've been on the gtk-devel list for quite some time now and I totally missed your email, when did you send it? What was the subject? Now, the problem you are trying to address is much deeper than just covering the current API with a thin cairo wrap. There is a whole load of stuff to adress to get the new API right, in two weeks there's going to be a hackfest at Dublin to discuss the whole situation, I've sent a few mails about this hackfest and posted a call for participation on my blog for anyone interested in participate. After the hackfest we will publish some of our work on public branches and ask for feedback and contributions, feel free to catch up there and help us to solve the whole problem for Gtk+ 3.0.
There was quite a load of mails back in Februar 2008, as well as in July 2006 when I tried to optimize GTK's double buffering a bit. I was/am not angry because my code was not taken two times, but rather because nobody took even notice. GTK is talking about recruting new people because the few core-hackers can't keep up fixing the load of bugs, but in reality nothing has happend. I've contributed to many different projects, but I've never been not noticed at all ;) Glad to know there is progress, a new theming API will definitivly help all the non-GTK applications like Java to get things done right. I will maybe send comments and small patches when converting Java to the new API, but personally I will focus on QT as soon as its LGPL.
Call it Swing, please =) There's SWT which integrates much better with native widgets, Qt has Java bindings, and I myself work on one of the two Java-GTK bindings. -- Colin, realizing this is hopeless but trying anyways
I think GtkStyleContext mostly addresses the issues here.
Great to see some movement in this area, however I feel sad that I did all the work for nothing, with nobody ever willing to review it.