1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
Notes from the Systray and Panel Applets meeting:
* Just for minimizing is the wrong approach - use the taskbar
* What should (and shouldn't) be the systray?
* This is made more difficult to control because of the literal representation of a system tray item as an actual icon.
* having a "systray" that is really nothing more than information published on an IPC bus would make splitting up the functions into the taskbar, the systray or other presentation mechanisms a matter of policy defined by the host application rather than by the application publishing the system tray item/icon. this allows greater flexibility today and in the future by not tieing ourselves down to a specific interpretation of how it should look and how the user should be allowed to interact with it, but by simply defining the actual information that needs to be presented and communicated between the host application (e.g. the desktop panel) and the application associated with the systray entry.
* Provide a menu like the OS X dock in the taskbar
* Current uses:
* minimization (bad?)
* notifications
* new mail
* software updates
* cross desktop applets (since the tray is cross-desktop)
* visible daemons
* marketing (yes, it's actually there and working)
* cross desktop applications needs to be fixed
* notifications need to be fixed?
* redefine the current spec to be more purposeful and focused, and promote panel applets instead
* a better design than the current OOP icons via XEmbed is needed for the various reasons noted at [[http://aseigo.bddf.ca/?pID=1092|http://aseigo.bddf.ca/?pID=1092]] (and probably other reasons too =)
* how to make cross-platform applets
* Add applet menu
* .desktop file
* [[ShowOnlyIn|ShowOnlyIn]]= etc is required
* Menu merge
* panel provides standard items to applet to merge into its menu
* Size negotiation
* max useful size
* min useful size
* orientation
* use X calls to do negotiation (XEmbed related?)
* Life Cycle
* .so? - use proxy
* desktop looks like (for a GNOME applet):
* Exec=gnome-applet-wrapper --applet=foo.so X-GNOME-Applet=foo.so (for KDE)
* Exec=kappletproxy --applet=foo.so # or whatever we call it X-KDE-Applet=foo.so
* two paths, one panel is in charge, the other the panel is in charge (for activation)
* d-bus service for activation
* Saving config
* sometimes deleting an applet should delete config, sometimes it should not
* Middle-click move?
* shouldn't interaction policies be up to the host application? -AJS
* Breaking Up the Systray into the Taskbar and Individual Applets
* the systray is a well-known concept to users and developers, and one that isn't completely broken if done properly
* the taskbar should be for management of windows, not all items in the systray map cleanly to windows. if we simply add systray icons to the taskbar when no window for it exists, we start to confuse the purpose of the taskbar which leads to a confusing and unclear (read: not usable) interface for users. the MacOS X dock is rife with these issues, and users tend to struggle with it because of that.
* the taskbar currently has flexibility that remove the guarnatee that you can always see these icons/menus (such as "only show windows on the current desktop" or "show only minimized windows"). so we either limit the taskbar, or we lose one of the benefits of the systray: constant and universal visibility. trying to present two separate concepts in the same gui leads to making both less expressive.
* moving the systray into individual applets means, really, just making little individual systrays. systrays with one icon each, if you will.
|
