Bug 362857 - Background transparency not applied when restoring session
Summary: Background transparency not applied when restoring session
Status: CONFIRMED
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: 19.08.2
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
: 380998 389630 393563 399867 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-05-09 17:08 UTC by Freddie Witherden
Modified: 2021-02-23 11:50 UTC (History)
14 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screen Shot of Error Message (51.76 KB, image/png)
2017-06-06 22:00 UTC, Joe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Freddie Witherden 2016-05-09 17:08:20 UTC
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
Comment 1 Joe 2016-10-13 19:16:27 UTC
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."
Comment 2 chrisg_123 2017-03-11 14:28:59 UTC
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.
Comment 3 Maxim Therrien 2017-05-07 03:05:42 UTC
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.
Comment 4 Joe 2017-06-06 21:59:28 UTC
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.
Comment 5 Joe 2017-06-06 22:00:02 UTC
Created attachment 105952 [details]
Screen Shot of Error Message

Just for posterity, a screen show of the error message.
Comment 6 Kurt Hindenburg 2018-01-31 16:14:38 UTC
*** Bug 380998 has been marked as a duplicate of this bug. ***
Comment 7 Kurt Hindenburg 2018-01-31 16:15:01 UTC
*** Bug 389630 has been marked as a duplicate of this bug. ***
Comment 8 Kurt Hindenburg 2018-05-03 14:48:17 UTC
*** Bug 393563 has been marked as a duplicate of this bug. ***
Comment 9 Kurt Hindenburg 2018-05-03 14:49:16 UTC
Yes, either Konsole needs to have a way to start after compositor or handle changes to transparency better.
Comment 10 Gunter Ohrner 2018-05-03 16:24:51 UTC
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?
Comment 11 Kurt Hindenburg 2018-05-04 03:30:43 UTC
Yes I think it has to do w/ timing.  It sometimes works for me and sometimes doesn't.
Comment 12 Christoph Feck 2018-10-16 17:44:15 UTC
*** Bug 399867 has been marked as a duplicate of this bug. ***
Comment 13 pearlydragon 2018-10-17 02:12:36 UTC
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.
Comment 14 pearlydragon 2018-10-17 02:19:24 UTC
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.
Comment 15 pearlydragon 2018-10-17 02:21:05 UTC
KDE Frameworks 5.50.0
Qt 5.11.2 (built against 5.11.2)
Konsole 18.08.1

Still bugged.
Comment 16 trmdi 2018-10-17 02:30:24 UTC
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.
Comment 17 Christoph Feck 2019-02-08 15:36:07 UTC
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.
Comment 18 Joe 2019-03-16 02:53:53 UTC
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.
Comment 19 neilsimp1 2019-03-25 17:33:48 UTC
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.
Comment 20 Joe 2019-03-25 23:40:21 UTC
@neilsimp1@gmail.com 

I think that is expected behavior, as full screen games generally flip the compositor/kwin off, thus no transparency.
Comment 21 pearlydragon 2019-03-28 04:20:16 UTC
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.
Comment 22 pearlydragon 2019-03-28 04:25:06 UTC
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.
Comment 23 Eon S. Jeon 2019-12-30 05:59:21 UTC
(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.