adam at kde.org
Sun Jan 1 15:24:00 GMT 2006
Today I looked into porting KListBox, since I need it for KLineEdit, where
it's used for the completion box, which I need for KInputDialog, which was
the thing I initially wanted to port. As far as I can see the raison d'etre
for KListBox, KIconView and to an extend also KListView is treefold:
1) support for honoring the system settings for single/double click selection
2) support for timer based auto-selection on hover
3) mouse cursor change over items.
1) is supposed to be addressed by Qt, in 4.1, but it turns out that it honors
the system setting by asking the QStyle for a hint, which means the
responsibility it transfered to the style authors. While we could decide to
rely on that, it might make sense to continue explicit support for our own
kconfig based switch directly for the time being, and since there is also 2)
and 3), I guess these classes will have to keep existing.
So the natural choice is to use QListWidget as their new base class, and port
them to that. A few issues I'd like some input on, though:
- signals like execute and doubleClicked add a second parameter with the event
position, which QListWidget no longer delivers. We can figure out the
position ourselves, but is that worth it? If something relies on the event
position, should they not be reimplementing the event handler instead? I'd
rather remove that parameter.
- the doubleClicked signal's API docs say it's there "for completeness" and
should not be used. It only makes sense if we keep the extra position
parameter, otherwise it's redundant, I think. Shall we remove it?
- there's quite a bit of duplication between KListBox and KIconView, shall we
try to merge those into one class, not unlike QListWidget/View does?
- If we change the name anyhow, would it be easier to leave the old classes as
is, put them into kdesupport and write a new one implementing the features
mentionend above in it? People will have to port heavily anyhow, since the
QListWidget interface is substantially different from Q3ListBox/Q3IconView,
so we might as well make it more explicit.
KListView goes beyond the issues mentioned above, so I've left it out of my
considerations for the moment. Does anyone have a battle plan for that one
yet at all?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel