activities overview, take N

[Aaron J. Seigo]

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.

> > * 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 :)

> > * 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.

> > * 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.

> 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.

-- 
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: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20091013/02af0470/attachment.sig