[Kommander-devel] listbox setSelection patch

[Eric Laffoon]

Hi Silvan,

On Thursday 27 March 2008 7:07:31 am Silvan Calarco wrote:
> Hi Eric,
> well looking at the code the setSelection and setCurrentItem call the same
> function (setCurrentItem):
>
>     case DCOP::setSelection:
>     {
>       QListBoxItem* found = findItem(args[0], Qt::ExactMatch);
>       if (found)
>         setCurrentItem(index(found));
>       break;
>     }
>
>     case DCOP::setCurrentItem:
>     {
>       int index = args[0].toInt();
>       if (index < (int)count())
>         setCurrentItem(index);
>       break;
>     }
>
> The only difference is in the argument (the index versus the string).
> As the QT functions name suggests I thought it was more clear that:
>
> setCurrentItem calls QT's setCurrentItem
> setSelection calls QT's setSelected
>
> Furthermore the setCurrentItem listbox function just moves the keyboard
> pointer to the item (the listed item is , but does not select it, so
> it's "partially" selected as reported in this old post:
>
> http://mail.kdewebdev.org/pipermail/kommander/2006-September/001436.html
> ) so I think the current implementation is far as useful as the setSelected
> function and it's different from user expectations.
> Finally adding a "setSelected" function would be ok too, but I still would
> find incoherent the association betweek setSelection and setCurrentItem.
> Thank you for your interest in this issue.
>
> Cheers,
> Silvan

Well since you put it that way it does seem a little broken. I am probably 
responsible as I remember vaguely Michal asking about this years ago. As a 
heavy Kommander user (or is that ham-fisted?) I find I need to access either 
the index or selected text of a dialog at different times for the same 
purpose. Also I have signals and slots set up to do things with them 
that "come undone" for instance on initialization, so I need to call them. 
Not the same, but I probably should look at the docs and ponder. Of course 
the problem is that what we end up with is either allowing diverse behaviors 
the become confusing or forcing some people to accept something they don't 
want. One inherent truth is that Kommander is a little different than regular 
programming, so every issue needs to be looked at without preconceptions for 
find the best solution. From what you say something needs to be done... the 
question is what. I also added functionality recently to this widget and in 
the interest of fair play I'm posting the diff here if you are interested.

Here's the inpetus for this patch. I created a data table where the table 
widget has a data value showing in a column. When a user clicks in that 
column a created combo appears. This combo is fed by complimentary arrays (a 
good reason to make another patch) and feeds the database key value to a 
hidden column using signals and slots and a created script. Clicking outside 
the cell causes the widget to disappear and the selected text to be written 
to the cell, thus destroying the widget until it is recreated.

The problems arose using keyboard entry. AFAIK there is no way to tab to a 
ComboBox and manually change it's selection. So I created a Kommander 
function to popup the list which you can call. Maybe I should have added a 
gotFocus slot. It's easy to detect in the table anyway.

Focus events can be easily added as they are inherited from QWidget
===textedit.h
signals:
  void lostFocus();
  void gotFocus();
===textedit.cpp
void TextEdit::focusOutEvent( QFocusEvent * e)
{
  QTextEdit::focusOutEvent(e);
  emit lostFocus();
}

void TextEdit::focusInEvent( QFocusEvent * e)
{
  QTextEdit::focusInEvent(e);
  emit gotFocus();
}

I think I should insure focus events for all widgets  in KDE4.
-- 
Eric Laffoon
Project Lead - kdewebdev module
-------------- next part --------------
A non-text attachment was scrubbed...
Name: combobox.diff
Type: text/x-diff
Size: 1917 bytes
Desc: not available
Url : http://mail01.fortunecookiestudios.com/pipermail/kommander-devel/attachments/20080327/a359a786/combobox.bin