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/komm
ander/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
_______________________________________________
Kommander-devel mailing list
Kommander-devel mail.kdewebdev.org
http://mail.kdewebdev.org/mailman/listinfo/kommander-d
evel
|
--
Eric Laffoon
Project Lead - kdewebdev module
_______________________________________________
Kommander-devel mailing list
Kommander-devel