Not going to merge this until the meson files are updated appropriately.
Oct 2 2019
Mar 11 2019
Jan 26 2019
Correct the password popup logic.
Fix typo in eldbus string.
Jan 25 2019
Jan 24 2019
Jan 23 2019
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.
Jan 22 2019
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?
Jan 17 2019
@ApB fwiw - I can rep this with firefox stable, so its not just nightly. Looking into it.
Jan 16 2019
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.
Jan 11 2019
@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.
Jan 9 2019
So the gadget doesn't get updated when the language is changed by the keys?
Oct 24 2018
Aug 8 2018
Jul 13 2018
Jul 6 2018
Jul 5 2018
Jul 3 2018
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
Jun 28 2018
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.
Jun 27 2018
No complaints here. This was done at the request of Cedric before all the work to prioritizing, triaging, and tagging tickets happened.
Jun 26 2018
Jun 25 2018
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
Jun 22 2018
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?
Jun 21 2018
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!
Jun 20 2018
@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.
Something fixed this... Don't know what.... but it is working fine now.
Jun 19 2018
Working now per @vtorri so closing as resolved.
Jun 15 2018
Really neat feature to help clean up themes. Tested and works fine.
Jun 14 2018
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.