Aug 12 2021
Ummm.... Where do you type this in? this must be fore your log in so before enlightenment even runs?
Oct 8 2020
May 22 2020
Mar 24 2020
Attached issue got fixed.
Mar 19 2020
great, now we have two different working workarounds
Sorry, I edited my message. We solved it (for the moment), with CFLAGS=-O1 instead of -O2.
Mar 18 2020
can you try using clang instead of gcc? like @rbtylee suggested
Mar 17 2020
Here we go... :(( +1 on i686
That's prevent python-efl-1.23.0 to be pushed to Mageia Cauldron with default compilation option.
Feb 20 2020
I ran into this issue trying to package 32 bit versions of python3-efl versions 1.23.x for Bodhi.
Jan 14 2020
Dec 4 2019
Popups can still use a different comp style - there are already a set (default, everything, flip, fullscreen, menu, none, popup, rotate, still). comp provides "rules" to choose which to apply to what element.
Dec 2 2019
Nov 19 2019
We apply our theme on the popup.
commit 822680869ff70a0f69dd383e3a810f3f18462dbc removes the possibility of not drawing the shadow.
I rewrote our popups and deleted the arrows.
I already have enough patches to work correctly on X.
Thank you for watching.
Nov 7 2019
it's a gadcon popup? have you modified the theme? this is your own module for wifi? how do you get the arrow pointing TO the gadget? normal e gadcon popups don't know the location along the edge they pop up from - they tend to center around their gadget but if at a screen edge they will shift to stay on screen, but the theme doesn't know how to move an arrow if there was one... have you modified this? default theme gadcons are solid thus the default config is to give them a comp style with a shadow... in fact e_gadcon doesn't know about popup theme elements that do have alpha ... i'm looking at the code now. e is doing the right thing here... it knows the popup is solid and thus should have a shadow... :) there is no support to not do this. again - the comp matches decide what style to use so you can change the style chosen for gadcon popups, but e is doing the right thing.
it is an "e/gadcom/popup", the lower part is transparent in order to place an arrow
Nov 6 2019
that wifi menu popup... this smells like a compositor matches issue where it doesn't have the right rule to choose the right menu? I can't reproduce that here because I have no idea how that popup is shown, but if you check the compositor advanced settings you can edit the window matches and one of the rules allows a match to match ARGB or not and... if a window is ARGB it should be using a style that doesn't have a dropshadow. is it an override-redirect window? it's certainly an ARGB one which would normally mean no shadow. i need to know what kind of window that is and what its properties are... is there a way i can test and reproduce that here?
Nov 5 2019
The 3rd picture was a bug in the Ordissimo office. Corrected :).
The bug on image 3 does not affect patch, I applied the patch upside down and it does not change anything!
Oct 15 2019
Oct 4 2019
Sep 29 2019
Sep 26 2019
Sep 13 2019
Resolut by D9900
Sep 10 2019
Sep 9 2019
I just backported our applications and modules to ELF-1.22.4 and E23 commits 0aea2d23a7573.
I confirm, the EFL bug bet is fixed.
Sep 3 2019
I don't see any issue when running this test code with latest master. Can you confirm whether this is resolved?
Aug 16 2019
May 24 2019
This code reproduces part of the problem.
May 23 2019
The problem appeared by switching to EFL-121.1 and E22.
When I go down in version it disappears.
I did not find how to reproduce it, I did not find any factor causing the problem.
I do not understand the opening of this loop, since it was only at the opening of the apps that I found it.
Do you have any scenario that trigger it? Or any way for me to see it in a public application?
May 17 2019
Bug not resolved just less frequent.
Resolved by D7744
Apr 30 2019
Apr 1 2019
Nov 7 2018
Oct 29 2018
ah, yes, the issue is visible also resizing the window, It's the first time I try to resize the window.
The bug is also visible when you press one of the button to perform the animation, so I don't
think thi is related to window resize. Seems more like swallows are not in sync.
it is when the window resizes right that you are talking about?
oh that is weird... and bad.... this doesnt seem like animation and more like swallows are not following the parent correctly... at least when i resize....