multiple plasma-desktops

[Aaron J. Seigo]

replying to the list because this belongs there.

On Wednesday 20 February 2008, you wrote:
> the situation now is that for each screen, we have one view and one
> containment. it's all tied together.

obviously; there's been no switching coded added. a given view, however, will 
always have one and exactly one primary Containment at a given time. it 
pretty much has to so we can continue to respond to things like xrandr 
changes even when zoomed out.

> the containment's toolbox signals are 
> connected directly to the view in a way that assumes it's a 1-to-1
> relationship.

yes, due to the above. this does not mean, however, that:

* we can't switch those connections when the primary Containment changes
* we can't listen to signals from other containments as well

> the situation we *want* to have by 4.1, as far as I can see it, is that we
> want containments separated, so you can freely zoom into a different one to
> switch activities. 

"separated", as you put it (because really they are already separated: the 
containment really doesn't know much about the view) is not necessary for 
switching.

> many containments for one view - 

no. a view can be showing multiple containments, but there is always one 
primary containment connected with it (at least for desktop and panel views, 
which must track screen size changes)

> but with composite and  
> virtual desktops, we also can have many views for one desktop [let's skip
> the issues that causes for Widget::view()].

it simply means that we need to add in which desktop we are currently dealing 
with. trivial to fix.

> and then there's the issue of 
> multiple screens, which I do not properly understand. I'm guessing that
> either we can freely use any screen's containment on any other screen
> regardless of resolution/size, or we lock a containment to a specific
> screen - or maybe there's a middle path where we can do something smart
> like letting you use a containment from another screen if the resolution is
> the same. can you explain that aspect of it for me?

there are three situations:

0. the View's primary containment
1. other View's containments
2. free containments (unnasociated with a current view)

those three situations can be programmatically discerned by:

0. Containment::screen() == View::screen() (and potentially desktop(), once 
that's there, though not necessarily)
1. Containment::screen() != -1 &&  Containment::screen() != View::screen()
2. Containment::screen() == -1

note that in the view-per-desktop scenario, case 0 is interesting in that you 
can have multiple views with the same screen(). it really changes nothing, 
however. it's just a neat detail.

> for now, for simplicity, I'm going to assume that only one screen exists. I
> don't know how to deal with placement of containments when screens are
> plugged in, when screens have different sizes, getting automatic and
> manually created ones to both be in sensible places on the canvas, etc...

for now i figure we should just create them in a grid ... or perhaps even have 
an area for "free" containments versus screen associated ones.

the only code that this really affects is:

* the inter-containment dragging code. however, with the dekstop->panel 
dragging code (which could be generalized a bit perhaps) that becomes a 
non-issue: drags between views are handled by that code path, drags between 
containments within the same view (e.g. when zoomed out) are handled normally 
by the canvas.

* the "where do i place this containment?" code. right now we manually 
calculate where to place it, but the actual placement is somewhat random. if 
we used a layout (e.g. a gridlayout) to manage this it would not be an issue.

> so, if the user has composite (and the unimplemented
> view-per-virtualdesktop thing) it's many views to many containments.
> otherwise it's many containments to one view.

it's always one (primary) Containment to one view, with all other free 
Containments available to be switched to. it's just a question of which one 
is being shown.

> we have a concept of 'active containment':

and likely always will.

> most of the time this is the one that's shown on the view. 

correct

> when we zoom out, suddenly other desktops are 
> visible.

s,desktops,containments, .. but yes

> currently, their toolboxes are visible with them, zoomed out and 
> really hard to click.

let's try and not mix N different issues into this. let's deal with one issue 
at a time (the zoomed out toolbox issue has already been discussed and 
concluded on, in fact)

> I think it'll be useful to keep the one we just 
> zoomed out of as the 'active' one, in case there's stuff that wants to act
> on a containment (ctrl+f12, unless we want that to show the zoomout)...

exactly. there will always be the primary containment, until switched.

> now the problem, is, how to we get to the *other* desktops?

s,desktops,containments,g

> their signals
> need to be connected somewhere. if we connect them to our view, we also
> need to modify the signals to say which containment they're coming from (at

not necessarily it could well be possible for all non-claimed (e.g. all 
screen() == -1) containments to handle their own zoomed status and switch 
their screen() to the screen of the view the click came from. 
QGraphicsSceneMouseEvent::buttonDownScreenPos is our friend here.

friendly switching is already handled in Containment::setScreen(int screen). 
it removes the currently screen() associated containment from that screen and 
claims it for the current containment.

what is missing is a way to signal the outside world of this change. this 
probably belongs Plasma::View.

> least for things like zoomin and addwidgets - actually, why the fuck is
> addwidgets going through the view in the first place?).

because it really depends on the view whether and how to show the add widgets 
interface. think of DashboardView.

> once we have them 
> talking, we need to make the 'active' containment switch to the one whose
> button was just clicked, especially if it was the 'zoom in' button.

right; switching the active containment is pretty easy though: change 
Plasma::View::Private::containment and reconnect signals (probably emit a 
signal noting its changed). a signal in Plasma::View::setContainment might be 
handy here.

> now, we could just blindly connect all containments' signals to the view,
> but there are two problems:

yeah, we don't want to do that.

> 1, those connections are unnecessary when
> zoomed in, and potentailly annoying. 2, when there are multiple views, how
> do you know which view should be told to zoom in when the button is
> pressed? you don't really want all containments always talking to all
> views.

i think these are already covered by the above.

> I think the easiest way to simplify both of these at once is to only
> connect to signals from containments that are visible. you zoom out, they

i don't think this is necessary at all; see above.

> get connected; you zoom in, connections are broken from all but the one you
> zoomed into. the only problem is, if you have two views both showing a
> containment at the same time, you still have to figure out which view the
> clicks are coming from.
>
> so, how hard is it to know which view a click came from?

QGraphicsSceneMouseEvent::buttonDownScreenPos =) and again, this should be 
handled within Containment itself.

> assuming we can solve the problem of getting containment signals to the
> right views, and find a way for this to get along with multiple screens,
> the rest should be pretty easy.

yep.

> there are some minor glitches with 
> accidental view-moving and dragging things between containments, and
> figuring out a decent ui will take more thought, but it looks like things
> won't be too hard. for now I'll just stick an add button on some blank part
> of the canvas.

perhaps this even belongs in the toolbox.

> this does make me wonder about the toolbox again though. right now every
> containment has its own toolbox that zooms out with it and becomes nearly
> unusable. my workaround will be to put the zoom controls in the contextmenu
> so that I just don't have to use the darn toolbox at all, but I'm guessing
> it should not shrink,

probably not, no. again, this is a *different* issue from that of containment 
switching, however.

> regardless of whether we get it to stay in the corner someday
> (you've kinda scared everyone away from trying to work on that 
> anyways).

erm. how exactly? it's not the easiest thing to do, but i haven't discouraged 
anyone from working on this. in fact, i've helped people with questions who 
have tried working on this in the past. =/

> oh, and I moved the 'lock widgets' function from desktop to containment so
 > that I could add a lock button to my toolbox.

well, this isn't necessary. the containment itself can add to the toolbox. i 
do agree that this should be moved to Containment itself, though, as it's 
generally useful.

 > I feel like it really belongs 
> in corona or something, 

and how would Corona show this feature? and if a Containment doesn't want to 
provide this? and if just one Containment is locked down via kiosk, but 
others aren't? etc, etc.

> since it does lock everything, and 
> toggleDesktopImmutability() is really just a wrapper for the corona
> setImmutable function - 

correct ... that doesn't mean it belongs in its entirety in Corona.

and again, this is a separate issue. maybe break this email into a few 
different threads.

> the only valid reason I can see for it to be 
> outside corona is that it still works if no corona is found.

that's not why, no.

> the only problem with this is that I haven't figured out how to make the
> button text change from 'lock' to 'unlock' when appropriate.

what would be great is if we could use QActions for the toolbox.

> how can we ensure that manually created containments and containments that
> come from screens don't get in each other's way?

i think a GridLayout and be done with it. it's the easy solution to "where to 
put it?" and "can't overlap"

> should I be able to zoom into a containment that comes from a different
> screen?

i think no, only non-associated containments.

> what if that screen has a different resolution? 

solved with the above =)

> how do we figure out which view a buttonclick came from?

QGraphicsSceneMouseEvent::buttonDownScreenPos

> are you ok with toggleDesktopImmutability() moving from Desktop to
> Containment?

yes.

-- 
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 Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080221/3ea0575f/attachment.pgp