activities overview, take N

[Marco Martin]

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