[Konsole-devel] [Bug 154239] konsole transparency does not work

[Eike Hein]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=154239         




------- Additional Comments From hein kde org  2008-01-07 14:38 -------
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.