4.5 - Activities

[Aaron J. Seigo]

On March 9, 2010, todd rme wrote:
> you add a new screen, a new containment is added to all existing
> activities (I'll use "containment" as shorthand for the whole-screen
> containments like desktop and netbook, as opposed to the panel
> containment or container widget). 

that would be very heavy; probably best to do it when the active context is 
switched.

> The new containment takes the same
> wallpaper as what I will refer to as the primary containment, the
> containment that appears on the primary screen (whichever screen that
> happens to be).

this is easy to do in a user-expected way with 2 screens; it gets increasingly 
trickier with more screens, esp if the user starts customizing the other 
screens. in any case, i think this is a moot point. for now we can do exactly 
as we do now, with new containments getting the default wallpaper. wallpaper 
matching is a nice idea, it's something we can get to once the big pieces are 
in place first, though.

> If you remove a monitor, that containment disappears, and the widgets
> it has are no longer running and taking memory, but its layout is
> remembered, so if you plug in that monitor again, or any other
> monitor, the containment, including all of its widgets, is placed on
> that monitor. 

this implies a startup penalty for adding another screen, but that's probaby 
worth the memory and cpu savings. this is, however, something that has very 
little to do with the context<->containment mapping. it could be done with the 
code that exists today, in fact. patches welcome.

> Which screen gets which containment depends on the
> screen priority, one containment always appears on the primary screen,
> the second containment always appears on the second screen, and so on
> for however many screens there are.

curious: have you looked into the screen management code that's already there?

> and all of your activities will work just fine.  It also means that
> the same containment will always appear on your primary screen,
> whatever that might be.

"whatever that might be" is the trick since it isn't always constant, and when 
it is it isn't always consistent with what the user thinks. i'd prefer to just 
stick with the more straightforward screen-number-associated-with-containment 
approach we have now.

> The critical thing here is that containments have to rescale the
> widgets they contain depending on the monitor resolution.  Otherwise

this is both containment-specific (not all containments follow the same 
layouting strategy) and orthogonal to coordinating containments and contexts. 
it would be interesting to see work done on this, but it's a different project 
touching different parts of the code base altogether.

> you will end up useless activities when you change resolutions, which
> is what we have now.

have i mentioned recently how much hyperbole annoys me? :)

> Now there is a possible variation on this, although I do not know
> whether it is a good idea or not.  The idea is that you can have the
> same activity associated with more than one containment.  So say you
...
> not connected.  So you could set up a containment for use with a
> projector when you don't have a projector handy.

being able to switch between different containments belonging to the same 
context could be interesting for this particular use case, but it's something 
that can be added later and would highly depend on how the initial 
setup/switching goes.

> Further, you could have it so people could change the activities
> independently on their two monitors, allowing them to have the same or
> different activities on the two monitors depending on what they are

no; this is more complex than necessary (just think of the control UI) and 
every time we've offered independent screen actions they've been rejected by 
most people we've gone to for feedback

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