GUADEC: A message from the release team

By Jake Edge
August 4, 2010

Instead of the talk he was planning to give on the first day of presentations at GUADEC, GNOME release manager Vincent Untz needed to shift gears to announce the biggest news of the conference: GNOME 3.0 would be delayed. The reason for the delay is simple, the code and documentation "weren't quite ready", so rather than have an "OK-ish" release, the team decided to push it back. There will still be a release in September, however, as the team is committed to the six-month release schedule, but it will be another in the 2.x series: 2.32.

Untz noted that GNOME 3 has a compelling story: "It's the first time since I started with GNOME that people are so excited about GNOME". GNOME 3 was first announced at GUADEC in 2008 with a target of making the 2.30 release (i.e. March 2010) be the first GNOME 3 release. In the interim, that was pushed back to September, and now to March 2011. The team has "quality as [its] first priority" and, after meeting with various teams in the first few days of GUADEC, it became clear that more time would be required for a solid release. "We want people to love GNOME and we want people to love GNOME 3", he said.

In addition to the 2.32 release, there will also be a GNOME 3 beta release in September. "We want people to start using it, start playing with it, application developers to port to GNOME 3". By March, "we want something that's really good", Untz said.

But that means developers and maintainers of GNOME modules will need to work on two branches for the next two months: one for 2.32 and one for 3.0. That dual-branch development mode made up most of the concerns expressed by audience members about the announcement. Some were worried that it would cause too much extra work, but Untz and the release team—who joined him on the stage—seemed to think it was manageable.

The release team will be taking steps to ease the transition, starting with getting GtkApplication backported to GTK+ 2, which will help modules that need to switch back from GTK+ 3. There will also be a flag (--enable-gtkN) available in the configuration process that will allow applications to be built for either GTK+.

Some maintainers will want to deliver new features in September and for those, the 2.32 and 3.0beta releases will be the same. Others may want to focus on 3.0 and will just release an update to 2.30 with bug fixes and the like. Separate from his talk, Untz said in email that each maintainer will decide how to handle it and the release team will assist: "we do not think it will be that much of a burden".

He also noted that GNOME's development model, by design, is focused on "evolution rather than revolution", and that 2.32 would fit that model well:

In addition to new features in the existing modules, we'll integrate gnome-color-manager and rygel. That means that GNOME 2.32 will be our first release to have integrated color management, as well as support for DLNA (UPnP AV) for a rich multimedia experience at home, with all the connected devices that people now have (TV, speakers, phones, video game consoles, etc.)

Certainly GNOME Shell is the most high-profile module that is still in need of work, but there are others as well. There are still a lot of applications that need migrate to GTK+ 3 and GSettings, for example. Updating the documentation for GNOME 3 still has a ways to go, "the new accessibility stack would get performance improvements that will make the switch to the new stack much smoother for users", the GTK+ engine for the art team's new theme is not quite ready, and so on:

Interestingly, most of those issues, when taken separately are not blockers per se. But the addition of all of them would have lead to a quality that is not up to our standards.

There are some other things the release team will be pushing, he said in his talk, including encouraging the maintainers to "target achievable goals". In particular, there will be something like a feature freeze for the GNOME Shell functionality so that they finish what they started and don't go off "making crazy plans". In addition, the release team will be trying to get the community to implement the UI mockups that the design team has created.

There has been some criticism of the GNOME 3 plans because of the lack of support for "applets", but Untz sees it differently. Most of the applets in use today are either things that will be incorporated into GNOME Shell or are some kind of monitoring tool (for system performance or email for example). There are also a few applets that are "dedicated to a specific task", like the Tomboy notes applet or the Hamster time-tracking applet, he said.

We don't believe that the system we have today with applets is the right approach: the size of applets is limiting the user interface, and the current number of existing applets probably show that applets are not an attractive way for developers to extend the desktop. In addition, a few applets are actually slowly moving to full applications (tomboy and hamster are good examples). This is why we won't add support for applets as we know them today.

There are plans to look at a system to replace applets some time after the GNOME 3 release, but it is not the team's highest priority at the moment. There are alternatives, though:

It's also worth mentioning here that the traditional GNOME 2 UI (with the GNOME Panel and applets) will still be available with GNOME 3, so people who have a need for a very specific applet will still be able to use the GNOME 2 UI for some time.

Overall, the announcement was met with general approval from the audience. The project wants to make a big splash with GNOME 3 and "OK-ish" is not the way to do that. There seems to be a clear focus on the things that need to be completed before there can be a solid release, so one gets the sense that we won't see further delays. For users who can't wait, there are plans to make the beta more easily available for various distributions, which should allow more testing and a better final release.

Index entries for this article
Conference	GUADEC/2010

Good

Posted Aug 5, 2010 4:19 UTC (Thu) by ncm (guest, #165) [Link] (20 responses)

It's encouraging to see sanity emerging in the Gnome team.

Here's hoping Gnome 3 won't force Nautilus on everyone just because "people find it useful". Recent Gnome 2 releases have made an effort in that direction, but you can still turn it off in Gconf by changing desktop/gnome/session/required_components_list to "[windowmanager,panel]". There was a trend to force the issue by shoveling random things like desktop background settings into Nautilus and out of Metacity or Gnome-session or wherever they're done now, but that seems to have subsided. Certain individuals have actually told me I should run Nautilus anyway, and just turn off all its visible features, if I don't like it. Loopy.

I wonder if the Emacs edit key bindings will finally be retired. They aren't supported in current Epiphany edit windows, the checkbox in the settings dialog was wiped out long ago, and the help text in Gconf suggesting how to enable it was scrubbed. I wonder what is supposed to be so awful about supporting control keys for editing.

It's disappointing to find them still talking about Mono programs like Tomboy. Weren't they planning to replace that with a regular program?

Good

Posted Aug 5, 2010 4:45 UTC (Thu) by brouhaha (subscriber, #1698) [Link] (7 responses)

I wonder who thinks losing Emacs edit bindings is a good thing, and why? I've been using them for years, and surely I must not be the only one.

While I understand the desire to simplify things for novice users, I don't like the direction of completely removing functionality used by advanced users.

Good

Posted Aug 5, 2010 9:15 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

Even the Mac supports C-a and C-e shortcuts, at least. Often it seems that 'making things simple' really means 'making them like Microsoft Windows'. But then, some useful shortcuts for refugees from the Windows world - like double-clicking a window in the top left to close it, or C-Esc to bring up the start menu - aren't added either.

In general, the principle of least surprise suggests that common keyboard shortcuts should be supported wherever possible. The exception is if they might often be typed by mistake. But Emacs keybindings aren't the kind of thing you can type by mistake.

Good

Posted Aug 5, 2010 18:55 UTC (Thu) by foom (subscriber, #14868) [Link]

Mac OS X can support emacs keybindings without a problem because it doesn't use the control key for shortcuts. The mac uses the command (or "Apple" key) as the shortcut modifier. That leaves control mostly unused, so there's no conflict by having it do emacs things in text boxes.

That logic doesn't apply to Linux, which instead uses a somewhat random combination of Alt/Meta and Control to invoke shortcuts in most apps.

Good

Posted Aug 6, 2010 9:33 UTC (Fri) by etienne (guest, #25256) [Link] (4 responses)

> I wonder who thinks losing Emacs edit bindings is a good thing, and why?

Initially, Microsoft.
It all started when they decided to replace the standard Shift-Delete/Shift-Insert for cut&paste by the much more intuitive Control-C/Control-V.
Not at all related to bother Windows users who try Unix.

Good

Posted Aug 6, 2010 15:25 UTC (Fri) by anselm (subscriber, #2796) [Link] (1 responses)

Actually, Microsoft pinched these shortcuts from Apple. In Apple's original (mid-1980s) Human Interface Guidelines, there is an explanation of the rationale behind the shortcuts. One must admit that »Control-C« for »copy« does make a certain amount of sense, while the wedge-shaped letter »V« in »Control-V« is supposed to suggest squeezing something in at some point, hence »paste«. Doesn't seem all that stupid, now does it – unless you're carrying lots of Unix baggage in your head, where »Control-C« means »kill the current process«.

Now Apple may or may not have come up with these by themselves or they may have in turn adopted the usage from the Xerox Star, which inspired the Macintosh GUI by way of the Apple LISA (I wouldn't know), but in this particular instance Microsoft doesn't appear to be the culprit.

Good

Posted Aug 6, 2010 19:18 UTC (Fri) by spitzak (guest, #4593) [Link]

The actual question is why did Microsoft (and the CDE) choose "Ctrl" rather than the "Alt" key to emulate the Apple settings.

Earlier precedence with MSDOS programs (and with X and Andrew) was that "alt+letter" was far more often used to trigger actions. Also the Alt key on the PC at that time was positioned in exactly the same place as the "command" key on a Macintosh. So it would seem a no-brainer to use the Alt key instead.

I have a few theories as to why ctrl was chosen but I don't really know:

1. CDE wanted to work on machines that did not have any extra key other than Ctrl.

2. Non-PC programs designed for serial terminals had to use ctrl+letter for shortcuts, so they may have thought they were being consistent with this (though they were wrong, as they failed to think of the terminal emulator itself as a program). This may also explain the unintuitive use of shift+insert/del to avoid the shortcut key for operations that were not supported by older terminals.

3. Microsoft wanted existing MSDOS programs to be easily ported to run in a window. Since most were using Alt+letter for shortcuts they used ctrl to avoid interfering.

4. Some foreign keyboards were using the Alt key for typing non-ASCII letters (though was this actually prevalent in 1986?)

If anybody has the real reason, it would be interesting.

Good

Posted Aug 9, 2010 9:08 UTC (Mon) by dgm (subscriber, #49227) [Link] (1 responses)

Personally, I really found the new combinations much better when Microsoft introduced them. I never managed to learn Shit+Delete, most of the time I wanted to copy (Ctrl+Insert), not cut, and Ctrl+C followed by Ctrl+V was so much easier than Ctrl+Insert followed by Shift+Insert.

Specially nice was that Cut (X), Copy (C) and Paste (V) are all together in the QWERTY keyboard, and all are enabled by the Ctrl key. By contrast, Shift+Del, Ctrl+Insert, Shit+Insert are simply more cumbersome.

And I think the exact think could be said about that Emacs and Vi key bindings too. They may be useful for the small part of the World that is the Emacs (and Vi) heavy user community, but bring nothing to the vast majority of us.

Good

Posted Aug 9, 2010 19:32 UTC (Mon) by brouhaha (subscriber, #1698) [Link]

I'm not at all suggesting that Windows-like (or Mac-like) key bindings should be removed. I'm just complaining that emacs-like bindings shouldn't be removed either. If there's an issue with them, then there should be a setting somewhere to select them.

Some of us have been using Emacs for longer than Windows has existed.

Good

Posted Aug 5, 2010 8:04 UTC (Thu) by Los__D (guest, #15263) [Link]

Weren't they planning to replace that with a regular program?

It IS a regular program

Good

Posted Aug 5, 2010 8:45 UTC (Thu) by jschrod (subscriber, #1646) [Link] (10 responses)

Why do you want to take Emacs key bindings away from us Emacs-using folks? What is your goal in alienating us?

On the one hand, you speak up against fewer choices (Nautilus) because you don't like it and it irks you.

On the other hand, you speak up for fewer choices (Emacs key bindings) because you don't care and have no use for it.

Very selfish, don't you think?

So, should I do like you, and speak up for forcing Nautilus on you and demanding Emacs key bindings for me, because I don't care about Nautilus, but care about Emacs key bindings? No, I won't do the same as you -- I'm for _your_ ability to not use Nautilus *and* _my_ ability to use Emacs keys. (And I don't need an UI to configure it, btw; gconftool is fine for me.)

Good

Posted Aug 5, 2010 9:33 UTC (Thu) by ncm (guest, #165) [Link] (9 responses)

Such confusion. I use Emacs key bindings myself, but I suppose Gnome 3 will eliminate them, and then I'll have to do without or switch to KDE.

By the way, for those who haven't discovered it yet, the way to add Emacs key bindings to Gnome programs that haven't eliminated the option yet is to go in Gconf to /desktop/gnome/interface/gtk_key_theme and type "Emacs" into the text box.

I don't understand why they're not on by default, in addition to Home/End/etc. buttons. Would it be so bad if somebody accidentally hit ctrl-A and their cursor moved?

Good

Posted Aug 5, 2010 9:46 UTC (Thu) by jschrod (subscriber, #1646) [Link]

Sorry, I really understood you as being for Emacs key binding removal. My apologies.

I blame it on not being a native English speaker. ;-)

Good

Posted Aug 5, 2010 9:50 UTC (Thu) by bronson (subscriber, #4806) [Link] (7 responses)

Yes. Ctrl-A on pretty much every platform means Select All.

Good

Posted Aug 5, 2010 11:45 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

And Select All is such a *useful* feature in an input line.

Good

Posted Aug 5, 2010 19:03 UTC (Thu) by foom (subscriber, #14868) [Link]

Yep, it sure is.

Good

Posted Aug 6, 2010 19:21 UTC (Fri) by spitzak (guest, #4593) [Link] (4 responses)

This is trivially fixed by making ^A select all if you are already at the start of a line, so typing it twice works.

Good

Posted Aug 10, 2010 9:25 UTC (Tue) by dgm (subscriber, #49227) [Link] (3 responses)

Why not do it the other way? Hit ^A once and you select all text, hit it twice and the cursor is moved to the beginning of the line. For extra fun, hit it again to remove the selection. More hits could bring other functionality too, or you can make it a cycle that starts over again.

Note to GNOME/GTK+ hackers: this post was supposed to be completely facetious, not a real suggestion. Please DO NOT DO THAT.

Good

Posted Aug 10, 2010 15:32 UTC (Tue) by spitzak (guest, #4593) [Link]

I suspect that you are just making a joke about my suggestion, but what you suggest would require remembering the cursor position while select-all is done, which most editors do not do (the cursor is one end of the selection). Also cyclic modes are a very bad idea, though they were popular with some older Unix editors, they are not user-friendly as the user has to watch to get them to stop, rather than just blindly hitting the key many times to get at the state they want (if it is the last state).

Good

Posted Aug 11, 2010 23:49 UTC (Wed) by nix (subscriber, #2304) [Link]

Sounds like you want the immortal gnxt.

Good

Posted Aug 13, 2010 12:34 UTC (Fri) by richdawe (subscriber, #33805) [Link]

That would be fun for people using screen's default key bindings, where Ctrl+A starts screen's special key sequences.

I've just about managed to reprogram my fingers to type Ctrl+A A to go to the start of the line instead of just Ctrl+A (in screen sessions).

Not a KDE 4.0

Posted Aug 5, 2010 11:04 UTC (Thu) by NAR (subscriber, #1313) [Link]

Seems like they've learned their lesson from the KDE 4.0 problems: don't release something as .0 if it's not ready for prime time.

GUADEC: A message from the release team

Posted Aug 5, 2010 13:03 UTC (Thu) by sorpigal (guest, #36106) [Link] (5 responses)

Lessons Microsoft can teach us that we still haven't learned: Platforms are important.

The problem with getting rid of applets isn't so much that applets are so useful as it is that stuff that worked in GNOME 2.x will just stop working in 3.x. Microsoft's 'platform' may be a maze of half-broken crap and shims for legacy support, but on the other hand everything that actually worked tends to stay working. So applets don't support some awesome GNOME Shell vision? So what! Grandfather them in, mark them as deprecated and move on. If it turns out that the new way really is superior people will port (in their own good time) and meanwhile everything compiles and users can still get to the functionality to which they have grown accustomed.

When a third party program that used to work in an old release doesn't work in a new release I call it a regression and I blame GNOME, not the third party.

GUADEC: A message from the release team

Posted Aug 5, 2010 15:24 UTC (Thu) by me@jasonclinton.com (subscriber, #52701) [Link] (3 responses)

> So applets don't support some awesome GNOME Shell vision? So what! Grandfather them in, mark them as deprecated and move on.

That is EXACTLY what the release team has done. Please actually read the article before commenting.

GUADEC: A message from the release team

Posted Aug 5, 2010 19:14 UTC (Thu) by foom (subscriber, #14868) [Link] (2 responses)

Not really...you have the choice of:
1) Complete old shell UI, including applet support.
2) New shell UI without support for applets.

Grandfathering them in and marking them as deprecated would be to add support for them to the new UI but discouraging their use.

GUADEC: A message from the release team

Posted Aug 6, 2010 7:51 UTC (Fri) by Darkmere (subscriber, #53695) [Link]

Actually, that is a mess to promote such lovely hacks as the Windows 7 auto-hiding icons as the "blessed" solution. Running programs in programs with the process model that panel applets have will not really be supported since that particular breed of COM-like objects are being discontinued.

Keeping the shim would mean that you would need to retain the whole thing indefinitely.

The good part however, is that your beloved and much needed classical panel will still be there, and will be what you have unless you have shiney 3D-like accelerated graphics on your computer. It will be maintained and supported.

GUADEC: A message from the release team

Posted Aug 6, 2010 17:01 UTC (Fri) by bkw1a (subscriber, #4101) [Link]

What I care about is whether old binaries, compiled under an older version of Gnome, will run without modification under the new Gnome. Is this the case?

GUADEC: A message from the release team

Posted Aug 9, 2010 9:18 UTC (Mon) by dgm (subscriber, #49227) [Link]

Excellent point.