Having more than one split, if the terminal is shown/hidden a few times (sometimes as little as one time) the wrong split is focused, i.e. not the one that was focused before hiding the terminal. Reproducible: Always Steps to Reproduce: 1. Split terminal into at least 2 terminals, and notice which terminal is currently focused 2. Show/Hide yakuake a few times 3. After a few tries (anywhere between 2-7) focus will change to a random split Actual Results: A split other than the lastly focused split gained focus. Expected Results: The focus should remain on the split lastly focused.
*** Bug 359928 has been marked as a duplicate of this bug. ***
*** Bug 357979 has been marked as a duplicate of this bug. ***
Git commit ee7152471dc8a733d5acbd0e026d7898a24be1f2 by Eike Hein. Committed on 02/03/2016 at 11:58. Pushed by hein into branch 'master'. Fix terminal focus not being preserved on hide->show. M +16 -0 app/sessionstack.cpp M +4 -0 app/sessionstack.h http://commits.kde.org/yakuake/ee7152471dc8a733d5acbd0e026d7898a24be1f2
Created attachment 97764 [details] bug video
I cannot confirm that this is fixed. The active terminal is still changing with each opening of yakuake. (see attached screen cast) As you can see at the end of the video, the focus sometimes is lost completely, i.e. no terminal is focused. in this situation it is still possible to write to some terminal. QT 5.5.1 Plasma 5.5.5 Yakuake 3.0.2 and current git
This started happening to me as well. Eike could you confirm that your previous fix is included in version 3.0.2?
Yeah, it is.
can you please reopen this bug: there is one more person observing it in Bug 357861
Created attachment 97836 [details] A fix, works for me. I fixed it with this patch, however I'm not sure if this is the right fix.
i can confirm, that the patch works on top of yakuake 3.0.2
Your patch sort of works around a symptom of the problem - Qt is for some reason moving focus to the other terminal, and your patch rejects that in the event handler. This avoids the problem but doesn't really tell us why it happens in the first place (it shouldn't), so I don't want to apply it and instead investigate it further to fix the problem closer to or at its root. It's helpful investigation though, thanks!
Yes, this is why I said I was not sure if this was the right fix :-)
Patch works for me. However, I've also got this bug regarding focus being off and shortcuts not working if mouse is above Yakuake when it appears: https://bugs.kde.org/show_bug.cgi?id=360234 Maybe they are related ?
Aye, see comment in linked ticket.
*** Bug 360659 has been marked as a duplicate of this bug. ***
This bug appeared on my laptop again. It works on the desktop. Both have the latest Arch Linux with yakuake 3.0.2
(In reply to dns2utf8 from comment #16) > This bug appeared on my laptop again. > > It works on the desktop. > > Both have the latest Arch Linux with yakuake 3.0.2 I think it is a race condition, because I noticed it works on all my slow computers but not on the new ones.
(In reply to dns2utf8 from comment #17) > (In reply to dns2utf8 from comment #16) > > This bug appeared on my laptop again. > > > > It works on the desktop. > > > > Both have the latest Arch Linux with yakuake 3.0.2 > > I think it is a race condition, because I noticed it works on all my slow > computers but not on the new ones. Are they both 64-bit? Do they both use the same packages? I've had this issue on my 2009 and 2015 laptops, as well as an Arch VM with KDE installed. It's never gone away.
Yes, all 3 are 64-bit. The desktop uses an E3-1245 v3, the old laptop is an t400. The new laptop with the problems is a t460s. I noticed something odd: 1. open yakuake 2. split the terminal 3. open another tab 4. close and open yakuake 5. close the terminal 6. now you are on the second tab in the second split 7a. close and open yakuake 8a. you are still in the second split 7b. type something, should end up in the second split 8b. close and open and you are in the fist split So depending upon if you type something after closing a tab, it works on my t460s for one cycle.
I noticed something else: The split selection remains correct if I leafe yakuake with Alt+Tab for another window, but it will be wrong if I use the hotkey. Hope this helps.
tested and reproducible with qt 5.6.0
*** Bug 361618 has been marked as a duplicate of this bug. ***
I investigated this issue. Likely, the bug is in Qt. I filled it in the bugtracker: https://bugreports.qt.io/browse/QTBUG-49071 Also I sent a patch, which has been accepted: https://codereview.qt-project.org/#/c/144899/ This should be fixed in Qt 5.6.1. Please, verify it with that version. Best, Alexander Bersenev
I'm on Qt 5.7.0 and the bug still persists.
I still see this bug. yakuake 3.0.2 qt 5.6.1 plasma 5.6.5
(In reply to Alexander from comment #23) > I investigated this issue. Likely, the bug is in Qt. I filled it in the > bugtracker: > https://bugreports.qt.io/browse/QTBUG-49071 > > Also I sent a patch, which has been accepted: > https://codereview.qt-project.org/#/c/144899/ > > This should be fixed in Qt 5.6.1. Please, verify it with that version. > > Best, > Alexander Bersenev I assume you've tested the patch and it works? Can you verify if your patch has been added and whether it resolved the issue for you? I'm on Qt 5.7.0-2 and the bug still persists.
I am running yakuake 3.0.2-3 and qt 5.7.0-2 on Arch. It works now on my laptop too. I noticed plasmashell hanging from time to time and I/O blocking dbus along with it. The funny thing is, when I ran kdeutils-sweeper 16.04.3-1 all problems disappeared.
(In reply to dns2utf8 from comment #27) > I am running yakuake 3.0.2-3 and qt 5.7.0-2 on Arch. It works now on my > laptop too. "It works" as in the problem is solved? The proper split is focused? > I noticed plasmashell hanging from time to time and I/O blocking dbus along > with it. The funny thing is, when I ran kdeutils-sweeper 16.04.3-1 all > problems disappeared. Including this issue? What did the sweeper clean?
This bug has been hampering my productivity for a long time. It has been consistently repeatable for me under multiple versions of Mint KDE on multiple laptops and also in VirtualBox. I've watched this page with baited breath hoping for a real fix. I even tried the patch, but must have done something wrong because then it wouldn't save my configuration changes; I spent months reconfiguring Yakuake every time I had to reboot just because this small-seeming detail is such an obnoxiously distracting impediment to my workflow. Today it finally occurred to me to just mess with relevant-seeming settings, looking for a workaround. In the Yakuake configuration under Window, turning off "Ask the window manager to perform the animation" seemed to prevent the issue at first, but I could still trigger it occasionally if I spammed the toggle key as fast as I can (tensing my arm isometrically so it shakes at around 10 Hz). Note that I had the duration set to 100 or 150 at different times. Then I set the duration to 0, but that just makes KDE do a fade effect by default. So I also disabled Fade under Desktop Effects in KDE's System Settings, and I am now completely unable to trigger the bug. Maybe it fixes the shortcut problems too, I hadn't ever noticed that one so I couldn't say. I did observe in the course of this, that the bug appears to trigger more often if I toggle it again while the last animation is still occurring, and also if I release the alt key between each toggle (my shortcut is alt+grave). I wanted to disable the fade effect for the Yakuake window only, but didn't see an obvious way to do that through the GUI. I saw a way to disable all compositing for the Yakuake window under Window Rules in the Window Management settings, but transparency is also often important to my workflow. I also tried the various focus-giving/receiving/stealing options in the same area with no noticeable impact on the bug. I hope this helps devs narrow down the actual cause, and saves users like me from ending up in a psych ward until that happens.
Doesn't work on my end. I already wasn't using any animations so I turned Fade on and off again, disabled asking the window manager to animate the window and it still happens. I was hoping that with a stable plasma release this bug would have received more focus as it is a fairly important bug. I completely agree that it's a productivity-killer to always have to think if I'm writing on the right split. I also have highlighting upon focus enabled, but unfortunately the split does not animate the focus when yakuake is opened/retracted. Maybe this means that the wrong split is selected upon retracting the terminal? If you notice (with any sort of animation on) the split loses focus as soon as you hit the retract button. I think during retraction no split is actually focused, which might even be the problem?
(In reply to unknown32768 from comment #29) > I even tried the patch, but must have done > something wrong because then it wouldn't save my configuration changes; The patch of commend 9 is doing the job as a workaround for me.
Your workaround also works for me. Kudos!!!! :-) Using OpenSuse Leap 42.1 and Plasma 5.5.5 (In reply to unknown32768 from comment #29) > Today it finally occurred to me to just mess with relevant-seeming settings, > looking for a workaround. In the Yakuake configuration under Window, turning > off "Ask the window manager to perform the animation" seemed to prevent the > issue at first, but I could still trigger it occasionally if I spammed the > toggle key as fast as I can (tensing my arm isometrically so it shakes at > around 10 Hz). Note that I had the duration set to 100 or 150 at different > times. Then I set the duration to 0, but that just makes KDE do a fade > effect by default. So I also disabled Fade under Desktop Effects in KDE's > System Settings, and I am now completely unable to trigger the bug. Maybe it > fixes the shortcut problems too, I hadn't ever noticed that one so I > couldn't say.
It's important to set the duration to 0. (In reply to silentz0r from comment #30) > Doesn't work on my end. I already wasn't using any animations so I turned > Fade on and off again, disabled asking the window manager to animate the > window and it still happens. > > I was hoping that with a stable plasma release this bug would have received > more focus as it is a fairly important bug. I completely agree that it's a > productivity-killer to always have to think if I'm writing on the right > split. I also have highlighting upon focus enabled, but unfortunately the > split does not animate the focus when yakuake is opened/retracted. > > Maybe this means that the wrong split is selected upon retracting the > terminal? If you notice (with any sort of animation on) the split loses > focus as soon as you hit the retract button. I think during retraction no > split is actually focused, which might even be the problem?
I already had duration set to 0. Still doesn't work for me. (In reply to David P. from comment #33) > It's important to set the duration to 0. > > (In reply to silentz0r from comment #30) > > Doesn't work on my end. I already wasn't using any animations so I turned > > Fade on and off again, disabled asking the window manager to animate the > > window and it still happens. > > > > I was hoping that with a stable plasma release this bug would have received > > more focus as it is a fairly important bug. I completely agree that it's a > > productivity-killer to always have to think if I'm writing on the right > > split. I also have highlighting upon focus enabled, but unfortunately the > > split does not animate the focus when yakuake is opened/retracted. > > > > Maybe this means that the wrong split is selected upon retracting the > > terminal? If you notice (with any sort of animation on) the split loses > > focus as soon as you hit the retract button. I think during retraction no > > split is actually focused, which might even be the problem?
This bug was (is) a blocker to me, in fact it was the root cause that make me move away from my KDE/yakuake working env. :-(. At least I learned tmux :-)
Eike, I think you may be misunderestimating the annoyance that this bug is. Having worked for a few months with it, it really made me consider to stop using yakuake altogether. Yakuake is all about being efficient & fast with a terminal, and this bug makes you constantly remember to re-focus on the right pane lest you type commands in the wrong terminal. The workaround posted in #9 did the trick to me, and yakuake is a breeze again. I understand that this is a workaround and not a formal fix, but why not merging it until someone finds and fixes the actual cause? It doesn't seem to cause any regression and will make users happier.
I have recently been trying out the latest KDE Neon disto. This is the most serious bug i have noticed using Neon and Yakuake. It's extremely dangerous to use yakuake in a way where you have multiple splits logged into several remote hosts (as may be common for any system admin). If one switches from yakuake to a text editor and back to yakuake, you never know which terminal will be focus. When one is working rapidly, switching between an editor (or whatever) and yakuake, it's very possible to type/paste into the wrong session because of the random selection. Therefore it seems yakuake is extremely dangerous to use until this issue is resolved.
(In reply to panino from comment #37) > I have recently been trying out the latest KDE Neon disto. This is the most > serious bug i have noticed using Neon and Yakuake. It's extremely dangerous > to use yakuake in a way where you have multiple splits logged into several > remote hosts (as may be common for any system admin). If one switches from > yakuake to a text editor and back to yakuake, you never know which terminal > will be focus. When one is working rapidly, switching between an editor (or > whatever) and yakuake, it's very possible to type/paste into the wrong > session because of the random selection. Therefore it seems yakuake is > extremely dangerous to use until this issue is resolved. This probably won't be of much use to you, but I threw together a package for Archlinux back in September that uses the workaround patch, posted in this list. For anyone using Arch Linux search for "yakuake-sp-git" on the AUR. For people on other distros just compile it from github and install it with your distro's package manager: https://github.com/silentzawr/yakuake-sp-git It's a few versions behind and I will be force rebasing on top of yakuake's latest git whenever I update it, so beware if you want to contribute.
In latest KDE Neon, it works just disabling the window manager setting. (In reply to unknown32768 from comment #29) > Today it finally occurred to me to just mess with relevant-seeming settings, > looking for a workaround. In the Yakuake configuration under Window, turning > off "Ask the window manager to perform the animation" seemed to prevent the > issue at first
*** Bug 376569 has been marked as a duplicate of this bug. ***
*** Bug 381084 has been marked as a duplicate of this bug. ***
Confirming this bug in Yakuake 3.0.4+ Probably related to https://bugs.kde.org/show_bug.cgi?id=375085 Qt Version: 5.9.1 Frameworks Version: 5.36.0 Operating System: Linux 4.9.40-1-MANJARO x86_64 Distribution: "Netrunner Rolling"
*** Bug 375085 has been marked as a duplicate of this bug. ***
another workaround patch from Bug 375085 (which stores and restores the active terminal state): https://phabricator.kde.org/D6907
*** This bug has been marked as a duplicate of bug 386350 ***
Why is this bug from 2015-12-17 marked as a duplicate of bug 386350 opened 2017-10-30? Shouldn't it be the other way around to not lose the history and the patches?