[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [Panel-devel] Plasma panel
From:       Alex Merry <huntedhacker () tiscali ! co ! uk>
Date:       2007-10-01 9:53:17
Message-ID: 200710011053.27280.huntedhacker () tiscali ! co ! uk
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 30 Sep 2007, Aaron J. Seigo wrote:
> On Sunday 30 September 2007, Alex Merry wrote:
> > On Sunday 30 Sep 2007, Aaron J. Seigo wrote:
> > > Panel
> > > Panel
> > > Panel
> > > ------------- 0 -----------
> > > Screen 1			Screen 2			Screen 3
> >
> > The problem here is knowing where on the screen to put the
> > PanelView...
>
> isn't that was Location Containment::location() is for? =) we may
> need to add more values to the Location enum, but this only leaves
> stacking orders if we decide to support multiple panels on the same
> screen edge ... which i'm not sure we need/want to.

Yes, I thought of that after I'd written the email and turned off the 
computer :-P

In fact, I think the only tricky bits would be (a) knowing where to put 
a new panel and (b) shunting all the panels above when increasing the 
width of a panel.

>
> > > the trick will be preventing users from accidently moving objects
> > > into the negative coordinate space themselves, but i think this
> > > is pretty easy to do, really (mostly by controling what the views
> > > are showing).
> >
> > It actually is fine, as long as the panels have a z-value higher
> > than the desktops.  Anything moved into the panel space will just
> > slide under the panels
>
> this doesn't take into consideration hiding panels, does it?

I mean if we put the panels at negative co-ordinates.

>
> > I've got another version with signals for updates here.  See what
> > you think.  Note that PanelViews are created on demand now, so you
> > can now add panels from the desktop context menu.
>
> i'm not sure we need the appletAdded signal, do we? (if we do, i'd
> also provide a pointer to the Containment it is in with the
> signal...)

I was using that in Panel, but it's no longer necessary.  I left it 
there mainly for symmetry with containmentAdded, but I'll remove it 
until there's a use case for it.

Oh, and I realised we don't need the sizeChanged or positionChanged 
signals if we shunt the containmentAdded signal around to after the 
geometry is set up (ie: place the onus on the calling code if 
delayedInit is true).

>
> also, i'm not sure i like the add[South|North|East|West]Panel
> methods. i'd like to come up with a more ... human friendly way of
> doing this. *thinks*

That was just testing a concept.  I actually wanted a submenu, but this 
was easier.  The other option is just to put it on an empty bit of 
screen real estate (should such an edge exist) and provide a way for 
the user to drag it around.

Alex



-- 
KDE: http://www.kde.org
Ubuntu/Kubuntu: http://www.ubuntu.org http://www.kubuntu.org

["signature.asc" (application/pgp-signature)]

_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel


[prev in list] [next in list] [prev in thread] [next in thread]