Version: svn (using Devel) Installed from: Compiled sources Compiler: gcc OS: Linux I try to finish my plasmoid. The applet uses 2 Plasma::PushButtons They are rendered/work fine on the Planar containment of the desktop, but they are not drawn at all on I I use it on the panel. Of course the paint code is different for the two cases, BUT if I test my applet on plasmoidviewer the buttons are painted fine both on the planar and horintal factor! The most strange is that even on the panel that the buttons are not shown up, they really exist there! I mean I put them in my code left and right of the svg pic, and I can click on them even if they are not shown up!
Created attachment 25287 [details] The problem demonstrated
a test case (some code) would be useful. also, devel discussion is more easily done on panel-devel@kde.org =)
It was mentioned before here in plasma-devel , but noone answered... So I thought I should open a bug. On Thursday 12 June 2008 15:41:25 Aaron J.Seigo wrote: [bugs.kde.org quoted mail]
Aaron, the kolourpicker applet is a nice simple example of the problem.
On Thursday 12 June 2008, Toussis Manolis wrote: > It was mentioned before here in plasma-devel , but noone answered... > So I thought I should open a bug. sometimes you just have to send a "anyone have an idea?" mail to jog our memories. i sometimes lose mail when i'm travelling..
I did. Maybe I missed the answer though... ;)
Pino mentioned the kolourpicker applet... I it does not do the job... I could write a simple applet with one button.
I have a test case with only the plasma pushbutton in a layout. The Plasma::RadioButton is the same, as is the Plasma::TextEdit and probably others. Pino says it worked before WoC.
there seems to be some ugly interactions with setAttribute(Qt::WA_NoSystemBackground); in the widget implementation (to not show the gray background) and clipping, so either disabling that or setFlag(ItemClipsChildrenToShape, true); in the panel containment fixes it. it really seems to be some wacky qt bug. could we disable clipping in panels? it could cause the problem of applets entering from the top of the screen, looks like we should choose between one of those two bugs...
great work tracking it down marco and annma. too bad it's such a nasty one =/ i suppose we should disable clipping inside panels. to help make up for that, perhaps we can move the panels higher up the canvas (into more negative y) so that if an applet does "bleed over" it has more room to abuse before showing up in the desktop containment area.
SVN commit 820580 by mart: disabling clipping in panels for now, because it breaks rendering of proxy widgets BUG: 163903 M +2 -1 panel.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=820580
a thing i was thinking was maybe in flushupdatedcontraints of applet to apply a transform to the applet if its minimum size is more than the panel, so it will be rendered horribly but won't escape, i know it's ugly but i fear it will take a very long amount for all applets to behave well in panel (most of kdeplasmoids don't) so at least it won't be the disaster