KListBox/KIconView/KListView

[Till Adam]

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 
of items 

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? 
KListWidget, then? 

- 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?

Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060101/4ed772d1/attachment.sig>