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)
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
Cheers,
Marco Martin
> Thanks,
Index: battery.cpp
===================================================================
--- battery.cpp (revision 874297)
+++ battery.cpp (working copy)
@@ -168,20 +168,23 @@
if (constraints & (Plasma::FormFactorConstraint | Plasma::SizeConstraint)) {
if (formFactor() == Plasma::Vertical) {
if (!m_showMultipleBatteries) {
- setMinimumHeight(qMax(m_textRect.height(), contentsRect().width()));
+ setMinimumHeight(qMax(m_textRect.height(), size().width()));
} else {
- setMinimumHeight(qMax(m_textRect.height(), contentsRect().width()*m_numOfBattery));
+ setMinimumHeight(qMax(m_textRect.height(), size().width()*m_numOfBattery));
}
+ setMinimumWidth(0);
//kDebug() << "Vertical FormFactor";
} else if (formFactor() == Plasma::Horizontal) {
if (!m_showMultipleBatteries) {
- setMinimumWidth(qMax(m_textRect.width(), contentsRect().height()));
+ setMinimumWidth(qMax(m_textRect.width(), size().height()));
} else {
- setMinimumWidth(qMax(m_textRect.width(), contentsRect().height()*m_numOfBattery));
+ setMinimumWidth(qMax(m_textRect.width(), size().height()*m_numOfBattery));
}
+ setMinimumHeight(0);
//kDebug() << "Horizontal FormFactor" << m_textRect.width() << contentsRect().height();
} else {
setMaximumSize(QWIDGETSIZE_MAX, QWIDGETSIZE_MAX);
+ setMinimumSize(KIconLoader::SizeSmall, KIconLoader::SizeSmall);
}
}
if (!m_showMultipleBatteries || m_numOfBattery < 2) {
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
