Bug 141238

Steve Hill on Fedora bugzilla reported the same bug on 0.9.1 version.

https://bugzilla.redhat.com/238193

Created attachment 22365 [details]
failed attempt to solve the issue ...


The following summarizes an attempt discussed with Gilles on the IRC:

In digikam/folderview.cpp album tree view re-implements Qt class.
Trying to setVScrollBarMode(QScrollView::Always) 
and setHScrollBarMode(QScrollView::Always)
does not work: Then the problem is that the horizontal one appears, 
but one cannot scroll ...
The default is QScrollView::Auto, so it should work.
Gilles suspected that the content size of viewport is not 
properly defined and because of this the scroolbar do not appear:

"""AlbumFolderViewItem class does not set dimenssion somewhere and 
this class is a child of FolderItem and this one re-implemente 
paintCell() where the dimension must re-computed.
Qt doc : http://doc.trolltech.com/3.3/qlistviewitem.html#paintCell
"If you reimplement this function, you should also reimplement width()."
"""

The attached patch provides a reimplementation of width(), currently
just returning 600, for testing purposes.
This value should be large enough to trigger the automatic use of a 
horiztonal scroll-bar.

However, it does not work.

So that's currently the end of the story, ideas are welcome!

Marcel,

Your viewpoint ???

Gilles

Marcel, 

No idea about comment #2 from Arnd ?

Gilles

I disabled paintCell and width() completely, still the scrollbars are not working. Maybe this is a totally different issue?

The only thing that works here is to use setResizeMode(Q3ListView::NoColumn);

Then scrollbar will always be visible, but it is working. I think this is normal, looking at Eclipse right now it also shows the horizontal scrollbar all the time, even if the contents would fit in the frame.

Right now we use LastColumn, which will resize the columns to fit the width of the folderview. So turning of resizing the columns seems to be the only way.

Another note: QListView (Qt4) will work better I guess, but we can only use it later on when switching to model-view concept.

Andi

With QT4, we need to use QTreeWidget, not QListView... i think

Just my experience... to have already tried to port this code to Qt4, but without to re-define Model/View (I have used default class as well)

Gilles

I just tested this with the ImagesList (QTreeWidget) widget from KIPI: the same issue. When I enter a big value into the EyeCounter column of RemoveRedEyes, the text gets truncated and you can not scroll, because ImagesList resizes its columns.

So this is just the normal behavior. We need to turn off resizing and it is working. Also Kmail will not show me horizontal scrollbars, because Kmail also resizes the columns.

I suggest to just remove all resizing code from the views and it is working.

Arnd,

actually your patch is working fine, if resizing is turned off, the column will be 600px wide. But you can not see the effect when resizing takes place.

Andi

So what to do here? The only possible solution seems to be to display the horizontal scrollbar all the time...

Any other suggestions?

Andi

Again: Should we just display the horizontal scrollbar all the time? Seems to be the only way.

Andi

If this is the only way to fix that bug... +1 for always showing of horizontal scrollbar.

Looking at many apps I use daily (Eclipse:GTK, amarok1:Qt etc) they all have the hori scrollbar active all the time.
Maybe this is just a normal behavior?

Andi,

No. it's not the normal behavior. Look konqueror folder view for example.

To have take a look indeep in folderview/folderitem code recently, i'm pretty sure that the problem is in itemRect() method. Investigations still in progress.

Gilles

But konqueror folderview has more than one column, this is a totally different behavior. It uses columns that are not automatically resized, so when space is missing, folder names will be cut of and "..." is attached.

I have not seen one app that will automatically resize the column when expanding folder items and show the scrollbar if needed, since the column only knows its absolute size (the width containing all nested items).

So when adding heavily nested album trees, the column will be for example 1000px wide, always. To have auto scrollbars, you need to resize the column, which will result in a very big sidepanel that is not resizable by the user.

At least this is what happens here all the time when I try to implement something.

To sum it up: the konqueror folderview doesn't work the same way then the one in digiKam (at least in KDE3).

Andi

(In reply to comment #15)
> So when adding heavily nested album trees, the column will be for example
> 1000px wide, always. To have auto scrollbars, you need to resize the column,
> which will result in a very big sidepanel that is not resizable by the user.

Now I'm confused by my own words :-)

What I meant was to get rid of the column cutoff (and the "..." chars),  we need to auto-resize the column (Q3ListView::AllColumns / LastColumn). This is all ok in our code.

If you resize the folderview (pull the slider to the left), the column itself will not get smaller (and the scrollbars should appear). This is the behavior we expect, but it seems to be that in this resizemode scrollbars are never shown.

I can see this effect in other apps with other toolkits like GTK, too.
Maybe I'm getting things wrong here, but for me it looks like this is the only way to do: display the hori scrollbar all the time.

Andi

Created attachment 29881 [details]
Konqueror KDE3 folder view

Andi,

You is wrong here (:=))) Look my screenshot of Konqueror folder view from KDE3...

Gilles Caulier

But if you collapse the folder structure, the scrollbar will still be visible (the more you expanded, the wider the scrollbar will be).
So it is displayed all the time actually.

Created attachment 29882 [details]
tree collapsed again

scrollbar still showing (because the column size is resized now and not auto-resized to the current folder view width). This is the behavior I am talking about... :-)

I have reproduced this behavior, the thing is that the scrollbar will be visible mostly all the time then (if you every expanded your tree and collapse it again).
When using autoresize like we do, no hori scrollbar is ever displayed, because the column size is applied to the current folderview size. So there is no need to display a scrollbar, because the column is not wider than the folderview.

SVN commit 1029595 by aclemens:

I really think we should set the resizeMode for AlbumFolderView and
TagFolderView to NoColumn, otherwise the column is just re-sized to the width of
the folder view and items that are beyond the size are invisible.
Maybe the Qt4 version behaves better, but since we still use a Qt3Support class
here, there just doesn't seem to be a better solution.

I'd rather have a scrollbar visible all the time than not be able to see nested
albums :-)

CCBUG:141238

 M  +2 -3      albumfolderview.cpp  
 M  +2 -3      tagfolderview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1029595

I will close this one for now, I guess the Qt4 port will solve the problem in a more elegant way.
Anyway the main problem should be solved now.

Andi

SVN commit 1044060 by aclemens:

Fix (hopefully at last) the FolderViews.
Qt3 and Qt4 acts strange here, columns are either resized to the list view
width (this is stupid) or it maximizes the column, but doesn't grow the column
when the view is actually wider than the column.

We now calculate the column width our self, and it seems to finally work fine.
A too small view will show scrollbars, a wider view will switch to
LastColumn-ResizeMode.

To see the old "weird" behavior in Qt4, just fire up Kmail and resize the
folder view, the last column will stay where it is.
But this is necessary to have a scrollbar, because otherwise the column is
always resized.

I think this is a bug, because a normal QScrollArea acts not like that, but a
ListView somehow does.

CCBUG:141238

 M  +0 -1      albumfolderview.cpp  
 M  +29 -1     folderview.cpp  
 M  +0 -1      tagfolderview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1044060