multiple plasma-desktops

[Chani]

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

this one will depend on desktop() at some point too

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

ok, cool.
right now the view actually sets its screen to be the containment's screen, 
which seems a little odd.

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

ooh, layouts. I didn't think of that. :) the only thing that bugs me is it 
might not look very pretty if someone has two screens with very different 
sizes.

> > we have a concept of 'active containment':
>
> and likely always will.

good. you disagreed with this a while ago, which was confusing me, but I think 
you'd just misinterpreted what I'd said.


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

I didn't think of doing it this way.
that would mean putting code into Containment that understands zoom stuff, I 
guess... and also something that'll handle the 'add widgets' button being 
clicked in one of those containments, because the view's slot will act like 
the button was pressed in the active containment...

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

ahhh. I see.

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

handy for what? :)

> > so, how hard is it to know which view a click came from?
>
> QGraphicsSceneMouseEvent::buttonDownScreenPos =) and again, this should be
> handled within Containment itself.

ok, cool :)


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

originally I wanted that. but, well, when you're zoomed out there's more than 
one toolbox... and why not make use of that blank canvas space? :)

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

me and gamma were talking to you about toolbox plans and you suddenly started 
contradicting things you'd said before, telling us not to do things the way 
we thought we were supposed to. when we asked you to explain, you said it'd 
be easier if you just wrote the code yourself. :(


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

I was thinking about the slot, not the button, and I've changed my mind now 
anyways.

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

yeah, that probably would be nice.


>
> > should I be able to zoom into a containment that comes from a different
> > screen?
>
> i think no, only non-associated containments.
>

ok. we still need to be able to have two views on different desktops show the 
same containment, btw.
I have a feeling people with multiple screens might get confused when they 
zoom out and see containments they can't zoom into, but that can be dealt 
with later if it turns out to be a problem.


-- 
This message brought to you by evyl bananas, and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080222/17c36cb0/attachment-0001.pgp