On March 6, 2010, Andrzej JR Hunt wrote: > > apart that ToolButton should be used instead, don't really like a > > > > fuction that does enabling -and- repositioning in one. positioning should > > be done by a layout, really > > I now have a layout, however I'm having to call update() on it everytime I > change the button's size since it doesn't realise this itself, which seems > a bit strange to me. On the other hand no position calculations are > required, making life simpler.
i don't think this will work very well because we will want the button to overlap with the View of the containment (for visual reasons). layouts prevent that kind of overlapping (that's mostly the point of them :) and the position calculations in this case are not hard to do. > > i'd also position the buttons so they overlap the border of the svg. > > e.g. for the right-hand button in a horizontal panel, something like: > > qreal left, top, right, bottom; > > containment()->getContentsMargins(&left, &top, &right, &bottom) > > setContentsMargins(0, 0, m_hideButton.width() - int(right), 0); > > m_hideButton->move(0, geometry().right() - m_hideButton.width()); > > > > (obviously would need to be generalized for vertical panels and > > top/left/right/bottom buttons) > > I've now implemented the buttons as part of a layout (which is part of the > view), so the positioning isn't required, however what I have noticed is > that for setContentsMargins(left, top...), when used on the view, only the > top and bottom values have any influence, with the left and right values probably because of the layout. if you update the patch on review board i can provide more concrete feedback there. > One solution I'm thinking of now is adding a special method to the panel > containment such as requestEmptySpace(int left, int top, ...), which in the there is already setContentsMargins, and this is still the wrong approach as it is far too easy for a containment to break these assumptions. there is a way to do it that is guaranteed to work every time in every case, so let's not try to hack around things and create problems for ourselves. esp since this is a feature that would be of interest only to plasma-desktop, while libplasma is not a desktop specific technology. -- 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 Qt Development Frameworks _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel