[PATCH] Make KListView honor renameability

[David Faure]

On Friday 19 December 2003 17:38, Ravi wrote:
> 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?

keditbookmarks, for one.

> > 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.
??
QListViewItem::firstChild ... but I can't see the relation with the above.

> The problem then is that KListView is NOT a drop-in 
> replacement for QListView. Should we document this somewhere?
Feel free to document differences in KListView's class docu.

> 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 renaming, I'm fine with using Qt's model.
For DND that's another debate.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions