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

List:       kde-panel-devel
Subject:    Re: [Panel-devel] [PATCH] fix resizing applets
From:       "Robert Knight" <robertknight () gmail ! com>
Date:       2007-09-05 23:36:52
Message-ID: 13ed09c00709051636q42662284ud24b9eecca853553 () mail ! gmail ! com
[Download RAW message or body]

> 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@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
> 
_______________________________________________
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]