containment types

[Aaron J. Seigo]

On Tuesday 11 March 2008, Chani wrote:
> I'm a bit confused about what these containment types really mean and how
> they're supposed to be used. mainly I'm confused about what is and isn't a
> desktop containment.

yes, they lack documentation.

> right now, being a DesktopContainment means three things: you get applet
> handles, you get the desktop toolbox, and setScreen() works properly.
> I don't like those three things being lumped together.

> what if I want to 
> write a desktop containment without a toolbox? (yes, that is where I'm

that's a CustomContainment, then.

> going.) what if I want a desktop without handles, because I want to do
> something funky like tiling applets?

the handles support is about to change, from being something we do with an 
event filter to "window decorations" (not the best of names, but it's what 
QGraphicsView calls them) on applets themselves.

this will open the opportunity to make these more flexible.

> would it be reasonable to have separate variables for enabling handles and
> toolbox? then the meaning of  setContainmentType(DesktopContainment) would
> be "setScreen should work, and handles and toolbox default to on" ?

other than the "because we could", why?

the benefit of having set profiles is:

* consistency across types
* avoiding individual authors making poor decisions by providing standards
* less code in plugins

it's really the exact same reasoning as behind things like applet background 
standardization, svg themes, etc...

> then I could create a shiny new desktop containment and do
> setHasToolbox(false) or setHasHandles(false) to replace them with my own
> crazy ideas.

... and then when we use a random scripted Applet as a containment we have to 
try and make sure we get the right set of flags set on it to behave properly.

... and then we'll have well meaning authors creating things that are broken 
in interesting, subtle and varying ways.

it's very interesting that every time a standards system is introduced, 
someone speaks up and makes a passionate and even reasoned plea to get rid of 
it and replace it with Ultimate Tweakage(tm) instead.

and then after i stonewall we go with it and a months later ....... nobody 
actually notices, cares or is concerend that we, e.g. have a standard system 
for backgrounds, images, constraints, etc.

in fact, people can write code faster because there are less details to worry 
about and users get a more consistent experience. the code base maintains 
fewer special case code paths, and those that exist are easier to understand 
because there are fewer orthogonal variables.

> oh the other hand, if being a DesktopContainment absolutely means having a
> toolbox and handles, then setScreen should work for non-desktop desktoplike
> containments, right?

it does.

> ...I have a feeling that that would cause other pain, 
> though, because I bet there's more code that assumes containments that
> serve as a desktop must be of type DesktopContainment.

no.

> oh btw, I'm working on a new containment. should I put it in extragear or
> playground? :)

playground, where all new plugins start.
then review, then extragear, if all goes well.

-- 
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/20080312/d4559282/attachment.pgp