[Panel-devel] [PATCH] fix resizing applets

[Aaron J. Seigo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20070902/48b1752f/attachment.pgp