User:Chani/WayOfThePlasma/Categories/CustomContainments
What are containments anyway?
Conclusion
Containments are applets, that contain other applets. The desktop panel, for example, is a containment. It allows the developer to group sets of applets together and provide a common look & feel for the contained applets. An applet look is of course mainly determined through themes, but with containments a developer can impose certain size constraints on applets, he can pin down how items are laid out inside the containment, he configures the background of a containment and defines a context menu for it. Notable containments so far (as of 03/2008) are Panel and DefaultDesktop.
Original Text
"... everything that holds a group of desktop widgets is a Containment." Also the rest of Aaron's blog post (see Sources below)
Sources
The Power of containments (on aseigo's blog)
Applet Layouts
Layouting in containments is done using the same system used by QGraphicsWidget. The reason for this design is to allow information about the required and available space to flow freely in both directions from the component which has it to the one which needs it.
Original text
Aaron Seigo
* do you think that the QGraphicsWidget system of sizeHints would be enough for the widget side of things?
Alex Merry
From QGraphicsLayoutItem? Yes, that seems to provide the things I was thinking of (setPreferredSize and setMinimumSize). It then becomes a policy thing - all applets need to do is call the relevant methods in constraintsUpdated() (not updateConstraints as i kept saying in the last email).
Aaron Seigo
great. that's what constraintsUpdated() has always been meant for.
btw, for those curious as to why i took this approach:
in kicker applets would get asked at random points for their heightForWidth and/or widthForHeight. the clever figured out that height was asked for in vertical panels and width in horizontal.
however ... you never new when you were in one or the other previously, nor did the applet know about impending changes. moreover, it was only in these methods that the applet could know for sure which way to orient itself and so much calculation would happen in these methods, often inducing applets to break the const'ness of these methods. end result:
- what should have been fast methods (called repeatedly during layouting) were
rendered slow.
- applets were constantly in the dark about their environment
most frustrating was that the panel class(es) had *all* the information necessary .... but no way to get it to the applets. just as frustrating, the applets had no way to query about their environment when they might randomly want to (only the applet knew when it was most appropriate to know, e.g., it's orientation).
with plasma we have the added requirement that not only should we have horizontal and vertical layouts, but free form planar layouts too. oi vey!
and thus was borned constraintsUpdated and accessor methods for formFactor(), location(), etc...
information flow freely in both directions, the applet is always in control and the containment lets the applet know whenever the containment has changed the applet's world in some way (e.g. change form factor, location, the applet's size, etc)