Some suggestions to address this, also considering that if the widths are adjusted manually, all the changes are lost when we move to another filter or item inside a filter (package group, pattern, ...):

1) Remember the column widths in a YaST2 session when moving from one filter to another, and perhaps remember the column widths across sessions (which would also sort of need remembering the size of the window). Or perhaps have an "auto-size", given that the space needs vary as the list content changes. However, "auto-size" is not easy to do right, because in many cases there won't be enough space for all the text to be displayed and the question is which ones to shrink and by how much. Besides, just determining the desired widths can take too much time. OTOH the code to get and set column widths in Qt4 is pretty simple, and hopefully integrating it in YaST is not too difficult either.

2) Shrink "Size", enlarge "Installed (Available)" and make "Summary" the stretchable column. Or, what seems better to me but takes more coding, have "Size" use a fixed width and the other columns stretchable. "Size" is the only column that really doesn't benefit from stretching, its maximum width being small and easy to calculate. (IIRC, having multiple stretchable columns in a QTableView makes them all have the same size, which we probably wouldn't want in this case, but it's not that bad; it's possible, though, that I didn't research this area enough or that you are not using QTableView. Also, it's not too hard to do a proportional resize manually when the grid is resized.)

If you have a working patch for this with Qt4, please attach it.

There doesn't seem to be a simple way to fix this with Qt4. In the current version (yast2-qt-2.17.19, yast2-qt-pkg-2.17.15) the width of the "size" column is fixed to match its content, and if the user resizes columns, the resized widths remain in effect even if the table content is cleared and completely replaced.

But there doesn't seem to be a reasonable way in Qt4 to have table columns resize to fit their content, stretchable, and user-resizable. You can have any one of the three, but not a combination.

Will keep investigating; this is really annoying.

I'm no Qt4 guru, but I used QTableView in the last months, and my previous suggestions seemed doable, so I figured I could probably do a patch.

First of all, I wasn't able to find yast2-qt-2.17.19. I couldn't find a Subversion server with the sources, and as for RPMs, the latest I could find was 2.17.18, using http://software.opensuse.org/search to search in Factory. Even then, I didn't really know what other packages I needed to build "Qt4 YaST", and how to actually proceed and do it. I took a look at http://en.opensuse.org/SUSE_Build_Tutorial, but it seemed rather complicated, so I gave up.

Anyway, I looked at the source and I saw that you don't use QTableView, but QTreeWidget, so my knowledge doesn't necessarily apply. I'm not sure that I understand correctly "Comment #3" above, and I can't currently see how this version works, but it seems to me that now no column is stretchable. If that's the case, and since both QTableView and QTreeWidget use QHeaderView, I expect this to work:

   In YQPkgList::YQPkgList(QWidget*):
       horizontalHeader()->setResizeMode(1, QHeaderView::Stretch);

This would make the second column stretchable, which to me is good enough if the other columns' widths are fixed and remembered when going from one package group to another.

Sorry, in Comment #4 "horizontalHeader()->setResizeMode(1, QHeaderView::Stretch);" should be replaced by "header()->setResizeMode(summaryCol(), QHeaderView::Stretch);"; I copied the code from a QTableView and forgot to adapt it.

The problem with the above approach is that it's no longer user resizable if you set a QHeaderView column to "stretch" mode. I tried that, and that's even more annoying than the original problem: If anything still doesn't quite fit on the screen (which is very common in package selection), there is no way to make it visible. 

You can have either QHeaderView::Stretch or QHeaderView::Interactive, but not both. IMHO that's a severe limitation of that widget; this should not be an "enum", but flags that can be combined with logical "or".


The sources are here:

Base class: QY2ListView

http://svn.opensuse.org/svn/yast/trunk/qt/src/QY2ListView.h
http://svn.opensuse.org/svn/yast/trunk/qt/src/QY2ListView.cc

Intermediate base class for package selection related lists, including packages, patches, patterns, and more:

http://svn.opensuse.org/svn/yast/trunk/qt-pkg/src/YQPkgObjList.h
http://svn.opensuse.org/svn/yast/trunk/qt-pkg/src/YQPkgObjList.cc

Derived class for packages:

http://svn.opensuse.org/svn/yast/trunk/qt-pkg/src/YQPkgList.h
http://svn.opensuse.org/svn/yast/trunk/qt-pkg/src/YQPkgList.cc

*** Bug 406631 has been marked as a duplicate of this bug. ***

Created attachment 251881 [details]
stretchable column example

Stefan, I think I understand what you are saying, but I don't think you're right. What I'm saying is that you can have 1 stretchable column and the others user-sizable, and I'm attaching a little program to prove it (in HeaderResize.tar.bz2).

All the widths are adjusted by clicking and moving the separator at their right, except for column "3", which is stretchable. It looks a little weird, because when you resize columns "4", "5" or "6" they extend to the left; anyway, they expand and shrink in a consistent manner.

What about QHeaderView::ResizeToContents ?

You're right, Qt4s' column/row resizing options are "strange". Reporting bugs related to this issue to Trolltech is futile (I already tried several times)...

I don't know the code structure, but column resizing should be necessary only in 2 cases:
- everytime the list content changes
- at resize events (implement virtual void QWidget::resizeEvent())

If the "automatic" resizing functionalities are not adequate, simply write a custom column-width-calculation-function. Then call it followed by QTableView::setColumnWidth(...) in both of the above mentioned cases. That's all.

I could write a patch, but I would need some guidance through the code...

Hello, am I missing something or is there no patch yet included in Beta 5.2? Bug #406631 mentioned something about some fixes?

The fix for this resulted in bug #447273 (version numbers missing). 
(Partly) fixed again, this time hopefully without introducing a new bug with yast2-qt-pkg-2.17.20.

I am still at a loss here: the issue with too small columns, especially for the available/installed version is not fixed it RC1. What am I missing here?

Created attachment 256913 [details]
YaST software module when maximized

The version column does not use the additional available space. This would enhance the users' experience a lot...

If only it were so simple...

Column handling changed a lot with Qt4. It used to be pretty smart in Qt3, but now most of the responsiblity is being relegated to the application. Unfortunately, there is no mode that does all the things we' like to have here: Adapt to content width, stretch to use all available space, yet allow the user to resize the columns manually. Those three options are now mutually exclusive.

Is it possible for SUSE to make an enhancement request with the Qt4 team for the features you would like to see?

Every time I bring up this screen I manually pull the bar over so that I can see the contents fully.

Created attachment 259514 [details]
Proposed solution for resizing the columns

I'm working on an open source program which needs for a QTableView to show as much information as possible. Now that I'm (mostly) done with that, I adapted it to work with a QTreeWidget and I tested it in YaST to address this bug. Since I'm quite pleased with the results, I'm posting a patch in the hope that others will have a look and perhaps it will be integrated into the official build.

The main idea is to resize the columns based on cell content, after the list has been populated.

The way my class is connected now to YaST is more of a hack currently, but improving this is no big deal.

In the attachment I included the patch as well as the changed/new files, so they can be easy looked at.

To build YaST, have a look at http://en.opensuse.org/YaST_Development

To apply the patch, copy ColumnResize.patch to <YaST-dir>trunk/qt-pkg , then go to <YaST-dir>trunk/qt-pkg/src and run:
  patch -p1 < ../ColumnResize.patch

Please let me know if you have trouble building or if you think the resizing can be significantly improved (there should be no horizontal scrollbar and most of the content should be visible, but it may be that what I did works well on my machine and not so well on others).

Created attachment 271070 [details]
Another patch for discussion

I've found some time this weekend to take a look at this issue:

First of all: thank you Marian for your patch. I've tested it and it works without problems, the results are OK for me.
But I guess the main problem with this patch is, that it might be a bit too complicated. It adds much code, which then has to be maintained by Stefan...(Stefan, tell us the truth ;-) ).

However, I've written another (simpler) patch for discussion:
It adds a new function YQPkgList::optimizeColumnWidths() and calls it each time a package is added to the list (YQPkgList::addPkgItem(...)). It does the following:

1.) get optimal widths by setting them with QTreeView::resizeColumnToContents(...)
2.) determines visible width of the Widget
3.) calculates difference of both values
4.) optimizes column widths according to the following strategy:
	- distribute overhead space to all columns (except the status-icon-columns), if we have more space than we need
		=> +:	looks much better
		=> -:	we waste space when the window is resized (to a smaller width), because there is currently no column width adjustment/optimization on resize-events
	- reduces width of the "summary"-column (there is a lower limit), if we have less space than we need; if that is not enough, we will get a horizontal scrollbar

Step 4.) is of course discussable. It should be easy to experiment with it (see code comments).
Please tell me what you think about it, so that we can solve this annoying issue soon.

Frank

I think my approach provides more flexibility than is needed in this case, so keeping it simpler is better. OTOH, if fast column resizing based on content that exceeds the width of the table is needed in several other places, it might be a better idea to have a standard solution somewhere and use it. (Well, actually I think this kind of functionality should be part of Qt.)

In my tests the screen looked OK, except for one thing: if you sort by the first column (package status), as I do, its width expands, supposedly to accommodate the arrow (which doesn't actually need any more space), which makes the horizontal scrollbar visible and the "size" column partially obscured.

Created attachment 271962 [details]
Patch for column width optimization V2

Here is an improved version of the patch.
This one works really great, because the column widths are now optimized on window resize, too !
I also fixed the issue reported by Marian.
The optimization process/strategy is still the same as in the first patch, but I had to split the function into 2 and the sized-to-contents widths are no saved as global data members (=> improved performance on window resize events).

Stefan, what do you think about it ?

Thank you for your contributions! But I need to ask you for some patience. We are doing a bit of internal reshuffling here.

*** Bug 469919 has been marked as a duplicate of this bug. ***

*** Bug 470071 has been marked as a duplicate of this bug. ***

*** Bug 486993 has been marked as a duplicate of this bug. ***

*** Bug 513242 has been marked as a duplicate of this bug. ***

As far as the fixed width size column is concerned, there is an anomaly where my size column is 9 characters wide and David Rankin's size column is 8 characters wide. This results in my size column displaying correctly as long as the size is <1000 and > 1023 but David's size column doesn't display correctly for >99.
ie. If the installed size is 99.0 KiB we can both view it correctly and if it's 100.0 KiB then I can view correctly but David's is obscured. If the size is 
1019 KiB then both of us have an obscured view of that cell.
Both of us seem to have the same yast/qt4 versions. What would cause this difference?
See the attachments of https://bugzilla.novell.com/show_bug.cgi?id=513242

Concerning bug 513242 (fixed size of the "size"-column):
there is indeed no need make this column non-resizable. It can be fixed by deleting the line

header()->setResizeMode( sizeCol(), QHeaderView::Fixed );

from the constructor of YQPkgList.

However, the patches hanging around here for a long time now will resolve this issue, too.
In the meantime I got some ideas for further improvements, but Novel/SUSE seem to be not very interested (although this issue is open since 8 months now and has already 5 duplicates), so at this point, I better spend my free time working on some other projects I'm involved in.

some people (like me) who test factory get hardened to the cosmetics of yast software management but you can resize all of the columns except for package size. it's the only thing that enables people like myself with limited bandwidth to limit unnecessary downloads of things like qt4 devel-doc packages for instance. So why not just delete the line mentioned in #26,  AFAIR the columns used to fill the full window once.

Shouldn't setColumnWidth( sizeCol(),          fms.width( " 9999.9 K  "        ) );
be :-   setColumnWidth( sizeCol(),          fms.width( " 9999.9 KiB  "        ) );
to resolve bug  bug 513242 properly.

Implemented setColumnWidth( sizeCol(),         fms.width( " 9999.9 KiB  "        )
in my own yast2-qt-pkg-2.18.9-1.4-x86_64.rpm using rpmbuild and my size column is now the correct width to display > 999.9 KiB in full and qt pkg works fine.
I have a build service account, I just haven't worked out how to use it yet and my home directory isn't visible otherwise I could make it public.
Should I post a patch?

Made submit request to YaST:Head yast2-qt-pkg-2.18.9-fxszcol.patch
IMHO a fixed size size column is fine.

(In reply to comment #17)
> Created an attachment (id=271070) [details]
> Another patch for discussion

Snipped 

> Please tell me what you think about it, so that we can solve this annoying
> issue soon.
> 
> Frank

I just tried your patch and it conflicts with my one but it certainly works very well so I am going to submit your patch instead of mine. Hope thats ok with you.

Submitted yast2-qt-pkg-2.18.9-colSzOptimize_V2.patch to YaST:Head on build service
The package is available from :- 
http://download.opensuse.org/repositories/home:/plater:/branches:/YaST:/Head/openSUSE_11.1/
If you are brave enough to try it, you will need YaST:Head and zypp:Head repositories enabled as well and your yast and zypp instalation systems will become bleeding edge, it's working fine for me though on factory versions of x86_64.

yast2-qt-pkg-2.18.10 contains the patch. Many thanks to Frank Schäfer for the patch and Dave Plater for testing.

Great news and thank you for your efforts Dave !
When I find some free time again, I will create another patch which should optimize and speed-up the current code enormously (without changing the optimization policy).
Happy holidays !