windows and default activity assignment

Aaron J. Seigo aseigo at kde.org
Wed Dec 1 07:09:58 CET 2010


 hi all ...

so recently application windows have started to be associated by default with 
the activity they were started in.

after using it for a while now, i have found that it is becoming increasingly 
annoying. and for the same reason that hard-wiring virtual desktops and 
activities together would be: they are not perfect analogs.

i think it makes a lot of sense to assign windows that represent documents to 
the current activity.

however, for windows that are not associated with a document it makes very 
little sense much of the time. i want my IM app open no matter what (though 
i'd like it shift the contacts based on activity); i need kontact open no 
matter what (though similarly, i'd love it to be internally activity aware); 
ktorrent? same deal. amarok? yep.

this was my impression after first using it, but i've given it some more time 
and instead of getting used to it, i'm just running into the annoyance more 
and more.

and there is a growingly obvious dichotomy to me: one default for windows that 
represent documents; one default for windows that represent services / 
communication. the distinction is a little (though not very) fuzzy on the 
edges, but there are huge areas on both sides of the line that are quite 
clearly defined.

imho it is a very bad idea to try and put this feature into 4.6 because there 
are two very important bits missing right now:

* the ability to show what are on other activities; if i switch away from an 
activity and i "lose" application windows and i want to get back to one of 
them, i'd really appreciate a button to click on in the taskbar that would let 
me see where it is. or maybe this belongs in an improved activities management 
UI (and is another reason why i really can't see a "quick activity switcher" 
ever being more than a half-baked wimp of an interface: to be useful, being 
able to get a powerful overview of activities is really, really helpful to the 
point of being a required feature)

* the ability to know which windows represent a document and which do not

i'd like to request that we defer auto-assignment of windows to activities for 
4.7 and work on the above two issues in that release (along with whatever else 
we scrape together as requirements).

i'd also like to have another run at the activity manager UI, this time using 
QML and implementing things a little smarter. the current code makes my brain 
cells cry out "lord, there must be a less convoluted way to do something so 
simple!" and the UI is ok but really rather disapointing due to the limits of 
what is easily achievable with the current approach relative to using QML. 
this would be a nice opportunity to work in things like "associated windows" 
overviews.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101130/eee458e5/attachment-0001.sig 


More information about the Plasma-devel mailing list