are you sure you compiled and installed the patched efl? the valgrind log - specifically the first entry is the same as before even though i explicitly have code there to NOT free the data it's complaining about and telling it to enable that code... your log would make sense if you hadn't installed the patched efl and were running the previous unpatched one... ?

you need your efl build tree. you need to apply that patch in the efl build tree then recompile + install efl. to do that:

cat you try this patch?

just so we have it here...

aha! that's more like it! :)

waaait .. we dont need massif. we need memcheck... :)

I fixed up our loader modules a while back (a whole bunch were compiled in always as opposed to being modules like they used to be) thus bloating out our runtime deps and dirty pages... so the issue here is not what is being linked to but link ordering if my quick read of the above is right? as @bu5hm4n says - that is one of those details meson itself handles - we provide more abstract sets like "link to these here". we don't determine ordering (well it's not meant to determine ordering - that's kind of the point of meson to not have us worry about every compiler,platform and requirements of ordering of linkage etc.) ?

Scrot issue. It draws a selection box. To do this it draws to root window with xor pattern and "include inferiors" thus basically scribbling all over the screen however it likes with no respect for the fact the compositor has placed a window above all others in the screensaver overlay layer. Thus it's scribbling all over where the compositor draws. This was fine to do in the days before compositing. It stopped being fine once you had compositors drawing the screen. What you have is simply a race condition where the xserver switches from using copies to buffer exchanges for displaying the screen buffer. that means with copies, the xserver COPIES the image from the gl backbuffer to the screen - thus overdrawing anything scrot managed to scribble. when it goes to swapping, the xserver will SWAP buffers. that means what buffer is displays is a pointer. "display buffer A", then switch to "dis[play buffer B" and basically the pointer is swapped. the memory that USED to be displayed on the screen now is recycled for a new backbuffer to draw on. evas (e) takes advantage of this with the buffer age extension in gl to know how old the buffer is and only draw the areas that updated.

fixed by d23615046b92333d7f27f97c040a6666a65a7aa3

Don't design the menu from elm menu.... certainly not from theme. Look more at e's menus for inspiration. A menu has to sanely be able to do check and radio items and ALIGN icons, radio/check indicators as well as submenu indicators/arrows.

ok. that says that pp->program is NULL, yet the only code that creates pp (allocates it and fills pp->program) can't fill it if pr were null (it'd crash there when created) so... the only thing left is that it's some kind of memory corruption. that pp struct is corrupted in the heap and the program member nulled out. at this point... you need valgrind or asan.

in git just recently

move to here - i can't reproduce any of the above issues. works perfectly for me. what os AND video drivers?

can we move this thread to T3438 ?

i am not sure what your problem is - i'm staring art it working right now in front of me on am amd card. i have had it work fine plenty of times on intel too. can switch x->terminology and back, vt to terminology and back...

T3438 has nothing to do with this and it works just fine for me in a tty. i do try it every now and again/ i can vt switch all i like. have been able to for a long time. but that is the other ticket and i'm staring at a "can't reproduce"... so i call that one resolved long ago etc. but irrelevant to this.

ok. a segv... now it's time for valgrind or asan to tell us more...

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.

try this instead:

try this instead then:

commenting that out isn't the right thing... do you have the image? i suspect it's _jpeg_gry8_convert_copy() messing up the ptr... cat you try this patch instead:

Just tested as I was sure this worked.... it works. efl apps. x11 apps via xwayland as well as gtk apps.

This does happen - the RUNTIME linker (ld.so) will search and if it finds the libs in a system dir it seems to prefer those to the ones in the tree. this happened under autofoo and still happens with meson it seems. i know they SHOULD be using an rpath which SHOULD make the in-tree libs preferred ... but that seems broken when running eolian_gen and edje_cc as part of the build... :(

if you had the old built tree around a "make uninstall" would do it. but i guess you don't... so yes - you'll have to manually uninstall it. delete all the ecore, edje, evas, etc. etc. dirs and libecore* etc. etc. libs that come from the efl install.

close it

the status is the same. this doesn't fix any bug. it makes the code longer and more verbose. sure. a better fix would be to make these strncpy's as that at least involves a tiny bit less work for the cpy func as it doesn't have to first walk to end of string (which it will try and immediately stop as it's already at the end). i am not in favor of putting in code that just is more verbose that doesn't fix anything. as the code to modify the string buffer is pretty much right after the buffer is either zeroed out or initialized to be empty (at least start with a nul byte) i don't see an argument for "one day if something changes" as anything that changes this will see the strncat code and should realize it needs changes. i don't see there being any real chance of this though. i'd rather these just become strncpy's to be clear their intent is not to append but to initialize the buffer, which is what they do. it would also silence the warnings.

you have a classic "2 installs in 2 places" problem.

well terminology doesn't barf this time :) evas tests fail for me (along with a bunch of other tests too all barfing on aarch64). :( but this is already the case without this patch. so this certainly improved things vs the last version.

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.

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?

@cedric - ok. cool, but what of cases where we literally do have to have a lot of objects subscribe to some event on a shared object (e.g. a parent or toplevel)? mainloop obj is going to be a nasty place for this kind of stuff... :(

This pretty much sounds like it's a freebsd thing to fix in the ports or in their install of meson. there is no choice on the install location for pc files in our build files at all... it's wherever meson thinks they should go. That is 100% the right thing to do.

After spending a week on reviewing our usage, I think anything advice 16 registered callback is an indication of buggy/suboptimal code that can be solved.

There is a bunch of other unexpected offender from edje_load.c:L664

testing

oh this is a mess now. the original patch has issues anyway - like core_timer_add() being undefined - also no tracking of that timer etc. ... and now it's messed up... so might want to abandon and start again?

Some apps may require it yes. We dropped support years and years ago. KDE did too. The xmbed code is gone. It was horrible. at least 50% of apps did not handle the xmbed tray selection owner going away and coming back while they ran (so restarting e lost icons and the apps didn't detect the tray coming back to re-register the icon). they almost all looked like complete junk when not 22 pixels in size (using low res icons). They all behaved differently. Some rendered square grey boxes using no alpha, assuming gtk theme background matched from their window to the panel because they just assumed they were in gnome, some did use argb ... and it doesn't port to wayland. so ... not going to go IMPLEMENT the support again for something that will not work any better because of badly behaved client apps.

I can't make it do it... tried. seems to only happen when your mouse is right on the very edge. theme doesn't change behavior for me...

Ah, finally after to follow your details I was able to set my own keyboard configuration, by just enabling that checkbox it worked...

well gstreamer is locking/pausing and not returning. can you list all threads and get bt's from all of them? this smells to me like some other gst code is probably holding a lock and not releasing it for some reason, thus causing a simple file close to hang and not be able to gain the lock.

I don't see this. menu appears where it should next to my mouse. maximized, un-maximized... tried maximizing/unmaximizing multiple times...

hmm the "only one systray" would be a holdover from xmbed days where you actually can't have more than 1 due to the nature of xmbed.

i don't see this. i check the checkbox int he menu and it stays up for a little bit until the timeout then hides as it should. i mouse over and it appears... i move my mouse away and after a little pause it disappears.

these tools talk directly to the xserver. they don't deal with e. e may modify the x kbdmap itself at times like at startup based on the kbd map/layout config and on specific keybinings configured to switch kbdmap.