kdiroperator detail view

Peter Penz peter.penz at gmx.at
Sat Oct 13 11:04:11 BST 2007


Hi Anders,

On Saturday, 13. October 2007 08:31, Anders Lund wrote:
> IT's STILL not working well, in Kates sidebar the name column isn't
> correctly resized, file names arent' fully visible. Exp with the missing
> tooltip this makes usage bad.
>
> What is wrong with my original patch?

I think that are 2 factors that make the "automatic resize column width" 
feature difficult to implement:

1. The number of resize events depends whether KDirLister has the items in the 
cache or not. Although David Faure mentioned that KDirLister can be fixed to 
behave similar no matter whether the cache is available or not, I still think 
the root of the issue is to rely on a given number of resize events...

2. The auto-resizing is turned off in KDirOperatorDetailView::resizeEvent() as 
soon as model()->rowCount() > 0. This means if the size of e. g. the first 10 
loaded items is quite small, the autoresizing might work quite well. As soon 
as other items are loaded later, no autoresizing will be done anymore and 
hence items might get clipped if they are larger than the first items.

From my point of view for KDE 4.0 we should consider using one of the 
following approaches:

A) Just let QTreeView do the job of resizing the columns. Don't try to stretch 
the columns ourselves in the resizeEvent()... This makes it easy to enable 
the resize mode QHeaderView::Interactive, so that the user can adjust the 
width if wanted. I think his approach would be the same as we have in KDE 3.

B) Go back to the original approach where we stretched the columns to the 
available width of the viewport. But in this case QHeaderView::Interactive 
could not been activated in an easy manner... I think this approach worked 
very well in the file-dialog, but as you said in Kates sidebar a custom 
resizing of columns might really be useful, which is not offered here...

C) Combine the benefits of A + B, but this might be really time consuming and 
tricky to implement (although I'm sure this is possible :-)).

Honestly speaking I fear I have no time for implementing C for KDE 4.0. 
Personally I'd go for approach B, but no matter whether we go for A or B: I 
think the behavior should be consistent and not depend on the cache or the 
directory content.

Do you have a suggestion which way we should consider?

Thanks!
Peter





More information about the kde-core-devel mailing list