Summary:
There will be several methods to set orientation in edc, so we have decided to make one big vector,
the main reason is that we use quaternion by default, but look_at, for example, is given as 6 coordinates.
Reviewers: Hermet, cedric, raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1693
Summary:
Move check visibility of node from evas_3d_node to evas_3d_camera
Move functionality (normalize, check distance, calculate frustum)
in evas_3d_utils.h (we are planing use evas_is_sphere_in_frustum in evas_gl_3d.c -
don't render mesh if it non visible)
Add possibility check frustum by box, aabb, central point
Refactor example frustum culling
@feature
Reviewers: Hermet, raster, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1420
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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:
.ply format is important for relation blender and EFl, because in blender exist only two mesh export API: bpy.ops.import_mesh.ply and bpy.ops.import_mesh.stl. One of them is necessary for .edc 3D generator. Which I writing now.
Sorry, it isn't like image loader. Refactoring of import/export will be soon.
Reviewers: Oleksander, artem.popov, Hermet, raster, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1544
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: The first version of .eet format is added. All changes due to discussion in D1307 are done.
Reviewers: artem.popov, se.osadchy, reutskiy.v.v, Hermet, raster, cedric, Oleksander
@feature
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1477
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: The first version of .eet format is added.
Reviewers: Hermet, raster, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1307
Summary:
The event descriptions of Evas_Object were hardcoded instead
of declared in evas_object.eo and thus no binding could be aware of
their existence.
Note: Evas_Canvas events were left as is.
Reviewers: cedric, tasn, q66, JackDanielZ
Reviewed By: q66
CC: felipealmeida, raster, smohanty, cedric
Differential Revision: https://phab.enlightenment.org/D1065
I am concerned that we do duplicate the color format of a texture insteed
of reusing the colorspace enum from Evas (that already exist). I believe
this is a side effect of not using Evas_GL_Image for texture.
This let me think that I wont allow this API out of BETA until we reduce
duplication by using Evas_GL_Image as it seems it will also impact the
public API of Evas_3D.
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
const have been added in object parameter of two legacy APIs to fit
Eolian generated files.
Since these functions retrieve information from object, it is logic that
the object would be const.
The first object that we generate with Eolian is Evas_Line, as it is a
simple one.
Two files are generated during build:
- the .eo.c contains the APIs definitions invoking Eo, the Eo functions
extracting the parameters and calling the hand written functions and
Eo structures to define the objects. These hand written functions are
located in e.g evas_object_line.c.
- the .eo.h contains the APIs and Eo prototyes.
We will continue with the other objects. If you note something wrong,
please update us asap:
daniel.zaoui@samsung.comyossi.kantor@samsung.com
perepelits.m
Bogdan Devichev
Dmytro Dadyka
Oleksandr Shcherbina
Jason Gerecke
ChunEon Park
Cedric BAIL
Tom Hacohen
Daniel Kolesa
Savio Sena
Cedric Bail
subhransu
Gwanglim Lee
Yossi Kantor
Daniel Zaoui