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 <[EMAIL PROTECTED]>: > > > > > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
