ben at meyerhome.net
Sun Jan 1 19:47:36 GMT 2006
On Sunday 01 January 2006 4:24 pm, Till Adam wrote:
> 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,
What is wrong with using the theme to determine that?
> 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.
What about QTreeView, QTreeWidget, QTableView, QTableWidget, and QListView?
Many developers will want to pass a model to the view and not have to
populate it via a widget api. I really really do not what to make a kde
version of each one of these qt classes. And what about people who write new
views based upon QAbstractItemView? Will we have a KAbstractItemView too?
If these really are fundamental problem or missing feature with Qt's view's
that every application should have it be brought up to the trolls to get in
I took a brief look at the kde3 views before 4.1 was released and after
finding the theme check concluded that it was a good solution.
I am not sure what you are referring to with number 2 looking at the
klistbox. klistview and kiconview docs I don't see any mention of a timer or
#3 I think could be easily added to qt's views.
> A few issues I'd like some input on, though:
> - 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.
The qt4 model view system is so different then the qt3 code that I push for
moving the current code into support.
Public Key: http://www.icefox.net/public_key.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel