Thoughts on applet layouts

[Aaron J. Seigo]

On Thursday 13 March 2008, Alex Merry wrote:
> On Thursday 13 March 2008 13:21:14 Aaron J. Seigo wrote:
> > On Thursday 13 March 2008, Alex Merry wrote:

> > * how will this better / easier than a Containment supplying it's own
> > Layout class? (other than obviously not having to create a separate
> > subclass, i mean from the amount of code that needs to be written..)
>
> Well, there's no reason the work couldn't be done by another class, rather
> than the virtual layout() method.  As long as the class interface allows
> grid layout of icons but not other applets, for example.

sure; there's no real restrictions there.

> > * do you think that the QGraphicsWidget system of sizeHints would be
> > enough for the widget side of things?
>
> 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).

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)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080313/0c1df5a8/attachment.pgp