Re: Gnome-panel: "Always beneath" property

["Nickolay V. Shmyrev" <nshmyrev yandex ru>]

В Сбт, 11/08/2007 в 22:39 -0700, Dylan McCall пишет:
> 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! 

Hi Dylan. Thanks for your contribution and such detailed mail :)

I think it's a good idea actually. Probably there is sense to create
gnome-panel bug and add a patch there for review. It's much easier to
discuss code than just proposal of feature.

Probably some usability people will give a comment too.