[Panel-devel] [PATCH] fix resizing applets

[Robert Knight]

> this leads to situations where the panel changes the geometries, 
> the applets change their sizes, the panel changes the 
> geometries 

An applet's size constraints are supposed to be determined only by its contents, and unless I am missing something, calling setGeometry() on a widget with values which are valid (ie. within the widget's constraints) should not result in the size hints changing and updateGeometry() being called.  This could be enforced in the Widget internals if you are assuming "hostile" or "stupid" applets.

Regards,
Robert.

On 02/09/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Sunday 02 September 2007, Robert Knight wrote:
> > Right now, I consider a usable panel replacement to be the most
>
> no one disagrees with that.
>
> > What I propose applets should do when something occurs which affects
> > their natural size is:
> >
> > void MyWidget::someMethod()
> > {
> >    // do something which affects the size constraints
> >    // of the widget
> >
> >    updateGeometry()
> > }
> >
> > The applet's container (be that the desktop or the panel layout) then
> > takes care of updating the applet's size.
>
> besides being annoying to have to remember to put that everywhere (hellow
> prepareGeometryChange()) this is what was tried in kicker and it was a
> pretty
> dismal failure. two things that happen as a result:
>
> - applets will change internal layouts based on size constraints (think of
> things with rows of buttons like launchers or system trays) which in turn
> can
> change their size. this leads to situations where the panel changes the
> geometries, the applets change their sizes, the panel changes the
> geometries ... and hopefully it stops at some point (we've had problems with
> applets in the past which didn't, causing infinite loops that make the panel
> unusable and the cpu pins at 100%), but by then we've 3-6 relayouts of the
> panel which makes the entire thing feel sluggish. i can't even imagine
> trying
> to animate everything in that kind of environment.
>
> - due to the (from the applet's perspective) spontaneous resizing even when
> external objects (e.g. the panel) change its size, it turns out that there
> is
> no really reliable way of knowing that this has happened in certain methods
> (esp ones that get called both as a result of) and this results in really
> ugly code full of hacks and stupidly inneficient work arounds that mostly
> work but make writing applets harder while making the final results
> crappier.
>
> i really want to avoid recreating the problems with kicker and actually make
> use of the years of knowledge we've accrued through maintaining and
> improving
> it. containers, such as panels, should only advertise constraints, what
> space
> is available and other information for applets to conform to. that is the
> entire point beyind constraintsUpdated().
>
> it may be that layout classes, as such, are simply -not- the right approach
> for panels. or that we need layouts which do not try and enforce complete
> control over the applet's sizes. perhaps the applets should be free to claim
> space, set their own size and the layout needs to react to them rather than
> the other way around.
>
> at the end of the day, applets need to be in control of their size. their
> containers can only offer hints (like for factor, maximal sizes, etc.) and
> they should be notified when those hints change.
>
> sorry for not bringing a more concrete solution to the table. i'm more
> motivated to enjoy the last rays of weekend summer sunshine today.
>
> --
> 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
>