As far i understood the situation, Efl.All is going to be internal, and this interface is the thing that should be used. So all in all the components declaration can stay here.

here comes a test

yes.

added testcase

Why is this api explicitly needed, and not just ecore_timer_add in the test itself ?

Its hard to impossible to test this commit. It just holds the scrollers while the mouse is over a slider. there is no example to particulary verify this single commit.

Nice catch!

And its actaully a bug fix ... :)

Just take a look into the referenced task

Okay, i don't know whatever commit in this stack caused this, but now my testsuite fails with: ../src/tests/elementary/elm_test_fileselector.c:135:F:elm_fileselector:elm_fileselector_selected:0: Assertion 'elm_fileselector_selected_get(fileselector) == exist' failed: elm_fileselector_selected_get(fileselector) == "/tmp/elm_test-bQ9btE", exist == "/tmp/elm_test-bQ9btE/exist"

Given that we are heading from one *deepshit* issue into the next, i will just closed eye approve this, given that the appearance before the commits is the same just with a lots more errors.

Thanks a lot! :)

The reason i did not review this earlier was, that there was a open question from you to jsuyu, can you next time clarify that his concerns have been met or they have been invalid, I did not want to land this before this questions have been addressed / clarified. Thank you :)

Thank you!

So this is a won't fix ?

@YOhoho you fixed something simular, can you take a look at this ?

@YOhoho D7841 caused this error, it appears that efl_ui_container_layout cannot handle a few objects there. Can you take a look ? :)

I have not read the whole discussion, only the task description, but isn't this does with Efl.Ui.Widget_Factory ?

I cannot see those errors on elementary_config anymore.

I think this was resolved a while ago, feel free to reopen if you see it again :)

This is causing T7360. Can you take a look at why this is happening ?

Okay, cause found!

A little bit more debugging information: this is related to elm_image, if you replace the elm_icon part in the test_icon.c with a direct evas_image, then everything is fine, no lacking, by the time you make it a elm_image, the lacking starts to happen.

Okay, if i am now using the most upperst revision then the items do not get mixed up anymore. However, the first population run finishes before the new path is populated. This is something that I would not expect as a user.

Ho Ho Ho! This issue was fixed by Santa!

/o\

Yeah ... and this is just fine, meson later on brings this keyword in...

This has nothing to do with windows, evas and meson do not play well together, hence evas is build with leaving internal API outside linking. You can -Db_lundef=true in order to workarround this.

I 100% agree with this change. However, can we wait with this change until we are open for the next release ?

A little bit of debugging information: this is fully related to images. You can replace the icons in the genlist with a button or label, and there is no lacking.

@Jaehyun_Cho the reason i have added this under the csharp namespace is that it *cannot* be confused with autogenerated EFL applications, and we prevent later collisions in case we want to name a class efl.application.

With the script given in [1] you can check how many problem cases we have. We have 0 *direct* problem cases, but ~8 cases that cannot be checked by the script. However, they are looking fine to me.

Does not apply here ...

Looks fine to add them to Eo.h efl_event_callback_call is the only one accepting event_info afair.

#1 Open a large directory in fileselector, close the window -> SEGV
#2 Open a large directory in fileselector, click on home -> things get added to the view that are not in the directory that is least recently opened
#3 Open a fileselector, click arround -> observe a giant amount of errors in the console

I wait for the day we get a bug report "But i wanted to set text while the object was beeing deleted! I used that to safe a string Plz fix!"

ab30ff3f9bd8b82c5df9c97e0092d18221f0b7dc

_eio_build_st is protecting itself from doing what I wrote above, it just feels a little bit fragile, since changing this would leave the world in parts, maybe make pd->st = NULL and pd->info = NULL; in case of an error ?

Let's just keep this here open until the release is out, then we can still decide on a name :)

use less stupid API in eolian.

Maybe just try to use inline comments for once, it might be usefull...

update

This can now be reviewed!

If one, either pname or fileis NULL then the pl / cl is different, and the block is executed. Hence, if the strcmp is executed either both are NULL or both are not NULL. Thus This commit seems fine.

I cannot find -S in a .pc file ...

Segarray is still in the API so cedrics wish was not fullfilled.

Autotools support (marking is as RC so its out of the pipeline)

Uhhm, this is the same test just twice under a different function name... Is this a cnp error ?

This revision actaully fixes that and makes it shutting down in a few seconds.

Are you sure its a infinite loop, or just terribly slow? It takes here ~ 3 min. until the window is closed. It is faster with my recent gengrid patches ... :)

Maaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaan :(

This is usally a indicator that the widget tree builds a cycle in the shutdown. I can open here a lot of windows and nothing happens, it might be depending on what kind of widgets are there. Do you remember which windows you opened ?

Is there a reason why this does not change Makefiles ?