This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex] 

This document is a roadmap for GNOME Shell development for the GNOME 2.30 to GNOME 3.0 development cycle. Once finalized, it is intended to be a static document; ongoing tracking of particular work items will occur separately, primarily in Bugzilla. Please coordinate changes to this document other than "bug fixes" with OwenTaylor.

The rough period covered here is from the release of GNOME 2.30 on March 29 to the hard GNOME 3.0 code freeze on September 13. See TwoPointThirtyone for the exact schedule.

Listed after the general writeups of each area are tasks that need to be done in that area. Some of the tasks are tagged as [SOC] for things that would make good summer of code projects. (Other gnome-shell projects can be found on the Summer of Code pages. And feel free to talk to us about taking other parts of this as a SOC project.)

Performance

Performance is one of the primary determinants of whether people will like the shell or not like the shell. If the shell is unresponsive and chunky, then no matter how much functionality is there and how pretty it is statically, people will get a bad impression of it.

Getting quantifiable numbers for performance is a prerequisite for all other work on performance - it's necessary to be able to evaluate patches, and to track down performance regressions that occur over time. Quantifiable numbers for the shell would include startup time, frame rate with a constantly animating application, time to go into the overview, time to open the Applications and Documents more (both cold cache and warm cache.) It would also include memory usage, both initially and after defined amounts of activity.

Once we have quantifiable numbers, we need to be able to chart these numbers over time. To be able to see what commits to gnome-shell cause performance regressions, and to track our performance against goals. And we'd like to have these numbers charted on a range of representative hardware.

Another chunk of performance work in the shell is to track down and eliminate all disk IO that occurs in the main thread - any blocking disk IO that occurs in the same thread as the redraw loop will cause the system to be unresponsive under heavy IO load.

App Integration

GNOME Shell is not a standalone program, it integrates closely with other desktop components, and it also integrates with applications. Fleshing out the exact ways in which applications integrate with the shell is a major theme of this development cycle.

Some of these areas of integration are: the application menu - each application is supposed to be able to make items that are global to the application available in a drop down from the application name in the top panel. Jump lists: we want to make it possible for applications to offer other options than currently open windows from the icon in the application well, whether they are running or not. Notifications: while the message tray primarily works with the existing notification specification, we need to specify more exact guidelines about when applications should notify and what they should include in their notifications. And finally, we want to make it possible for applications to offer extended user interface from the status area - for example, a twitter client like Gwibber should make it possible to post a message directly from the icon in the status area.

Appearance

Considerable work needs to be done to make GNOME Shell attractive.

Mutter needs some changes (already prototyped) to be more flexible in themes and window controls, so we can implement current theme mockups and also future theme work. Work also has to be done on the Mutter shadow code so that we can use bigger shadows and configurable shadows - the current code tends to show artifacts when more aggressive shadows are used.

There is a continuing process of making GNOME Shell conform to the visual mockups; as the GNOME art community gets more involved with the shell and refines the appearance, this will become an even more active area.

Accessibility

Accessibility has traditionally been a strong component of the message of the GNOME project. Since GNOME Shell is replacing existing components of the desktop and also running with a new toolkit, considerable effort will be needed to even maintain the status quo, much less to improve the experience from the existing level.

The work can be basically broken down into three areas:

The first area is keyboard access; because of the search orientation of the shell a lot of functionality is currently available from the keyboard, but there is no comprehensive way of navigating the shell by keyboard or to provide keyboard alternatives to all mouse actions.

A second area is exporting the user interface tree to be used by screen readers and similar; the subcomponents of this are figuring out how to hook in ATK (work has been done with this in the context of ca11y) and then how to export appropriate roles and actions for all the controls in the shell.

A final area is magnification - as the desktop compositor, magnification naturally lives in the shell process. Considerable work has been done on on implementing magnification within the shell and exporting it over D-Bus, but it still needs to be reviewed and integrated into the shell code base.

Window management

The move of the shell to be more centered around applications rather than windows has lots of cascading consequences for the details of how window management should occur: for example, when alt-Tab'ing to a window, we may want to raise all the windows of that application as a group.

Further refinement is needed for multiple monitor support; some of the idea in the current design document are slightly ambitious, like making workspaces only apply to the primary monitor, but some immediate fixes are needed well: we should show a window overview on each monitor to avoid cramming multiple monitors of windows onto the primary monitor, and we should make sure that the primary monitor is correctly identified, since behavior with a wrong primary monitor is unacceptable. (This latter is more of a GNOME and GTK+ work item than a GNOME Shell work item.)

And a small feature we want to implement is easy side-by-side tiling of windows. (probably by dragging windows to the side of the screen.)

Finding Documents and other Items

Probably the biggest weak point in the shell interface right now is getting to objects that the user cares about other than applications. The "Places" and "Recent Items" section of the dash show a very large number of more or less relevant items at a very small size. The browser mode for recent items is pretty much just a placeholder. Plans for a replacement are still under development, but they will likely involve combining "Places" and "Recent" items together, and unifying the idea of "Places" and "favorit items" with the concept of the current GNOME desktop.

Search integration may also need attention. It's not clear at this point whether Tracker is mature enough to be a standard part of GNOME 3 - there's been a lot of work put into it, and at times its performance is impressively good. On the other hand, when reindexing it can make some systems pretty much unusable. But if Tracker is a standard or common optional part of GNOME, we should integrate it into search in the shell.

Finding Applications

The current application browser is very simple - just a flat grid of applications. We don't want application browsing to be complex, but since the current browser doesn't scale to the number of applications found on many Linux user's systems, we'll need some enhancements here. These likely will be based with and aligned with the file browsing enhancements.

The time to open the application browser also appears to be unacceptable currently - we can't synchronously read hundreds of files from /usr/share/applications at the point that the user clicks on applications more and expect that to get done in a fraction of a second.

Message tray

The slide-in message tray at the bottom of the screen is mostly working already, but there remain a number of major work items.

Patches to make GNOME Shell use Telepathy directly for instant messaging and to allow the user to reply in-line to instant messages are close to landing. Once that happens, there remain some amount of additional work in the area to get retrieving history from logs to work correctly and to fine-tune the interaction between the notifications and Empathy chat windows.

The design calls for notifications to merge together and "stack up" in some circumstances... rather than having a large pile of notifications for Gwibber that have to be individually dismissed, all the tweets that Gwibber is displaying should combine together. There is development work to implement this and some amount of design work to figure out the exact detail.

Also yet to be fully explored is how messages from the message tray are throttled - should setting a status of Busy cause all messages, or all non-urgent messages to be blocked? Should the user automatically be set busy when they have a presentation open? Should there be some central place for the user to configure what notifications they want and what they don't want?

System Tray

Many of current icons that live in the system tray - PackageKit, ABRT/apport, and even media player icons like Rhythmbox are really about a past notification or a current activity that will produce notifications in the future. The plan is to move these icons to the message tray status area, and to reserve the system tray for system status - volume, battery, network, and so forth. The simple way of doing this is to simply display the current system tray icons in the message status area. It will have to be determined whether this produces a fully satisfactory behavior, or whether we need to implement a new protocol for applications that want a persistent message icon.

For stuff that does stay in the system tray, we'd like the behavior to be more menu-like. We'd also like to make the system tray icons work in the overview. This could involve some combination of rewriting system tray functionality directly with Clutter and the shell toolkit, using an alternate system tray specification like "application indicators", and reworking the overview not to take a X pointer grab.

Widgets/Gadgets

The current sidebar in gnome-shell doesn't reflect current thinking about the topic, and also is very poorly integrated into the visual appearance of the shell. Its frequent appearance in gnome-shell screenshots is guaranteed to make the core developers cringe.

One possibility that has been discussed as an alternative is turning the current clock dropdown into a full-featured widget layer; things that could be added to the layer might include weather, alarm clock, stock tickers, and so forth. Note that many of the features that are present in the GNOME 2 "intlclock" dropdown really are only approximately tied to the current time - things like weather really have no close tie to time. So, in this sense tying widgets to the clock dropdown is an expansion of GNOME 2 ideas. If widgets are done in some other way, we'll need to reintroduce to the clock at least some of the intlclck eatures that *are* closely tied to time, like multiple international clocks and evolution calendar integration.

Extensions

The idea of extensions has always been to provide an escape hatch - to make gnome-shell a friendly environment not just for the people who want their desktop to work without thinking about it, but also for the people who *do* want to think about it, want to tweak their desktop, and want to experiment with new and different ways of managing windows.

The rudiments of an extension framework are there, however a lot of what is needed to make it practically possible to distribute extensions to people isn't: we don't have a defined set of hooks for extensions to tie into, we have no way of packaging up an extension into a single file, we have no central extension repository or way of people locating extensions, and we haven't figured out how we will go about reviewing and collecting feedback about extensions to avoid problems with buggy and malicious extensions.

2024-10-23 11:37