Extender api review, round 2

[Aaron J. Seigo]

On Wednesday 30 July 2008, Alex Merry wrote:
> On Wednesday 30 July 2008 22:23:58 Rob Scheepmaker wrote:
> > On Wednesday 30 July 2008 21:32:24 Alex Merry wrote:
> > > Question: who owns Extenders?  Applet, or the creator of the Extender?
> > > If the Applet owns it, then I can't create it on the heap (ie: as a
> > > non-pointer member of my subclass), and a factory method might be
> > > safer. If the creator owns it, they have to keep a reference to it to
> > > clean it up anyway.
> >
> > Applet is the creator of the extender, so I don't really get your
> > question.
>
> Oh, I suppose they're all QObjects, so its just the QObject parent
> mechanism. So there's no need to worry about owning or deleting.
>
> If I wanted to have a widget as a detachable item, what would I do?  From
> what I can see of the API, it would be something like, in
> initExtenderItem(), I'd have
>     if (item->name() == "MyExtender") {
>         item->setWidget(new MyWidget);
>     }
>
> And in init(), I'd have something like
>     Extender* extender = new Extender(this);
>     ExtenderItem* item = new ExtenderItem(extender);
>     item->setName("MyExtender");
>     initExtenderItem(item);
>
> Is this right?



> This doesn't feel natural to me: it looks like Extender is
> just another widget/other child of the applet.  When it's really more of a
> one-off thing, like a layout.

besides the fact that layouts are just another child object, yes, Extender is 
another widget associated with the applet. it happens to be a special sort of 
one, however.

> So I'd find something like
>     setExtender(new Extender);
>     ExtenderItem* item = new ExtenderItem(extender());
>             // or ExtenderItem(this)
>     // yadda yadda
> or
>     setExtender(new Extender);
>     ExtenderItem* item = new ExtenderItem(name);
>     initExtenderItem(item);
>     extender()->addItem(item);
> more natural.

i personally don't like this because:

* Extender now has no explicit ownership
* instead of just doing the new, you also have to set it
* it implies that an extender is useful on its own without an applet (it 
isn't; it's a decorator of sorts, not an indepedantly useful item)

as for having to set the name of the item separately or in the constructor .. 
if it requires a name to be useful then yes it should be in the constructor.

if we do end up supporting more than one extender per applet (still unsure of 
that one myself =) then setExtender breaks completely =)

> I also don't like the initExtenderItem() method, but I also can't see how
> to get around it without forcing people to subclass ExtenderItem or create
> all the ExtenderItems it might need in init().

neither are really options.

> I'm afraid I'm coming at this without a clear idea of the concepts around
> extenders, except that they allow users to pull parts of applets away from
> the main widget.

the point is to allow aditional, usually either transient or more detailed, 
items to be shown as an extension to an applet. those items are detachable and 
mixable.

examples might be notifications in a notifier or calendar information in a 
clock.

-- 
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/plasma-devel/attachments/20080730/021fd8e4/attachment-0001.pgp