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.

makes sense.

OH don't get me wrong - hand optimizing for some special cases where it really makes sense would be good, but a "optimize most cases to a reasonable degree on average" will cut down the work.

but we call other events a lot like mouse move or move,resize and geom change events. a cache would only cost an extra cmp+bra if empty before walking the events ... if it is a few slots its a small walk of N items probably in a short array of 4 or 8 items. in your case of "not so frequent invalidates but invalidating everything" the invalidate should find most objects with empty caches so its the extra cmp+branch for the cache ptr check which should be next to the events so its in the same cacheline. yes. it's a cost. will this cost give us a win in all the other cases without having to hand write special event counting and maintain a bunch of event counters

wouldn't a nicer general solution like a cache of event ptr -> count of cb's registered be good? keep the last N event types in this cache (have it be a small 4, or 8 slot or so cache) ... and we need the ability to remove the cache entirely on "inactive objects"? the callback call can look in cache, if it's there and count is 0, instantly-return. if not in cache - do a walk to try call and while it walks, update the cache to have an entry? we need some timestamp/cycle count or something for the last time a callback was called on an object and so with objects that rarely produce events the caches can be freed...

backtrace... :) run rage in gdb 0 when its hung and not responding - ctrl+c and get a bt :)

stuck where? backtraces? stuck how?

it never was "usable". i never implemented gui controls. I put that there to use later when i do. key controls should work (+ / = for vol up / down). so it's not a bug - just a yet-to-be-implemented feature.

none of this fixes any bugs - it just makes the code longer and wordier. warnings are there to encourage us to look at code that might be a problem... the code obviously was not in need of adding - strlen(buf).

eina headers have to solve this because eina_inline_lock_posix.x has the implementation and it needs to #define enough to ensure the headers it has other 3rd part apps use have everything working. so:

my change fixed xpm to work again - so i suspect my commit fixed this and this should be closed :) it wasn't working right if you did async loads because of the thread field being false. :) i tested it myself and the xpms were loading fine...

see inline comments

so <font_size=12>hi</> is no longer allowed

we do want the background to know and be able to react to being disabled. you want a widget tree (imagine you disable a scroller that has a table of buttons, checkboxes and has a background behind it). you want to be able to "grey out" a background if that is the visual paradigm. as default backgrounds are already grey it's kind of pointless, but perhaps dim it or fade out any swallowed image or rgb solid color set to mute it and make it more "grey" to indicate that whole area is part of a disabled tree. in the case of a window you can disable the whole window as well and thus all content in it... :)

not into different edj files - no.

I don't really see how, conceptually, we can consider the theme API completely unstable if we're releasing widgets? The premise I'm working off is that any theme built off the current API will continue to work until 2.0.

can we then keep the theme api unstable? yes - there is versioning but it means:

Having a look at some of the edc's for efl/* things:

This really needs to be carefully reviewed before release. I won't have time over the next week or so (conference event all next week + travel).

just fyi. one solution is to just back out the "new software map rendering code" and go back to the old one for now. it's a "nuclear option" but it'd fix it. i'd rather not though and have @Hermet look at it.

no- this happens on 64bit too. the new map rendering code reads out-of-bounds. it miscalculates coordinates and pointer addresses. i've seen it fall over pretty badly when i tested the old screen setup dialog in e where you could rotate the monitor in the gui... :) lots of cases of large amounts of garbage pixels.

@Hermet ping ^^^^

oh wait... to be non-obvious you have to use requires not extends... this is kind of weird... why?

btw... this is horribly broken. to the point it's a showstopper.

a70808fb9643e95659582aced54e09555252afe7 + e6d9ea7539418ea2f898853c5f3655d3417153f7

quick hack that solves things... but not nice big-picture-wise... :(