This moves all part_drag APIs to legacy and implements them for
EO using efl_part(). All parts now support these APIs, even if
they are not draggable. Making this more fine grained would
probably be much extra work for little gain.
This creates a new interface Efl.Ui.Drag.
Summary: The User requires this signal to handle spinner widget easily on their app.
Test Plan: Spinner test on elementary_test.
Reviewers: cedric, jpeg, Hermet, woohyun, Jaehyun, myoungwoon, Jaehyun_Cho
Reviewed By: myoungwoon, Jaehyun_Cho
Subscribers: myoungwoon, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4886
Summary:
Elm.Widget.event_callback_add conflicts with Efl.Object.event_callback_add.
To solve this problem, "widget_" prefix is added to methods starting with
"event".
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4521
This reverts commit 082ea96673.
As per mail from Andrii, and he's right:
From: Andrii Kroitor <an.kroitor@samsung.com>
To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net>
Subject: [E-devel] elementary callbacks hell
Date: Fri, 23 Dec 2016 18:03:58 +0200
Recently existing callbacks behavior was broken once again. This time by
https://git.enlightenment.org/core/efl.git/commit/?id=082ea9667343b7016d86143a625881a8c4aa30a4
Before that commit "changed" callback was triggered only on user
changes, after - on user changes and changes from code.
I understand that in some cases this flow is needed. But previously you
could simply trigger your callback after setting value to spinner from
code to get desired missing behavior.
On the other side - now you can't distinguish value changes made by code
from value changes made by user without dirty and painful to support
hacks. If you don't want your callback to be
triggered by elm_spinner_value_set you need to add some flag meaning
"change from code", raise it before every call of value_set, check it
inside callback, remove it after the call.
And if you want to call it from spinner "changed" callback..? Good luck
here. This is possible, but requires additional wrappers around
spinner_add and spinner_value_set and replacement with custom signals.
So this change added bigger problems than solved.
Summary:
If user set spinner value other than it's
current value, this is change in value. So changed
callback must be called on value set.
@fix
Signed-off-by: Umesh Tanwar <umesh.tanwar@samsung.com>
Reviewers: raster, singh.amitesh, cedric, jpeg
Subscribers: atulfokk, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4471
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
The spinner entry will be activated when user gives a focus to text button in new focused ui concept.
To support this, we have to change internal logic about change text button to entry, entry to text button.
@fix
Test Plan:
elementary_test
spinner sample.
Reviewers: woohyun, Hermet
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4475
When unfocusing spinner, entry's UNFOCUSED callback is called.
In the callback function, entry is hidden and spinner gets focus
from focus_revert logic.
This gave lots of meaningless focused/unfocused state changes.
@fix
Summary:
The accessible name is char*, this could confuse API user.
If we provide user callback to get description, an user would return allocated string.
The usage of elm_interface_atspi_description_get/set should be same with elm_interface_atspi_name_get/set
Reviewers: lukasz.stanislawski, cedric, raster
Reviewed By: raster
Subscribers: stanluk, jpeg
Differential Revision: https://phab.enlightenment.org/D4378
Left/Right(or Up/Down with vertical one) changed the value of
spinner previously. However, it gave uneasy because focus could not be
moved to another winset until the value met the min or max.
Now, inc/dec button can get focus, and enter input on them change
the value.
Additionally, central text button changes to the entry automatically
when it gets focus. i.e. toggle on the text button is removed.
@fix
Efl.Object.event_callback_call no longer calls legacy smart callbacks;
calling only event callbacks registered with the given event description
pointer.
Create the method Efl.Object.event_callback_legacy_call to inherit the old
behavior from Efl.Object.event_callback_call, calling both Efl.Object events
and legacy smart callbacks.
Update all other files accordingly in order to still supply legacy
callbacks while they are necessary.
This removes:
Efl.Event interface
And renames:
Efl.Event.Input -> Efl.Input.Event
Efl.Event -> Efl.Input.Event (merged)
Efl.Event.Pointer -> Efl.Input.Pointer
Efl.Event.Key -> Efl.Input.Key
Efl.Event.Hold -> Efl.Input.Hold
This also moves some interfaces from efl/ to evas/ where they
belong better.
This allows renaming Eo_Event to Efl_Event.
Summary:
When user edit spinner value on entry.
The user want to back on entry to edit spinner value even swiching view(focus out and focus in).
I considered a couple of exception case ( case that entry should not reactivate.)
1. User click spinner button to give focus.
2. User give focus to spinner's object using key action.
Test Plan:
Add sample in elementary_test.
Edit spinner value.
Gives focus to other window.
Back to spinner view.
See the action.
Reviewers: Hermet, woohyun, cedric, jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4120
Summary:
if trying to apply incorrect theme, widget apply default theme and return TRUE.
so there is no way to check it really apply correct theme.
To resolve this problem, _elm_theme_set return three type enum
* related history : 4ca3ef4514
* elm_object_style_set is public api, so I didn't change it.
* typedef name [ Theme_Apply ] is temporarily, please suggest better one.
@fix
Reviewers: singh.amitesh, herb, Hermet, cedric, jpeg, raster
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4073