markg added a comment.
In D18380#400910 <https://phabricator.kde.org/D18380#400910>, @rjvbb wrote: > > But still, isn't there another way? Now the header and view are locked together. One doesn't work without the other. > > What's the problem with that? The custom header class isn't public. I did indeed use it for stuff that were not part of a class, or of the KDirOperatorDetailView class in earlier iterations. There's no hard reason for that, I just find it tidier (and it saves me from having to compile all other modules that import the kdiroperatordetail view headerfile when I change a detail that doesn't concern them). > > > The thing that triggered me to comment wasn't any of that though. It's the "narrow mode". I cannot see how that wouldn't be seen as a bug by a user. With that little trick you're also overruling any font spacing settings the user might have had (in fontconfig) which is quite likely going to cause unexpected behavior and therefore bug reports. > > I'd say make a test case and convince us. You may have missed the fact that I'm no longer doing anything to the used font (the same in all columns). I'm just using the event flow to let Qt determine column widths using whatever information it wants, and then I "fixate" those widths in order to restore interactive mode. This is an admittedly complex way to do something that Qt doesn't allow us to do: 1) set interactive mode, 2) ask QHeaderView for the width that would be used in one of the automatic modes, 3) set those modes (with a minimum imposed on the name column). I know. I'm not attacking you here :) I've been in the same annoying situation countless of times when wanting to have this very feature. It's a pain Qt doesn't give it. But there are ways to solve it and yours is on the complicated side. > I can imagine that someone might file a bug about the name column getting a bit larger when resizing. In practice I'm not convinced many users will even notice this because it will happen only once, making the column more readable (and how much time does one spend resizing side-bars anyway). I think this is a bridge to take if and when we get there. A possible workaround would be to calculate our own minimum width in such a way that we arrive at the width Qt later decides to pick for some reason (for the default font at least). This is a typical "last mile" thingy. Yes, it works. But not as perfect as it could be which eventually is going to add up in hundreds of other "last mile" things. Each on their own not worth the time to fix. All together giving the user a "yep, they still need to work uit some bugs" feeling. > Something we (= a number of us) need to look into is what happens when you resize a view *after* a manual column adjustment, and what should happen in that case. Knowing that anything to make the manual adjustment permanent will only increase the code complexity. I'd say the last column will be the victim there. Just enable setStretchLastSection(true) (works in my example too) and let a resize be handled that way. This results in the view leaving all columns exactly as is when resizing except for the last column. The user still has to resize the name column to make it bigger/smaller and that very action should be stored and restored next time. It saves the hassle of trying to figure out what the user intended. > > >> The size calculation is not perfect > > My initial implementation wasn't perfect either (Nate complained how it worked in narrow mode) ... and addressing that was what introduced most of the complexity. > > At this point I have invested enough time and energy in what is essentially a behavioural detail. I like doing that kind of thing but I'm not motivated enough to start from scratch (I'll consider making little changes but not much more). Your work is well appreciated! It triggered me to look into it as well. Together we can probably figure out a perfect solution that does't leave any hiccups that the user will consider a bug, however short they might be. And as an added bonus might be used as a generic better QHeaderView version. p.s. This custom header view thing should definitely be a candidate for probably KItemViews. Not my version as-is, but the concept of having more flexibility in the header view. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D18380 To: rjvbb, ngraham, #frameworks, #dolphin, apol, dfaure, ahartmetz, markg Cc: markg, cfeck, dhaumann, kwrite-devel, kde-frameworks-devel, michaelh, ngraham, bruns
