the plasma side of activities...
- play/stop/delete icons are misaligned
- iirc the list gets a bit funny when things resize or go away
- 'add widgets' button is still available when locked
- support switching to other-screen containments (explained better on the Multiscreen page
- activity manager doesn't show which activity is the current one. some sort of pretty highlight or something would be nice.
- those remove/stop buttons could be a lot prettier. hover effects n'stuff
- random wallpaper when creating a new containment?
- prettify the search filter?
- View::swapContainment could do with cleanup like Activity::open.
- we should hack something into Context so that it keeps the activity name in sync itself, instead of relying on Activity while KActivity* is in kdebase
- Activity could pay better attention to its containments, in case they get moved around by something else... it kinda assumes that it has full control when it doesn't.
- sorting of the activities (probably by last activation?)
- 'running'/'stopped' categories that scroll to the first running/stopped activity
- something in the panel that tells me what activity I'm on and lets me switch quickly
- dataengine? (what are use cases? how much easier than ActivityConsumer is it?)
windows can be associated with activities
- iirc some effects leave 'holes' for windows on other activities. need to check if anyone solved that
- special window rules for activities, for those stubborn apps that will never play well (might want to wait until session support is in though)
expose the associations somehow so that the taskbar can have activity features
- turn libtaskmanager's window-context-menu stuff into a library that can be reused instead of reimplemented in three places (there, kwin and somewhere-I-forget).
ksmserver handles your login and logout session; now it's going to handle saving and restoring the non-plasma side of activities too :)
on store, it either works instantly or hits the ten-second timeout. some callback is getting dropped somewhere and I'm not sure why.
I need to know which clients are on which activities, so that I can close the right ones instead of a hardcoded set. 18:11 < fredrikh> Chani: windows are supposed to have either an SM_CLIENT_ID property, or a WM_CLIENT_LEADER property that points to the window that has it expose the generic loading function over dbus instead of the testing one figure out how to restore activity-window associations
- give the activity kded API for open/closed activities (a close will have to be requested first, because ksmserver can cancel it, and we want the plasma part going down last for prettiness. that means we need cancel/done functions so that plasma's notified when ksmserver finishes.
- get it all working smoothly, plasma -> ksmserver -> plasma
- have a look at that "legacy" session stuff
- start dealing with behaviour for processes on >1 activity (can probably note who they're sharing with, copy on store and purge/skip on restore)
- start looking into making apps activity-aware and improving session support
- tell us whether a resource is associated with an activity, so that its window can be auto-associated
- void requestCloseActivity(id);
- QStringList openActivities();
- QStringList closedActivities();
not 100% sure about:
- in KActivityInfo, bool isOpen() or State state() (possible values Open, Closed, Opening, Closing) ?
- only one activity can be in an inbetween state (opening/closing) at a time, but it can be in this state for an arbitrary amount of time (eg. if an application asks whether to save and the user doesn't answer).
- although opening can take more time than closing, it's not interactive, so it would be easy to pretend it's instant. the catch is that you can't actually open/close any others until that one's done opening.
- if the activity manager can't find anyone to close the session for it (say, if the user's running compiz), it will assume there's nothing to save and immediately emit activityClosed.
/Ideas for the future