KDE/kdebase/workspace/plasma/applets/systemtray

Jason Stubbs jasonbstubbs at gmail.com
Wed Aug 6 17:45:17 CEST 2008


On Tuesday 05 August 2008 23:39:36 JST, Jason Stubbs wrote:
> Take for this widget tree:
>
> widj1
> |--widj2
> |--widj3
>    |--widj4
>       |-- widj5
>    |--widj6 (QX11EmbedContainer)
>
> With the introduction of alien widgets, the ancestors of any native widgets
> also became native widgets but siblings were left as is. In the above tree,
> widj6, widj3 and widj1 would be native while the rest aren't. That means
> that widj1 was responsible for painting widj2, widj4 and widj5.

Just for the record, I haven't studied exactly how 4.4.0 handles things. It 
may be that widj1 handles everything other that widj6 in the above case... 
(Where did the j in widj come from?)

> Why does this cause problems with the system tray? Well, widgets aren't
> made native until they are required to be. Assuming that the above tree is
> created and parented in numerical order, the native widget creation order
> would be widj6, widj3, widj1, widj2, widj4. That also ends up being the
> stacking order.

Again for the record, I didn't look into things far enough to be sure that 
parents are turned into native widgets before siblings (ie, if widj2 becomes 
native before widj4), but that also doesn't affect the outcome as far as 
widj6 is concerned.

-- 
Jason Stubbs


More information about the Plasma-devel mailing list