a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
This fixes some of the warnings generated by calling functions on NULL
objects. One of the main remaining points is to avoid unwanted warnings
on non-existing parts.
Ref T6326
This reverts commit 3a9d54085b.
I got crash and a lot of valgrind warning with this patch. All in all, I
think we can just wait for next release and do a proper cleanup of our API
to not rely on strings at all.
For references this is the first valgrind warning I get (Not going to past the 100 following one) :
==11860== Invalid write of size 4
==11860== at 0xB10DDD1: _ecore_event_evas_modifier_lock_update (ecore_input_evas.c:432)
==11860== by 0xB10E3DD: ecore_event_evas_mouse_move (ecore_input_evas.c:725)
==11860== by 0x5D5115D: _ecore_call_handler_cb (ecore_private.h:317)
==11860== by 0x5D5115D: _ecore_event_call (ecore_events.c:518)
==11860== by 0x5D5CC47: _ecore_main_loop_iterate_internal (ecore_main.c:2381)
==11860== by 0x5D5D42E: ecore_main_loop_begin (ecore_main.c:1289)
==11860== by 0x5D5D490: _efl_loop_begin (ecore_main.c:2831)
==11860== by 0x5D59555: efl_loop_begin (efl_loop.eo.c:32)
==11860== by 0x14F275: main (test.c:1188)
==11860== Address 0x19a36828 is 7 bytes after a block of size 1 alloc'd
==11860== at 0x4C2AACE: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11860== by 0x4C2CC81: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11860== by 0xB10DDA8: _ecore_event_evas_modifier_lock_update (ecore_input_evas.c:425)
==11860== by 0xB10E3DD: ecore_event_evas_mouse_move (ecore_input_evas.c:725)
==11860== by 0x5D5115D: _ecore_call_handler_cb (ecore_private.h:317)
==11860== by 0x5D5115D: _ecore_event_call (ecore_events.c:518)
==11860== by 0x5D5CC47: _ecore_main_loop_iterate_internal (ecore_main.c:2381)
==11860== by 0x5D5D42E: ecore_main_loop_begin (ecore_main.c:1289)
==11860== by 0x5D5D490: _efl_loop_begin (ecore_main.c:2831)
==11860== by 0x5D59555: efl_loop_begin (efl_loop.eo.c:32)
==11860== by 0x14F275: main (test.c:1188)
this only modifiers modifiers if the modifier mask changed. it stores
it per seat and matches up before deciding to actually modifier the
modifiers. this SHOULD fix T5252
@fix
This reverts commit f654714d75.
Modifiers do influence mouse events, though a mouse input can't change them...
This commit broke modifer+drag on windows in E, so I'm reverting it.
mouse events have nothing to do with modifiers or locks, so dont try
modify them on mouse events. a total waste of cpu and time.
this should also fix T5251
This function will set the modifiers/lock per seat in Evas.
Some places will still use ecore_event_evas_modifier_lock_update(),
since multi-seat is not supported.
This struct should contain the Evas device that originated the event,
otherwise events from different devices may mix up and lead to undifined
behaviour.
After my input event changes, the propagation path has been altered
from:
ecore_x -> evas_event
to:
ecore_x -> ecore_input_evas -> evas_event
But ecore_input_evas was ignoring cancel events by default. There
should be no good reason to disable cancel events anymore,
according to @jypark. Also, this fixes an actual bug :)
Fixes T4301
Yup, I broke everything again. This time, mouse move inputs
would not move the cursor, since I was bypassing the regular
_ecore_evas_mouse_xxx callbacks.
Fixes T3766
This is still VERY experimental and not fully done yet.
All other pointer events need to be sent as well.
The legacy event system is used as a transportation mechanism,
as it is too hard to change the logic. This only adds an extra
eo event in case of move. Obviously for performance we might
want to listen to callback_add,del but that's an optimization
for later.
The whole point of sending those pointer events is to carry more
information than can be sent over legacy evas events, and unify
the events in a common format.
Since the direct input event callback returns true if the
event has been processed, we can easily support legacy and
progressively implement full support for eo input events.
this was broken in 5cb6cdbc5e such that
when multiple sources produce mouse events using the same device,
these events are marshalled as though they were from the same canvas.
the result is that eventing is wrong on at least one of the canvases,
and spurious mouse-up events are triggered before every mouse down
fix T2509
Summary: This cleans up the _ecore_event_evas_mouse_button function.
Coverity was reporting that the state tests in the 'if' function could
not be be reached due to eel variable being null. This moves the if
(!eel) check to run before the state tests.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If ecore get the mouse cancel event(ex: display off, or window stack change) from below, we need to deal with.
Currently, evas also generates up event using evas_event_feed_mouse_cancel function when window hide is called.
if cancel event occurs, ecore also call evas_event_mouse_feed_cancel like window hide situation.
cancel event means all button or touch event should be canceled, but in the future, if we need to deal each cancel event according to touch point,
we need to add api like evas_event_feed_multi_cancel
@feature
Summary:
This patch set adds the necessary code to expose device axis state to applications. This was primarily written with graphics tablets in mind, which -- in addition to acting like a mouse -- also provide information about pen pressure, tilt, etc. Other devices could potentially benefit from this API as well: touchscreens, joysticks, knob controllers, "spaceballs", etc.
Whenever an update to the device state is recieved, an "Axis update" event is synthesized. This event contains the updated information, typically scaled and normalized to a particular logical range (e.g. zero to one for pressure, -pi to pi radians for angles, etc.). Information about the tool which generated the event is also stored so that applications can disambiguate events from multiple devices (or in the case of multitouch screens, individual fingers).
This API is only wired up for use with X11 at the moment. Support for other backends (e.g. Wayland) should be easy to add for those familiar them.
**Note**: The following is a list of changes from the "v2" patches originally sent to the mailinglist
//Define and implement new Ecore_Event_Axis_Update events//
* Harcode axis labels instead of including xserver-properties.h
* Use C89-style comments
* Use doxygen comments
* Update comment text to note axes with unbounded/undefined ranges/units
* Create "Ecore_Axis" and "Ecore_Axis_Label" typedefs
* Reference typedef'd instead of raw types
* Adjust how we count through valuators to support tilt/az
* Add support for tilt and azimuth
* Tweak memory management in case number of valuators differ
* Expand TWIST axis normalization to declared range
* Only normalize TWIST axis if resolution == 1 (wacom bug)
* Cache label atoms on first use to minimize round-trips
//Implement EVAS_CALLBACK_AXIS_UPDATE event and friends//
* Update to doxygen comments
* Update comment text to note axes with unbounded/undefined ranges/units
* Typedef 'Evas_Axis_Label', 'Evas_Axis'
* Move typedef for 'Evas_Event_Axis_Update'
* Reference typedef'd instead of raw types
//Wire the Ecore and Evas implementations of axis update events together//
* Expose ecore_event_evas_axis_update in Ecore_Input_Evas.h
* Move ecore_event_evas_axis_update to more logical position
//DEBUG: Add axis update logging to evas-multi-touch.c//
* Removed from patch set
//Make evas-multi-touch demo use new axis functionality//
* Have pressure adjust rectangle brightness instead of size
* Use more available axis data when rendering rectangle (azimuth, tilt, twist)
Test Plan: The evas-multi-touch demo was updated to support axis update events. A graphics tablet was then used to verify that the pressure, azimuth, tilt, and twist data was coming through correctly.
Reviewers: cedric, raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1514
Conflicts:
src/lib/ecore_input/Ecore_Input.h
Carsten Haitzler -
** fixed forward enum typedefs (make things unhappy)
** fixed conflict above
** fixed wrong param type for _evas_canvas_event_feed_axis_update()
** fixed @sinces to be 1.13
** fixed formatting/indeting
** fixed order of operation reliance in if's with ()'s to be clear
** fixed functions to be static that should have been
Summary:
This problem occurred due to xkb_keysym_t value of libxkbcommon by e wl server.
e wl server should pass keycode from evdev input device on to wl client.
In order that e wl server receives valid keycode Ecore_Event_Key should have
an extended data member. This patch should be applied with server side patch.
@fix
Test Plan: run e wl server -> create wl client -> type keys
Reviewers: raster, devilhorns, zmike
CC: cedric
Differential Revision: https://phab.enlightenment.org/D712
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
Ecore_Evas_Input should use this function to report mouse move events.
The previous used function should be used to refeed events, or to
artificially feed mouse move events to the canvas. Basically every other
feed_mouse_move use case that is not an event from the input system.