Bug 333744

Please see the discussion at bug 290747.

*** This bug has been marked as a duplicate of bug 290747 ***

I took quite some time, looking at bug 290747 and every single bug mentioned/linked from there. There isn't a single mention about anything even remotely related to what I'm asking here.
I think my question isn't duplicated, and certainly is a legit question regarding the future of Dolphin.
I'm not asking for Columns view mode *now*. I'm asking if it's reasonable to reconsider bringing that mode back sometime in the future, when everything else is done.

Also, while digging in all the bugs, I red a comment that made me think about the reason behind the removal of this feature. There was a huge code refactoring that was supposed to split the core/engine and the view modes. From what I understand, a view mode shouldn't cause bugs in other view modes nor in the core (if there is a real separation and if it's done correctly). If that is the case, why columns mode isn't bringed back?

Can I get 5 minutes of your time and receive an answer, please?

(In reply to comment #2)
> Can I get 5 minutes of your time and receive an answer, please?

If you had spent 2 minutes reading the first two comments to bug 290747, you would have found this:


(a) The Columns View required a lot of complex code, and put a very high maintenance burden on the very small team of developers.

Some more details about this, which can also be found easily: Complex code was required not only in the Columns View class itself, but everywhere else. Changes in every part of the code base often required special code paths for the Columns View.


(b) The Columns View had only very few users.

We know this because of the feedback we get all the time at bugs.kde.org and elsewhere. For example, the Columns View had quite a few bugs which were easy to reproduce, but which were reported only very rarely. Moreover, the number of complaints about the removal of the Columns View was close to zero. In contrast, there were many small changes in Dolphin, which looked a lot less harmful than the removal of a view mode, but which generated many more user reactions.


When deciding which features to include in an application, one always has to evaluate if a feature is useful enough for a large enough part of the user base to justify that a lot of effort is spent on it - not only when implementing the feature itself, but forever. The cost incurred by ongoing maintenance is *much* higher than the one that is required for the initial implementation.

> I took quite some time, looking at bug 290747 and every single bug
> mentioned/linked from there. There isn't a single mention about anything
> even remotely related to what I'm asking here.

Yes, there is, see above.

> I think my question isn't duplicated, and certainly is a legit question
> regarding the future of Dolphin.
> I'm not asking for Columns view mode *now*. I'm asking if it's reasonable to
> reconsider bringing that mode back sometime in the future, when everything
> else is done.

No, it's not. There is never a state when "everything is done".

> Also, while digging in all the bugs, I red a comment that made me think
> about the reason behind the removal of this feature. There was a huge code
> refactoring that was supposed to split the core/engine and the view modes.
> From what I understand, a view mode shouldn't cause bugs in other view modes
> nor in the core (if there is a real separation and if it's done correctly).

Feel free to look at the code base and figure out ways to separate the logic more cleanly. The problem is that the Columns View is just so different from everything else that a lot of specialized code is needed for it, and adjustments have to be made all over the place to ensure that it works. Just one example: In all current view modes, there is a single scroll bar and only a single number that is needed to keep track of its offset (OK, in a very narrow Details View you also get a horizontal scroll bar, but that does not change much).

Lots of code interacts with the scroll offset (think of the part that restores the view state when going "back" in history, for example). All this code must be changed if a view mode with different columns, each having their own scroll bars, is re-introduced.

And this is just one tiny example.

(In reply to comment #0)
> A file browser must serve the purpose of letting users, well, ...browse
> their files... preview them, sort them, get some information about them. A
> file browser isn't expected to have any text-editor features nor
> image-editor features, nor anything that is not strictly related to file
> browsing. My point is, 
> given the proper nature of the application Dolphin, after a certain amount
> of time and after a certain amount of patches, it will get to a bug-fix
> (maintenance-only) situation where no further things would be implemented
> because everything a file browser should have would be already implemented.
> 
> That means that, once achieved that maintenance-only state, no further man
> power would be needed, which means that some features that were dropped some
> time ago, because they (and I'm quoting exact words here) "introduced an
> internal code complexity that raised the 'entry-barrier' for contributors",
> could be bringed back, right?

No. There never is a state where no further man power is needed. We get loads of bug reports all the time, some of which are actually about real bugs in Dolphin which have existed for many years, and which no one has found earlier.

Moreover, changes in Qt, kdelibs and many other places sometimes also require changes in Dolphin.

And even if there ever was a state where no further work would be required, then implementing a feature that makes future maintenance a pain, and which is used by a very small part of the user base only, is definitely not the right way to deal with it.

> Do you think it is reasonable to reconsider bringing the columns view back?

No, see above.

> And one last question: Do you consider my reasoning valid or do you think
> I'm making wrong assumptions about Dolphin reaching maintenance-only mode?

Yes, you are making wrong assumptions, see above.

BTW, even if we completely disregard the effort required to make changes in the code, maintenance also means to deal with the flood of incoming bug reports. A very large amount of time is required to handle the reports which are about bugs which have been fixed long ago, are not reproducible, are bugs in libraries, etc.

Which makes me come back to

(In reply to comment #2)
> Can I get 5 minutes of your time and receive an answer, please?

You got more than 45 minutes of my time now (i.e., about 75% of the time that I am able to spend on Dolphin per day on average). Was that time well spent? I don't know. It will have no positive effect on Dolphin at all, and probably you will disagree with me anyway and say that we are developers who do not listen to users. Moreover, if every user insisted that the maintainer explains decisions that were taken years ago over and over again, and answers questions for which lots of answers that can be found easily, then no useful work will be getting done ever again.

If you still disagree, feel free to use the last Dolphin version that had the Columns View (it should be quite easy to build it from source if you install kdelibs-devel packages). You can also fork Dolphin and re-implement the Columns View on top of the latest code if you think it's worth the effort (your report makes me think that you do). Forks of file managers whose maintainers take unpopular decisions are not unheard of, and if enough people agree with you, they will use your fork.

*** This bug has been marked as a duplicate of bug 290747 ***

> You got more than 45 minutes of my time now (i.e., about 75% of the time
> that I am able to spend on Dolphin per day on average). Was that time well
> spent? I don't know. 

It was. You replied to a user, which is something that quite some projects (even paid ones) don't do.

> Complex code was required not only in the Columns View class itself, but 
> everywhere else. Changes in every part of the code base often required 
>special code paths for the Columns View.

I'm not sure I understand this. Wasn't Dolphin 2.0 supposed to bring a complete split between core and views?
I'm not trying to troll here, but if the views depend that much on core code, you're doing it wrong. And that is something
that even a first-year Comp. Sci. student can tell you. Maybe it's time to give another look at Dolphin's base?

> (b) The Columns View had only very few users.

I agree on this one.

Overall, I get your point. Thank you for giving me an answer.

> I'm not sure I understand this. Wasn't Dolphin 2.0 supposed to bring a complete split between > core and views?
Dolphin is written with MVC in mind.

As Frank already wrote, the problems are more the special code paths in the view code (settings, save/restore,  ....) than anything else (from an implementation point of view of course). 

All new code paths would need careful testing and so on, not doable with such a small team of volunteers.

(In reply to comment #3)

Chapeau... !

(In reply to comment #6)
> (In reply to comment #3)
> 
> Chapeau... !

Chapeau... for what exactly? 
For getting an answer explaining how Dolphin's team is so small it can't get a column view implemented? 
For getting an answer explaining how it's not that simple get some view-related code without hacking the core-related code?
For getting an answer that was supposed to make me feel bad because I allegedly took 45 minutes of the time of a dev?

What exactly is the "Chapeau" for?

(In reply to comment #7)
> Chapeau... for what exactly? 

For a LOT of patience! And for taking the (rare spare) time to respond politely in such an extensive way to a single user who just did not understand that everyhing was already said and done!

And believe me I loved the column view too and was very unhappy with the decision. But this is not a forum for discussions.