Not going to merge this until the meson files are updated appropriately.

Correct the password popup logic.

Fix typo in eldbus string.

Adding @Hermet @CHAN @woohyun so we can perhaps get someone to try and fix this properly so the cycle of fix/break with this particular functionality stops happening?

FYI the ticket showing that format is currently broken is: https://phab.enlightenment.org/T7656

I added the test for this and put it up for review: https://phab.enlightenment.org/D7745

I added a test for this so that once this is fixed again, in the future ninja test will fail when it gets broken again: https://phab.enlightenment.org/D7745

@raster can you update the work you've done here so I can see what's left? Thanks.

https://www.enlightenment.org/ss/e-5c48da6940acd0.80417298.jpg - @raster all new gadgets should be converted now.

Formatting2

Formatting

In D7718#136192, @michael.bouchaud wrote:

I see many things to do this

First and the biggest issue about the old and new, both try to catch pulse input_sink to add it to an e_client. This go to make 2 e_client_volume instances for each e_client associated with some sink_input. It works but consume only more ram and have no benefit.
The new gadget don't create his e_actions before we create a gadget. So some users in future need to add this gadget to control the volume with keyboard or whatever they want.
Old and new gadget, have a default_sink saved into the emix_config which is only one config not 2.
And for futur sharing code instead of massive cnp. The old and new gadget only use gui code and no more emix things. So if we fix for one we fix it for both.
For futur too we init the backend into e_mod_main.c and mod.c too, if we go to remove the old gadget. Just rm old gadget file and we are good.

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.

@cedric @akanad 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?