Review Request: reasonable applets size in bigger (probably vertical) panels

Aaron J. Seigo aseigo at kde.org
Mon Feb 4 21:19:23 CET 2008


On Sunday 03 February 2008, Marco Martin wrote:
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://matt.rogers.name/r/49/
> -----------------------------------------------------------
>
> Review request for Plasma.

unfortunately this has already been submitted so i can't coment on review 
request anymore, but this patch is incorrect in several interesting ways. =)

first the obvious stuff:

* this will not work in any applet which reimplements contraintsUpdated since 
Applet::constraintsUpdated won't be called. instead, such code should go into 
flushUpdatedConstraints (there's already some stuff like there in there) i'll 
add a comment in Applet::constraintsUpdated so that this doesn't get repeated 
in the future, as i can see how it's easy to end up with such a bug as it's 
not immediately obvious.

in this particular case, one could try and say that any applet that 
re-implements constraintsUpdated() shouldn't have its size changed ... but 
that's simply not true. it is perfectly valid for an applet to reimplement 
constraintsUpdated() for reasons that have nothing to do with form factor or 
geometry changes.

* the patch violated the style guide in a few places due to lacking 
whitespace.

* this is still going to result in gigantic icons for applets such as the 
battery in vertical applets due to the check for d->square. not great. i do 
see that it would break in certain situations, so i've fixed 
contentSizeHint() for squaring, taking maximumContentSize into consideration.

now the non-obvious stuff that we probably need to discuss:

* i now have tiny little icons for, e.g. the device notifier. ditto for the 
kickoff button. but for other icons. this new inconsistency, dependant on 
d->square, is not great.

* the code is not run if d->square, but d->square impacts 
expandingDirections() so isn't necessary as a check. an update of the widget 
*is* necessary however.

these two items can be resolved by simply removing the check for d->square. 
that, however, leads to a new world of hurt.

* why rely on the size of an icon for this? what about applets which aren't 
icons and have no relation to them? putting the code in 
flushUpdatedConstraints higlights this problem very nicely with, e.g., the 
pager which is now cut off and the battery applet which is now squished up.

* the resulting icons in Horizontal layouts is overly tiny.

so ... looking at the problem some more ... it seems that the real issue is 
two fold:

* it only applies to certain classes of applets which should conserve space.
* it is commonly related to the size of icons, but probably to any item which 
behaves similarly (e.g. a fixed representation that simply grows to fill the 
space)
* it doesn't really apply when the size of the constrained containment has 
a "reasonable" height:width ratio. it's when the containment becomes more 
square that the problem really shows up.

so a proper solution could take one of two forms:

* doing the right thing in each affected applet. this has the upside of always 
being right and the downside of requiring that we make the adjust in each 
applet.

* provide a way for applets to advertise themselves needing help with 
conserving space, doing so only when constrained and above a certain h/w 
ratio threshhold and using some applet specified base-line (which for icons 
would use IconSize)

i'm still puzzling over what the exact solution should be here. probably not 
helped by my 19 hours of flights across 11 tz yesterday ;)

-- 
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/20080204/9c13e024/attachment.pgp 


More information about the Panel-devel mailing list