D18380: KIO: make file dialog columns resizable again (and movable)

[René J.V. Bertin]

rjvbb added a comment.


  > 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 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).
  
  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.
  
  > 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).

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190127/f6f48a89/attachment.html>