Bug 330503

Summary: Table headings not adjustable
Product: [Unmaintained] muon Reporter: mike.summerton
Component: muonAssignee: Jonathan Thomas <echidnaman>
Status: RESOLVED UNMAINTAINED    
Severity: wishlist CC: aleixpol, bugseforuns, MurzNN, silhusk, sitter, s_chriscollins
Priority: VLO Keywords: triaged
Version First Reported In: 5.8.0   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description mike.summerton 2014-01-28 10:49:18 UTC
Cannot see the full version of an update because the version column is too narrow and is not adjustable, at least not using the mouse.  There appears to be no way of accessing the hidden part of the version.

Reproducible: Always

Steps to Reproduce:
1.Open muon update manager with updates available.
2.Try to adjust the version column width by dragging the divider.
3.Divider is not selectable
Actual Results:  
Version is not fully visible with my default setup and the column width does not change.

Expected Results:  
The column width changed.
Comment 1 Harald Sitter 2014-01-28 10:58:58 UTC
Qt 4 doesn't have the best sizing policies in the world unfortunately, so I don't think this will change to be honest. The other options are: have-width-changable-but-default-spacing-is-crap and have-width-changable-but-write-10000-lines-of-code-managing-smart-default-spacing. Neither particularly nice.

Perhaps it would be enough to show a tooltip? So, if you hover over the version that you cannot read you get the full version number.

Also, please note that usually you'll have the version displayed in the changelog widget that comes up when you select a package for upgrade, so this bug has limited impact.
Comment 2 mike.summerton 2014-01-28 11:26:06 UTC
In my experience, the changelog is empty more often than not, so this is not acceptable.  A tooltip is an acceptable workaround and so is making the version number column wide enough by default to display a full version number (I take a version such as 32.0.1700.102 to be typical).
However, I do find it strange that implementing either an adjustable column width or an intelligent one is such an issue, as it is rare to see this feature not implemented in a tabular display in any environment.
Comment 3 Harald Sitter 2014-01-28 11:56:54 UTC
(In reply to comment #2)
> However, I do find it strange that implementing either an adjustable column
> width or an intelligent one is such an issue, as it is rare to see this
> feature not implemented in a tabular display in any environment.

Actually it is neither simple nor correctly implemented most of the time for this particular type of table. Not every table is the same :S

    m_updateView->header()->setResizeMode(0, QHeaderView::Stretch);
    m_updateView->header()->setResizeMode(1, QHeaderView::ResizeToContents);
    m_updateView->header()->setResizeMode(2, QHeaderView::ResizeToContents);

That is why you cannot manually resize the columns and technically that should give 100% appropriate results, except it doesn't because this basically mandates that one resolves sizes from right to left rather than left to right and that is hard/impossible to communicate. Additionally there's a two way relationship between name and version as neither should be truncated (ultimately).

To put it in plain english the best spacing would be: allocate as much width as the longest value in the size column requires, then allocate as much width as the longest value in the version column requires, then fill the remainder with the name column.
 But, this is actually not the best spacing because version can have a wide spread (e.g. I have a version 0.0+git20140118+r2937~e006697+neon6~ubuntu13.10.1 while I know a package that has 1.0-1), so you'd additionally require a minimum constraint on name to prevent version from pushing name off the table (i.e. version would take up all the width minus size_width so that there is no space left for name) . Now this minimum could not be a fixed value but needed to be computed on-the-fly 'smartly'. For example the minimum could be so that 90% of all package names fit inside. This minimum however now restricts the rule we initially defined for version.
So, our best spacing is now: allocate as much width as the longest value in the size colum requires, then *calculate* as much width as the longest value in the version column requires and *calculate* whether at least 90% of the names column's values will still fit and if not then use whatever value accomodates that but if it fits then allocate the calculated width, finally allocate the remaining width to name. Gets more complicated already, and I am sure there's other cases that needed to be considered.

It is in particular the two way relationship between name and version that makes any attempt to get correct spacing rather complicated. And at the end of the day one of them will have to be rated lower than the other (i.e. one will have to be truncated when space runs out). Also this massive pile of compuation would need to happen over and over again whenever content changes or the window is resized, and the more entries there are the more expensive this entire thing gets to the point where it potentially locks the application for seconds while it is recalculating the column spacing :S
Comment 4 Harald Sitter 2014-03-19 12:04:09 UTC
*** Bug 332308 has been marked as a duplicate of this bug. ***
Comment 5 Aleix Pol 2015-01-15 15:29:06 UTC
Can I have a screenshot displaying a case where this is a problem?
Comment 6 Murz 2015-01-15 15:35:59 UTC
Here is screenshot: http://i.imgur.com/RpffdSC.png - I can't see full version of Adobe Flash plugin and other packages.
Other big problem is that I can't see current installed version of package, for compare how mutch is version difference (major update or minor bugfix version).
Comment 7 Andrew Crouthamel 2018-09-25 21:37:10 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 8 Murz 2018-09-26 06:33:52 UTC
This issue is still reproducible with Muon version 5.8.0 on KDE Frameworks 5.47.0.
Comment 9 S. Christian Collins 2021-10-27 14:51:29 UTC
This bug seems to be resolved now, as tested on the following configuration:

OS: KDE Neon 5.23 User Edition 
Plasma Desktop 5.23.2
KDE Frameworks 5.87.0
Qt 5.15.3

Muon doesn't appear to have been updated (still at 5.8.0), so it looks like the fix came through one of the KDE libraries?
Comment 10 Christoph Cullmann 2024-09-23 18:22:10 UTC
Muon is no longer maintained, please switch no a supported alternative like https://apps.kde.org/discover/ or the package manager native no your system.

Sorry for the inconvenience.