Idea: Window management for 4.5

Aaron J. Seigo aseigo at kde.org
Sun Jan 31 19:33:48 CET 2010


On January 30, 2010, Jonathan Schmidt-Dominé - Developer wrote:
> But when you want to keep notifications alive, see the status etc., a
> central place is not very comfortable, for example you want to switch to
> Dolphin after copying has been finished. Or you may want to switch to the
> application, close it or access its systray-menu, because you have seen
> the notification.

while i agree with the system tray issue, i think the notifications are rather 
different.

system tray icons replicate actions already in the taskbar (window activation, 
for instance) and the rest of what they provide (status indication, context 
menu, etc) can be perfectly integrated into the existing task entries.

notifications, on the other hand, can not be integrated into the existing task 
entries. they would appear outside of them. some notifications are also 
without an "application" (visible to the user, anyways) and so will still need 
some "generic" area to exist in. (note that an ApplicationStatus system try 
entry without a window can easily appear as an item in the tasks widget; so a 
'permanent and stable' representation is possible there; not so for the come-
and-go notifications). notifications are also not 1:1, they are 1:many so we 
need to deal with queueing, ordering, etc. it would also complicate the matter 
of getting to the notifications since left and right can have meanings already 
on the taskbar so getting to past/current notifications is trickier. added to 
this is that notifications are large and can easily overlap if placed randomly 
about.

as a technical detail, we usually can't tell which application a job is 
associated with (as they run in out-of-process plugins shared by apps) so jobs 
become another source of the issue.

the result of trying to put notifications into task widget entries (or a dock, 
if you will) would be a random smattering of popups here and there with 
difficult geometry management issues (so that concurrent notifications are 
visible and not in the way of the user), even more UI gadgetry to mange them 
(as we'd have that per-task entry!), still wouldn't remove the need for a 
generic notifications area (for notifications not associated with an app) and 
would, as Marco noted, mean that if i want to see "that notification" i'd no 
longer have a well define place for that to happen.

> That is why local notifications would be easier to use.
> Seriously, the onliest pro for the global place is that you could close
> them all relatively quickly. But a "close all" button and hidden
> notifications would be better.

it's not just closing them; it's also locating and responding. i'm really not 
in favour of spreading notifications out too much.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


More information about the Plasma-devel mailing list