[PATCH] Make KListView honor renameability

[Ravi]

On Friday 19 December 2003 11:43 am, David Faure wrote:
> On Friday 19 December 2003 17:38, Ravi wrote:
> > On Friday 19 December 2003 03:11 am, David Faure wrote:
> > > 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.

I see that I was not clear. Consider the following patch which ensures current 
behavior and is compatible with Qt's model as well:

Index: klistview.cpp
===================================================================
RCS file: /home/kde/kdelibs/kdeui/klistview.cpp,v
retrieving revision 1.211
diff -u -p -w -r1.211 klistview.cpp
--- klistview.cpp	6 Nov 2003 02:06:41 -0000	1.211
+++ klistview.cpp	19 Dec 2003 16:40:39 -0000
@@ -1152,6 +1192,13 @@ bool KListView::itemsMovable() const
 void KListView::setItemsRenameable(bool b)
 {
   d->itemsRenameable=b;
+  QListViewItemIterator it( this );
+  while ( it.current() )
+  {
+    for ( QValueList<int>::iterator col = p->renameable.begin(); col != 
p->renameable.end(); ++col )
+      it.current()->setRenameable( *col, b );
+    ++it;
+  }
 }
 
 bool KListView::itemsRenameable() const
@@ -1323,7 +1370,7 @@ void KListView::cleanItemHighlighter ()
 
 void KListView::rename(QListViewItem *item, int c)
 {
-  if (d->renameable.contains(c))
+  if (d->renameable.contains(c) && item->renameEnabled(c))
   {
     ensureItemVisible(item);
     d->editor->load(item,c);
@@ -1341,10 +1388,20 @@ void KListView::setRenameable (int col, 
 
   d->renameable.remove(col);
   if (yesno && d->renameable.find(col)==d->renameable.end())
+  {
     d->renameable+=col;
+  }
   else if (!yesno && d->renameable.find(col)!=d->renameable.end())
+  {
     d->renameable.remove(col);
 }
+  QListViewItemIterator it( this );
+  while ( it.current() )
+  {
+    it.current()->setRenameable( col, yesno );
+    ++it;
+  }
+}
 
 void KListView::doneEditing(QListViewItem *item, int row)
 {

The trouble is doing the same to any new QListViewItems that are added. We can 
always know about the addition of new toplevel items since they call the 
virtual function QListView::insertItem(), but we never know about additions 
lower in the hierarchy. If QListViewItem was a subclass of QObject, we could 
solve it like this, by monitoring for additions of QListViewItems and then 
calling the appropriate setRenameEnabled() function:

void KListView::childEvent( QChildEvent *e )
{
  if ( e->inserted() )
  {
    QListViewItem *lvi = dynamic_cast<QListViewItem*>( e->child() );
    if ( lvi )
    {
      lvi->installEventFilter( this );
      if ( p->itemsRenameable )
      {
        for ( QValueList<int>::iterator it = p->renameable.begin(); it != 
p->renameable.end(); ++it )
          lvi->setRenameable( *it, true );
      }
    }
  }
}

bool KListView::eventFilter( QObject *o, QEvent *e )
{
  if ( e->type() == Qt::ChildInserted )
  {
    QChildEvent *ev = dynamic_cast<QChildEvent*>( e );
    if ( ev )
    {
      QListViewItem *lvi = dynamic_cast<QListViewItem*>( ev->child() );
      if ( lvi )
      {
        lvi->installEventFilter( this );
        if ( p->itemsRenameable )
        {
          for ( QValueList<int>::iterator it = p->renameable.begin(); it != 
p->renameable.end(); ++it )
            lvi->setRenameable( *it, true );
        }
      }
    }
  }
  return QListView::eventFilter( o, e );
}

Of course, this would be yet another event filter hack (but given that 
KListView is full of them, I wouldn't mind adding another one). The only way 
I can think of is to count the number of items each time we need to paint 
(since new items will need painting), and that would kill performance.

Regards,
Ravi