I worked a bit on this extension years ago, and I use it daily, if you have questions, I might be able to answer them :)

Can you upload a file somewhere ? (Somehow compressed :-D)

I can only test on xorg right now, but when i drop something from elm test in chromium, accepted is true. Accepted is in simply reflecting if there was a transmission or not. Please ensure that you are actually performing a drag operation.

Hi! Thank you for the patch, there is one little thing, other than that, things do look good :)

What you describe is definitly a bug which should be fixed yes.

Making the unregister in line 231 conditionally for not widgets should fix that.

Oh okay sorry - my brain fully worked in phabricator terminology there :(

@n3rdopolis can we just use your mail address nerdopolis <bluescreen_avenger@verizon.net> for landing this ?

You can get the raw diff just here by clicking above "download raw diff".

1. This breaks legacy drop targets on none efl.ui.dnd elements.
2. This breaks registering 2 events, unregistering 1 -> no event will be delivered anymore.

_layout_get_hyphenationwrap also needs to protect against wordbreaks beeing NULL (as its now checked before).

Mhm, there are a few things that are not right in the way it is done right now:

1. false as argument to install_dir is deprecated, the entire configure file blog should be moved to the first if clause.
2. the prefix of efl can be different to the prefix of gdb, (for me efl goes to /usr/local/ and gdb goes to /usr/, gdb loads /usr/local as well as /usr/), so dir_lib actaully needs to be gdb prefix here, not the one of efl.

Thank you for your reply, i think the question here is if we want to cover our buildsystem for this usecase or not as this could get quite messy. @stefan_schmidt What would you say ?

Just my two cents: I think the tests should unconditionally run with the respones files, and not only if PATH_MAX is too small, this way we can ensure that the respone file is tested on any maschine that runs the tests.

Maybe as a quickfix it would be good to *not* call eina_file_close_from at all for now we only have that since 8 months. (And additionally, add a ok into the for loop)

Mhm, there is more: if a application has 2 threads running, and the other thread is in a critical section in malloc when we are calling fork, eina_file_close_from will never come to call realloc, which ultimatly deadlocks the child process, deadlocking the parent process on the read call. (That is also something the links given by @eagleeye are suggesting)

Undependend from whatever the reason for this deadlock is:

Mistake found, give me a few hours to run tests.

mhm, this issue is a quite weird, libbuffer.so should be renamed by a post installation script.
Would you mind answering / doing the following:

1. Share the log of your "ninja install" invocation ?
2. Which distro are you on?
3. Which meson version are you on ?
4. Whats your process of building efl ?

Seems good. Thx.

add comments and a nicer for loop

But yeah, i will write more comments for the code there.

@kimcinoo should we adjust that behaviour in cycle ? (Same argument applies there)

rebase

rebase & commit message update

Okay, i will wait with landing.

I guess this diff is not about the concept, i will just load the old version of it.

Mhm yeah, that is true. But on a conceptual level i am not sure if it is a good idea to do this, as there is no assertion the correct audio & visual are done, and thats kind of the point of the extension...

thx.

Yeah sorry, i missed the assignment, look good to me. (I wont land, waiting for @jsuya.

In D12092#231096, @jsuya wrote:

If there is no target (info's next or prev), elm_access finds the target once again in the focus_relation (539 line).

jup :)

I think this is also a case for a eina_safety_on_null_return, as this should simply never happen.

can you make a safety check out of that ? I dont think we should continue there if access data is missing.

im is already checked in this function, and ensured to be none NULL.

eina_unicode_utf8_to_unicode can only return NULL on memory allocation, i think its better to have have a early return of NULL when udelim is NULL.

I dont think this is really what you want.

you can also just use eina_streq, which does NULL checking.

Mhm :( yeah, now the times are not great anymore ... :|
Old:

       471.34 msec task-clock:u              #    0.964 CPUs utilized
            0      context-switches:u        #    0.000 K/sec
            0      cpu-migrations:u          #    0.000 K/sec
        7,327      page-faults:u             #    0.016 M/sec
1,513,816,860      cycles:u                  #    3.212 GHz
2,246,871,347      instructions:u            #    1.48  insn per cycle
  375,434,454      branches:u                #  796.526 M/sec
    4,104,794      branch-misses:u           #    1.09% of all branches

mhm, there is *no* chance that fslider can be uninitializied ?

Nice, thx!

This looks really nice otherwise :)

For the record:

address review comments

Will update later or tomorrow :)

https://travis-ci.org/github/Enlightenment/efl/builds/712468414

https://travis-ci.org/github/Enlightenment/efl/builds/712166565

I can do that if that helps anyone reviewing it. But its all the same ... :)

Mhm, can you elaborate why this is needed ?
As of right now, the package_c_args from the lib will be in package_c_args in meson.build:449, so i think this is currently unnessesary ? Where exactly was or is the missing symbol ?

Yeah time to remove it. https://i.pinimg.com/originals/28/5b/d8/285bd859271e26b94c3ce54881d0bddb.jpg

Thank you!

Patch does not apply ...

thx.

Note to myself, dont comment before awake: https://travis-ci.org/github/Enlightenment/efl/builds/703813078

https://travis-ci.org/github/Enlightenment/efl

In D12034#229727, @felipealmeida wrote:

I don't want to install an application to be able to compile or download dependencies. This makes no sense at all IMO. If we're not going to have wrap dependencies, we still need to be able to tell where dependencies are without pkg-config. We have neither, and wrap dependencies is a meson feature which, IMO, helps a lot. Lots of other libraries use it (gstreamer for example). And this doesn't need to be on by default. I wouldn't need subprojects in Linux (though I've used subprojects for gstreamer when developing for it, and was much easier when using git versions).

Hi bu5hm4n.

I am not really a fan of using subprojects here either, not because subprojects per se are bad, but they dont fit the scheme of efl and how distros work. Just from the top of my head a idea on why i dont think its a good idea:

• In case we are having subprojects, we are defining the version of a dependency, not the min version of anything, the version itself is then defined, in case there is a CVE or some major bug, we need to proactivly reroll another release of efl bump versions etc.. Not sure we have the capacity in the release department for that CC @stefan_schmidt )
• Not all meson projects can be used as subprojects, some require external dependencies, in case some code compiler is compiled, cross compilation will fail.
• Sometimes wraps do disappear (example stb, there is still the entry in the wrapdb, but the wrap in gone) in case we ever rely on wrap, we also need to take a share on maintaining the wraps, or we might loose them
• Subprojects bring the harm of 2 providers, so in case zlib-wrap is now sucked in as a dependency instead of a libzlib.so on the system, then the subproject wlll be compiled, and with the next ninja install it will be installed. In case you use any other project doing the same thing, or the distro shipping zlib as standalone, you will end up in a ugly conflict...

With these two comments, then: should I split 6 and 8 into two other patches? For 6 because we can track this in an isolated patch, and for 8 because of possible opinion divergence.

Sounds good :) (If getting out 8 is too much work, i dont have a issue with first merging that if the rest of the stuff is coming in a next patch :))

First Half of the issue

I think you can just remove the _dep prefix from these 4 vars ... no big deal, there is really no thought behind that scheme, just make sure the names do not collide :)

Independend from if this is a good idea or not, things that are not clear to me:

• How to do that in eolian ? Every eolian API is defined with EOAPI, which is defined to be EAPI & EAPI_WEAK with this approach you either need to patch eolian to take the correct preprocessor directives (then eolian needs to guess in which lib it is), or you need to redefine EOAPI which is then reintroducing the thing you are trying to solve
• How to handle EAPI's in modules ?

1 / 2 / 3 / 4: fine for me.
We recently bumped min version to 0.50 so 5 & 7 Should hopefully work without issues.

This looks fine, however, this is a ecore hash implementation that hasn't been running for > 10 years ... should we just remove it ?

THats good.

Thank you. I checked upstream that we do not assigned parent_obj *ever* by hand. And we don't. Can you ensure the same in tizen ?

Yep, that now looks even better. Thank you :)

Looks good to me, thx.

I think you can go ahead and simply remove these efl_isa calls.

I cannot comment how it was with regards to backwards comp. but shoundn't this also check if the group is the same ?

Beside that little nitpick it seems fine to me.