| Frameworks |
It uses an imported and improved version of QColumnView for display.
KFileItemDelegate got amended with an arrow if used inside KColumnView,
to replace the bad arrow drawing on top that vanilla QColumnView did.
If KColumnView turns out to be useful also outside of this, it can eventually
(after a period of maturing) be moved into another framework as part of the
public API.
For quick testing, I try navigating around, swapping the root node
and selecting some files. Outside of that, I use this on my main machine
as the default.
| No Linters Available |
| No Unit Test Coverage |
A screenshot before/after (or just after, since it is an addition) would be helpful in this case, since it is a visual change.
I'm not sure if it's a good idea to fork QColumnView in KIO. Is it not possible to contribute the changes upstream?
It's not that easy - QColumnView is practically abandoned upstream (with its huge amount of bugs it received basically no fixes at all), I really dislike the upstream contribution process (not really a valid reason, I know, but it would definitely make it much harder to fix bugs) and KColumnView breaks compatibility in certain ways. Anyway, I did not totally abandon that idea, but it really needs some testing before attempting upstreaming it. I really tried hard to make QColumnView work properly, but it's just impossible.
Sure!
Before: https://i.imgur.com/FXdLwca.png
After: https://i.imgur.com/L2WgmmG.png
Video (uploaded with the column view file dialog :-) ): https://gfycat.com/gifs/detail/HiddenShallowAnteater
Since this adds the column view again, how does this relate to the decision of dropping the column view back in 2012, see comment in this blog:
http://ppenz.blogspot.fr/2012/01/dolphin-20-status-update.html?showComment=1325669619833&m=1
Are the issues of maintenance addressed here?
Exactly because of this confusion (file dialog vs. Dolphin) I would not add columns to the file dialog unless they are also implemented in Dolphin.
Dolphin has an entirely different codebase for displaying items and directories, so none of this applies to dolphin :-(
To answer the maintenance burden question for KIO: There is only little added complexity here, most of it it contained within the KColumnView class.
Some of the supporting code for the tree view also applies to the column view.
The openURL method in KDirOperator has some simple special handling for the fixed root node (which should probably be used for the treeview as well, to have the right behaviour when clicking on directories), but that's about it.
This confusion is based on the programmer's perspective (browsing files -> same code?) and not necessarily the user's perspective.
The file dialog has not nearly dolphin's amount of features, but it does not have to be. Same applies for the other direction.
Having it in Dolphin as well would be great, but IMO it's entirely separate. The file dialog is made for navigating to files and dolphin is made for managing files.
Ok. What about licensing? The copied Qt code says LGPLv3 only, while the kio frameworks uses LGPLv2 (and maybe later). Those two licenses are incompatible - we cannot mix LGPLv3 only with an LGPLv2+ library, except if we make it LGPLv3 only as well.
I don't want to diminish your work here, but the licensing issue can be resolved by upstreaming your work into Qt itself, or by rebasing your work on an older version of Qt that still is LGPLv2, or by rewriting it by forgetting everything you saw previously :-) Licensing sometimes is tricky, and in this case, I think its a showstopper right now.
Or am I mistaken?
I guess I would need to move KColumnView into a license-compatible framework then - any suggestions?
That would be the kitemviews framework.
But really, fixing QColumnView in Qt is the much preferred way to go.
It sure sounds harder right now, but think longer term...
In the past, any time we forked something from Qt, we ended up spending even more time upstreaming the changes later. Even more, because the work has to be redone again, for licensing reasons, except if it's the same person doing both...
I see.
Issue is that:
Additionally there are some bugs I found that need to be fixed meanwhile:
Also, there's still the point that dolphin doesn't implement this and likely never will (if dolphin were using proper QAbstractItemModel it would just work (tm)...).
I'm not quite sure what to do here, but it seems to require a lot of work outside of the actual implementation which I'm not going to to, I'm afraid.
As opposed to KDE where it took more than 2 months to get a reply? ;)
- Nobody seems to maintain this upstream (I expect this to be gone in Qt 6)
Well, there's a new QtWidgets maintainer I hear, and you could become maintainer of QColumnView, problem solved :-)
and this is probably the only user of QColumnView anyway
So https://bugreports.qt.io/issues/?jql=text%20~%20%22QColumnView%22 appeared out of thin air? :-)
- This introduces breaking changes (both API and behavioural), not sure how to align those...
Can't comment without seeing the changes as a diff. API can often be worked around with a bit of redundancy (old method + new method) but behaviour is more difficult indeed.
Additionally there are some bugs I found that need to be fixed meanwhile:
- If the path contains a component that is not included in the KDirModel (hidden, for example), it breaks
- Sometimes it's required to click twice on a folder to open it
That's just bugs, can be fixed :)
Also, there's still the point that dolphin doesn't implement this and likely never will (if dolphin were using proper QAbstractItemModel it would just work (tm)...).
It used to... then they wanted more (e.g. animation when deleting a file)...
(I guess there are more reasons)
I'm not quite sure what to do here, but it seems to require a lot of work outside of the actual implementation which I'm not going to to, I'm afraid.
Your call. I'm not fond enough of column-views myself to offer any substantial help.
But I'm not very happy about a fork of a Qt class ending up in a framework I maintain, in the long run.
We're doing a UI and usability overhaul of the Open & Save dialogs in T8552: Polish Open/Save dialogs, and I think perhaps we should revisit this. I'm very strongly in favor of adding column-based navigation to both KDirOperator and also Dolphin (though I understand that's much more difficult). However I don't think it's the end of the world if we can only add it to the open/save dialogs for now, since navigation is the primary use case for these dialogs. On MacOS, column view is practically the only mode I use for navigation, since it's so much faster than the others.
Is there anything we can do to ease the difficulty of the Qt contribution process for you, @fvogt?
I don't think there is - I don't really want to maintain a component in Qt which I'm not even very familiar with (I only used it once, here).
That combined with the design issues this currently has (hidden dirs etc.) makes this not easy to get into shape. The current patch state is more a PoC than a finished product...
So I'll abandon this diff for now.
Having it as part of dolphin would be nicer, as the open/save dialog is per default too small to have more than two columns visible at a time.
So once this is part of dolphin I'll reconsider this and maybe work on it some more.