panel sizing of applets

[Sebastian Kügler]

On Tuesday 21 October 2008 13:46:58 Marco Martin wrote:
> On Tuesday 21 October 2008, Sebastian Kügler wrote:
> > On Tuesday 21 October 2008 01:49:34 Sebastian Kügler wrote:
> > > On Tuesday 21 October 2008 01:12:09 Guillaume Pothier wrote:
> > > > 2008/10/20 Sebastian Kügler <sebas at kde.org>:
> > > > > Removing the sizeHint (which I did last night) makes it work. So it
> > > > > turns out that our automatic machinery already works quite well. :)
> > > >
> > > > Not sure it is related, but now my panel is huge (and somehow the
> > > > rendering gets wrapped to the top of the screen instead of blow it).
> > > > Removing the battery applet solves this.
> > > > However, after removing it, the taskbar applet appears very thin;
> > > > growing the panel higher does make it bigger, but only to a fraction
> > > > of the available height. Then making the panel smaller makes the
> > > > taskbar very thin again, it seems it uses about 30% of the available
> > > > height.
> > >
> > > I'm getting weird sizing information in the battery applet after
> > > today's update. I'm also getting a huge panel that overflows to the top
> > > of the screen with the battery. The battery gets a contentsRect
> > > QRectF(0,0 264x269) assigned, which has obviously a bogus size.
> >
> > This is how it looks like with battery in panel (default for all laptops)
> > right now: http://oct21.imghost.us/DPku.png
> > Removing the battery applet helps, the panel gets back to normal then.
> > I've looked at the battery again, but I don't see where it's going wrong.
> > The initial size the battery gets seems correct (i.e. makes it fit into
> > the panel), then it receives a constraintsEvent which gives it a far too
> > large size. The panel then overflows and shows the effect from the
> > picture.
> >
> > This has only happened after yesterday's update in trunk/. I've removed
> > all sizing magic in the battery (i.e. no set*Size (height, width) from
> > the battery, but it still buggers up the layout. I'm a bit in the dark
> > here what's going on, maybe someone else can have a quick look at it (it
> > must be pretty annoying, broken panel in trunk ... :/).
>
> this patch -seems- to fix it, it just makes sure that the minimum height
> for horizontal panels is 0 and so the width for vertical panels
> (i wonder if it shouldn't be forced in
> applet::flushpendingconstraintevents, but maybe would just be hiding
> problems)

"Hiding problems" would IMO be fine in applets (we applet devs should be 
allowed to be stupid, no? ;-)) Those sizing problems are quite weird from an 
innocent POV though. (See this case, totally non-obvious what the fix would be 
...). I'm all for preventing this kind of unwanted stuff somewhere lower in 
the stack.

> oh, and a minor thing since in the panel  size=contentsize, but
> setminimumSize(contentsrect().size()) would make a resizing endless loop if
> they were different

Aye, was wondering about that. Makes sense.

Thanks a lot for having a look at it!
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20081021/3ae860e2/attachment-0001.sig