On Friday 17 January 2014 10:23:48 Martin Klapetek wrote:
> On Thu, Jan 16, 2014 at 6:01 PM, Sebastian Kügler <se...@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
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
