kdiroperator detail view

[Anders Lund]

On Saturday 13 October 2007, Peter Penz wrote:
> 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?

B is not usable in the case of kates sidebar, a widget which was copied by at 
least 4 other applications during kde3.

So I'm for A, in fact I think that B is so bad that if it is chosen, I can't 
use the widget but will have to fork it.

-- 
Anders

www: http://www.alweb.dk
jabber: anderslund at jabber.dk