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!
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
