Bug 2189

This could be related to the recent merge of Compton upstream with our version (https://git.trinitydesktop.org/cgit/tdebase/commit/twin/compton-tde?id=d74fed9b65e4c5e742a3fe81a05b83201ccf591a)

As I am already uploading the R14 RC1 files for shipment we're going to have to note this as a last-minute bug and try to deal with it for R14 RC2.  Worst case we can temporarily revert the upstream Compton patches that handle transparency.

Looks like this bug also works the other way--I have a Konqueror instance here that won't become transparent when a different window becomes active.  In my case everything worked fine until I launched the Kicker configuration dialog from the panel.

I wonder what changed...

Still investigating, but it looks like this issue persists across compton restarts, making me wonder if twin is not properly updating the translucency atom on gaining/losing focus.  What I don't understand though is why this suddenly started after updating Compton; can you confirm that this is a regression and not something that just wasn't noticed on the earlier tdebase builds?

Also, while we're fixing compton-tde we should also fix the badly broken shadow support.  A patch was graciously provided by the compton maintainers; it should be tested and merged:
https://github.com/chjj/compton/issues/105#issuecomment-39636904

Hi,

Yes, that's true for the shadow. I forgot to report it: The shadow is way too far, for me more than 500px to far from where it should be both in X and in Y.

I can confirm that I didn't had this trouble with the previous Compton.
Wonder if Twin always send correctly the active/inactive state to Twin.


Not much related to this, but I also wonder why window managers still use active/inactive states when the system is multitask. This makes no sense to me :)

-Alexandre

(In reply to Timothy Pearson from comment #2)
> Looks like this bug also works the other way--I have a Konqueror instance
> here that won't become transparent when a different window becomes active. 
> In my case everything worked fine until I launched the Kicker configuration
> dialog from the panel.
> 
> I wonder what changed...

Did you try to use similar settings as I have in the provided screenshot to achieve this?

-Alexandre

I am now having difficulty reproducing the glitch; my settings are the same as yours.  I'm guessing there is some kind of race condition involved as a result, but have no idea where it might be.

twin sets and unsets the opacity atom based on whether or not the window is active, so I don't think this is a compton-tde issue.  It is possible the race timing was slightly altered with the compton update, but that's about as far as I would be willing to go with that idea.

I have repaired the shadows, fading, etc. in several commits ending with GIT hash a3a88af (tdebase).  I don't think this will make it in to RC1 but it will be available for RC2.

I can confirm the glitch is in the setting/unsetting of the _NET_WM_WINDOW_OPACITY atom.  A window stuck itself in the partially-transparent state and xprop revealed the atom was still set (a normal active window does not have the _NET_WM_WINDOW_OPACITY atom set as long as active windows are given 100% opacity).

(In reply to Timothy Pearson from comment #7)
> I can confirm the glitch is in the setting/unsetting of the
> _NET_WM_WINDOW_OPACITY atom.  A window stuck itself in the
> partially-transparent state and xprop revealed the atom was still set (a
> normal active window does not have the _NET_WM_WINDOW_OPACITY atom set as
> long as active windows are given 100% opacity).

I found a way to reliably reproduce the issue (QtCurve widget style is in use)
In kcontrol open the Style module and click Info, then close the resultant dialog box.  kcontrol will remain partially transparent.

At the same time twin generates a couple of BadWindow errors, so I'm guessing the logic in setActive is not 100% correct.

In my previous comment that should have referred to the "Window Decorations" control center module, with the Crystal window style theme set.  Additional information that might be important is that I was testing on Desktop 1 with a maximized Konsole window in the background and a restored Control Center window in the foreground.

This issue came down to a missing setActive call on focus rotation.  It should be fixed in GIT hash 84d7db0 (tdebase).

Thanks for reporting!

Looks like I spoke too soon...I just had this bug reappear when using Konsole and Konqueror on Desktop 1; right-clicking a text file and selecting Open in New Window causes the bug to show up.

(In reply to Timothy Pearson from comment #10)
> Looks like I spoke too soon...I just had this bug reappear when using
> Konsole and Konqueror on Desktop 1; right-clicking a text file and selecting
> Open in New Window causes the bug to show up.

On further investigation this appears to be a potentially long-standing KDE/TDE bug with active windows that simply becomes more obvious when partially transparent inactive windows are enabled.  Without that setting enabled the only clue that something was wrong would be the fact that the apparently "active" Konsole window would not minimize when its Kicker entry was clicked.

I'm not sure when this bug was introduced.  It would be helpful for others to confirm its existence, possibly on 3.5.13.x as well.

(In reply to Timothy Pearson from comment #9)
> In my previous comment that should have referred to the "Window Decorations"
> control center module, with the Crystal window style theme set.  Additional
> information that might be important is that I was testing on Desktop 1 with
> a maximized Konsole window in the background and a restored Control Center
> window in the foreground.
> 
> This issue came down to a missing setActive call on focus rotation.  It
> should be fixed in GIT hash 84d7db0 (tdebase).
> 
> Thanks for reporting!

GIT hash 84d7db0 has been reverted due to causing crashes on some systems.  This bug has therefore not been resolved or repaired in any way at this time.

> GIT hash 84d7db0 has been reverted due to causing crashes on some systems
See bug 2218 for additional details.
Actually only one line of code from GIT hash 84d7db0 was reverted.

(In reply to Michele Calgaro from comment #13)
> > GIT hash 84d7db0 has been reverted due to causing crashes on some systems
> See bug 2218 for additional details.
> Actually only one line of code from GIT hash 84d7db0 was reverted.

That line was the only real fix for this bug. ;-)  For some reason twin is not keeping track of the active window well enough to set its opacity back to 100%.

Hi,

With the last update, I have a problem where the keyboard is not ''associated'' with the right window. I can hav both Firefox and Konsole open. Typing text in what should be Firefox and the typed text appear in Konsole...

-Alexandre

(In reply to Alex Couture from comment #15)
> Hi,
> 
> With the last update, I have a problem where the keyboard is not
> ''associated'' with the right window. I can hav both Firefox and Konsole
> open. Typing text in what should be Firefox and the typed text appear in
> Konsole...
> 
> -Alexandre

This sounds like a window focus problem.  Are you saying you are experiencing this issue with this patch applied?
https://git.trinitydesktop.org/cgit/tdebase/commit/?id=a7c3b934973a9435120596a6a577ab62e6fee348

Thanks!

Tim

Hi,

I updated my system on November 27, so I guess the issue is with this commit.
One thing I'd like to add is that I tried to turn off Compton effects to see if it would work, and I still get the issue.

Thanks!
-Alexandre

(In reply to Alex Couture from comment #17)
> Hi,
> 
> I updated my system on November 27, so I guess the issue is with this commit.
> One thing I'd like to add is that I tried to turn off Compton effects to see
> if it would work, and I still get the issue.
> 
> Thanks!
> -Alexandre

In that case I expect this issue to be resolved when the new builds hit; the regression was reverted on Nov. 28 in the above linked commit.

As mentioned earlier this bug goes deeper than just transparent windows; the taskbar activation issues were becoming a nuisance so I committed a potential fix for RC2 in GIT hash 17b142d.  This patch will receive widespread testing in RC2; if it is a problem I can revert it for R14 final.

Can you confirm this issue has been fixed in GIT hash 17b142dd?  This hash is part of R14 RC2.

Thanks!

Hi,

With my latest update, everything works as expected, including:
1.No half-transparent window problems
2.The keyboard is associated with the right window.
3.Shadows works.

Interesting to see that on my Asus EEE X101CH with its not too well supported graphic card, the Compton performance is very smooth without turning on OpenGl, and is ridiculously bad when using OpenGl. This is probably why using Unity is so painful on this computer: The graphic driver doesn't support well OpenGL.

Will we have the possibility to have one day a shadow for the taskbar, such as in KDE4 and Plasma 5?

Thank you!
-Alexandre

(In reply to Alex Couture from comment #21)
> Hi,
> 
> With my latest update, everything works as expected, including:
> 1.No half-transparent window problems
> 2.The keyboard is associated with the right window.
> 3.Shadows works.
> 
> Interesting to see that on my Asus EEE X101CH with its not too well
> supported graphic card, the Compton performance is very smooth without
> turning on OpenGl, and is ridiculously bad when using OpenGl. This is
> probably why using Unity is so painful on this computer: The graphic driver
> doesn't support well OpenGL.

I don't doubt that; many of the newer desktops require very powerful graphics cards to function.  We don't do any advanced processing in Compton so in most "normal" use cases the XRender performance is either the same or better than the OpenGL performance.  This flips around again when you start increasing screen sizes (e.g. on my >3000 pixel workstation), but on such a machine you expect to see a very powerful graphics adapter in the first place. :-)

> Will we have the possibility to have one day a shadow for the taskbar, such
> as in KDE4 and Plasma 5?

I don't see why not; Compton already supports this we just don't have a configuration option for it in the TDE control module.

Even worse, on my first-gen Asus EEE with a 571mhz Celeron and a well-supported graphic card, Unity worked perfectly, but on this much more powerful quad-core Asus EEE, it is painfully slow.

Reassigning the remaining issues for resolution in R14.0.1.

Do you see other issues with it? At least for me it now works flawlessly

-Thanks!
-Alexandre

(In reply to Alex Couture from comment #25)
> Do you see other issues with it? At least for me it now works flawlessly
> 
> -Thanks!
> -Alexandre

I made a mistake since this bug was still in NEW status...this was supposed to be posted to Bug 1489.

Fixing up this report...

(In reply to Timothy Pearson from comment #22)
> (In reply to Alex Couture from comment #21)
> > Hi,

> > Will we have the possibility to have one day a shadow for the taskbar, such
> > as in KDE4 and Plasma 5?
> 
> I don't see why not; Compton already supports this we just don't have a
> configuration option for it in the TDE control module.

I know that TDE is in hard freeze state, but is it possible to add the tick box for it? It should not create major disruption in the code base. Or can I turn it on by editing a config file?

Oh, that's right, I forgot about that remaining issue.

This will have to wait for R14.0.1 (even though the change is small, at some point we have to say "enough is enough" and release anyway).

Tim

Hi,

If someone has a little bit of time for it, it would be nice to add the tick box for having a shadow for the taskbar.

I'm looking for building the next release of my PCLinuxOS remaster with TDE R14.0.1

Thank you!
-Alexandre

(In reply to Alex Couture from comment #29)
> Hi,
> 
> If someone has a little bit of time for it, it would be nice to add the tick
> box for having a shadow for the taskbar.
> 
> I'm looking for building the next release of my PCLinuxOS remaster with TDE
> R14.0.1
> 
> Thank you!
> -Alexandre

This should be fixed in GIT hash 296f0f4 (tdebase).  Please let me know if this is the functionality you were wanting to see, and if so please close out this report.

Thanks!

Hi,
I should be able to test it in a few days!

Thank you!
-ALexandre

Created attachment 2484 [details]
Panel at the top

Created attachment 2485 [details]
Panel at the bottom

Hi Tim!

Thank you! It works!

If you have some time for it, a bit of polish would make it better, because when the panel is at the bottom of the screen, the shadow is not seen, as shown in the attachments. Ideally, the shadow should always be in the opposite side of the screen border where the panel is, as it is now when the panel is at the top of the screen.

Great! Each little details helps to bring TDE in the new century!
-Alexandre

(In reply to Alex Couture from comment #34)
> Hi Tim!
> 
> Thank you! It works!
> 
> If you have some time for it, a bit of polish would make it better, because
> when the panel is at the bottom of the screen, the shadow is not seen, as
> shown in the attachments. Ideally, the shadow should always be in the
> opposite side of the screen border where the panel is, as it is now when the
> panel is at the top of the screen.
> 
> Great! Each little details helps to bring TDE in the new century!
> -Alexandre

Yeah, I'm aware of that issue.  It is the result of the default shadow settings placing all shadows on the lower left edges of each window.

Fixing this would require a significant amount of work.  Can you file a separate enhancement report so that we don't lose track of this?

Thanks!

Hi,

Ok, I made enhancement ''bug'' report 2425.

A trick that I'll try is to center the shadow of windows, so that it could be seen from every side of the window

-Thanks!
-Alexandre

Hi,

If you try to use the following settings, it will work perfectly:
Base shadow radius: 7
Vertical offset: 171%
Horizontal offset: 132%

With this, there is just enough shadow, without getting too invasive, all around every windows. I think that it could be a good default setting. 
What do you think about it?

Thank you!
-Alexandre