[ANNOUNCE] KExtendableItemDelegate

Benjamin Meyer ben at meyerhome.net
Tue Apr 10 09:56:12 BST 2007


[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.

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.  

- Props for writing documentation.
- 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
- Rather then having private variables you should have a private class
- Should m_extendIcon and m_contractIcon be private or have accessors?
- Rather then saying "It is your responsibility..." a code snippit would be 
really usefull.
- Should extenderDestructionHandler() be private?
- extenderCreated should emit with a const QModelIndex &
- Not required, but spending five minutes on some basic autotests would be 
really cool.

-Benjamin Meyer




More information about the kde-core-devel mailing list