Gtk+ 3.0 Theming API Hackfest

It’s now official, a bunch of Gtk+ hackers are gathering together from the 16th to the 20th to bring some bling to Gtk+ 3.0.

Carlos Garnacho, Hagen Schink, Benjamin Berg, Cody Russell, Thomas Wood, Robert Staudinger and myself. I would like to thank Imendio, Canonical, Intel for helping on putting together his great team and a special thanks to my employer Sun Microsystems for supporting me on the organization and providing the venue for everyone.

We also wanted to make sure that we involved third party integrators so that we make the transition to the new API as easy as possible for them.
Nokia is sending Jens Bache-Wiig, from Qt Software, the guy behind QGtkStyle and Mozilla is sending Michael Ventnor the guy behind the Gtk+/GNOME integration with Firefox 3.x.
Big thanks for both companies for their support.

We want to remove all the boundaries artists have while creating themes, ease the live of widget developers that want themeable widgets, we want more powerful engines that are easier to write and maintain, a better look and feel integration with other toolkits and desktops and an API that allows other toolkits to look tightly integrated with Gtk+ and the GNOME desktop. All in one shot!

Quite a huge task, we are gonna need the help and support of everyone in the community to make this happen, once we got some working code out we intend to have public DVCS branches that people can try out so stay tuned.

Advertisements

27 thoughts on “Gtk+ 3.0 Theming API Hackfest

  1. You mean GTK will actually get a real drawing API and the lives of integrators won’t suck?
    Wow, congratulations! I was wondering when GTK would start transitioning to a real toolkit.
    Goodbye, pre-multiplied alpha channel and two-pass widget rendering.

    Like

  2. Yeah!!! Great job Alberto. I’m pretty sure this is going to be awesome.
    I can’t wait either for the Gtk+ 3.0!!!
    And I’m really glad wth the collaborations. People from different projects working together is more common each day… That’s so great! 🙂
    We’ll be waiting for news 😉
    Good luck and happy hacking!

    Like

  3. Are you going to be considering WM themes? Metacity has quite an interesting challenge ahead with v3 of the theme format coming out within the next year or so, including a possible change to SVG.
    (Maybe I should have asked to come to this– I hadn’t heard about it until today.)

    Like

  4. @Alberto:
    It’s possible it’s not going to touch on Metacity’s theming at all, and if so it’d hardly be useful for me to be there. I must have missed the earlier posts, but that’s my fault.

    Like

  5. Well, good to hear you are going to ease our lives (GTK themes/engine designers/coders) a little. The thing I hate most about the current setup is that we engine writers have to figure out many of the theming internals ourselves, the good thing is, that when you know how it works, you can do pretty anything…
    I hope you preserve the freeness we have and improve the docs in this area as well 😉

    Like

  6. This is definitely great to hear 🙂
    Being a bit of an outsider, I’ve only heard a rough sketch of the future look and feel… mostly cleanup, merging in of toolkits like clutter, gnome mobile, canonicals UI experiments, etc.,…
    Can building theming infrastructure precede usability and look-and-feel studies that might evolve user interaction?
    or is it that you guys have a pretty good idea of the architecture being implemented, and will build that under the assumption it will enable the visions of the future interfaces?
    (I’m sure you guys know more of what’s going on than me, hence my question)

    Like

  7. @Jeff:
    Thanks a lot dude.
    @Craig:
    Don’t expect magical things at the beginning, this is just the setup to have a clean start on 3.0.
    The idea is that 3.0 will get rid of all the deprecated code, to be able to move on and don’t have to care for backwards compatibility for once. And we will take that chance to improve the mess that the internal Gtk+ theming API is at the moment.

    Like

  8. If this is sorted out it would be great news. I currently have a large project with many widgets that are not derivative of anything from the base GTK though I have my own variations. i.e. GtkButton -> CaButton for instance.
    I can assign my own CaButton a GtkButton style (in a round about way) and it will render it pretty much correctly. The rub comes when you use different theme engines aside from the default. There are quite a few engines which have something similiar to g_assert(GTK_IS_BUTTON(widget)); in the render code which effectively breaks the drawing of my widget. GtkWimp is a windows example; though I submitted a patch for this a while back. I’ve had reports that QtCurve also acts strangely though I have not tried this out myself. thanks

    Like

  9. I wonder how you are going to solve the problem of custom widgets with unknown theme engines. Drawing primitives doesn’t seem to work, so I’m very curious with what kind of solution you’ll come back. 😀 Have fun!

    Like

  10. “we want more powerful engines that are easier to write and maintain, a better look and feel integration with other toolkits and desktops ”
    Wait does it mean we can get a KDE file dialog/print dialog inside GTK+ aps ? GTK+ really sucks in integrating with anything beside GNOME and Xfce.

    Like

  11. @val-gaav:
    That’s not theming. File a bug if you think that a native file dialog should be shown when you are running a KDE session. But I guess it should be the KDE people the ones that solve that issue.
    I will discuss that with Jens though.

    Like

  12. AFAIK with Qt 4.5 GNOME will get the native file dialog in Qt apps
    http://labs.trolltech.com/blogs/2008/10/01/native-file-dialogs-in-gnome/
    I don’t want to speak for KDE guys, but I think they are also in opinion it should be done in GTK+ . There is a terrible hack called kgtk for the file dialogs but it often just does not work.
    Would be really great if both sides integreted better with each other. Running a pure Qt based install or a pure GTK+ install is really hard because there is a bunch of good apps on both sides.

    Like

  13. The GTK dialogs suck big time with anything. And they are like that for a year at least. Hopeless how Firefox (which is otherwise fine browser), asks me each time how to open a file, for which there are valid freedesktop bindings. Then starts to search for programs in ~/… instead of say /usr/bin/. Then when I finally try to point it to /usr/bin the damn completion gets in a way and I get /usr// (damn), /usr/binin (damn) /usr/bin/ktorrentrrent (damn), /usr/bin/ktorrent. What people write so slow that it’s actually helpful?

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s