For patches which should not yet be merged
Details
May 27 2020
Final update
Final update
May 26 2020
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.
rebase on master
rebase on master
May 25 2020
fix wrong package_c_args defines
rebase
May 15 2020
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?
May 14 2020
May 10 2020
Mar 20 2020
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)
Mar 8 2020
Mar 3 2020
rebase & update the complete stack to work arround issues
Feb 26 2020
Feb 15 2020
fixes & rebase
Feb 14 2020
this is wrong.
Feb 13 2020
No more questions, Your Honor.
Feb 12 2020
naming fixes
More fixes and progress
Feb 7 2020
Jan 31 2020
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.
Jan 28 2020
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 .