When restoring Konsole from a previous session it does not appear to apply background transparency. Opening Konsole manually resolves this issue. To reproduce. Open Konsole and modify the current (default) profile such that the background is partially transparent. In system settings ensure that KDE is configured to restore the previous session on log in. Log out of the system and then log in again. Konsole should re-open however the background will be solid as opposed to transparent. Closing Konsole manually and then reopening it rectifies the problem (the background should now be transparent). Reproducible: Always
I also have this issue. I have the a few tabs open/saved, and when starting up/restarting, Konsole opens properly, but the transparent background is disable (and cannot be enabled). If I open a new instance of Konsole it works fine. I get the following error message under the Appearance tab in settings: "Konsole was started before desktop effects were enabled. You need to restart Konsole to see transparent background."
I am experiencing the same issue. As stated by others after a session restore Konsole windows do not maintain transparency. To resolve they must be manually closed and re-opened.
What I think is going on is that Konsole windows (and maybe some other apps) get restored too early, before Kwin is executed, and therefore, are launched with the preconception that Kwin is not present. The same concept also applies to another issue that comes up with global menus, where restored apps will use local menus instead of global menus until restarted, because they get started before Plasma (or whatever) is executed. Either delaying the restore process so that it waits for Plasma and Kwin to fully initialise or creating some sort of pre-binding that restored programs can hook onto to get Kwin or global menu functionality before Kwin/Plasma is even started.
I would also chime in and say that I also have this problem - it occurs both on my laptop and desktop, both using the latest NVIDIA drivers, with Plasma 5.10.1/Frameworks 5.34.0, and Konsole 17.04.1.
Created attachment 105952 [details] Screen Shot of Error Message Just for posterity, a screen show of the error message.
*** Bug 380998 has been marked as a duplicate of this bug. ***
*** Bug 389630 has been marked as a duplicate of this bug. ***
*** Bug 393563 has been marked as a duplicate of this bug. ***
Yes, either Konsole needs to have a way to start after compositor or handle changes to transparency better.
Interesting, for me it's a regression which only appeared after my upgrade from KDE Applications 17.12.3 to 18.04.0 and Frameworks 5.44.0 to 5.45.0. It worked fine before, and I even did not re-save my session after the upgrade... Maybe I was just lucky before?
Yes I think it has to do w/ timing. It sometimes works for me and sometimes doesn't.
*** Bug 399867 has been marked as a duplicate of this bug. ***
Before restart, or leave session I have 4-5 konsoles with any tabs. After login I have 50/50 konsoles with 30% transparent background. OS: OpenSuse Leap 15. Kernel: 4.12.14 All from Leap15 updates (non-)oss. All updated. This bug observed from OpenSuse 13.2 - minimum 3 years. How to fix it??? Very uncomfortable after each reboot open new konsoles and restore tabs.
May be any developers know about how to regulate starting queue, same like starts demons - each starts after all dependencies starts completed? Or say about way, where I can find answer, download sources and fix it myself.
KDE Frameworks 5.50.0 Qt 5.11.2 (built against 5.11.2) Konsole 18.08.1 Still bugged.
Not only Konsole but also others those support the transparent effect. For example, I use Kvantum to make Dolphin transparent and some time it happens with Dolphin. Another thing is the problem is not always happens, but sometimes, randomly.
We do not want to delay restoring the session and wait until KWin is ready. It is fine if applications are started before or during the window manager startup. Konsole could use KWindowSystem::compositingChanged() to find out about the current compositing state during runtime, and act accordingly.
So - the idea then would be to let konsole startup/restore (without transparency), and pole (or some other mechanism) kwin and when its ready, restore transparency? Seems reasonable enough, to be honest, as long as the enabling of transparency isn't too jarring.
This happens to me as well, but also happens when I open up a game. I have Konsole open in another monitor and the background goes black as soon as the game goes fullscreen on the other monitor.
@neilsimp1@gmail.com I think that is expected behavior, as full screen games generally flip the compositor/kwin off, thus no transparency.
Anybody know, why we cant apply transparent background on window, what run before run library, who provide transparency? We can turn on and off transparency, if we run Konsole at correct time. Why this option we cant change in this situation? I's weird... And weird fact of me need run other Konsole, open tabs in new window with path same as Konsole without transparency and close bugged Konsole... Or may be anybody know how to check - this Konsole window have transparency or not from bash? I can get list of Konsole windows and manipulate their position, size, desktop, name. May be if I can check anabling of transparency I can write some script, for clone tabs, size, position, name to new window, close bugged and run it after 10-15 seconds from start session.
What file response for order of windows, what save in session? I have any question to this file/daemon/script... In particular - why Vivaldi don't save in session and don't run after restart. And may be we can set priority of Konsole too small for run as later as possible.
(In reply to Christoph Feck from comment #17) > We do not want to delay restoring the session and wait until KWin is ready. > It is fine if applications are started before or during the window manager > startup. > > Konsole could use KWindowSystem::compositingChanged() to find out about the > current compositing state during runtime, and act accordingly. I do get that adding delay isn't a charming solution, but that doesn't mean solving this in other places is a valid option. Ad-hoc live detection is a source of complexity and race conditions, so app devs will straight reject implementing it, and tell their users to stop relying on this broken KDE feature. (e.g. https://github.com/tsujan/Kvantum/issues/341#issuecomment-461888167 ) Compositor is a *service* that a number of GUI apps depend on, so either its availability should be ensured before its dependents, or a stub has to be provided while the actual service is initializing. Both are what system service managers are doing, but neither is done in KDE, and the latter requires rather complicated changes. The only option is ensuring, and this can be achieved so easily by increasing a single delay value in startup logic (though different approach is preferable). I patched this on my laptop, and it runs flawlessly. If you're concerned about longer start-up time, it should be possible to cancel the delay by sending out feedback from KWin (or listening to KWin D-Bus signal). I'm trying this, though without any luck yet.