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

Reply via email to