This is the "ideas" web page for the GnomePanelEnhancements project. This project has been accepted as part of Google's [http://code.google.com/summerofcode.html Summer of Code] program ; the student is ManuCornet.

This project was at first a bounty, described [http://udu.wiki.ubuntu.com/GnomePanelEnhancements here].

Most of my work is already available in the Ubuntu Breezy distribution. All my patches are available on

http://www.manucornet.net/GNOME/code/already_pushed_patches/

for already pushed patches and on

http://www.manucornet.net/GNOME/code/

for patches waiting to be uploaded to the main repository.

Many thanks to

http://www.manucornet.net/google/google-soc-trans.png

I would also like to thank my "mentor", SebastienBacher, who was always there and available to answer my question and provide me with immediately useful help, and Vincent Untz who also gave me lots of very wise advice. I really enjoyed very much working on this project, and I want to say that I plan to keep on working with Ubuntu and GNOME, and as part as the Ubuntu ArtTeam as well, when I get some spare time, at least during my PhD (which should begin this september).

The "Add to panel" dialog

Purpose

The "Add to panel" is not very handy : one sometimes needs to scroll down a long list of applets to get what he wants. The idea would be to make it "two-dimensionnal", with a few categories, and applets in them.

Here's what the "Add to Panel" dialog looked like until now (sorry for the French entries):

http://www.manucornet.net/GNOME/Add_to_panel_before.png

Coding

All right, that was a hard one, but it's now finished.

The new dialog (now available in Breezy) has the following features :

• Applets are listed on a 2D canvas.
• The dialog is designed to be easy to use in lower resolutions, down to 800x600.
• A search bar has been added ; displayed applets are updated in real time while you type.
• The selected applet's description appears below the applet list.
• You can navigate in the canvas with the keyboard (even in search more, when most applets are hidden).
• You can add an applet by dragging-and-dropping it, or juste double-clicking it.

• All the common applets have been patched to have a category, and all the category have been rethought (not yet shown on the captures) : Launchers & Menus / Accessories / Desktop & Windows / System & Hardware / Utilities.

• This new dialog uses less space, displaying more applets in a smaller window.

So here's how it looks right now :

http://www.manucornet.net/GNOME/Current.png

And two more captures to show how the display is updated "as you type" :

http://www.manucornet.net/GNOME/Current_2.png

http://www.manucornet.net/GNOME/Current_3.png

Nice idea, but a major thing that needs to be merged is the custom application launcher/launcher thing. What about integrating the gnome-app chooser thing? CoreyBurger

GNOME menus and sudo

Purpose

The idea here would be to know, for each menu item, whether the user needs to be sudoer (eg Synaptic) or not. If it does and the user is not sudoer, then this item does not need to be shown in the menu.

Coding

Desktop entries that need root privileges should have a "X-GNOME-RootRequired=yes" field in the desktop entry spec (other values for this field can be "no" and "optional", although only the "yes" value actually means something for now). Further discussions will decide how to actually add this to the specs.

Quick and efficient solution for Breezy

I have already coded a quick and easy solution for Ubuntu : since all the sudoers are in the "adm" group, the program only needs to check whether the user belongs to this group. However, this will only work with Ubuntu (but is retro-compatible for breezy, hoary, warty, and previous versions).

More general, but harder, solution

The process needs to be setuid root. It could simply lookup the /etc/sudoers file, but its syntax can be very complex, and I would probably need to import a large part of the code from "sudo", which is also very long and complex.

I have contacted the people from sudo, asking them if I could add for them a function to sudo, letting us use (for instance) the -t option (for "test") like this :

$ sudo -t command user is allowed to run command

They answered that this already existed (-l option, followed by a command name), but it requires the user to type his password (which is out of the question for us), unless the sudoers file has a line like "Defaults listpw=never". We had a discussion as to whether we could change the default to this "never" value, but they seem to believe this could be a security issue (and I tend to trust them about this !).

Therefore :

• An environment variable called USER_IS_ADMIN could be set by any way the distribution sees fit. Ubuntu only needs to check whether the user belongs to the admin group.

• Discussion are right now taking place in order to indeed add the "RootRequired=yes|no|optional" :

• The value is "yes" : if USER_IS_ADMIN is true, show the menu item and automatically use elevated privileges by prepending the right command (eg for Ubuntu : gksudo) to the "Exec" key. Otherwise, hide the menu item.
• The value is "no" : do not hide the menu item, do not change the Exec key.
• The value is "optional" : do not hide the menu item. If USER_IS_ADMIN is true, use elevated privilege. Otherwise, don't change the Exec key.

• If USER_IS_ADMIN is not set or the RootRequired key doesn't exist in the entry, assume the value is "no".

Doing this will allow the following :

1. Non-admin users don't see all these programs for which they don't have the authorization anyway.
2. Elevated privileges are automatically used when needed.
3. Some programs, for example package management tools, can be run without elevated privileges (eg list installed packages, search for a particular package), but still need them for more control (eg actually install new packages). By using the "optional" value, non-admin users can still perform non-admin actions, while admin users can use the full capabilities of the program.

Discussing specifications takes (a lot of) time, so this "harder and more general way" is not yet functionnal, but everything in the code is ready for it. And the solution local to Ubuntu is already committed and works fine (so basically the problem is already solved, for Ubuntu only).

Adding categories to applets

In the 2.6 version of GNOME, applets already used to have categories for easy grouping. I first wanted to use the same categories as these. But I thought they really didn't help the user much : "Accessories", "Utilities", "Amusements", "Internet", "Actions", etc. There were two main categories ("Accessories" and "Utilities") containing most of the applets and the difference between them was not clear ; and then several small categories, with a fairly precise meaning, containing one or two applets.

The new categories have two goals : to have 4 or 5 balanced categories with a "middle population", and to make more explicit titles. The new categories are as follow : Launchers & Menus, Accessories, Desktop & Windows, System & Hardware and Utilities.

Startup notification

People using GNOME for the first time are sometimes puzzled in front of this big empty screen, and two panels at the top and bottom of their screens. I have added a notification that appears only at the very beginning of the user's first session (and is never displayed again, unless the user reinstalls the system and deletes all his user configuration files). However, you can artificially make it appear by setting the apps/panel/general/first_time_launched GConf key to "true".

Here's what it looks like :

http://www.manucornet.net/GNOME/Startup_notification_transp.png

I am, of course, open to any other proposition for the text inside this notification.

A separator for the panel

When a lot of applets/menus/drawers are added to the panel, one would probably feel the need of a separator (in the way, say, Firefox has one). This request was made a few months ago, and somebody already uploaded a patch to add this separator as a small separate applet (and then, as an internal applet). However, the maintainter of the panel didn't have time to review this patch at that time, I adapted the code for the current version of the panel (which has changed on several aspects), and created an appropriate icon.

Here's how you can add a separator to the panel :

http://www.manucornet.net/GNOME/Add_a_separator.png

And here's what it looks like when you have a few of them in your panel :

http://www.manucornet.net/GNOME/Separator.png

icons

I have joined the Ubuntu ArtTeam, and will be designing icons for Breezy. Since I wanted to keep my work somewhat related to the panel, I chose to concentrate on the icons most used in the panel : applications icons. But I also gave a try for other kinds of icons.

Here are some icons I designed myself :

http://www.manucornet.net/GNOME/icons/mozilla-firefox-normal.png http://www.manucornet.net/GNOME/icons/mozilla-firefox-blink.png http://www.manucornet.net/GNOME/icons/mozilla-firefox-foxonly.png http://www.manucornet.net/GNOME/icons/mozilla-firefox-small.png http://www.manucornet.net/GNOME/icons/gtk-dialog-error-glow.png http://www.manucornet.net/GNOME/icons/gtk-dialog-error.png http://www.manucornet.net/GNOME/icons/gtk-dialog-info-glow.png http://www.manucornet.net/GNOME/icons/gtk-dialog-info.png http://www.manucornet.net/GNOME/icons/verbiste.png

And here some icons I modified a little from the original version to make them look better (in my eyes ) :

http://www.manucornet.net/GNOME/icons/gnome-cd-player.png http://www.manucornet.net/GNOME/icons/gnome-dev-mouse-optical.png

All these icons are under Creative Commons (commercial use allowed, no modification). All SVG (vector) versions all are available here :

http://www.manucornet.net/GNOME/icons/

Menu look

Another problem I tried to look into was the look of the menus in the panel. An idea would have been to change their appearance (with hover effects and/or even before the mouse comes to them) so that it is more obvious that they are clickable. However, the following problems made me decide not to change their appearance :

• After talking (on IRC) to several developpers and asking their opinion, the reaction was rather negative, and this is the main reason why I choosed not to change the menus' appearance. The current menus are clear and simple ; you only need to learn once in a lifetime that they are clickable, if you don't realize it at first.
• One of the simple ideas was to add a very slight border around the menu titles, and maybe a slight gradient as their background. But then, it appeared that this wouldn't have looked so nice with a lot of existing themes.
• Technically, changing these menus' appearance is rather tricky, unless I create a special widget for them. But then again, a lot of existing themes would need to be redeigned.

• Finally, it seemed that the real way to solve this problem was simply to add a notification on the "Applications" menu (see the "Startup notification" section, supra).

But I didn't want to make this decision without really knowing what could be done, so I have aslo learned how to create my own theme, modifying the metacity-1.xml and gtkrc files to get what I want. But this wasn't a waste of time : I'll certainly release one of two themes of my own in the next few weeks (maybe some variation on Clearlooks with more red colors...).