Created attachment 175630 [details] screenshot of scenario 1 This is a strange one to describe, I guess it it a general issue how tabs and movable things in Qt work. Normally I would expect that in the details view, the information column headers "name" "size" "changed" "type" could be arranged and their width resized, but not beyond the max width of the dolpin window or content section or whatever. But when grabbing the outer side of the most right of these header columns and dragging it to the right, outside the screen, I can pull it further and further and the scroll bar at the bottom appears to scroll through the window to the right. Actually, the issue seems to be that there is no hard barrier to the right. When resizing a side of one of these headers, and "pushing" the one to the right" outside the dolphin window width, the window just gets wider easily, which makes no sense. It should not be possible to move stuff outside of the window. This should not happen at all I think. Dolphin should not be expandable to the right, there should only be a scroll bar for vertical scrolling. Operating System: Fedora Linux 40 KDE Plasma Version: 6.2.2 KDE Frameworks Version: 6.7.0 Qt Version: 6.7.2 Kernel Version: 6.11.5-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland
Created attachment 175631 [details] video here you can see a bunch of things 1. it is not always possible to grab the outmost side. This should be default behavior, the most right column header outer side should not be grabbable at all but fixed to the most right window width 2. sometimes it is grabbable, kinda randomly 3. pushing a header beyond the normal window width barrier is easily possible 4. sometimes it is then possible to move it outside, the horizontal scrollbar appears which shouldnt happen
it is also possible to shrink the max width of these headers, to the left and to the right. This also makes no sense, they should always fill the whole width and there shouldnt be the possibility to have empty space to the left and right do you agree?
Confirmed that on Dolphin built from git-master it's possible to expand column headers beyond the right most border of the window On my system I'm always able to grab the right border of the right most column header (this is true on 24.08.2 as well) This may be intentional behavior on the part of QT / KDE, I'll leave it to more experienced contributors to explain that. Can you explain more what you mean by "shrink the max width of these headers"? I am able to shrink the headers so they don't fill all the space to the right - I assume this is what you describe? I'm not able to make blank space between the leftmost column and the left side of the window.
.
(In reply to Henning from comment #0) > This should not happen at all I think. Dolphin should not be expandable to > the right, there should only be a scroll bar for vertical scrolling. This is not always possible IMO. We should always allow users to add as many columns as they want. At some point there will be more columns than what fits the view. This is expected. Users are then allowed to scroll to the right to see the information of every column they have enabled. I kind of agree with the basic wish of this report though that it does not make a lot of sense that we allow increasing the size of columns even though they currently fully fit into the view. However, actively disabling this seems like a lot of work for very little gain. Not sure how I feel about it.
I thought a bit more about this and this request as it is would lead to major issues. The thing is that a file can have e.g. a file comment, song title, authors, or some other information which is extremely wide. Users need to be able to resize such a column until they can read the full data. So we should not prevent users from increasing the size of such columns. The logical consequence is that the columns can get too wide for the view/window. There could be an argument being made that we should identify such columns that can have very wide data in it and only allow resizing such columns. I am not sure though if that wouldn't just lead to a weird user experience because users would then get used to resizing sometimes working and sometimes not. >But when grabbing the outer side of the most right of these header columns >and dragging it to the right, outside the screen, I can pull it further and further >and the scroll bar at the bottom appears to scroll through the window to the right. There is a bug there which I am fixing which is that resizing the right padding at the same time increases the size of the previous column even if the goal was to only reduce the padding to zero. I am fixing this by adding a soft boarder, so one really needs to push hard and mean it to also resize the last role column.
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/877
Git commit 95542a389112491abf3a31c338e7d78f7785f48e by Felix Ernst. Committed on 29/12/2024 at 11:42. Pushed by felixernst into branch 'master'. Mirror details view mode for right-to-left languages This commit implements mirroring of the details view mode for right-to- left languages. This is the last of the Dolphin view modes which did not adapt to right-to-left languages correctly. Implementation-wise this is mostly about adapting the math so all the information is placed correctly no matter the view mode or layout direction. While most of the view actually changes the painting code for right-to-left languages, for the column header I decided to keep the logic left-to-right and instead reverse the order of the role columns. To implement this mirroring I needed to rework quite a bit of logic, so I used the opportunity to fix some bugs/behaviur quirks: - Left and right padding is now saved and restored separately instead of only saving the left padding - Changing the right padding no longer disables "automatic column resizing". - The grip handles for column resizing can now be grabbed when near the grip handle instead of only allowing grabbing when slightly to the left of the grip. - Role column headers now only show a hover highlight effect when the mouse cursor is actually above that role and not above the grip handle or the padding. - There is now a soft-boarder when shrinking the right padding so shrinking the padding "below zero width" will no longer immediately clear automatic resize behaviour. So now it is possible to simply remove the right padding by resizing it to zero width. Related: bug 449211 # Acknowledgement This work is part of a my project funded through the NGI0 Entrust Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology. M +14 -28 src/kitemviews/kitemlistcontroller.cpp M +10 -5 src/kitemviews/kitemlistheader.cpp M +5 -4 src/kitemviews/kitemlistheader.h M +6 -6 src/kitemviews/kitemlistview.cpp M +30 -11 src/kitemviews/kitemlistwidget.cpp M +6 -4 src/kitemviews/kitemlistwidget.h M +48 -25 src/kitemviews/kstandarditemlistwidget.cpp M +2 -1 src/kitemviews/kstandarditemlistwidget.h M +182 -144 src/kitemviews/private/kitemlistheaderwidget.cpp M +25 -12 src/kitemviews/private/kitemlistheaderwidget.h M +6 -2 src/settings/dolphin_detailsmodesettings.kcfg M +7 -1 src/settings/dolphin_detailsmodesettings.upd M +9 -4 src/settings/viewmodes/viewsettingstab.cpp M +10 -5 src/views/dolphinview.cpp M +1 -1 src/views/dolphinview.h https://invent.kde.org/system/dolphin/-/commit/95542a389112491abf3a31c338e7d78f7785f48e