multiple plasma-desktops

[Aaron J. Seigo]

On Thursday 21 February 2008, Chani wrote:
> > 1. Containment::screen() != -1 &&  Containment::screen() !=
> > View::screen()
>
> this one will depend on desktop() at some point too

yes. =)

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

i've actually fixed that in the patch i posted for review today. it now just 
returns the current containment's screen. one less thing to synchronize

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

true, but i don't see a nice way around that tbh, not without some cleverness 
in looking for screens that are N*avg and giving them multiple rows. i think 
it's a rare enough case that we probably needn't worry.

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

perhaps. iirc, you were asking if there was an "active containment" in on 
Corona (or at least that's what i thought you were asking?) and the answer to 
that is "no". a _view_ has an active containment, but there is no meaning to 
the question of "which is the active containment in plasma?"

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

already available in the paintInterface method really.

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

what we *might* need to do is make the toolbox sensitive to being the current 
containment for the given view. e.g. make a Plasma::Icon subclass that only 
paints and accepts events when it is the active view. not overly tricky to 
do.


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

yeah; full of corner cases.

i think i'm going to set aside an evening this week to write documentation on 
Corona / Containment / Applet / View interaction. it's actually pretty tricky 
when you sit down and consider it all.

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

if we find a use case where Corona, PlasmaApp (in plasma the binary) or the 
Containments would find this useful information. i don't have a use case off 
hand yet, though.

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

yes; i think we can actually do both tbh. maybe if we go the GridLayout route, 
then we can have an "empty" entry (at the end?) that is a button that 
says "Create a new activity"?

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

the latter is because the former was what i'd repeated several times: the 
toolbox shouldn't shrink, but then you need to move it. so you have to pay 
attention to the transformation matrix, but you have to set transforms off 
which means you have to do all the positioning manually. after saying it a 
few times over i became exasperated. i'm really not good at repetition. ;)

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

that's fine. because the associated-ness is by screen(). desktop() should not 
be used to decide if a Containment is associated, but rather with which 
View(s) it is associated.

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

i thought about that. what i think we will do is paint over these containments  
with a translucent grey (which will only change the background; neat!) or 
some such to show that they are manipulatable but not selectable and perhaps 
even change the toolbox options available.

-- 
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/116ce6ea/attachment.pgp