Page MenuHomePhabricator

terminology: transparancy not working (EFL git master)
Closed, ResolvedPublic

Description

Terminology transparency is not working properly with EFL git master.

I've reproduced this in E on Debian and Ubuntu.

This is also reproducible outwith E.

Seems to be an EFL regression.

netstar created this task.Apr 5 2020, 8:34 AM
netstar triaged this task as Showstopper Issues priority.
billiob added a subscriber: juippis.EditedApr 5 2020, 1:25 PM

It's working for me on Enlightenment v1.22.0 on X. I'm using efl and terminology on their respective master branch.

However, it's not working for me at all outside enlightenment with efl ranging from efl 1.22.0 to master.

Settings may not be applied to current window in terminology. Opening a new tab makes it work in the new tab according to @juippis.

@billiob seems fixed due to changes in terminology. In E at least. Tested on 3 machines.

@netstar , @billiob is this fixed now? Any problem remaining in efl? If not we should close this.

It still does not work for me outside e.
I couldn't find a release of efl, with a meson build, that had this to be working.

Hmm, so the part where Terminology is running in E is fixed in terminology, right?
And we we have it broken for Terminology running outside E since efl version 1.22 onwards.

Right now I would *not* consider this a release blocker for 1.24, but feel free to disagree.

I do agree with you. It's been broken on too many stable releases to be considered a broken on that one.

I agree here also. I didn't realise it had been broken outwith E since 1.22. With it working in E, I'm personally happy.

netstar closed this task as Resolved.Apr 20 2020, 9:12 AM

I'm just going to close this then...

how is this broken? to be transparent you create a window with an argb visual and fill it with alpha channel pixels... efl actually doesnt have any special different code-path per wm. there is a code path to detect a if the composite extension exists (and xrender and xfixes) etc. and falls back to shaped if it doesn't... it also checks to see if the parent window is argb or not on creation to ensure it matches a parent if done that way - for root window it's special and doesn't enforce it but if it's requested it'll work fine..

so ... is a compositor running? is it actually working correctly? i tried fvwm+xcompmgr and it works fine

http://www.enlightenment.org/ss/e-5e9e1a8a673596.45194700.jpg

i can enable and disable transparency there... is the compositor you're testing with broken? are you expecting transparency to work right without a compositor? (because then you get shaped windows...)

I was expecting something like using the picture from the root window of the wm and just use that as background.
I'm using feh to set the background picture.

that's not transparency. first it's an implied protocol where whoever sets a pixmap; on root window sets a property that gives that's pixmap id. it's a hack. it's also got wonderful side effects like the client has to track it's x,y relative to root and redraw every time it's moved - this doesn't sync. it'll always be a bit out-of sync as yoiu get the events that the window moved after it happened. in the age of real compositing this hack is no longer valid or desirable. as the person who came up with the hack in the first place over 20 years ago... i think i get to call it dead when it is dead. :) move on and use a compositor. :)