Bug 408775

Created attachment 120914 [details]
attachment-5774-0.html

I understand the issue here and I'll provide a patch for that.


>
> In general, I'm not quite sure about the splitted tab bars, since imo it
> creates a lot of unnecessary dragging of windows.
> I can see though why some people would want that.
>

There's no need to drag windows, you can navigate with the keyboard.

>
> My suggestion would be:
>
> On splitting:
> If there is only one tab active, open a new tab in the new view to avoid
> having
> to open the new tab manually.
>

splitting doesn't opens a new tab, why do you belive so?

If there are two or more tabs, leave the active tab in the current view and
> split the most recently used inactive tab into the new view.
>

Can you ellaborate on that? from what you explained I don't see how this
could be userfriendly.
I Implemented the split views as it's done in Terminator and Tilix (and
those are currently most used than konsole for userfriendlyness)


> On closing a view:
> Do not destroy any tabs. Really. Don't. _Especially_ not with running
> programs
> inside and without warning.
>

I'll add the check for running programms.

Tabs should *always* be closed by the user, _actively_.
> Instead merge the two tab bars.
>

Tabs are only closed by the users, the only way to close a tab withotu
explicit user is to close the *last* terminal inside of a tab. I can't have
terminals with nothing inside.

For the rest (the mirror mode that you seem keen on using it again) - I'm
not against it but the implementation was broken so I replaced by the
current split code. I'm just one developer and I would happily add the
split mode again, if well developed. Patches welcome.

(In reply to tcanabrava from comment #1)
> >
> > In general, I'm not quite sure about the splitted tab bars, since imo it
> > creates a lot of unnecessary dragging of windows.
> > I can see though why some people would want that.
> >
> 
> There's no need to drag windows, you can navigate with the keyboard.

How? I don't see a way to move a tab to another view with the keyboard.
In the tab bar for each view there is only the tabs for this view available.

> >
> > My suggestion would be:
> >
> > On splitting:
> > If there is only one tab active, open a new tab in the new view to avoid
> > having
> > to open the new tab manually.
> >
> 
> splitting doesn't opens a new tab, why do you belive so?

It does for me. I can see it, since I can see how keychain (is started with each new session) starts up.
Just the way as if I were opening a new tab.

> If there are two or more tabs, leave the active tab in the current view and
> > split the most recently used inactive tab into the new view.
> >
> 
> Can you ellaborate on that? from what you explained I don't see how this
> could be userfriendly.

It kind of depends on what you want from the splitting. In my use case, it would be the most convenient one, since I use the splitting mostly to switch quicker between two tabs I've used often recently.
So automatically putting the the tab used before the currently active one in the new view kind of made sense.
But I can also understand why you would want to start with a new tab instead.

> I Implemented the split views as it's done in Terminator and Tilix (and
> those are currently most used than konsole for userfriendlyness)
I have to admit, I've never tried Tilix. I've used Terminator a bit about 10 years ago, but ever since I've only used konsole.

> Tabs should *always* be closed by the user, _actively_.
> > Instead merge the two tab bars.
> >
> 
> Tabs are only closed by the users, the only way to close a tab withotu
> explicit user is to close the *last* terminal inside of a tab. I can't have
> terminals with nothing inside.

Sure, the user actively closes the current view, but it's really unclear that when doing that the tabs inside that view get closed as well (as opposed to moved to the other view).

> For the rest (the mirror mode that you seem keen on using it again) - I'm
> not against it but the implementation was broken so I replaced by the
> current split code. I'm just one developer and I would happily add the
> split mode again, if well developed. Patches welcome.
Sure.
For me, it was mostly that I just used it as always (actually in a lengthy system configuration session), closed the view and everything inside it was gone.
Cost me 15-30min to get there again. :(

Man, first I would like to apologise for my past reply, I replied with the assumption that you  where using the current released konsole and not the version before that. See, the whole split was complettely rewritten and it does not matches what you wrote as wrong behavior, but it also doesn't matches what you expect from correct behavior either.

The splits are now within a tab, not duplicating the tabbar. Would you please update the konsole or at least compile the current code from source code to test and see if you still don't like the split tab feature? It's completely different from what you described, as correct and as incorrect behavior.

Again, I'm sorry that my previous message was misleading, but at least now I understood where we got wrong on the versions. :)

I thought that 19.04.2 was the latest release version?

But I can of course try current master or any other version you want me to test, that's not a big deal.

Ok, had a quick look at current master and that is better.
It still closes the session in the split view if you close it, but at least you can't close multiple tabs accidentally.
Seems to be bugged if you split both vertically and horizontally though.

Personally, I'd still prefer to be able to split/unsplit with existing/persistant tabs, since that matches my workflow better.
Would be ok if I'd had to use the mouse for that, e.g. right-click on an inactive tab and select 'split view'.

Created attachment 120925 [details]
attachment-26861-0.html

Em dom, 16 de jun de 2019 às 19:37, Bernd Steinhauser <
bugzilla_noreply@kde.org> escreveu:

> https://bugs.kde.org/show_bug.cgi?id=408775
>
> --- Comment #5 from Bernd Steinhauser <linux@bernd-steinhauser.de> ---
> Ok, had a quick look at current master and that is better.


Thanks :)


> It still closes the session in the split view if you close it, but at
> least you
> can't close multiple tabs accidentally.


In my tests it asks you if you want to close if you have an open app, if
you have nothing opened then it just closes. If you want me to look for a
different proposal, I'm all ears. Maybe asking to close if there's more
than two  views in a split?


> Seems to be bugged if you split both vertically and horizontally though.


How? I'm using daily and I'm not experiencing bugs. Can you tell me what
seems wrong? I imagine leme ted recursive splitting so you can have a panel
on the vertical and other in horizontal, the old behavior was bugged: it
shifted the horizontal into vertical, the actual one cottectly handles both
in the same view.


>
> Personally, I'd still prefer to be able to split/unsplit with
> existing/persistant tabs, since that matches my workflow better.
> Would be ok if I'd had to use the mouse for that, e.g. right-click on an
> inactive tab and select 'split view'.
>

You are the 3rd person asking for this so I'm really thinking on re adding
it, but as I said I need help in the form of code.


> --
> You are receiving this mail because:
> You are the assignee for the bug.

(In reply to tcanabrava from comment #6)
> > It still closes the session in the split view if you close it, but at
> > least you
> > can't close multiple tabs accidentally.
> 
> 
> In my tests it asks you if you want to close if you have an open app, if
> you have nothing opened then it just closes. If you want me to look for a
> different proposal, I'm all ears. Maybe asking to close if there's more
> than two  views in a split?

Yes, it does ask if a program is running, so that is fine.
I think the situation where you close multiple tabs when closing a view doesn't occur anymore, since the splitting is now per tab instead of tabs per split.

> > Seems to be bugged if you split both vertically and horizontally though.
> 
> 
> How? I'm using daily and I'm not experiencing bugs. Can you tell me what
> seems wrong? I imagine leme ted recursive splitting so you can have a panel
> on the vertical and other in horizontal, the old behavior was bugged: it
> shifted the horizontal into vertical, the actual one cottectly handles both
> in the same view.

If I do split H and then V, the two smaller panels don't really work. The property bar with the expand/close buttons is only visible on the lower one, there are some graphical bugs and on one occasion konsole actually opened a new half-sized window with the actual session running that should be in the upper view of the V split.
Looking closer at it, it doesn't seem to be a problem with combo splitting, but rather that vertical splitting (which I normally don't use) is bugged.
I see the same behavior if I do only split vertically.
Funnily enough by doing this and closing the original session, I managed to drive konsole to a stage where I do now have konsole without a session running in this tab. I'll attach a screen of that.

> You are the 3rd person asking for this so I'm really thinking on re adding
> it, but as I said I need help in the form of code.

Sorry, I'm not really familiar with c++.
I did some messing around with Audex code, but that was all very straight forward stuff and nothing where you actually had to be creative, so I doubt I could be of help here. :(

Created attachment 120927 [details]
konsole after vertical splitting and closing the active view

Created attachment 120934 [details]
attachment-13159-0.html

Can you send me the hash of your latest commit?
I tried to do the same thing here and for me, it did not fail.

What I tried:
ctrl + t (new tab)
ctrl + ) (new vertical split)
ctrl + d (close active view)

I also tried multiple variations of that:
ctrl + t
ctrl + ( (horizontal split)
ctrl + shift + w (close active session)

Mixing up with ctrl + ( and ctrl + ) for multiple tabs.

how did you download the sources? (what origin, we recently moved to
invent.kde.org)



On Sun, Jun 16, 2019 at 11:16 PM Bernd Steinhauser <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=408775
>
> --- Comment #8 from Bernd Steinhauser <linux@bernd-steinhauser.de> ---
> Created attachment 120927 [details]
>   --> https://bugs.kde.org/attachment.cgi?id=120927&action=edit
> konsole after vertical splitting and closing the active view
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

The revision that was built is:
716884e78e9d16593ea71ed7e6fd12d607bacca8

So the second-to-last commit.

I'm running on KF5 5.59.0 and Qt 5.12.3, in case that matters.

hm, if I start with a clean session, then just splitting either way works, but both ways doesn't.
So:
Ctrl+(
Ctrl+) ← it's borked at this moment
Ctrl+d works, but depending on which screen is selected might leave an empty view behind.

The other way fails as well:
Ctrl+)
Ctrl+( ← borked

The problem, where it's bugged even on a single split doesn't seem to repeat always, I've only triggered that twice.
So not yet sure how to trigger that reliably.

Sources are from the KDE git repo:
https://anongit.kde.org/konsole

Created attachment 120936 [details]
Multiple random splits, seems to work with me.

(first of three pictures)

Created attachment 120937 [details]
ctrl + ( , then ctrl + )

also seems to work with me.

Created attachment 120938 [details]
ctrl + ), then ctrl + (

last of three images.

So, I did a bit of testing and I didn't found an issue - now, I'm not saying that there's no issue, just that I didn't managed to hit it. I'll continue testing here to see if I can find. but I tested many different split variations as you can see in the screenshoots, and they seem to work.
The commit hash you gave me is correct so I'm certain that you are running the current code. There's *one* other thing that I migth ask, tought. When you run the binary did you installed in a different prefix? If so, did you setup your LD_LIBRARY_PATH to look for the konsoleprivate.so in the correct prefix?
*maybe* konsoleprivate is the old one, being loaded in /usr/lib , and you are having a mix of new-konsole + old konsole.

(In reply to tcanabrava from comment #15)
> So, I did a bit of testing and I didn't found an issue - now, I'm not saying
> that there's no issue, just that I didn't managed to hit it. I'll continue
> testing here to see if I can find. but I tested many different split
> variations as you can see in the screenshoots, and they seem to work.
> The commit hash you gave me is correct so I'm certain that you are running
> the current code. There's *one* other thing that I migth ask, tought. When
> you run the binary did you installed in a different prefix? If so, did you
> setup your LD_LIBRARY_PATH to look for the konsoleprivate.so in the correct
> prefix?
It's integrated into the package manager, so it's installed in /usr/lib (or in case of Exherbo rather /usr/x86_64-pc-linux-gnu/lib/).

> *maybe* konsoleprivate is the old one, being loaded in /usr/lib , and you
> are having a mix of new-konsole + old konsole.

hm, the new one was definitely installed and the old one removed, but since I didn't restart yet, it might be that konsoleprivate.so is still in memory and being used by the new one.
Even though I would've expected the new one being loaded when I closed old konsole and then loaded the new one, since I don't have any program opened using konsoleprivate.so.

I'll resume my testing when I've had the chance to reboot (or at least logout), maybe then it's gone.

Created attachment 120939 [details]
attachment-16682-0.html

Thanks, that really helps me testing.

Em seg, 17 de jun de 2019 às 12:26, Bernd Steinhauser <
bugzilla_noreply@kde.org> escreveu:

> https://bugs.kde.org/show_bug.cgi?id=408775
>
> --- Comment #16 from Bernd Steinhauser <linux@bernd-steinhauser.de> ---
> (In reply to tcanabrava from comment #15)
> > So, I did a bit of testing and I didn't found an issue - now, I'm not
> saying
> > that there's no issue, just that I didn't managed to hit it. I'll
> continue
> > testing here to see if I can find. but I tested many different split
> > variations as you can see in the screenshoots, and they seem to work.
> > The commit hash you gave me is correct so I'm certain that you are
> running
> > the current code. There's *one* other thing that I migth ask, tought.
> When
> > you run the binary did you installed in a different prefix? If so, did
> you
> > setup your LD_LIBRARY_PATH to look for the konsoleprivate.so in the
> correct
> > prefix?
> It's integrated into the package manager, so it's installed in /usr/lib
> (or in
> case of Exherbo rather /usr/x86_64-pc-linux-gnu/lib/).
>
> > *maybe* konsoleprivate is the old one, being loaded in /usr/lib , and you
> > are having a mix of new-konsole + old konsole.
>
> hm, the new one was definitely installed and the old one removed, but
> since I
> didn't restart yet, it might be that konsoleprivate.so is still in memory
> and
> being used by the new one.
> Even though I would've expected the new one being loaded when I closed old
> konsole and then loaded the new one, since I don't have any program opened
> using konsoleprivate.so.
>
> I'll resume my testing when I've had the chance to reboot (or at least
> logout),
> maybe then it's gone.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

Unfortunately, that was not it, same behavior after reboot as well. :(

Created attachment 120944 [details]
attachment-19957-0.html

I dont Know what to say, I'll do more tests here.

Em seg, 17 de jun de 2019 às 14:02, Bernd Steinhauser <
bugzilla_noreply@kde.org> escreveu:

> https://bugs.kde.org/show_bug.cgi?id=408775
>
> --- Comment #18 from Bernd Steinhauser <linux@bernd-steinhauser.de> ---
> Unfortunately, that was not it, same behavior after reboot as well. :(
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.

Created attachment 120945 [details]
attachment-20107-0.html

if you can, can you let me control your konsole a bit over teamviewer?
I just tested the splits quite a lot and I got no problem.

On Mon, Jun 17, 2019 at 2:10 PM <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=408775
>
> --- Comment #19 from tcanabrava@kde.org ---
> I dont Know what to say, I'll do more tests here.
>
> Em seg, 17 de jun de 2019 às 14:02, Bernd Steinhauser <
> bugzilla_noreply@kde.org> escreveu:
>
> > https://bugs.kde.org/show_bug.cgi?id=408775
> >
> > --- Comment #18 from Bernd Steinhauser <linux@bernd-steinhauser.de> ---
> > Unfortunately, that was not it, same behavior after reboot as well. :(
> >
> > --
> > You are receiving this mail because:
> > You are the assignee for the bug.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.

Sorry, can't do that, I'm not running team viewer.

I did another test though. I ran konsole inside of urxvt and tried a few things.
On normal splitting, there are no error messages, but as soon as I mix vertical and horizontal splitting, I get about 100 of these messages:
qt.qpa.xcb: QXcbConnection: XCB error: 8 (BadMatch), sequence: 5129, resource id: 35651610, major code: 130 (Unknown), minor code: 3

That gave me an idea that it might actually be related to kwin or how konsole interacts with kwin (since iirc kwin handles the xcb connections).
So as a wild guess, I tried it with the compositor disabled and then it worked!
So to sum up:
compositor activated -> bugged
compositor deactivated -> works

Weird, isn't it?
Doesn't matter which backend for the compositor is used, I tried all of them (normally, I'm using the OpenGL 3.1 backend).
Also played around with the desktop effects and other compositor-related stuff, but couldn't find any further influence.

Created attachment 120946 [details]
attachment-22576-0.html

On Mon, Jun 17, 2019 at 2:59 PM Bernd Steinhauser <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=408775
>
> --- Comment #21 from Bernd Steinhauser <linux@bernd-steinhauser.de> ---
> Sorry, can't do that, I'm not running team viewer.
>
> I did another test though. I ran konsole inside of urxvt and tried a few
> things.
> On normal splitting, there are no error messages, but as soon as I mix
> vertical
> and horizontal splitting, I get about 100 of these messages:
> qt.qpa.xcb: QXcbConnection: XCB error: 8 (BadMatch), sequence: 5129,
> resource
> id: 35651610, major code: 130 (Unknown), minor code: 3
>
> That gave me an idea that it might actually be related to kwin or how
> konsole
> interacts with kwin (since iirc kwin handles the xcb connections).
> So as a wild guess, I tried it with the compositor disabled and then it
> worked!
> So to sum up:
> compositor activated -> bugged
> compositor deactivated -> works
>
>
That's both really weird and really anoying: I run compositor and I have no
issue. I'll forward this to the kwin guys as I really have no idea.
Thank you very much for the tests, I know it's frustrating to have a bug
and not be able to deal with it.
without the compositor, do you like how konsole behaves?

Weird, isn't it?
> Doesn't matter which backend for the compositor is used, I tried all of
> them
> (normally, I'm using the OpenGL 3.1 backend).
> Also played around with the desktop effects and other compositor-related
> stuff,
> but couldn't find any further influence.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.

Not sure, it's certainly not how I used the splitting before.
Guess I'll have to give it a try and see if it's something I'll use or (like many other features of konsole) skip.

What I certainly don't like is the toolbar thingy it adds at each view (the one with the expand view and close view buttons).
That kind of looks out of place to me and the additional bar takes up a lot of space for very low gain.
Also, if you're using the tab bar at the bottom like me, it's weird to have the tab bar below, but then the view toolbar at the top of the view.

Not sure what kind of interface would be better.
Maybe it would be possible to integrate the buttons into the konsole space like in the mockup I'm going to attach.
Would also allow to use bigger buttons.
But of course it brings other challenges, technically and also design-wise.
It would need to be done in a way that contrast between the symbols and the background is guaranteed.
And it's harder to signal which of the tabs is currently active (could add another symbol like ✔ or something like that, but not sure if that is obvious enough).

Created attachment 120950 [details]
mockup of suggested button placement

The header bar on splits was added because the UX guys asked to have it, I personally don't like and I plan to add a way to hide them. Some people like to have a bar to tell you what's the current displayed app / profile. I'll forward this to the UX guys on plasma too.

Just as an interesting observation:
I tried the same (splitting both ways) under Plasma Wayland, so with kwin_wayland as the compositor and there it worked as expected.
Did the cross check with X11 and when using Plasma/kwin_x11, it still gives the same problem.

Just had a look at this again to see if it is still valid.
In principle, everything works like designed, so there is no bug, but personally, I'd still like to have the option to actually split existing tabs.
I often have the situation that I'm working on specific tasks in two tabs and then decide I want to have them next to each other … and later on then I would want to have them in separate tabs again.
The current way that splits are always new sessions and are always destroyed once you undo the split is ok for many tasks, but overall, it's a bit limited. I think Konsole could improve there.
So I still would like to see something implemented there. ;)

Created attachment 153701 [details]
Tab to Split and back to Tab video

Note that when split headers are enabled, you can already move a tab into a split by dragging the header into the tabbar to select the tab that you want to split, and then dropping wherever you want to create the split. Then, the split can be moved back to a tab by pressing the "Move terminal to new tab" button in the split header.  Not the most discoverable UI, but that can probably be improved.

Thanks for the info. Moving a split back does work indeed. I didn't see those buttons, because in my icon scheme they are not visible … :/
(These are the first (and only so far) buttons where I observed a problem.)

The split also works, but getting there is quite advanced. I would've never even thought of making this move like that. ^^

So, since the feature is already there, you can close this bug report, if you'd like.
The remaining part seems to be to just improving the UI.

As a suggestion there: for me the intuitive way would be to right click on the tab and then activating an option there, just like you can detach a tab. So basically right click -> "Move terminal to new split view" would do the same thing that dragging the header to a tab does, activating the split selection.

Let us know if you still have this issue on a recent version

(In reply to Kurt Hindenburg from comment #31)
> Let us know if you still have this issue on a recent version

As I wrote in the previous post, I'm fine with closing the issue.