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.

+1 for a meeting.

In T5938#113686, @DaveMDS wrote:

@zmike ah, you right, the test is failing now, sorry I didn't know there was a test for this.

But it's the test that is wrong, as it is checking the new "broken" behavior, should I update the test to reflect the correct/legacy behavior?

In T6768#113679, @indefini wrote:

In T6768#113676, @raster wrote:

Time based or released based road maps are not of interest to those responding, including raster

You have GOT TO BE KIDDING. Let me quote myself above:

so just having goals and moving in that direction with regular releases of what is in a good state to release at that time is about as good as it gets. This is how the Linux kernel works and it's the largest open source project out there.

That is TIME BASED RELEASES. @indefini is 100% right - you are just wanting to complain and not bother with help because you don't even bother to read what does not fit your narrative. At least have the decency to read what I have written before pointing fingers at me claiming something that is utterly untrue. If there is one way to piss me off it is to accuse me of things that are absolutely untrue and OBVIOUSLY untrue. It's the 2nd insult you've managed in just this ticket. I'm beginning to think the problems in this project are people like you creating trouble where there is none. Yes. I'm calling you out on this.

I think he meant release roadmaps (time based or released based roadmaps) compared to this project roadmap that this ticket is about. I think he might be more interested about those than this project one.
And he says that you don't seem interested in release roadmaps because you wrote in the original ticket that you wouldn't gor for a per release roadmap.
I don't think he wants to tell lies :) this is just some misunderstanding :)

In T5938#113668, @DaveMDS wrote:

I restored the old behaviour with commit rEFLf0a0da9f449b

I think this only apply to legacy genlists and I hope I have not broken something else...
let me know if my commit broke something for you. It fix epymc for me :)

In T6768#113627, @indefini wrote:

In T6768#113626, @stephenmhouston wrote:

I think I agreed with the struggling part. You said it too, it is disappointing to not see much activity on these tickets. Though it is understandable that developers don't want to spend their (free) time on management.
In the end maybe it's ok if just a few people make decisions about this?

I think we have plenty of people willing to spend their time on management.

Then where are they? why did they not subscribed to this ticket and said "I want to do it, I want to maintain this project roadmap".

That isn't the problem. It seems to me the problem is no one wants to be managed/no one can agree on what should be managed/no one can agree on how it should be managed ... so in the end the plan is lets just make things up as we go - or depend on whatever raster says.

Yes, there is a problem on what should be and how it should be managed. That is why we opened this ticket to discuss about it!
We already identified some parts of the problem, now let's find/work on solutions.
I think you have to realize at one point that you are still in complaining mode. You have to switch to helping mode now.

In T6768#113586, @indefini wrote:

In T6768#113585, @raster wrote:

• edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.

Technically this is what enventor does. It does require you "Save". It could just auto "save" and rebuild after every change (and if there is no error) update. Right now it's manual to save. Or were you more thinking of something that can monitor a set of files you edit in a text editor anywhere and do a rebuild and update a preview so it'd work with any editor?

I want to see the changes in real time without latency. I change some value in the edc text and it instantly updates, or I could click an object and resize it, set its offsets directly in the preview with the mouse and the text would update.
I think it would make the flow easier and faster. Saving and compiling is too slow imho.

• enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.

Doing the library is really hard without also basically making policy. Also keeping compatibility. I think we have enough work doing that for EFL. I do totally agree with the touch/tablet support. I did start some work on that with a new vkbd module... It works decently in X. It does some touch support for a regular "Desktop" mode. Indeed proper mobile "fullscreen always" modes would be better still. I'm with you on this bit.

If it's too much work, it could be low priority. But if you want efl/enlightenment on any device I think it's not a bad idea to separate the common code into a library. The tizen watch wm must be quite different than e desktop, isn't it?

> At any rate. I appreciate the work you are doing -- and I know you would like to do more as many would -- but that you are struggling to get people to agree that what's failing the project is the continued unstructured philosophy, and if this is the best we can do with structure, then clearly it isn't good enough.
I agree. I think most people are not interested in management and can endure the problems that comes with no structure.

Ummm... I'm confused. It sounds like you disagree, but you say you agree... What exactly did you agree with?

I think I agreed with the struggling part. You said it too, it is disappointing to not see much activity on these tickets. Though it is understandable that developers don't want to spend their (free) time on management.
In the end maybe it's ok if just a few people make decisions about this?

ah you aren't using a tree.

In otherwords I don't think that item_)next/previous should delve into subitems at all... I think it should stay on the same level (as it does) and you can then delve into subitems with subitems_get

In T5938#113602, @DaveMDS wrote:

maybe I wrote the graph wrong, as your last comment seems non-sensical to me, I try again:

item #1
GROUP #1
 - item #2 
 - item #3
GROUP #2
 - item #4

in this scenario item_next(GROUP #1) currently return GROUP #2, while I expect (as is returned in 1.20) to return Item #2
... for sure not item #4

In T6768#113251, @indefini wrote:

In T6768#112939, @raster wrote:

first - thanks for documenting this and writing it up.

interesting. zero activity on this... nothing to say from anyone?

Maybe most people want a roadmap, but they don't feel the need to participate to it?
or they might propose changes to it later?

Here's what I want :)

• elementary : the possibility to make your own widgets easily and possibly share them.
• edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.
• engine : more opengl/vulkan api support, opengl win engine.
• enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.
• less bugs :)

In T6768#113249, @stephenmhouston wrote:

This is good for an About Us or Philosophy section on a website, but as far as releases and work goes, it doesn't even scratch the surface of what is needed for a roadmap.

I think you should write more precisely what you want this roadmap to be.
The first part about project vision is exactly what you said, but the rest is more like goals (and not "about us/philosophy") discussed by raster.
This is an overall project roadmap. Imho, it's not particularly made for releases and work but more for seeing where the project wants to go.
I discussed about a roadmap/ticket for each release in the original ticket T6740.

This is good for an About Us or Philosophy section on a website, but as far as releases and work goes, it doesn't even scratch the surface of what is needed for a roadmap.