Bug 154239 - konsole transparency does not work
Summary: konsole transparency does not work
Status: RESOLVED FIXED
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
: 155793 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-12-17 17:55 UTC by Sebastian Kügler
Modified: 2008-05-23 22:20 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Kügler 2007-12-17 17:55:39 UTC
Version:           3.97 (using KDE KDE 3.97.0)
Installed from:    Compiled From Sources
Compiler:          gcc 4.1.3 
OS:                Linux

Although I have Composite enabled (and kwin's fancy effects work), I'm not getting a transparant konsole background for some time now. Changing settings in the appearance tab doesn't make the konsole transparant. There's also no notice that it doesn't work.
Comment 1 Robert Knight 2007-12-17 21:20:00 UTC
I put the code to enable transparency on startup back in yesterday, but due to odd glitches which are still present, it requires that --enable-transparency is passed as an argument on startup.
Comment 2 Sebastian Kügler 2007-12-17 21:26:17 UTC
Thanks! I'll give it a go once my compile is done.
Comment 3 Sebastian Kügler 2008-01-07 14:25:28 UTC
It does work when starting with konsole --enable-transparency, autodetection is still broken though.

Would adding "--enable-transparency" to the .desktop file (or making it default otherwise) also work for non-composited environments? What would be the drawback?
Comment 4 Eike Hein 2008-01-07 14:38:15 UTC
I've made a commit to Konsole yesterday, r758145, that adds runtime detection to the Konsole KPart for use in Yakuake and similar: If the hosting application is found to be using an ARGB visual and a composition manager claims the relevant selection at KPart creation, the decision is made to support translucent painting, and the use then depends on the profile's settings. 

The same code could be re-used for the main application: Remove the command line argument as a condition for the ARGB visual picker in main.cpp, and then initialize TerminalDisplay's HAVE_TRANSPARENCY static bool using my transparencyAvailable() method just as in the KPart.

The algorithm in transparencyAvailable() coupled with the one-time startup initialization is still fairly conservative at this time (it only returns true when both the ARGB visual and "composition manager running" conditions are met, while the latter might change at run time if the user enables compositing after app startup . In Yakuake, I use the same code for the skinned main interface, but re-run it whenever the window is about to be opened (Yakuake is usually hidden and unrolls from the top edge of the screen at the press of a hot key) so that Yakuake can re-adjust itself to compositing without being restarted. In theory, to do it 100% properly, one would have to check for an ARGB visual initially, and then depending on that check for the composition manager X selection in every paint event, but that's undesirable for performance reasons. 
Comment 5 Robert Knight 2008-01-07 16:02:31 UTC
> What would be the drawback? 

On my desktop machine (which is unavailable at the moment) with NVidia hardware I noticed some visual artifacts and poor performance with ARGB visuals enabled on a composited desktop.

Apparently there are some changes in the latest NVidia drivers (from their website) which fix problems in this area.  I haven't had a chance to test them, if you have suitable hardware then please do.

Comment 6 Sebastian Kügler 2008-01-07 16:05:55 UTC
I'm running konsole --enable-transparency with latest nvidia drivers on a GF7600GS right now. No artifacts, performance is good.

As to those artifacts, those turn up in other applications (hi plasma!) as well. So not sure if it makes sense to axe individual applications because of that. People with old drivers will have a horrific user experience anyway when they try running composite ...

They should just update their drivers in that case.
Comment 7 Robert Knight 2008-01-07 16:09:26 UTC
> People with old drivers will have a horrific user
> experience anyway when they try running composite ... 

A terminal is a pretty basic utility which has to work comfortably, so I erred on the safe-side.  

Sebas, could you add a note about this into the release notes.  It might also be a good idea to provide a link to the list of omissions and bugs in branches/KDE/4.0/kdebase/apps/konsole/KNOWN-ISSUES-4.0 as well as the change summary in branches/KDE/4.0/kdebase/apps/konsole/CHANGES-4.0
Comment 8 Sebastian Kügler 2008-01-07 16:20:07 UTC
Will do. Thanks for the nice list of new features, that makes writing release notes a lot easier (and the result more complete).
Comment 9 Eike Hein 2008-01-07 16:21:30 UTC
The 169.07 drivers did successfully resolve the problem with ARGB scroll areas, and I didn't encounter any artifacts while trying out the KPart modified to use auto-detection in Yakuake/4 last night.
Comment 10 Kazuo Teramoto 2008-02-15 01:56:58 UTC
Hi I tried to use "--enable-transparency" but this don't work, my background is black... I hav set the trans to 100% and trans work in kwin.

I need to change anything?
Comment 11 Robert Knight 2008-02-15 02:10:17 UTC
> I need to change anything? 

Make sure that no Konsole windows are open before starting it with the --enable-transparency flag.
Comment 12 Robert Knight 2008-03-17 18:42:30 UTC
*** Bug 155793 has been marked as a duplicate of this bug. ***
Comment 13 Robert Knight 2008-05-23 22:20:24 UTC
Fixed in KDE 4.1.  Konsole defaults to using transparency if compositing is available.  There is an option to disable transparency on systems where it causes problems.