Why/how will sharing the same instance be an improvement/make transitioning easier? It seems to me not having co-dependence of any kind will make the removal of the old module easier? Perhaps ensuring independence of each at this point would be the better route?

@ApB fwiw - I can rep this with firefox stable, so its not just nightly. Looking into it.

So this is a wayland only issue - which suggests it falls in e_comp_wl_input.c ... Changing the xkb from the gadget menu and then from the keybinding gets the system kbd correct but doesn't update e's kb. To reproduce, on Wayland, Change the keyboard using the keybinding, then change the keyboard using the gadget, then change the keyboard using the keybinding again. The gadget's flag is changed correctly and matches key input in apps such as terminals etc... but if you just type on the desktop to search/etc... e is still using the previous kbd.

@snout any update? Also what are the steps you are using to add the gadget to the desktop and resize it?

My guess on thumbscroll being hardcoded to enabled is that someone working on elm for touchscreen devices/or a patch from Tizen who works on it with touchscreen devices, or something similar set thumbscroll as enabled somewhere along the way in the hardcoded default without considering the desktop use of elm. Either that or the values just have the hardcoded values but because they weren't used, they weren't tested, and no one cared.

I can confirm what Derek is saying. This patch removed the system fallback of the elm config - and thus left us with the code fallback which is not defaulted well :)

Got it.

So the gadget doesn't get updated when the language is changed by the keys?

https://git.enlightenment.org/core/enlightenment.git/commit/?id=f56a228e701eddf04f1bceba052cec83d5cd85c8

Adding evas_render(evas_object_evas_get(sd->spacer)); to line 439 in elc_popup.c fixes all of this. Now the question is why.

It is a drawing/rendering issue. See this video: http://www.smhouston.us/stuff/popup_render.ogv ... Notice the focus calcs the objects at the exact coordinates and size and placement of where they are supposed to be, regardless of the popup being drawn incorrectly. For reference of what the popup actually looks like drawn correctly so you can compare to the focus highlight in the video: https://www.enlightenment.org/ss/display.php?image=e-5b3bad1d204ad8.08297482.jpg

This looks good to me and I think is a necessary evil to add API. We can consider @bu5hm4n proposal to mark the API as beta... but... it is an api that legacy itself needs and if this could potentially be the last stable release for legacy (who knows how we decide to move forward with the efl branch once interfaces are stable)... then the api does not need to be beta in its last stable release. We could subsequently follow up a 1.21 where it is beta with a 1.21.1 where it isn't, but to plan on that seems like a lot of work for a necessary api, a trivial fix that works and tests fine, and is somewhat of a corner case.

Git everything -- Some can reproduce some can't. Go figure.

No complaints here. This was done at the request of Cedric before all the work to prioritizing, triaging, and tagging tickets happened.

In D6386#110165, @thierry1970 wrote:

• Using existing formatting.

I can help you with this too. It should be pretty simple as most of the code to do so is there. I would recommend to start by looking at modules/sysinfo/batman and how we display the popup and calculate time remaining etc...

This will also need to update the battery upower code in the sysinfo gadget. src/modules/sysinfo/batman

I dont disagree with you. When I found this to be the commit in question I thought I must have accidentally bisected wrong, until I tested the fix and confirmed that fixed it. Something with the focus tree calc realizes all the parts/objects in the scrollable popup?

Upon further testing this only fixes the elm_test scrollable popup case and does not fix Ephoto's scrollable popup in settings.

Hmm.. Actually D6361 only fixes elm_test scrollable popup case and does not fix Ephoto. Interesting.

I can confirm D6361 fixes this. As I am not hip to all of your focus work @bu5hm4n I'm aware this may not be the best fix. You can comment on the patch and lead me in the right direction if you don't have time to fix it, or if its just easier for you to fix it that works too. Thanks!

I just spent 8 hours bisecting this. The first bad commit is: 253430ab76348d99c81e3b753b6a32817bdb6666 ... looks like a @bu5hm4n commit. And seems like it would be highly unrelated.

@bu5hm4n any reason to not just use a hash?

And I lied. Just reproduced switching from GL back to software... Doesn't seem to happen on GL... Just software.

If I start E in software X I can repro every time... If I start in gl or switch to gl then back... I can't.

I highly highly doubt that this is useful... but here is an strace from running enlightenment -display :1 to open in xephyr... clicking to open two terminology windows from luncher, and hitting take screenshot and getting the all black shot. Since I already added the valgrind, figured I'd add this too just in casies. http://www.smhouston.us/stuff/output.txt

Agree 1000% here ... the parts alias: that asthis is confusing (and should probably be alias: this asthat anyway as all of our code and style is left to right... but that is a different story)

Simple enough fix, implementation looks correct, tested with colorsel and all works fine.

I need to check Ephoto for this behavior.

@SanghyeonLee @minkyu We are trying to get these legacy tickets closed to make a release... Do one of you have an update on this? Thanks.

Something fixed this... Don't know what.... but it is working fine now.

Working now per @vtorri so closing as resolved.

Really neat feature to help clean up themes. Tested and works fine.

In T6222#118044, @zmike wrote:

Do you get errors in your session log?

I believe Eina should be in the EFL namespace, simply because it is part of the EFL... Look at the history of the EFL... All libraries were EFL, every library that we developed and provided. While yes, Eina may be the lowest level and doesn't use any other part of the EFL and is simply there to be used, it is still part of the EFL and not namespacing it as such is confusing and implies otherwise. Further moving the lower level libs like eina, ecore, eio, etc... into a common namespace could help eliminate potential duplication that exists between those libs, such as file functions (eina, ecore, and eio all have file functionality, ecore and eio have file monitors), Thread functions (eina and ecore both have thread functionality), and other areas of potential duplication.

Yep.

Yes. I can't seem to reproduce in GL.

My suspicion here is that efreet_menu_get determines which menu should be default by checking strict first, then user config directory, then xdg directories to get the default app menu and then parse it and return it to you.
efreet_menu_async_get doesn't determine one from that group, in fact it will create a thread and parse out and hit the notify function for every single app menu that exists, starting with strict and going through all xdg directories. This breaks expectation of behavior as I believe the expectation is async_get will still determine default and return just that default, but do so async. Having that expectation with that not being the case could certainly lead to some crashes, for instance in E's case, rE3989e54e210edbb8974eec4cd19759d9994872a0 where the menu thread new callback requests async get and the notify cb sets the default app menu... this could happen quite a few times in succession due to every menu being parsed and notified by async_get and that being unexpected could definitely cause crashes.

Nope. No freeze. Just a pitch black screenshot.

and fwiw here is my valgrind while running that:

Can reproduce my problem with this at least. Start e in zephyr, open two terminology windows, menu->take screenshot. Black.

More detail:

In T6987#115381, @zmike wrote:

To elaborate, this happens only when dragging a gadget from a bar to the desktop.

@bu5hm4n I think this is valid use of API in the application side, can you check it out?

This seems fixed now after updating today... Anyone have any idea what commit may had inadvertently fixed this? @YOhoho @segfaultxavi @zmike

In D6251#106931, @zmike wrote:

If this mechanism isn't widely used then perhaps it should just be removed?

Looks good.

I believe you are more looking for Ecore Poller here than Ecore Timer... I suggest you change to that.

I don't mind helping you convert it to the E gadget. Just let me know if you want the help.

Came across this ticket - Now that NetworkManager has been implemented into enlightenment/gadgets/wireless.git ... OpenVPN theoretically is supported though not configurable from the gadget as of yet.

Just see that its broken again at this point. Haven't looked yet.

@raster this is broken again -- This is like the third time this has been fixed and then someone keeps always going back in and breaking it again. Hmmm.

Please post a patch for review here first so we can test before it is pushed.

And lets make sure we test a lot of other areas before moving ahead. Item ordering changed for a lot of reasons that were broke with genlist, not the least of which was how odd/even theme signals were being relayed due to broke ordering, so lets make sure everything is sane before pushing this behavior back.

https://git.enlightenment.org/core/efl.git/commit/?id=cf359629a529200b3b9e0accd2c45821dc64f60e

Haven't been able to reproduce or heard of anyone able to reproduce in months so marking fixed.

Can confirm that tree_focus_allow_set false is already being set on the ctxpopups on E's end and that this is indeed an EFL bug as we are not allowing or taking focus for the ctxpopups.