1. Applets Revisited

Panel applets for the next generation

You might also be interested in designs for the new weather applet or the design for Auric.

This affects gnome-panel and gnome-applets (also other modules). People please feel free to comment where appropriate however try to remember to sign your name against your changes.

1.1. Thoughts on Preferences

Some DEs have settings for major desktop components such as the taskbar and other things we implement as applets. It would be cool to have applets expose their preferences through a common interface (implemented by PanelContainer or some such) that allows a applet-capplet to let users configure their applets. It would highlight the applet on the screen and allow you to change the properties of the applet.

I'm not entirely sure how it would work yet. It is just the basis of an idea.

1.2. Post GUADEC '05

• DavydMadeley presented a paper at GUADEC: A Better Future Through Panel Applets.

• DavydMadeley and VincentUntz discussed plans for a new applets API that implemented a standardised applets widget, PanelContainer, which allowed you to place another widget inside it and handled menus, focus passing, transparency, label colours and everything else.

  • It was agreed that we would not break Bonobo compatibility for the time being, but we need a programmatic way to add and remove applets to and from the panel

• Google announced a bounty for panel applets

  • DavydMadeley: perhaps this should just wrap PanelContainer for easy binding and abstraction from complexity. Also a security model for such applets needs to be considered

• An idea was briefly discussed about merging applets and gdesklets into one thing and allowing them to operate as either or. It would appear that KDE have started doing something similar called Plasma.

DanBallard notes:

• Symphony OS (www.symphonyos.com, wikipedia) was slagged on p.g.o for putting everything (apps, admin, stats) on the desktop because it was anti multitasking and to use any of it you had to minimize all other apps.

• This trend (gdesklets is an example) seems like poor usability for the future in 3d desktops. In a 3d desktop the background/wallpaper will essentially be "far away" and anything you interact with should be "brought to front/focus". Having apps embedded in the "far" wallpaper would make them virtually unusable.
• The place stats/info and various parts of the interface should all be is in the panel, an essentially small and omnipresent toolbar. Think of it like a Heads Up Display. Keep it unobtrusive but highly useful and always available. Maximizing desktop realestate is maximizing application space which is good.
• The new disk mounter applet instead of desktop icons is a perfect example of this principal in effect.
• Following Davyd's plan to split and categorize applets, the hardware/stats applets could be on omnipresent panels and more launcher like applets could be on a more autohiding panel like something from MacOSX.

MarcoBarisione notes:

• I think we should have a generic PanelContainer, independent from the panel and Bonobo, so we can add it to the panel, to the notification area or in a test window (so debugging applets could be easy).

• A PanelContainerManager should handle tasks specific to the container technology (i.e. it should manage Bonobo stuff if the applet is in a panel.)

• With a simple API the PanelContainer could request to the PanelContainerManager some operations, for instance displaying a menu where items such as "Lock" are added if the applet is used inside the panel.

1.3. Pre GUADEC '05

This is all older discussion, lots of it is relevant, some of it isn't

An introduction to why this needs to happen is on Davyd's blog

HavocPennington notes:

• should check with UI guys who have a bunch of thoughts on this
• should preserve the relative UI consistency of applets, e.g. standard menu items,
  • tray icons are all over the map in this respect
• all applets should be able to autoposition rather than be manually arranged,
  • think about just having a toggle on/off for each applet rather than add/remove
• implementation-wise something more than notification spec will be needed, i.e.
  • some extra interfaces via dbus or whatever
• loading/saving applets via session management is no good, it's too flaky; cf.
  • discussion of fixing this for notification area as well that's been on d-d-l
• applets should remember their settings even across add/remove

• remember not to say "applet" in the UI

• there should probably be a nice libgnome-applet

DavydMadeley:

• The new applets will need a way to retrieve common menu items and such from the panel (probably via a simple library call). Since I would like to use something loosely based off EggTrayIcon (and no Bonobo in sight) we need an easy way to talk to the panel. Perhaps we could retrieve this information over D-BUS? (in fact, I see you've mentioned that on the next line)

• I didn't intend to use our existing session management, I mention in my blog, three types of applets. The applets tied to session length (clock, weather) will be managed by the applet-session-manager (which will be controlled directly by panel). Applets tied to hardware (netstatus, et al) will be controlled by applet-hardware-manager. Notification area icons will be controlled by their application.
• But we're allowed to say applet here right?
• Agreed.

JamesCape notes:

• It'd be really nice if the panel could behave as a single menubar, ala OSX.

JamesHenstridge: making applets act as toplevel menu items as in OSX would be a large change. To make them act like menus (as opposed to just looking like menus), the menu bar would need to be handled by the panel. Otherwise, menu navigation would not work right (eg. click to open one menu, move mouse to a menu associated with another applet). This is quite different to either applets or notification area icons, which each handle their own drawing and context menus.

DavydMadeley: James, what would be required to implement this. If each applet is a GdkWindow (or such) then could the panel track focus across it's GdkWindows that it packs the applets in and send a dbus signal to each applet saying "you've lost focus, close" or "you've got focus, open"? This could be abstracted into the same part of the library that uses dbus for panel merging.

VincentUntz: Before planning to rewrite the all thing, could we first determine why isn't bonobo ok and why we should use another technology. AFAIK, we can add what you want by just extending libpanel-applet. I'm not saying we should keep things as is, but I don't understand the need to change. I agree that adding a dbus interface would be useful.

DavydMadeley: It would be possible to use a bonobo based design still however there is a big move away from Bonobo in the whole desktop it seems. Nautilus has removed it and ThreePointZero might not even have Bonobo, instead using D-Bus and something next generation for COM.

JamesHenstridge: David, think about how a menubar works. You can click and hold the mouse on one menu item to expand the menu, move the cursor over multiple submenu items then over another toplevel menu item, which pops the first down and the new one up. Alternatively you can click/release on the first toplevel menu item, then move the mouse along the menu bar causes other menus to pop up. While a menu is popped up, it grabs the pointer, so all button and motion events get passed to the menu. Now if each top level menu item/menu combo is handled by a separate application, you'd need a fair bit of IPC to get everything to interact properly.

Of course, you can get all the behaviour for free by getting the panel to handle the menu items/menus. In that situation, applets would essentially be registering a toplevel menu item with an icon and possibly a label, and registering the menu items it wants. The panel would then have to send some type of message back to the applet when an item in the menu was selected. Given the limitations of such a setup, it isn't clear that it is worth the effort.

SergeyUdaltsov: What I'd love to see in the architecture is ability to add/remove applets easily from application (possible options: outproc and/or inproc applets, from the app POV). At the moment, it works ok for the Notification Area - but AFAIK it not trivial for the applet. Here is the use case: gnome-settings-daemon detects that number of layouts is >1 and automatically adds the keyboard indicator applet.

DavydMadeley: this would be very easy, we would just treat keyboard layouts like any other pluggable hardware.

SergeyUdaltsov: well, I was alwais afraid to use that kind of "treatment" (representing thing A as if it belongs to the class C while it is not - just for the implementation sake). At the end of the day layouts are NOT hardware:) Anyway, on the implementation level it would depend on how the "pluggable hardware panel representation" will work - so we'll see...

1.3.1. Components of the New Architecture

1.3.1.1. gnome-panel

GNOME Panel will look much the same as it does now. libpanel-applet as we know it will cease to exist, as will the Bonobo interfaces to panel. The entire panel will be one big EggTray (Notification Area). Applets added to the panel will be added in the default panel location (or as close to as autopacking will allow) however applets will be movable. gnome-panel will remember these location settings and apply them to applets next time they are instantiated.

Panel will have to export some sort of interface (perhaps via DBUS) to allow applets to easily communicate with the panel, get things like default menu items, and generally do the sorts of things bonobo might have done.

Panel will have a "Lock Panel" setting which is global for that entire panel (not for the whole desktop), this is in contrast to having a lock applet setting for every applet. When the lock panel setting is in effect, applets on that panel will not be movable, however applets can be added and removed at will.

VincentUntz: there's already a "lock panel" setting that is per panel. It only needs some love (you need to restart the panel for it to be effective, and show it in the ui).

(Any chance of having the panel act more like the way editing the toolbars works, like in epiphany and firefox? Say I have a bunch of launchers and I take one out from the middle, then dead space remains and one must micro manage to move everything to the right or left. I think it would be beneficial to have applets automatically 'sticky' to the right or left and let the person add space. Also, why should the panel be in an always edit mode? Is it such a common action that it needs to be accesible 24/7? or should the panel be in a 'locked mode' by default and allow you to 'edit' the panel?)

• Modifier keys are better than full-blown modes. So instead of having locked/unlocked modes with their own shortcut menu items and gconf keys and who knows what else, make panel items movable only if you're holding down the Alt key when you start dragging (same modifier as Metacity uses for a similar function). -- MatthewPaulThomas

Javier Aravena: hey, I know this is kinda hard to do, and that's a really big change, but wouldn't it be great to use the same applets in gdesklets and the panel? even more, it would be really cool to be able ti drag applets from the panel to the desktop and backwards, i guess it could be done by integrating the panel and gdesklets, besides, python is way more easy to write than C, but C applets should also be allowed for gdesklets, and the panel should be able to load python applets

1.3.1.2. applet-session-manager

Applet session manager will control applets tied to the lifetime of the panel. Such applets include the clock applet and weather applet. They will be spawned by the applet-session-manager (which will probably be simply part of gnome-panel). User requests to add or remove these applets will be handled by a-s-m. a-s-m will not add or remove applets without user interaction, except to start them when the panel is born and to shut them down when the panel dies. It should also reload crashed applets.

1.3.1.3. applet-hardware-manager

Applet hardware manager will be similar to applet-session-manager but will control applets tied to the lifetime of hardware, such as a wireless card or cpu frequency scaling. a-h-m will listen to events from HAL. When HAL indicates that a new piece of hardware has been plugged in, a-h-m will let gnome-panel display the applet for that hardware in it's last position, if it's a new applet, a-h-m will let gnome-panel automatically position it in the default location on the panel (auto packing dependant). It will be possible to disable the display of hardware applets through their preferences (eg, if they don't want the cpufreq applet displayed) a-h-m will remove the applet and remember this setting, it will not display the applet for this hardware next time.