a more dynamic Applet::formFactor()

[Aaron J. Seigo]

On Sunday, September 26, 2010, Marco Martin wrote:
> On Saturday 25 September 2010, Giulio Camuffo wrote:
> > And, on the other hand, i don't see how a new form factor would solve
> > this issue, as you suggested in your other message. How can a form
> > factor specify an applet it is constrained and it isn't constrained at
> > the same time?

how can a form factor specify an applet is constrained in the first place? 
because we put arbitrary meaning to numbers like "Plasma::Horizontal" in the 
Plasma::FormFactor enumeration.

so if there was a new FormFactor such as MinimalPlanar which which hint to 
Applets that it is a Planar form factor, but to be conservative in space 
usage, that could help.

however, i don't really know what all the rules would be for your containment. 
when should what kind of applet behave how? (e.g. "A popup applet should 
collapse to its minimal form when it is in a group that ...")
 
> seems to behave like 2 completely different containments in one, it could
> require something like a Continment::formFactor(Applet*)

form factors are "push": when the containment sets the form factor, applets 
are notified. this makes it completely unambiguous as to when to trigger 
behaviours based on the form factor (or other constraints). which means that 
if there is a formFactor(Applet *) we'd end up with one of the following:

* setFormFactor(Applet*) to know when the per-applet form factor changes, plus 
a bunch of internal bookkeeping to keep it straight

* setFormFactor(Applet*) to know when the per-applet form factor changes, plus 
a new virtual (well, slot, since we can do new virtuals right now due to BC) 
that leaves formFactor up to the Containment subclass to figure out.

* break the push mechanism altogether and then make Applet subclasses poll 
whenver they _might_ do something different based on the form factor (which 
doesn't work, actually, so this isn't a valid possibility)

i don't like any of the above. there's probably a better solution.

-- 
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 Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100926/8c75132a/attachment.sig