Systemtray breakout notes

[Eike Hein]

On Friday 17 January 2014 10:23:48 Martin Klapetek wrote:
> On Thu, Jan 16, 2014 at 6:01 PM, Sebastian Kügler <sebas at kde.org> wrote:
> > Some applications nest in the systemtray, and appear in both taskbar and
> > systemtray. We'd like to merge their entries. Example: Kmail's taskbar
> > item
> > could show the number of unread emails as an overlay, instead of having a
> > separate icon in the systray.
> 
> Note that there exists DockManager API for exactly this purpose and
> IconTasks is implementing it. Also Chrome/Chromium was integrating with it
> (IconTasks using DockManager), I don't think it does anymore, though their
> dockmanager handler checking is weird (basically they check for some
> ubuntu/unity lib being loaded in memory), but it may have changed since I
> last looked.

A couple of rough notes on the general idea:

* The status quo: The objects exposed on the KDE default Task Manager
  traditionally are windows, not applications, and in this it differs
  somewhat from the system tray ... the tray represents windows at
  times, too, but in some sense is limited to docked main windows
  while the Task Manager is not (document windows, utilitiy windows,
  dialog windows ...). Assuming this difference persists, exposing
  system tray data on the Task Manager unassisted would be met with a
  couple of practical problems:
 
  - Apps may not use the same icon for their window and for their tray
    icon, and window icons can further contain their own stateful in-
    formation of their own (e.g. some drawing apps put a thumbnail of
    the current document in there), so there can be contention between
    the two.

  - Some apps use the tray for 'docking' in addition to notifica-
    tions, e.g. IM messenger buddy lists. This can conceivably cause
    the information to be perceived as window-specific, so showing it
    on all windows the app has on the Task Manager wouldn't be appro-
    priate. However if we want to put it only on one Task Manager
    item, we run into the problem of how to programmatically decide
    which.

  I think there's lots of problems there that might conspire to make
  this impractical with legacy apps. That would mean something opt-in
  like DockManager is needed. Whether the DockManager API can fill
  that need would have to be evaluated ... purely going by the name,
  it probably doesn't allow window-specific customization, though.

* If we actually want to go with a dock pattern for the default Task
  Manager instead to reduce the cognitive load on the user (i.e. move
  window-specific information into a second tier like Icon Tasks does
  with its tooltips) then libtaskmanager requires its own round of work
  for that, too, to maintain positions and item identities stably across
  the launcher -> [start-up notification] -> task -> launcher lifecycle
  (Icon Tasks does some of this on the applet side instead which isn't
  viable in a QML frontend).

  A lot of this work exists to some degree in an experimental fork
  of the Plasma 1 Task Manager:

  http://quickgit.kde.org/?p=scratch%2Fhein%2Fexpanding-icons-taskmanager.git

  ... but it still requires cleanup, and many of the matching-heuris-
  tics involved are leaky abstractions on X11 (like e.g. the old
  OpenOffice-on-docks problem that requires exception rules to deal
  with).

  Note that moving to the pure dock pattern involves some real down-
  sides and trade-offs though, e.g. making it harder on users to keep
  track of window-specific state. It's a decision with far-reaching
  consequences for the feel of the workspace so it shouldn't be done
  lightly, especially when we're discussing potentially creating new
  APIs for apps to push info ... there are opportunities there for
  both interaction patterns.


> Cheers

Cheers,
Eike