Gtk+ 3.0

by Miguel de Icaza

The Gtk+ 3.0 proposal being discussed currently sounds like a disaster for GNOME. The reasoning was first articulated in the histrionic Imendio Gtk+ 3.0 Vision presentation done at the Gtk+ Hackfest in Berlin. This is a meeting where application developers were underrepresented, and somehow we have accepted those proposals as the community consensus.

The proposal goes like this: Gtk+ 3.0 will hide all public fields in objects, provide accessors to these, remove APIs that have been flagged as deprecated and introduce no new features.

All the actual new features that some people want would come up in future versions. Which features will come is yet to be decided, because nobody knows when and what will be implemented.

There are lots of technical problems with the proposal, and from my discussions this week at GUADEC it does not seem that the Gtk+ developers have discussed the implications with the users of Gtk+.

There is a major strategic problem with the plan as well. The most important one is that there is no actual plan for which features will be added, and when these features will be added. There are no prototype implementations, and the idea of first developing the new features in a branch to actually study the code, the implementation and its potential APi breakage is not even on the agenda.

Basically, we are being told that we should trust that first breaking the API and hiding fields will suddenly enable a whole generation of new features to be implemented.

But it gets better. There are no guarantees that 3.x will not break the API if the feature in question turns out to require API breakage. Which means that we might actually end up in a situation where there will be multiple API breakages.

This by all means sounds like a bad plan.

Towards a Better Plan for Gtk+ 3.0

I am not against breaking the API for newer versions of Gtk+ if the benefits outweigh the downsides, and the execution presented is not bad. But "3.0 will help us clean up" is not a good enough reason.

We need:

  • A Clear Roadmap: We need a clear roadmap of which features will be implemented and when they will be implemented. This is the first step to making decisions.
    A clear roadmap would also allow new developers to join the efforts and big companies like Red Hat and Novell to dedicate some full time resources to make some of these feature happen. As things stand today, we are basically being told to "wait-until-3.0-then-we-will-sort-it-out".
  • Working Code: Before a feature for a future version of Gtk+ can be considered a reason to break the API, the technology must exist in the form of a patch/branch.
    This is not new, and should be of no surprise to anyone. This is how the Cairo integration into Gtk+ was done, how the layout changes are being implemented and how every other software product is ran.
  • New API-breaking features must be publicly discussed with the community: Since this will affect every application developer (open source and proprietary) we should get the feedbacks of these communities.
    We could all get as excited as we want about a "gboolean bouncing_text" field in a GtkLabel, but that does not mean that we should break the API for the sake of it.
    Application developers were underrepresented at the Berlin hackfest, and even GUADEC is a microcosm of the ISVs that we had to reach. For instance, I did not see anyone from Adobe, VMware or Medsphere at the conference.
  • Transitional 2.x Releases: For a long-enough period to get distributions to include the code, Gtk+ 2.x should include getter/setter macros to allow software developers to upgrade their source code to work with and without the public fields. To soft-land the switch to a hiding-field Gtk release (this is covered in the Imendio proposal).

This is by no means a comprehensive plan, it is only the beginning of a plan.

Lets please avoid inflicting in GNOME a KDE 4.0 (yes, I know its not the exact same scenario; and yes, I know those clock applets are cute).

Gtk+ Extensions

From looking at the original Imendio proposal. it seems that plenty of the things they want can be implemented without breaking the API:

  • Animation: doable entirely without breaking the API. The animation/storyboard framework is an entirely new codebase, that would not touch anything in Gtk+. Some widgets might require smoother rendering on changes, but all can be done in an API-compatible framework. public API.
  • Physics: same, add-on.
  • Data-binding: same, add-on.
  • Easier language bindings: same, add-on.
  • Improved back-ends, more OS integration: Can not think of a major issue, but granted, I could be missing something, and Imendio has done the OSX port.

And my own favorite: killing all Gtk+ theme engines, and replacing it with a Qt-like CSS theme engine. This is not really an API break, as the only consumers of this code are the theme engines, and those we can safely kill and replace with CSS themes, no application code would break.

Maybe Havoc's proposal requires an API breaking change. And maybe this is worth breaking the API for. But breaking it for no gain, and no prototype to even understand the actual effects post 3.0 is wrong.

Update: For what its worth, I would lean towards breaking compatibility in 3.0 if it meant 3.0 would include the Havoc-like Scene system. That would make it worthier of a change.

Update: As usual, the Linux Hater Blog has some great commentary. Some of his feedback on KDE 4.0 applies to our own decision making. Worth a read.

Posted on 14 Jul 2008


by Miguel de Icaza

Thanks to Behdad and the organizers at GUADEC, I will be having a BOF/discussion session tomorrow at 4:30pm to discuss a new class of applications built on Silverlight or Flash and how they relate to the future of the Linux Desktop.

Some of the ideas are clearly derived from Alex and Chris thinking about the desktop; it is heavily influenced by our work on Moonlight; by the recent strides that Adobe has made on creating great looking applications on the web (Buzzword and Photoshop Express) and the future of Gnome.

Join me tomorrow for a discussion on how to launch an effort to create an open-source, RIA-based desktop applications.

I am very excited.

Posted on 08 Jul 2008

Guadec/Istanbul; Rich Desktop Applications.

by Miguel de Icaza

Next week I will be attending the GNOME Developer Conference in Istanbul.

Looking forward to meet old friends and looking forward to discuss with people the future of rich applications.

BOF: Does anyone know how to apply for a last-minute BOF?

If there is some free presentation slot, I would like to hold an informal BOF to discuss these ideas.

Posted on 04 Jul 2008

Aaron and Banshee

by Miguel de Icaza

Today I walked into Aaron's office unannounced and I just saw him glowing. Like a girl that has been kissed for the first time, like a donkey in the spring.

A voice in the background was narrating Banshee features, and I was wondering just what is that noise?

As I went around to his monitor to see what he was watching and listening to, I saw this review on Banshee that included a screencast/podcast.

He was *so* excited that he was actually watching it in three computers at once.

I could not believe it.

Three computers at once. One, two and three. All playing the podcast. At the same time.

I was speechless.

From economic mastermind to flattered developer.

He said to me: "I have never seen a production of such caliber" as he listened to the background music in the above podcast.

I just stood there quietly. Unsuspectingly recovering the Twix office supply.

Posted on 03 Jul 2008

Moonlight 0.7 Installers

by Miguel de Icaza

Yesterday I forgot to point to the actual page to install the Moonlight plugins.

You can download the latest plugin from here. Just like the last release, these plugins are compiled without ffmpeg support.

The source code is available here.

You can track the progress and try out a few applications yourself from our Moonlight Status page.

Posted on 03 Jul 2008

Moonlight 0.7 is now Available

by Miguel de Icaza

A new release of Moonlight is now available. The team has been working very hard on improving the performance of Moonlight as well as improving our compatibility with Microsoft's Silverlight.

Get your copy here. Source code is moon-0.7.tar.bz2.

This release will also work with both Firefox 2.0 and Firefox 3.0. We have also switched our installation system to use signed XPIs, but we will also require a browser restart (we could not figure out a way of avoiding this).

Some of my favorite work that happened on this cycle is the effort to improve our multi-browser support, work towards supporting WebKit and Opera is underway and will improve over time. This work benefitted from our own work to support both Firefox 2.0 and 3.0 in the plugin.

Windowless mode (the mode that allows blending of HTML content and Silverlight content) is vastly improved but is only available on Firefox 3.0. This is a feature that is used extensively by Silverlight designers.

More details from the release:

  • Webkit loads the plugin (kangaroo, lewing)
  • The stream/downloader/request/response logic (used for downloading media) has been been almost entirely moved from the browser bridges into libmoon, with the browsers providing subclasses. (kangaroo, sde)
  • Finally add argument checking to all wrapped plugin objects (fejj).
  • Windowless mode fixes (lewing, toshok)
  • Plugin event handling fixes (lewing)
  • Engine
    • Many clock/animation framework fixes. We now pass both animation matrix tests, and many, *many* other bugs (and regressions) have been fixed. (mdk).
    • Bug fixes in the Stroke{Collection}.HitTest and Stroke{Collection}.Bounds code (toshok, sde).
    • Namescope merging fixes (sde, jackson)
    • Parser fixes, and changes paving the way for 2.0 work (jackson)
    • Fix mouse event bubbling behavior (toshok)
  • Media
    • Big, big strides in our media framework and the various (file, http, mms) downloaders, (fejj, rolf, kangaroo, fer)
    • MMS stream selection (kangaroo)
  • Performance
    • Shape caching and bounds computation reduction (spouliot)
    • Geometry bounds work (spouliot)
    • Fast path for position updates (Canvas.Left/Canvas.Top) (toshok)
    • Improved temporary cairo surface bounds (lewing)
    • Glyph rendering speedups (fejj)
    • Resort by ZIndex as a dirty pass (toshok)
  • Silverlight 2.0
    • work is progressing. A very simple 2.0 application successfully ran. (miguel, jackson, sde).
  • Posted on 02 Jul 2008

    Hanging out at Microsoft

    by Miguel de Icaza

    I will be at Microsoft on Thursday and Friday, and only have meetings on Thursday afternoon.

    I would love to meet other hackers. If you want to meet, discuss, talk, drop me an email:

    Posted on 18 Jun 2008

    oh. hai.

    by Miguel de Icaza

    People at the office became LOLcat fans by reading every day i can has cheezburger a few months ago. It was harmless entertainment.

    But recently I have discovered that LOLspeak has started to creep into our codebase.

    Consider the IHasSourceView interface or the ActiveSourceCanHasBrowser property.

    What other naming conventions should we adopt?


    Posted on 17 Jun 2008

    Office Justice, at Last!

    by Miguel de Icaza

    For the past few weeks, since Aaron Bockover found out that some of us like Twix. He then bought all the 70 cent twixes in the vending machine at the office and started reselling them for a dollar.

    Michael struck back by bringing fruits and vegetables today. To which Aaron replied "I hope those fruits rot".

    Today the machine was refilled:

    This has brought finally an end to the empire of speculation from this rapacious market meddler. With at least 12 new twix bars injected into the local office economy we should enjoy a smooth sailing for the rest of the week.

    Update: Some sources inform me that Aaron was trying to create an artificial scarcity in the office by buying the remaining 12 twixes, he hit a glitch in the machine, he got two bars for the price of one.

    This is not bodding well for the local Twix aficionados:

    Update 2: Capitalism knows no limits:

    Update 3: To add insult to injury, he is now selling individual Twix bars for 70 cents each, or a full pack for 1 dollar.

    Update 4: We will be picketing Aaron's office at 4pm this afternoon:

    Posted on 17 Jun 2008

    LinuxHater's blog, I am a fan

    by Miguel de Icaza

    I love the LinuxHater's Blog. This is a must-read RSS feed.

    It is funny in a way that xkcd is funny to Unixers. Whoever is writing that blog has extensive experience on Linux and enviable writing skills.

    A first class grilling/roasting of Linux and the Linux community. It should help keep things in perspective.

    Some good starting points:

    Posted on 12 Jun 2008

    « Newer entries | Older entries »