Re: Revisiting the GNOME Panel in general...

[Gediminas Paulauskas <menesis chatsubo lt>]

On Tr, 2004-09-22 15:06+0100, Scott James Remnant wrote:
> This is something that's been itching at me for a while, and Jeff
> prodded me in the direction of the list and Davyd's blog post[0].  As

> [0] http://www.livejournal.com/users/davyd/118545.html

> Davyd identified three kinds of applets, I'd like to actually expand on
> that list a little bit:

   1. applets that are tied to the lifetime of the session,
   2. applets that are tied to the lifetime of a particular program, and
   3. applets that are tied to the lifetime of hardware

To me looks like types 1 and 2 are the same. Applets like window list or clock
turn into simple programs, which do not even have a main window; but they
register with the session, and display a notification widget in tray (the
spec allows to put any widget in notification area, not only an icon).

>    And (possibly) controversially, I think this also includes Launchers.

If, by Davyd's plan, everything on panel becomes a "notification icon"... Oh,
we have a problem with foot menu, launchers, buttons and drawers, which are
different kinds of panel objects than applets.

If only applets are put into
"notification area", users can no longer mix launchers with applets or have
different applets on different panels (default setup).

If every panel object is converted to tray object, then we have more kinds
of objects than mentioned 3: launchers, buttons, and drawers. All of them
would be handled by applet-session-manager, as Davyd calls it, and it would
provide basic UI (right click menus, launcher editor, drawer properties
dialog) for them; taken directly from current panel code.

>    If I put a CD Player launcher on my panel and click it, Sound Juicer
>    (probably) should appear.  Why can't I subsequently use that launcher
>    as if it were the old CD Player applet?
> 
>    Or another example.  Click the Rhythmbox icon to start it, that icon
>    should subsequently serves the same purpose as the current
>    notification icon.

That would be an impressive interface! It would save space, as you won't
have two objects on panel (launcher and notification icon). But that
principle is quite different from most other desktops... GKrellM and Window
Maker do have such items, however - which are used to launch an app if it is
not running, and display some info and controls if it is (wmxmms/gkrellmms
for good example).

>  * Applets directly related to information.
> 
>    These are the informational ones such as pagers, clocks, weather,
>    etc.  They're there because the user added them (or got them in their
>    default profile and haven't removed them).

That's what applets related to session are.

> To handle all of this, the Panel definitely needs to be a lot more
> intelligent about placement of applets.  If I disable then re-enable the
> bluetooth in my laptop the (theoretical) applet should vanish and then
> reappear in the same position as before.
> 
> The panel would also need some way of knowing where the user likes
> applets to appear.  Starting an application like Rhythmbox from the menu
> would need to place its applet somewhere sensible, and if the user
> doesn't lock it onto the panel it should probably vanish and not turn
> into a launcher when closed.  (You'd probably want to remember the
> location for next time its started though).

Whether an applet, which appears/dissapears like hardware applets, or a
notification icon of a running app, a position, preferred placement should
be saved. That would be a few parameters

    1) which panel/notification area should be used,
    2) position relatively to other objects and ability to move the
       object around,
    3) alignment if more space becomes available around (stick to applet in
       the left/right, or don't move), and
    4) a menu item to remove applet (launcher, drawer, button) and/or
       disable application's notification icon without quitting the app
       (e.g. you do not want Network Manager icon to appear on panel when
       you connect the cable (since it's sole purpose is to show an icon, it
       would not be launched at all), or you don't want Rhythmbox to show
       notification icon when you launch it. Currently there are different
       mechanisms to do that: toggling a preference/plugin in app, removing
       an applet, and automatically-appearing hardware or printer queue
       applets are not handled at all. This feature should be complemented
       by a list of disabled applets/notification icons to re-enable them.

> People mostly arrange panels in one of two ways:
> 
>  1. They fill the panel.  Often they make the panel shrink-wrapped
>     around its contents.
> 
>  2. They use the opposite sites of the panel, it seems that menu +
>     launchers on the left and applets on the right is a popular layout.
> 
> 
> So, here's an idea...
> 
> The edges of panels could be used as "applet attractors", or "applet
> zones".  Each zone would manage ordering of applets within it.  New
> applets would pick the appropriate zone and become managed by it.  In
> effect, each panel would get a left-hand and right-hand "notification
> tray".
> 
> These could be configured to only accept certain types of new applet.
> Explicitly dragging an applet around would override that, and you should
> probably still be able to place applets outside of a zone if you so
> wish.

Having read/written all that, I remember that I have seen an UI which does a
lot of what we want - Toolbars' Customize feature in Mozilla Firefox!
Some items in toolbar could be called "launchers" and some "applets". Also,
it has other item types which would be very useful to have on panel, too:

    1) separator
    2) space
    3) flexible space (auto-expanding)

Those shouldn't be too hard to have in panel. Similar things are possible
with GTK+ toolbars already.

Imagine customizing your panel like you do your firefox toolbars.

Regarding "applet zones" or groups - would be very nice to have such a thing
for maximum flexibility and bringing order to panel. A notification area can
contain both items and groups, where groups contain other items. You can
create a new group or delete one, and move items into and out of groups.
Item's position is position in containing group. By default there would be a
group for hardware applets, and another for application notification icons,
which is default group to put icons which appear without user specifying its
position by mouse+add to panel. For example, my current panel would be
divided like this (square brackets enclose a group, group's title below)

foot [terminal gedit evolution firefox xmms] tasklist showdesktop pager -->
                  launchers

--> [ gaim network ] weather notes volume clock
         default


OK, so I can imagine how the "next level" panel would look like and behave,
and I like the idea of turning the panel into a big notification area.
However, this seems like a lot of work. Much of that means porting existing
panel functionality and applets to the new panel, but requirements for
infrastructure are quite big and it has to be implemented first. IMHO this
is no small task possible to do for GNOME 2.10. This also breaks
compatibility with all current applets, so it can only go into GNOME 3.

Have in mind that current notification spec as published on freedesktop and
implemented by gnome-panel and libegg/eggtray are far from perfect and lacks
features we need today. A new Desktop Notification spec for "baloons" is
being written by Christian Hammond and is at
http://galago.sourceforge.net/specs/notification/ . tigert was posting new
exciting ideas on his blog for notification messages, but they are only
ideas and mockups still. So, even the vision is still blurry, not talking
about exact techniques and implementation of them. Of course, work needs to
be started already to have the features in future.

Talk about no need of bonobo in panel/applets, usage of D-BUS for
panel/applet/application communications, overlap between gnome-session and
D-BUS etc. Dream about GNOME X.

menesis