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