View source for 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===
[http://aseigo.blogspot.com/2008/03/power-of-containments.html 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'''

<tt>* do you think that the QGraphicsWidget system of sizeHints would be enough for the widget side of things?</tt>

'''Alex Merry'''

<tt>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).</tt>

'''Aaron Seigo'''

<tt>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)</tt>

===Sources===
[http://lists.kde.org/?l=kde-panel-devel&m=120541315801099&w=3 panel-devel archives - March 2008]