2021-04-12 05:56:50 -07:00
|
|
|
#include <e.h>
|
|
|
|
|
2021-04-12 04:47:27 -07:00
|
|
|
#ifdef HAVE_ELPUT
|
|
|
|
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
#include <Eina.h>
|
|
|
|
#include <grp.h>
|
|
|
|
#include <sys/types.h>
|
|
|
|
#include <pwd.h>
|
2021-03-24 08:04:48 -07:00
|
|
|
#include <Elput.h>
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
|
|
|
|
static Eina_Hash *active_gestures;
|
2021-03-24 08:04:48 -07:00
|
|
|
static Elput_Manager *manager;
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
Eina_Vector2 pos;
|
|
|
|
unsigned int fingers;
|
|
|
|
struct {
|
|
|
|
Evas_Object *visuals, *win;
|
|
|
|
} visuals;
|
|
|
|
} Swipe_Stats;
|
|
|
|
|
2021-04-05 11:32:22 -07:00
|
|
|
static int gesture_capable_devices = 0;
|
|
|
|
static E_Bindings_Swipe_Live_Update live_update;
|
|
|
|
static void* live_update_data;
|
|
|
|
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
static Swipe_Stats*
|
2021-03-24 08:04:48 -07:00
|
|
|
_find_swipe_gesture_recognizition(Elput_Device *dev)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
|
|
|
Swipe_Stats *stats = eina_hash_find(active_gestures, dev);
|
|
|
|
|
|
|
|
return stats;
|
|
|
|
}
|
|
|
|
|
|
|
|
static Swipe_Stats*
|
2021-03-24 08:04:48 -07:00
|
|
|
_start_swipe_gesture_recognizition(Elput_Device *dev)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
|
|
|
Swipe_Stats *stats = _find_swipe_gesture_recognizition(dev);
|
|
|
|
|
|
|
|
if (stats)
|
|
|
|
eina_hash_del_by_key(active_gestures, dev);
|
|
|
|
|
|
|
|
stats = calloc(1, sizeof(Swipe_Stats));
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(stats, NULL);
|
|
|
|
|
|
|
|
if (e_bindings_swipe_available())
|
|
|
|
{
|
2020-07-28 01:02:58 -07:00
|
|
|
E_Zone *zone = e_zone_current_get();
|
|
|
|
|
|
|
|
stats->visuals.win = elm_notify_add(zone->base);
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
elm_notify_align_set(stats->visuals.win, 0.5, 0.5);
|
|
|
|
elm_object_tree_focus_allow_set(stats->visuals.win, EINA_FALSE);
|
|
|
|
evas_object_layer_set(stats->visuals.win, E_LAYER_CLIENT_PRIO);
|
|
|
|
evas_object_show(stats->visuals.win);
|
|
|
|
|
|
|
|
stats->visuals.visuals = elm_progressbar_add(stats->visuals.win);
|
|
|
|
elm_object_text_set(stats->visuals.visuals, "Progress of visuals");
|
|
|
|
evas_object_size_hint_min_set(stats->visuals.visuals, 300, 50);
|
|
|
|
evas_object_show(stats->visuals.visuals);
|
|
|
|
elm_object_content_set(stats->visuals.win, stats->visuals.visuals);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
eina_hash_add(active_gestures, dev, stats);
|
|
|
|
|
|
|
|
return stats;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2021-03-24 08:04:48 -07:00
|
|
|
_end_swipe_gesture_recognizition(Elput_Device *dev)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
|
|
|
eina_hash_del_by_key(active_gestures, dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
static double
|
|
|
|
_config_angle(Eina_Vector2 pos)
|
|
|
|
{
|
|
|
|
double res = atan(pos.y/pos.x);
|
|
|
|
|
|
|
|
if (res < 0) res += M_PI;
|
|
|
|
if (pos.y < 0) res += M_PI;
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2021-03-24 08:04:48 -07:00
|
|
|
static void
|
|
|
|
_stats_free(void *ptr)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
2021-03-24 08:04:48 -07:00
|
|
|
Swipe_Stats *stats = ptr;
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
|
2021-03-24 08:04:48 -07:00
|
|
|
evas_object_del(stats->visuals.win);
|
|
|
|
free(stats);
|
|
|
|
}
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
|
2021-03-24 08:04:48 -07:00
|
|
|
static void
|
|
|
|
_apply_visual_changes(Swipe_Stats *stats)
|
|
|
|
{
|
|
|
|
if (live_update)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
2021-04-05 11:32:22 -07:00
|
|
|
live_update(live_update_data, EINA_FALSE, _config_angle(stats->pos), eina_vector2_length_get(&stats->pos), 0.8, stats->fingers);
|
2021-03-24 08:04:48 -07:00
|
|
|
}
|
|
|
|
else if (stats->visuals.win)
|
|
|
|
{
|
|
|
|
Eina_Inarray *res = e_bindings_swipe_find_candidates(E_BINDING_CONTEXT_NONE, _config_angle (stats->pos), eina_vector2_length_get(&stats->pos), stats->fingers);
|
|
|
|
E_Binding_Swipe_Candidate *itr;
|
|
|
|
double total = 0.0f;
|
|
|
|
unsigned int len = 0;
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
|
2021-03-24 08:04:48 -07:00
|
|
|
EINA_INARRAY_FOREACH(res, itr)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
2021-03-24 08:04:48 -07:00
|
|
|
total += itr->acceptance;
|
|
|
|
len ++;
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
}
|
2021-03-24 08:04:48 -07:00
|
|
|
|
|
|
|
if (len > 0)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
2021-03-24 08:04:48 -07:00
|
|
|
char text_buffer[1000];
|
|
|
|
|
|
|
|
snprintf(text_buffer, sizeof(text_buffer), "%d gestures possible", len);
|
|
|
|
elm_progressbar_value_set(stats->visuals.visuals, total/len);
|
|
|
|
elm_object_text_set(stats->visuals.visuals, text_buffer);
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
}
|
2021-03-24 08:04:48 -07:00
|
|
|
else
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
2021-03-24 08:04:48 -07:00
|
|
|
elm_progressbar_value_set(stats->visuals.visuals, 0.0f);
|
|
|
|
elm_object_text_set(stats->visuals.visuals, "No gesture found");
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
}
|
2021-03-24 08:04:48 -07:00
|
|
|
|
|
|
|
eina_inarray_free(res);
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-03-24 08:04:48 -07:00
|
|
|
static Eina_Bool
|
|
|
|
_swipe_cb(void *data EINA_UNUSED, int type, void *event)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
2021-03-24 08:04:48 -07:00
|
|
|
Elput_Swipe_Gesture *gesture = event;
|
|
|
|
Elput_Device *dev = elput_swipe_device_get(gesture);
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
|
2021-03-24 08:04:48 -07:00
|
|
|
if (type == ELPUT_EVENT_SWIPE_BEGIN)
|
|
|
|
{
|
|
|
|
Swipe_Stats *stats = _start_swipe_gesture_recognizition(dev);
|
|
|
|
stats->fingers = elput_swipe_finger_count_get(gesture);
|
|
|
|
stats->pos.x = stats->pos.y = 0;
|
|
|
|
}
|
|
|
|
else if (type == ELPUT_EVENT_SWIPE_UPDATE)
|
|
|
|
{
|
|
|
|
Swipe_Stats *stats = _find_swipe_gesture_recognizition(dev);
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
|
2021-03-24 08:04:48 -07:00
|
|
|
stats->pos.x += elput_swipe_dx_get(gesture);
|
|
|
|
stats->pos.y += elput_swipe_dy_get(gesture);
|
|
|
|
|
|
|
|
_apply_visual_changes(stats);
|
|
|
|
}
|
|
|
|
else if (type == ELPUT_EVENT_SWIPE_END)
|
|
|
|
{
|
|
|
|
Swipe_Stats *stats = _find_swipe_gesture_recognizition(dev);
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
|
2021-03-24 08:04:48 -07:00
|
|
|
if (live_update)
|
2021-04-05 11:32:22 -07:00
|
|
|
live_update(live_update_data, EINA_TRUE, _config_angle(stats->pos), eina_vector2_length_get(&stats->pos), 0.8, stats->fingers);
|
2021-03-24 08:04:48 -07:00
|
|
|
else
|
|
|
|
e_bindings_swipe_handle(E_BINDING_CONTEXT_NONE, NULL, _config_angle(stats->pos), eina_vector2_length_get(&stats->pos), stats->fingers);
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
|
2021-03-24 08:04:48 -07:00
|
|
|
_end_swipe_gesture_recognizition(dev);
|
|
|
|
}
|
|
|
|
return ECORE_CALLBACK_PASS_ON;
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static Eina_Bool
|
2021-03-24 08:04:48 -07:00
|
|
|
_debug(void *data EINA_UNUSED, int type EINA_UNUSED, void *event EINA_UNUSED)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
2021-03-24 08:04:48 -07:00
|
|
|
Elput_Event_Seat_Caps *caps = event;
|
|
|
|
const Eina_List *node, *devices = elput_seat_devices_get(caps->seat);
|
|
|
|
Elput_Device *device;
|
|
|
|
int number_of_gesture_devices = 0;
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
|
2021-03-24 08:04:48 -07:00
|
|
|
EINA_LIST_FOREACH(devices, node, device)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
2021-03-24 08:04:48 -07:00
|
|
|
if (elput_device_caps_get(device) & ELPUT_DEVICE_CAPS_GESTURE)
|
|
|
|
{
|
|
|
|
number_of_gesture_devices++;
|
|
|
|
}
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
}
|
2021-04-05 11:32:22 -07:00
|
|
|
gesture_capable_devices= number_of_gesture_devices;
|
2021-03-24 08:04:48 -07:00
|
|
|
return ECORE_CALLBACK_PASS_ON;
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2021-04-05 11:32:22 -07:00
|
|
|
_init_for_x11(void)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
2021-03-24 08:04:48 -07:00
|
|
|
const char *device = NULL;
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
|
2021-04-05 11:32:22 -07:00
|
|
|
if (!elput_init())
|
|
|
|
{
|
|
|
|
ERR("Failed to init elput");
|
|
|
|
return;
|
|
|
|
}
|
2021-03-24 08:04:48 -07:00
|
|
|
device = getenv("XDG_SEAT");
|
|
|
|
if (!device) device = "seat0";
|
|
|
|
manager = elput_manager_connect_gestures(device, 0);
|
2021-04-05 11:32:22 -07:00
|
|
|
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN(manager);
|
2021-03-24 08:04:48 -07:00
|
|
|
elput_input_init(manager);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
_shutdown_for_x11(void)
|
|
|
|
{
|
|
|
|
elput_manager_disconnect(manager);
|
|
|
|
manager = NULL;
|
|
|
|
elput_shutdown();
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
}
|
|
|
|
|
2021-03-24 08:04:48 -07:00
|
|
|
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
E_API int
|
2021-04-05 11:32:22 -07:00
|
|
|
e_gesture_init(void)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
2021-03-24 08:04:48 -07:00
|
|
|
if (e_comp->comp_type == E_PIXMAP_TYPE_X)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
2021-04-05 11:32:22 -07:00
|
|
|
_init_for_x11();
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
}
|
2021-03-24 08:04:48 -07:00
|
|
|
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
active_gestures = eina_hash_pointer_new(_stats_free);
|
2021-03-24 08:04:48 -07:00
|
|
|
|
|
|
|
ecore_event_handler_add(ELPUT_EVENT_SWIPE_BEGIN, _swipe_cb, NULL);
|
|
|
|
ecore_event_handler_add(ELPUT_EVENT_SWIPE_UPDATE, _swipe_cb, NULL);
|
|
|
|
ecore_event_handler_add(ELPUT_EVENT_SWIPE_END, _swipe_cb, NULL);
|
|
|
|
ecore_event_handler_add(ELPUT_EVENT_SEAT_CAPS, _debug, NULL);
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
E_API int
|
2021-04-05 11:32:22 -07:00
|
|
|
e_gesture_shutdown(void)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
2021-03-24 08:04:48 -07:00
|
|
|
if (e_comp->comp_type == E_PIXMAP_TYPE_X)
|
|
|
|
{
|
|
|
|
_shutdown_for_x11();
|
|
|
|
}
|
|
|
|
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2021-04-05 11:32:22 -07:00
|
|
|
E_API void
|
|
|
|
e_bindings_swipe_live_update_hook_set(E_Bindings_Swipe_Live_Update update, void *data)
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
{
|
2021-04-05 11:32:22 -07:00
|
|
|
live_update = update;
|
|
|
|
live_update_data = data;
|
Introduce gesture recognition
This is currently using libinputs gesture recognition. And offers a
config screen to setup new gestures.
1. No default gesture bindings are setup
2. When libinput is not available the module is not going to be loaded,
and nothing is recognited.+
3. Only swipe gestures are recognized yet.
4. For now, you are required to be part of the input group, otherwise we cannot
get the libinput events. (See Todo 1)
5. The visual representation is not really good. In terms of UI, it is
visually showing a value coming from left to right, which is
indicating a direction, which is not always the direction of the
gesture, which is kind of bad. More improvements needed here.
Some things that still can be done:
1. The whole libinput things should be handled by elput, either with the
input group hack, or logind, or simply by root. The ideal idea would
be that e_sys is creating the elput context, which also listens for new
devices etc.. When all this is done, and it recognizes a new device, it
can simply sent a message from e_sys to e, that there is some new
device, with a opened fd. (However, this all needs to be locked up in a
way that e_sys cannot be abused)
2020-07-02 03:18:42 -07:00
|
|
|
}
|
|
|
|
|
2021-04-05 11:32:22 -07:00
|
|
|
E_API int
|
|
|
|
e_bindings_gesture_capable_devices_get(void)
|
|
|
|
{
|
|
|
|
return gesture_capable_devices;
|
|
|
|
}
|
2021-04-12 04:47:27 -07:00
|
|
|
|
|
|
|
#endif
|