Gnome-panel: "Always beneath" property

["Dylan McCall" <dylanmccall gmail com>]

First off, hello. After months of toying with the more noticeable applications like web and file browsers, I have ended up with my first real attempt at a contribution being for something I used to take completely for granted: The panel!

So, what have I gone and done this time?
I will admit, this was set on by what some may call jealousy of Windows Vista's attractive sidebar. It is not really jealousy, mind you, but rather a realization of the accepted position of "desklets", which are applets drawn at a position very close to (visually connected to) the desktop.
What Vista's sidebar tells me is that we can have those applets restricted to a little sidebar and still have them happily used.
There are numerous implementations of desklets in Gnome, and, frankly, I am not fond of any of them. (Well, with the exception of one, but I will get to that). They all bear a harsh reminder that they are entire other programs being run besides the panel, wasting precious memory, boot time, etc. for no reason but to give me a pretty clock on my desktop.

I find this weird, because Gnome-panel already does applets on panels that obscure the desktop and other windows. If it did something like desklets (which do not obscure other windows) as well, we could have everything done under a single infrastructure, which means less resource consumption and an easier to understand desktop experience. As is, it can sort of do desklets already. Just create a panel and stick applets on it. With the right applets, we can have a panel that works like the Vista sidebar! (Even detach that panel by turning off the Expand option and you can have a floating clock, for example).

I am sure you know the problem with this, though. Your new "desklet" has resulted in that much less screen space across the desktop! This is a common problem when people get to customizing their Gnome panels: They have to balance screen space and panel features, because the two are mutually exclusive. I find this particularly unfortunate when I consider those funny little applets like Geyes and Fish, unused because people do not want to waste precious screen space (and sanity) with those applets constantly staring at them.

This is why "desklets" are a good idea. They play the same role as the panel applets, but they do not permanently occupy screen space; they stay out of the way, just sitting on the desktop (which has always been the place the user customizes with backgrounds, so it may as well also be jazzed up with applets).

Now, back to the point of this. Gnome Panel is capable of all of that, just by doing one simple thing: getting out of my way!
I added an option to the panel properties dialog saying "Always beneath". That option tells a panel to be always beneath normal windows, right on top of the desktop. (Checking it overrides the normal stacking order of a Dock window).  Most desktop environments give this sort of option, and it is useful for many things - not just desklets. For example, someone may have a panel he wants to always see, but to save screen space he has another panel set to be always beneath so that windows are allowed to obscure it. That way, he can keep some handy, customized functionality in his panel without sacrificing screen space.

Rather than just talk about it, I did indeed go ahead and attempt it myself.
-Currently that "Always beneath" option is added to the properties dialog and gconf (all hooked up correctly, I believe). I had tried the more common "Always above", but I decided it would make more sense with
the unchecked option meaning "change nothing," while the checked option
means "something unusual occurs". (I believe the rule of thumb is that checked = new functionality?).
-Checking "Always Beneath" makes the panel appear beneath normal windows, and it also unsets its "struts". That way, a maximized window will completely obscure the panel and it will not distract the user via sticky windows. The panel keeps to its own place: The desktop (which is built to be obscured anyway).

This is Really Cool with the desklets scenario since we can have
applets at the level of the desktop flowing seamlessly with applets on
a 'normal' panel, under one infrastructure making the desktop a lot easier for the user to understand and customize. Indeed, the user still has to think of applets going on
panels set to be Always Beneath, but I think that is a lot easier and a lot tidier than installing an entirely new program to do the same job. (Especially considering that this new program would have its own set of applets, configuration windows and menu items, which is never fun). It is not a very obtrusive feature, so the user doesn't have to think about it or care about it if he doesn't want to.

A few unfortunate problems at the moment:
-The removal of struts means that desktop icons do not react to the position of an "always beneath" panel. Hoping that is fixable, because it can be confusing...
-An "always beneath" panel will snap to the edge of the screen when repositioned, possibly disappearing behind an always on top panel. (It should instead snap to the inside edge of that panel!). This seems a problem already showing its face elsewhere with panels that are not expanded when they are moved similarly. In general, this is not a problem except if somebody wants a really big "always beneath" panel lined up with another big panel that stays on top. I could blame the user all I want, but it would be nice if this could be fixed. (Note that this, like the last, is fixable by turning on struts. If we could have something like those struts affecting only certain types of windows, that would be good).
-Trivial, but the maximum panel size in panel properties is 120 pixels. One can set it higher in the gconf editor. Is there a reason for this?
-There are so far no applets really suitable to the "desklet" use case. I am sure if that sort of thing became possible with the panel, more significant applets would not be too far away.

I might add that this is my 4th day ever caring about xlib; a good sign that there are ways around these problems which I do not know!

Also, if anyone has any suggestions about that label ("Always beneath"), feel free to speak them. I came up with that in a hurry, and it doesn't really flow off the tongue like "Always on top" seems to. It ended up with an ugly accelerator key, to boot.
I shouldn't restrict the openings for ideas, though... I am looking forward to any thoughts here at all!

I have some screenshots and use cases, uploaded to Google Picasa for some weird reason...
http://picasaweb.google.co.uk/DylanMcCall/GnomePanel
If you are not yet fatigued by my writing, please note the captions on those images.

This is really a pretty trivial change under the hood, but I think giving this tiny bit of extra functionality to gnome-panel would be really worthwhile. The added functionality is significant, with very little hit on usability.


Bye,
Dylan McCall

PS:
I was about to attach a patch, but I just remembered I haven't tested this with the trunk build. (I developed and tested it on 
2.18, then moved it upwards. Looks like it will work, but I may as well be safe and build the thing).
In that case I should really have just left this message for a while since that renders a chunk of it useless, but, as you can see, I am quite impatient sometimes. I look forward to your responses!