Final update

Final update

Final update

A few last comments. With them fixed I think this one is ready to go.

Besides the subject of the commit message I am happy with this.

Mybe change subject to: build: refactor dependency handling ?

My two earlier comments still need to be addressed, after that its ready.

The build time concerns have been fixed and a build without the efl-one option set will not have a build time penalty anymore.

fix evas bug

rebase on master

rebase on master

rebase on master

fix wrong package_c_args defines

fix comments

rebase

The files changes are needed as we are building the library now outside the library folder, which means we need a file object instead of a random string, interpreted as a path.

Yeah that is expected. We need to build each and every shared object lib again as a static library, which doubles the amount of libraries we are building, that is sadly nothing we can get around right now.

When doing some first build tests with this I saw a jump in ninja build targets from 3600 to 5800 without efl-one set and 5200 with it set. Is this to be expected due to the different ordering?

I was also wondering about the files() changes all over the place. Is this for better work with newer meson versions or is this related to refactor in a way I do not understand?

Classes and methods inside classes are already sorted alphabetically in C docs:
https://www.enlightenment.org/develop/api/efl/object
and in C# docs:
https://enlightenment.github.io/www-content/gh-pages/api/csharp/api/Efl.Object.html
so don't worry about me.

This should only affect the C implementation code. We should likely alphabetize any doc generation (cc @segfaultxavi) so that we get consistent docs generated regardless of eo file ordering.

Even if this pays off, i dont know if its really worth it doing that, as the reordering of .eo files seems quite a bit random. Do we really want that ? I will just put the revision here so we can discuss it, maybe we need a better way to do this. (This is also a heavy platform specific depending topic)

rebase & update the complete stack to work arround issues

fixes & rebase

this is wrong.

No more questions, Your Honor.

naming fixes

More fixes and progress

Except for the minor cosmetic of the .h file name not matching the function name, I am good with this. You might want to add a _unregister function as some of the register could be done in a module and disappear at any point.

Unfortunately we don't have a way to detect it with the current infrastructure because the device will be 0 in the case of pointer events when it should probably be -1.

I somehow still do not like that we sent a MOVE before the DOWN event of the first finger, but not for the second finger, that feels absolutly inconsistant. IMO we either do not have move before multi,down and down, or we have it for both, having a different event flow based on if we are multi or not does not make sense. The normal event flow is: in;move;down for multi it would be in;down; that is weird,.

device is 0 on the eel that has ECORE_INPUT_DOWN...

IGNORE ME

Yea remove L709, idk what I was thinking there.

That does not fix the issue... the move event is still sent when a second point is downed .