[PATCH] KEditListBox::setCustomEditor

[Sebastian Trüg]

On Friday 18 January 2008 13:14:07 David Faure wrote:
> On Friday 18 January 2008, Sebastian Trüg wrote:
> > Please find attached the overhauled patch.
> >
> > I did some more cleaning up:
> >
> >  * moved the setEditor method to the Private class
> >  * moved the init method into the Private class
>
> OK.
>
> >  * Removed the "m_" prefixes from all private members. This is just
> >    confusing
>
> Hmm, I'm not sure this is a good change; the prefix helps differenciating
> member vars from local vars when reading the code of the methods of
> the private class.

I personally find it confusing. Especially because some vars had a prefix and 
some did not (looked as if after porting to a Private class new vars did not 
become a prefix as it is normally done AFAIK). IMHO m_, i.e. member vars are 
those that are defined the the class itself and are private while vars in a 
Private class are to be used in the class via the d-> prefix which then 
replaces the m_ prefix.

d->m_something looks weird.

I agree that it might be non-perfect for methods of the Private class. But you 
cannot have both. Private classes might the good for BC but they are surely 
not beautiful...

> > But I also changed the behavior a bit and hope this gets your OK since I
> > think my changes finally make KEditListBox really usable.
> > Basically what I did was to replace the handling of the current item with
> > the selected item. The result is:
> >
> >  * The user can see their selection now (like they are used to anyway). 
> > The current item is not always visible in all styles and if you have to
> > know what to look for.
> >  * Action buttons are enabled and disabled based on the selection instead
> > of the current item.
> >  * After adding an item (or changing it via return) the selection is
> > cleared which allows to add a new item (in the old version after
> > selecting an item it is impossible to ever add a new one again since
> > there is no way for the user to change the current item)
> >  * The same is true for removing an item. The selection is cleared and
> > the user can add new items or change others.
>
> Sounds good.

:) I hoped so.

> >  * Whenever the selection changes the lineedit gets the focus. This is
> > very convenient as it saves one click and there is no real use for the
> > keyboard focus in the listview.
>
> Are you sure? What about users without a mouse? Can they still use
> Key_Up/Key_Down in the listview?

Hm, users without a mouse can change the selection by tabbing into the 
listview and then changing it. But they have to tab into it for each change, 
i.e. Key_Tab->Key_Down->Key_Tab->Key_Down. While this might not be very nice 
IMHO most users will handle KEditListBox with a mouse and then the focus 
feature is very very convenient.

Cheers,
Sebastian