On Tuesday 13 October 2009, Aaron J. Seigo wrote: > On October 12, 2009, Chani wrote: > > > * a "hidden windows" button could be shown in the tasks widget when > > > there are hidden-by-activity-change windows around; switching to one of > > > those windows would switch the activity as well? > > > > I'm not sure. we don't do that for desktops. but because we don't do that > > for desktops, I've seen people lose windows. :) > > hey, can we do that for desktops right now and see how it works? :) > > yes, they are the same kind of problem, really. sure, let's try this. > > > > * a "Choose Activity" button would appear in the toolboxes (panel and > > > desktop) > > > > +1 > > > > hrm. when I first read this I was thinking "popup menu with plain list of > > activities", but actually showing the activity bar would make more sense. > > is that what you meant? > > yes. > > > oh hey, a bit offtopic but I have a feeling the keyboard-shortcuts button > > in the cashew would really be better off in that new plasma KCM... must > > agreed.
yup. just make sure to disable options not available in the current chosen shell. > > > * the kwin desktop grid effect would have remove/add buttons added to > > > it to fill the virtual desktop management gap a bit more; we should > > > offer a plasmoid to trigger it and perhaps add it, by default, to the > > > panel > > > > sure, and my next plasma patch (soon as I stop freaking out about > > robocup) will be an "add desktop" action in the pager. I've forbidden > > myself from changing my number of virtual desktops until I add that > > action ;) > > > > a generic "trigger kwin effect" plasmoid should almost be a Junior Job :) > > yeah :) both that and modifying kwin to gve it all the necessary atoms to activate all the needed effects :) > > > * windows associated with an activity could be listed in the mouse over > > > pop up in the Choose Activities interface > > > > +1 > > hmm... can we drag windows to the activities somehow? would there be an > > easy way to unassociate windows from the activity bar? > > yes, i think some drag and drop would be in order. it could be cool to > combine this eventually with an expose or desktop grid effect from kwin as > well as to provide support for libtaskmanager drags. dragging the windows during the expose effect in kwin? i wondoer how feasible is that but sounds cool > > > * in a-containment-per-virtual-desktop mode (which i'm starting to feel > > > small amounts of regret over offering ... but maybe i'm just being > > > pessimistic :) the "Choose Activities" would be per-virtual-desktop. > > > if you wanted to migrate an activity from one desktop to another, you'd > > > have to store it first. the more i think about per-virtual-desktop > > > containments the more i cringe, though. > > > > this paragraph makes me cringe. I don't get it and I'm not sure I want > > to. > > yeah, same here. > > > although it does make me wonder... do multi-monitor people want both > > their monitors to switch activity at once, or do they want to be able to > > mix & match? > > when we had the dashboard and zooming per-screen, people with multiple > screens complained. now that they change all together, the rate of > complaints has dropped considerably. so it seems that people expect the > monitors to work together. i was hoping they wouldn't as that could lead > to some neat usage scenarios, but i don't think it's worth making an > option out of it. > > > > there's probably more than could be done along this line of thinking. > > > any ideas? > > > > what happens to associated windows when their activity gets stored? > > 1)do they forget their association? > > i think that would be bad, and probably harder than #2 as it would mean > tracking when the "store" state of an activity changes. > > > 2)do they remember their association and reassociate themselves if that > > activity comes back? > > i think the association will remain always in nepomuk; it just won't matter > because the activity won't be active. > > > 3)do they get stored too somehow, like a mini-session? > > 3 would be the most cool, yes. something to try once the basics are in > place. > > > one thing that could be tricky is handling multiple-associations sanely. > > it'd be really cool if we could get a window associated with three > > activities (say, my konq window for generic school stuff, associated > > with every course activity) to be stored when the last school activity is > > stored and restored when one of those activities is restored. sort of a > > smart combination of #2 and #3. > > that would be very cool, yes. > > > associating a window with >1 activity... how can that be done gracefully? > > not sure yet :) i think this kind of question will be easier to answer once > some of the foundation pieces are in place. > > > when doing it from the taskbar, do we have an "activity" submenu with > > checkable actions? > > i think so, yes. > > > do we have two submenus, "copy to activity" and "move to > > activity" like kopete does for contact groups? > > copying a window is a bit of an odd thought; but moving is certainly going > to be at least somewhat common i'd expect. well we can call them "associate with this activity" and associate ONLY with this activity" > > if windows/tasks are dragged, I assume that counts as a move; > > depends on whether multiple activity associations are more common than > single activity associations. > > > not only are > > you physically moving something, but I expect move will be a far more > > common action than copy. > > could well be. i think you're probably right. but i'm really not very sure, > tbh; we need to test these things. > > i expect this new interface to be in a state of change for at least two > releases. > -- Marco Martin _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel