Hello,
I have two folders which I normally view each in a separate tab. However every now and then I need to view them side by side (ie. splitview).
So what I do is select splitview in one tab, change to the other tab, copy the URI, go back to the other tab and insert it in one of the split views.

Kind of cumbersome, so I was wondering if it is possible to directly "merge" two tabs into one tab with split view?

Also I'm missing an indication in the tabs with splitview. For example the tab title could change to "folder A | folder B" and a special icon would be nice IMHO.

fakd wrote:I have two folders which I normally view each in a separate tab. However every now and then I need to view them side by side (ie. splitview).
So what I do is select splitview in one tab, change to the other tab, copy the URI, go back to the other tab and insert it in one of the split views.

Kind of cumbersome, so I was wondering if it is possible to directly "merge" two tabs into one tab with split view?

No, it's not possible at the moment, and I don't think that this is possible to implement in a good way. What workflow should be used for merging the tabs? Offer the option in the context menu of a tab? Then you would have to click the other tab after that, and we would have to make sure that the tabs which already contain split views are disabled for this click. And this is only the most obvious problem that I see at the moment. Moreover, a lot of complex code would be required for such a feature, and considering that it would only be useful in a few corner cases (and that https://bugs.kde.org/show_bug.cgi?id=177031 got zero votes or comments in almost 5 years), I'm afraid that implementing this does not make sense. Sorry about that.

fakd wrote:Also I'm missing an indication in the tabs with splitview. For example the tab title could change to "folder A | folder B" and a special icon would be nice
IMHO.

This has been discussed some time ago: https://git.reviewboard.kde.org/r/104305/. The outcome was that even if the idea looks nice at first sight, there are quite a few problems with it if you have a closer look.

freininghaus wrote:

fakd wrote:...Kind of cumbersome, so I was wondering if it is possible to directly "merge" two tabs into one tab with split view?

No, it's not possible at the moment, and I don't think that this is possible to implement in a good way. What workflow should be used for merging the tabs?

Ideally it should be possible to select two tabs (ctrl + left mouse) and then hit the splitview button. If there is already a splitview in one of the tabs, the splitview button should be greyed out. Here someone suggest to use ctrl click on tabs instantly for splitview, I could live with this, too.
But I see that it is currently not possible to select tabs (using the context menu would be ****), is it planned to make tabs selectable? Maybe then it wouldn't be so complex anymore to introduce such feature(?).
(In the above mentioned post, TheBlackCat said he wanted to introduce drag&drop for tabs, which would go into this direction...)

freininghaus wrote: ...and that https://bugs.kde.org/show_bug.cgi?id=177031 got zero votes or comments in almost 5 years

Well, there was a duplicate 4 Years ago.. and I could comment something now.

freininghaus wrote:

fakd wrote:Also I'm missing an indication in the tabs with splitview. For example the tab title could change to "folder A | folder B" and a special icon would be nice IMHO.

This has been discussed some time ago: https://git.reviewboard.kde.org/r/104305/. The outcome was that even if the idea looks nice at first sight, there are quite a few problems with it if you have a closer look.

Hmm, reagarding how many votes the brainstorm has, I find the reasoning against this patch rather lame. Especially since they are quite easy to fix, for the active folder one could use an asterix or bold text or or .... Regarding the space problem, ideally the inactive folder should be shortened first (I know complex). But even if not, when one has more tabs open than screen width available (for it) one just hast to live with it, IMHO.
And all the above doesn't apply to an special icon for splitview.

fakd wrote:

freininghaus wrote:

fakd wrote:...Kind of cumbersome, so I was wondering if it is possible to directly "merge" two tabs into one tab with split view?

No, it's not possible at the moment, and I don't think that this is possible to implement in a good way. What workflow should be used for merging the tabs?

Ideally it should be possible to select two tabs (ctrl + left mouse) and then hit the splitview button. If there is already a splitview in one of the tabs, the splitview button should be greyed out. Here someone suggest to use ctrl click on tabs instantly for splitview, I could live with this, too.
But I see that it is currently not possible to select tabs (using the context menu would be ****), is it planned to make tabs selectable? Maybe then it wouldn't be so complex anymore to introduce such feature(?).

If you or someone else implements "making tabs selectable" in QTabBar, then we can talk about it

But even then, giving the "Split View" button different meanings, depending on whether multiple tabs are selected or not, will definitely require more complex code.

fakd wrote:

freininghaus wrote: ...and that https://bugs.kde.org/show_bug.cgi?id=177031 got zero votes or comments in almost 5 years

Well, there was a duplicate 4 Years ago..

The duplicate was from exactly the same user who reported the first report.

fakd wrote:

freininghaus wrote:

fakd wrote:Also I'm missing an indication in the tabs with splitview. For example the tab title could change to "folder A | folder B" and a special icon would be nice IMHO.

This has been discussed some time ago: https://git.reviewboard.kde.org/r/104305/. The outcome was that even if the idea looks nice at first sight, there are quite a few problems with it if you have a closer look.

Hmm, reagarding how many votes the brainstorm has, I find the reasoning against this patch rather lame.

Did any of the people who voted for the feature on Brainstorm consider the possible unpleasant side effects? And if we implement it, how many users who did not read the suggestion at all will report the new behavior as a bug?

This is the reason why many developers don't like to respond to feature requests: All users who see the suggestion find the feature great, and as soon as you point out any kind of problem with it, your reasoning is "lame" and you are the "lazy" developer who "just doesn't listen to users".

If, on the other hand, you implement the feature, then the moment it is shipped to users, all those users who did not think about the possible bad side effects start complaining about them. Please believe me, this always happens.

I should not have responded to this topic - I guess that it's best to not waste any of my little spare time (which could also be invested into bug fixes, for example) discussing feature requests, because whatever I do, it's always wrong

freininghaus wrote:Did any of the people who voted for the feature on Brainstorm consider the possible unpleasant side effects? And if we implement it, how many users who did not read the suggestion at all will report the new behavior as a bug?

This is the reason why many developers don't like to respond to feature requests: All users who see the suggestion find the feature great, and as soon as you point out any kind of problem with it, your reasoning is "lame" and you are the "lazy" developer who "just doesn't listen to users".

If, on the other hand, you implement the feature, then the moment it is shipped to users, all those users who did not think about the possible bad side effects start complaining about them. Please believe me, this always happens.

Of course if there is an suggestion for improvement, there has to be an discussion about possible negative side effects. But I don't see the special case here, since improving software is what we all want and most of the dev work is this, too (besides from fixing broken things).

The other view on this is, dev tell user to move their feature request from BKO to brainstorm (to see if more users are interested). So then they are on brainstorm, but still with an huge* amount of votes, they still don't get accepted - this is not satisfying either.
And in contrary to BKO on brainstrom you can even downvotes requests. So what was missing here was IMHO the discussion on brainstorm, were possible flaws of this patch should have been discussed. And then one could see if the majority would agree on sacrificing space vs. overview.

freininghaus wrote:I should not have responded to this topic - I guess that it's best to not waste any of my little spare time (which could also be invested into bug fixes, for example) discussing feature requests, because whatever I do, it's always wrong

Well, I know talking to users is a tedious task. But IMHO user - dev communication is part of the KDE community, so thanks for that.


*:
Considering the (sad) fact that about ~5 user are active on brainstrom, 43 is huge. (I know the time factor (its ~1year old) somehow diminish this.)