Summary:
Patch from a series of patches to rename EAPI symbols to specific
library DSOs.
= The Rationale =
This patch is from a series of patches to rename EAPI symbols to
specific library DSOs.
EAPI was designed to be able to pass
`__attribute__ ((visibility ("default")))` for symbols with
GCC, which would mean that even if -fvisibility=hidden was used
when compiling the library, the needed symbols would get exported.
MSVC __almost__ works like GCC (or mingw) in which you can
declare everything as export and it will just work (slower, but
it will work). But there's a caveat: global variables will not
work the same way for MSVC, but works for mingw and GCC.
For global variables (as opposed to functions), MSVC requires
correct DSO visibility for MSVC: instead of declaring a symbol as
export for everything, you need to declare it as import when
importing from another DSO and export when defining it locally.
With current EAPI definitions, we get the following example
working in mingw and MSVC (observe it doesn't define any global
variables as exported symbols).
Example 1:
dll1:
```
EAPI void foo(void);
EAPI void bar()
{
foo();
}
```
dll2:
```
EAPI void foo()
{
printf ("foo\n");
}
```
This works fine with API defined as __declspec(dllexport) in both
cases and for gcc defining as
`__atttribute__((visibility("default")))`.
However, the following:
Example 2:
dll1:
```
EAPI extern int foo;
EAPI void foobar(void);
EAPI void bar()
{
foo = 5;
foobar();
}
```
dll2:
```
EAPI int foo = 0;
EAPI void foobar()
{
printf ("foo %d\n", foo);
}
```
This will work on mingw but will not work for MSVC. And that's why
LIBAPI is the only solution that works for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
On Windows 64bits, long is a 4 bytes type. Declare count as being a intptr_t instead of long
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11836
Summary:
The glayer_tap_finger_size can get diffrent value on each profile.
Need to get system config value and will set it for gesture manager.
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11485
need to always make sure we set this when a gesture is being tracked so
we know which touch point we're watching
Differential Revision: https://phab.enlightenment.org/D11387
it's not enough to just check the value for this in the recognizer; we need to
always modify the recognizer property here to correctly manage object lifetimes
and generate the correct events (e.g., not emitting momentum gestures while
multiple fingers are moving simultaneously)
also update a couple existing unit test checks which were wrong
Differential Revision: https://phab.enlightenment.org/D11386
if the recognizer is processing using a touch point other than the first finger,
e.g., in the case where multiple fingers are pressed simultaneously, then
the recognizer needs to also detect distance based on that finger
more fixes for triggering tap events while fingers are moving
Differential Revision: https://phab.enlightenment.org/D11385
when a gesture ends and is not set to continue, the gesture object must
be preserved until the entire touch sequence ends in order to ensure that
all the touch point states are accurately detected and updated and so
additional instances of that gesture are not accidentally triggered
this fixes weird corner cases where you could tap with two fingers and
then get a long press event while dragging the second finger around as
long as you did it quickly enough
Differential Revision: https://phab.enlightenment.org/D11384
this is a 1:1 port with minimal changes other than what's necessary to
integrate into the new framework
Differential Revision: https://phab.enlightenment.org/D11383
this is consistent with the rest of efl naming
ref T8503
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D11376
we probebly want to use import here, as we want to rebuild this file
when efl_canvas_gesture_events is changed.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11273
this serves no purpose and isn't used anywhere
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11323
this needs to return the actual gesture class type so that custom gesture
events can implement their own properties if necessary
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11322
this should all be managed by efl.config
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11320
recognizers need to be able to get and set this appropriately
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11319
this is the timer pointer, and we need to be able to delete the timer when
the gesture ends
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11299
correctly set 'pressed' member of touch data only on press events and
don't change it on move events in order to avoid having mismatched states
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11291
we use c_enum_naming_style in our enums, not cSharpEnumNamingStyle
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D11275
this is redundant now that touch_count exists
ref T8554
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D11274
this simplifies (and optimizes) a bunch of code by letting gesture recognizers
return directly the type of gesture they recognize for use internally
ref T8503
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11267
the old one used here is marked deprecated
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11263
this is all just duplicated code, so we can deduplicate it with minimal
effort to clean up the api
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11251
we can just use efl.config here instead of duplicating it
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11248
this is needed by recognizers which use timers in order to do timeouts
on gestures
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11245
this is always a full iteration so we don't actually need a list
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11241
these objects need to be cleaned up immediately outside of event
processing to avoid having them automatically deleted later on and
triggering a double delete
Differential Revision: https://phab.enlightenment.org/D11240
this adds support for creating custom (out of tree) gesture recognizers by
adding an abstract recognizer class that can be inherited and reused
docs TBA
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11223
this exposes internal objects that we shouldn't be exposing
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11221
if we have not begun to process a zoom gesture by this point, then we should
not be emitting a cancel result
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11208
cancel is used to indicate that a gesture which has begun to trigger has been
canceled, so if we have already canceled then we should not re-cancel here
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11207
we only care about the last touch unpress event, so we should be ignoring
every other event instead of canceling, as we are also ignoring the
multi-touch press events
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11206
this is functionally wrong (the comparison fails) and also causes SIGBUS on
arm
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11198
this can be fetched using efl_provider_find from the recognizer
ref T8503
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11177
this is a manager functionality, and recognizers are always child objects of
managers
ref T8503
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11176
we still access this using private data in the in-tree recognizers, but
now it's also accessible normally to custom recognizers
ref T8503
Reviewed-by: woochan lee <wc0917.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D11175
Felipe Magno de Almeida
Vincent Torri
Mike Blumenkrantz
Daniel Kolesa
Woochanlee
Marcel Hollerbach