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.

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... :(

I think @cedric did the mempool stuff. My original code would have just malloced everything. But I do know why it creates mempools per collection... So to free everything it just frees the whole mempool and not each item one by one, making the "free it" cost lower. This is kind of a work-around to eet originally not supporting arrays for encoding so everything was lists. This allows us to collect everything into one region of memory for this implicitly via the mempool (because mempools are the same-sized items, a bit like an array). As I mentioned before. I never expected out edj files to become so incredibly huge. I expected them to maybe have a few dozen part collections (group {}) or 100 at most. We've ended up at like 10-20x my "at most" expectation now by default. As I mentioned before... I'd do things differently if I got to re-do it but not even decoding but doing everything mmaped live from the file. for the directory entry of Edje_Part_Collection_Directory_Entry's I'd do something like:

hey @smohanty - keep things from getting personal. we DO have guidelines on how to behave: https://www.enlightenment.org/contact . You're not joking here and it's definitely crossing a line.

solved with 1106cf9db45e45a719fd26b2b5fdcc3c568a34c9 and 4bdb0212a2831087b5031c266c3ab44fdd85928a allowing you to set magnifier and desktop style entry mode in elm config gui

that's what i see - it goes up a dir to where the mount points will appear .... :) so we're on the same page then. :)

i've tried a few combinations of the options and i can't see a new window appear. i do see an existing window that points to the base mount point go up a parent, and others that point further in disappear with error dialogs. we could handle that a bit more consistently i guess... but... no new window. :( both eject and unmount -> same story. unless you change settings efm will not even mount until you open the dir in an efm window. it'll auto unmount when you close the window. it's intended to be this way to minimize filesystem dirtying until you actually need/use it (opening the window == using it). there is an option to do the "always mount anyway" but that exposes you to making filesystems dirty... so i don't know how to see what you're seeing :)

I have.... never seen that... ever. I am not even sure how that can happen? I unmount here and efm just goes back a dir if its in the root of the mountpoint or if its deeper it ends up closing the window(s) with these dirs with error dialogs. i dont see a NEW efm dir appear.

oh the orange blinker == scan, blue == visible.

that's up to bluez. it'll stop blinking when it stops scanning :)

can you try again after my commits that fixed a bunch of things that could have led to heap issues? once something is messing the heap (or even stack) up... it's kind of unreliable as to what else it may damage along the way.

I'm not that crash hot on Efl.Text.Annotation.Factory. Certainly as a name... Wouldn't Efl.Text.Range be better and as part of the constructor/construction of the range you have to pass 2 cursors? the question now would be - does the range keep tracking the cursors or is it fixed and the cursors are just used as markers for begin/end when u construct or set/change them later? so more:

just fyi. i build on aarch64, armv7 and x86-64 regularly (like multiple times a week on all and daily on aarch64 and x86-64) so if there is a break - i do not see it. it'd maybe be some special cflags or environment that induces the break vs what i build on/under.

just as a slightly more generic point... this is what eolian_gen was meant to be for. it's job would be to appropriately MAP the efl api to the native language. For example perhaps camelcase functions if that's what that language ecosystem prefers. it's job should also be to specifically deal with these issues rather than them leak into our .eo files themselves. rename classes or types as appropriate in the tool... then it also enforces a consistent naming for such situations too which is too.

Updated: We always use EINA_MAGIC , even in tizen people are scared to turn of EINA_MAGIC_DEBUG , so List Node Data size = 5 Pointer = 20/40 byte

I tried array/inlist for clippers and it was way worse, because of the access pattern.

If you ask me do i want to use a container which can only store a 4/8 Byte Data (pointer to data) for that it keeps 16/32 Byte of Book Keeping . I will not even look at it. (let alone how bad/good to access that 4/8 byte of data). If we just assume that there is no problem and bigger problem is somewhere else .. we are just ignoring the problem that's all.

well inlist always is part of much larger data structs ... so the inlist header inside a much larger one makes little difference so arrays will be just as cache-missy as a linked list as no single object item is less than a cacheline. ... they are all big structs. so let's skip that. that's the real world usage pretty much.

i see no code to free the hash when edf is freed... :) also yes - doesn't handle building the hash if stl->name is null properly :) in theory the incoming edj file could be malformed with null style names... so handle the case.

@bu5hm4n that's the idea of blist indeed. it's after a lot of thought on what eina list is bad at. it makes some compromises because it has to, but in return for other benefits. it's a "use in cases where it'd really help" cases. So trivially short lists -> not much help. Lists we very very very rarely walk -> not much help. Impossible for anything that keeps Eina_List * nodes middle-of-list and expects them to be "constant" until member removed. It doesn't solve inlist style use cases which imho are mostly for very big objects where arrays would not help and just hurt.

cool. i saw those :) let's call this done for now.

we very rarely need to store something that simple in a list... but i get your point. most of the time it's a fair bit more than that. unless you can show me the many uses of such tiny data structs (that are either filled with lots of data - thus wasteful or are walked really often - thus getting cache misses) ?

ok. well still - callbacks use a lot of memory too... :) i don't have much to say about vtable as i've never looked at it at all... so i'll leave that alone for now, but callbacks can be optimized a bit i think. it won't need a change in design other than looking at the events we have and maybe merging some or adding merged ones where valuable?

no one was interested. i've been meaning to drop this into eina and begin using it internally whenever possible. a slow move over to it would help.... a lot. it's designed to help with locality by having blocks be a multiple of contiguous cachelines. it actually will save memory on anything that is not a super-short list. it still looks like eina list in that it stores pointers to stuff (inlist is a different beast). i built it as a fairly easy move from eina list to blist... just read the patch review. it's intended as super-early "lets throw ideas around" for this to be a viable replacement for eina list in almost all cases. as it hides the implementation it can even just drop down to a single array internally if the data never changes and is just appended to most of the time. it could under-allocate blocks for super-short lists. there are openings for lots of optimizations it can do to be even better in corner-cases. we don't have to do all of them day 1. the first step is agreeing on the api & design being good. the implementation leaks out into design somewhat but not much. the only thing this can't do that a list can is keep a handle to a specific member of a list (an eina list node) and know that handle will be valid until that member is deleted/removed. it can't do that bit. all other uses if eina list are fair game. i also designed it to be less error prone so no list = func(list, ...); just func(&list, ...);

by bookkeeping you mean things like callbacks? because that is what was selected, but the vtable stuff was what was expanded...

yeah. actually found bug #2 in that patch. i still have one of my unlocked funcs still lock. forgot to remove them... now down to .... 28 locks to start elm test. so... update. locally with an updated patch... 615604 -> 28 lock+unlock cycles. i think... that will be good enough eh? :) even if a read lock is 3x as expensive... we do it 0.004% as much as before, and still get the write contention improvements. :) i call this a win.

cool. so i guessed what you wanted. btw that patch has a small bug in it. find it :) (i already have and fixed it locally). it won't affect running things and testing performance though.

oh yeah... env vars may in theory change between tests.