[PATCH] panel placement at the center (or whatever) of the screen

[Aaron J. Seigo]

On Sunday 30 March 2008, Marco Martin wrote:
> > this is something that affects the view more than the containment itself.
> > in fact, we've gone to not recording geometry in the placement of
> > containments on the canvas at all. it would be nice to keep it that way
> > if possible.
>
> hmm, so the position should be saved somewhere else?

yes. with the view

> and the size also?

the size, no. constraints on the size need to be externally defined though, i 
think. right now they are set to be the size of the screen. that probably 
needs to be reworked so the view can have something to say about that.

the max size is really all that needs to be communicated in, along with wether 
it should be expanding to fit that size as needed or just always that size.

> > in your patch, there's not chekcing for the panel going off the screen,
> > so it would be pretty trivial for the user to end up pushing a panel into
> > another view. this would be particularly easy with vertical panels.
>
> the geometry is intersected with screen geometry but there is the problem
> that the width (or height) could become 0, but i really don't know how to
> avoid it, unless there is an hardcoded minimum size.

yes, there should be a minimum size set in PanelContainment.

> > the control UI for this would need to appear in the view itself (at the
> > edge closest to the screen middle, or the top edge for floating views),
> > and i think we could just use the office icons for these things. drag the
> > margin handles, select the justification (those could sit in the middle
> > between the margin handles) .. voila.
>
> hmm, appearing outside the panel?

or along the top edge of it...

> should be a window on his own? every time 
> the mouse gets over the panel? wouldn't it become annoying?

it would be triggered by the showing of the panel toolbox (yes, that monster 
again), or even selecting one of the resulting tools.

> > no moving things on the canvas, natural boundaries enforced for screen
> > edges.
> >
> > so the offset in your patch would become the left margin value, but
> > stored in the view. and set up there as well.
>
> ok, so it will still use the applet entry of plasma-appletrc?of course not
> the geometry, so another entry?

yes, perhaps maximumSize.

> and what, the view should have his own 
> config object? ahhh my head explodes.

the view will need to store it's position on screen (this is required for 
floating panels to be supported, obviously =) as well as the anchor points 
and justification.

> also, i really really would like to make the placing work before doing any
> fancy configuration interfaces with panels handles (that probaly needs
> other things before being possible?) that reeeally don't feel like to atm.

yes, that's fine. you'll just have a hard time doing it with the one config 
dialog which comes from the containment though...

> i think this patch could work if the placement config plus some other
> params would be read from the proper place and the config interface be the
> ugly current one (but it's from the containment, hmm) or even no config
> interface for now and only readingfrom the config file

yes, config file for is probably fine.

-- 
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/20080330/39d826ca/attachment.pgp