[ANNOUNCE] KExtendableItemDelegate

[Andreas Hartmetz]

On Tuesday 10 April 2007 10:56:12 Benjamin Meyer wrote:
> [snip]
>
> > It was not planned to be in the public API. When I added it to kdelibs,
> > it was not planned to have it public. Well, kdelibs didn't compile the
> > way I put it in, and somebody added its .h file to CMakeLists.txt to fix
> > compilation. So, it's already in the public API.
> > It can be made private if most people think it's too special or too
> > unused [zero users outside of kdelibs ATM - cf. rules for new public
> > classes] to warrant a place in the public API.
>
> Not talking about if the class is bad or good, but it is bad precedence for
> us to make things public long term just because they were accidently made
> public.  The class should be made private until there are two uses outside
> of libs as our policy states.
>
If not enought interested developers appear in the next one or two days, I'll 
make it private and put a copy into to the new kdelibs evaluation thing.

> Besides it shouldn't be public when there is a comment like this
>
> //TODO:follow binary compatibility rules
>
> :P
> :
> > It also breaks some assumptions of the Model/View/Delegate design,
> > especially the one that a delegate holds no persistent data. The delegate
> > needs to remember which items have an extender widget.
> >
> > HOWEVER, I think it is in fact very useful in many situations. It vastly
> > simplifies programming in its use case. You can put large editor widgets
> > directly next to the data they edit.
> > KShortcutsEditor, the widget in the "Configure Shortcuts" Dialog, makes
> > use of it, if you are curious about its mechanism and looks.
> > As mentioned in another thread, KShortcutsEditor is still under
> > development. The code of KExtendableItemDelegate is in
> > kdelibs/kdeui/itemviews/kextendableitemdelegate.cpp/h.
> >
> > Are there any prospective users, or do you have comments on its design?
>
> It is a neat class.
>
Thank you. Thank you also for taking the time to review it.

> - Props for writing documentation.

Hehe. There was a question on IRC about the possibility to insert widgets into 
a view. I already had like two beers at the time and made most of the 
one-liners in the documentation in 25 minutes ;)

> - To match the rest of kdelibs style you want to run the code through
> astyle --indent=spaces=4 --brackets=linux --indent-labels --pad=oper
> --one-line=keep-statements --convert-tabs --indent-preprocessor $file

Yeah, I planned to do this when the class was more or less done. I guess it is 
done enough now :)
Kate has visible tabs, which makes tabs really really covenient.

> - Rather then having private variables you should have a private class

This was planned (see TODO :) )

> - Should m_extendIcon and m_contractIcon be private or have accessors?

They are intended to be set by subclasses. You have to subclass 
KExtendableItemDelegate anyway to do anything useful, I guess.
With private data in a private class, there is will be no other choice than 
protected accessors.

> - Rather then saying "It is your responsibility..." a code snippit would be
> really usefull.

OK.

> - Should extenderDestructionHandler() be private?

Yes. If you want to do some cleanup as an API user, there is a signal to tell 
you about destruction of an extender. This is a very good candidate for a 
private slot.

> - extenderCreated should emit with a const QModelIndex &

Yes. I misinterpreted normalization.

> - Not required, but spending five minutes on some basic autotests would be
> really cool.
>
Uh oh, I really have no idea how to autotest GUIs.

> -Benjamin Meyer