[PATCH] Make KListView honor renameability

[Ravi]

On Friday 19 December 2003 03:11 am, David Faure wrote:
> This setting defaults to false, right? I can't find it in the docu (grmmbl)
> but the code seems to initialize it to false. In that case, I strongly
> object, this is going to break existing code.

You are right. I have been using this patch for a while now, but I realize 
that I don't use any apps that allow in-place renaming. Apart from kfm, are 
there any such apps out there?

> It's quite scary indeed - there's a global setItemsRenameable and a
> setRenameable per column (in KListView), and a setRenameEnabled per column
> per item (QListViewItem). But QListView doesn't appear to have global
> settings, only per item settings, that's where their model differs.
> I don't see how this can be cleaned up in a BIC way before KDE 4.

Agreed. After playing around with it for a while, I cannot find a way for the 
list view to know that a QListViewItem has another child item. (The generic 
way of using QChildEvent is not available since QListViewItem is not a 
subclass of QObject.) The problem then is that KListView is NOT a drop-in 
replacement for QListView. Should we document this somewhere?

Are we going to conform to Qt's model in KDE 4? I prefer the Qt model since it 
allows much more flexibilty, and is intuitive to use.

For my app, I have to choose between conforming to KDE style settings 
(SingleClick, etc.) or maintaing two branches of my code. Damn :-(

Regards,
Ravi