GnomePanelEnhancementsIdeas

Revision 15 as of 2005-08-25 09:52:53

Clear message

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].

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

The current version of the patch is here : http://www.manucornet.net/GNOME/code/panel_addto_canvas.patch

All right, that was a hard one, but it's nearly finished. I took a look at the gnome-control-panel code, which already implements a canvas, and transposed it to the "Add to panel" dialog. That took me a lot of time to adapt the code (the two "philosophies" were completely different in their structures and the way they handle it, and the code is quite long), create categories for the applets, and learn eveyrthing I needed about GTK+/LibGnomeCanvas. So here's how it looks right now :

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

and here :

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

Since the categories themselves need to be added to the .server files (when a .server file doesn't have a "panel:category" field, I just stick its applet into "Miscellaneous"), nearly all the applets are "Miscellaneous" Smile :) But categories are managed and layed out dynamically, so everything will be fine when the *.server files are updated (I need Vincent Untz for that).

The patch is ready, fully functionnal and just waits to be tested Smile :)

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

The major problem is that it's too big for a 800x600 screen (still very common). So it must be, IMHO, be reworked a bit to allow lower resolution. LionelDricot

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

The current version of the patch is here : http://www.manucornet.net/GNOME/code/gnome_menus_for_non_admins.patch

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".

So, here's the best solution I see : make a helper, based on sudo's code, but set the "listpw" variable to "never", and call this helper (which doesn't seem to need to be setuid root, that's good news) each time a .desktop file has a "RootRequired=yes" field. This would provide a very good precision, since a menu item would appear if and only if the user can run this particular command.

Panel sizing based on screen resolution and size

Purpose

Items on the panel sometimes get messed up when the screen resolution changes. One of the tracks would be to let some of the items have a "relative" position, as opposed to an "absolute" position on the panel. I still need to figure this out.

Other "minor" things that will be done, look & feel

I call them "minor" because they will probably need a very reasonnable amount of coding and time (although one can never be sure :)), as opposed, for example, to the "Add to panel" enhancement. I will also probably do a little graphics to create (or enhance) a few icons/menus/panel elements.

Use of non-menu-like colours on the panel

Application clutter

A major cause of "application clutter" in the menus was removed with the "GNOME menus and sudo", hiding from non sudoers the entries that need sudo rights.

However, the remaining task would be to let new users have the original, clean, menus, even though more advanced users alreay added a lot of geek stuff Smile :) This would just mean create a set of "*.menu" files for each user (and copy it from a "skeleton" default set).

Not much coding, here, but a few things would need to be redesigned a little.

Pop-up balloon ?

A Windows XP-like pop-up balloon (or I might even find a diffrent way to do this...) to indicate to new users where to find things (eg Applications menu).