It is my understanding that some items view are created with efl_add directly
and manipulate VIEW directly with Eo new API. This clash with the inconsistent
behavior that evas_object_del expect. To work around this, we track object life
by explictely relying on efl_wref_add while holding the pointer to the object.
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
Summary:
For now, how to check whether a widget is legacy or not
is to check flags in private data or static flag, which is set
during elm_legacy_add.
If Efl.Ui.Legacy interface is added, it can be easilly checked
by efl_isa(obj, EFL_UI_LEGACY_INTERFACE)
Reviewers: woohyun, jpeg, cedric, Jaehyun_Cho
Subscribers: conr2d, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5748
Summary:
focus_user and focus_object are similar classes. by merging them into
one mixin, we can maintain consistency.
Test Plan: make check
Reviewers: bu5hm4n
Subscribers: cedric, Jaehyun_Cho, woohyun, jpeg
Differential Revision: https://phab.enlightenment.org/D5734
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 makes it possible to very easily create drop shadows and glow
effects on any widget. This is absolutely not optimized, though the main
performance bottleneck is that the proxy images get redrawn after just
moving.
@feature
theme_klass: set/get klass name used for resize_obj
theme_element: set/get group name used for resize_obj
theme_style: set/get style name used for resize_obj
element_update: automatically sets and apply theme for
sub object of widget.
See previous commit :)
Note: right now the background part has a small 3d indent which comes
from the legacy theme being used. This will be fixed soon.
Because of the way elm_code test case is written, by directly including
the C file, we end up with two symbols for the internal _elm_legacy_add
flag. This makes some test case fail (after applying a pending patch).
Solution found by Sungtaek Hong.
elm_code test case needs to be fixed. Don't include the C files
directly, testing static inlines should be done through a common .x or
something, but not by including the C file itself. This has led and will
lead to many issues.
elm_code_widget is causing a lot of trouble as it's relying on internal
access to elementary, without being built as part of elementary.so. Many
EAPI symbols are exported that shouldn't need to be, as they are only
internals of elm.
This will be used to solve issues around style_set:
if the widget is legacy or pure eo we may need to select a different
style. So in the constructor we need to know whether we are legacy or
eo. Note that calling style_set in finalize only is too late as we would
lose information such as efl_text_set() called inside efl_add().
thats just a little helper, where the logic to find and fetch the
provider is bound to the position in the widget tree, this means that
for example gengrid could change the way the logical parent is
evalulated. (For example to map the logical parent to a item)
This moves the API entry points from Widget to Layout parts. I don't
think the other widgets support translation, but that is easy to fix.
The actual code implementation remains in elm_widget.c.
Legacy-only widgets are covered by Part_Legacy, while all EO widgets
that have text inherit from Layout (except Win but I don't think the
window title was translatable in legacy).
This removes 2/3 remaining part APIs from Widget.
Ref T5363
This will be used to replace the part translation API in Elm.Widget. It
should work for both parts and non-parts (ie. the main text of a button,
for instance).
For now I'm taking the following approach:
- All efl_text_set/get strings are untranslatable, i.e. get() returns
the visible string, set replaces and can not be translated.
- translatable_text_set/get needs to be used to enable automatic
translation, which in turns calls efl_text_set to modify the visible
string. Thus, translatable applications will have to use
efl_ui_translatable_text_set a lot more than efl_text_set, unless
they translate strings application-side.
Note that some other frameworks take a simpler approach equivalent to
calling efl_text_set() with an already translated text. This prevents
runtime language changes of the application, unless the application
handles them specifically.
It's a complex struct but defined in EO as a simple struct. ABI-wise
it's equivalent to Eina_Rectangle. Some macros that use Eina_Rectangle
also work on Eina_Rect out of the box, most of the code dealing with
x,y,w,h will require no modifications either.
But Eina_Rect provides direct access to a size or position 2d component,
as well as the usual x,y,w,h. The field "rect" is provided as a
convenience for code dealing with both Eina_Rectangle and Eina_Rect. We
may or may not require it.
Note: Size2D could use unsigned values but I have spotted a few places
in the code that actually use -1 to indicate invalid size (as opposed to
0x0).
@feature
We had here a little problem, state focus_state_eval function handled
the unregisteration and consideration of the focus flags and then only
called a helper function (which was a widget function), that then did
the registeration in logical or regular mode.
Elm scroller for example took that function overwrote it and did onyl
permit logical registrations. Then again a evaluation of the focus state
and flags took place, and the function considered elm_scroller should be
registered as regular object, but found it to be logical. This lead to
the problem that we permantently unregistered Elm.Scroller and
registered it again as logical just to unregister it again. This was on
the one side a performance downside. But also a bug since all items from
within the Elm_Scrollers sub manager are getting reparent onto the
parent, which means not the root of the scroller (the scroller itself)
is the logical entrypoint to the widget but rather this reparented
widget, which led to unexpected focus warps like described in T5923.
tldr: this fixes T5923
See the previous commits. All focus_highlight APIs are defined in the
Widget class but only implemented at the Window level. For consistency I
believe this call should also be forwarded to the window. The previous
logic had absolutely no effect at all, except storing a stringshare.
The day focus_highlight becomes widget-specific (i.e. each widget has
its own highlight style) then this can be changed.
Note: This will apply to legacy API as well.
Ref T5363
This removes the special code in the legacy API for
elm_widget_focus_mouse_up_handle. Add an internal helper to find the
first widget parent. And mark as protected.
Apparently this functions is still required for the new focus manager.
Ref T5363
It's not beta. It's about to die.
Also, move #define ELM_WIDGET_BETA to the common header file, as it is
consequently required by ALL widgets. :(
Ping @bu5hm4n :)
Ref T5363
I was told that the scrollable interface is being redesigned for EO.
This API definitely does not belong to the base Widget class, as it's
quite specific to item-based scrollable widgets, such as lists and
grids. Since Elm.Interface_Scrollable is itself being revamped, it is a
good place to move that EO API for now.
Ref T5363
1. Uniformize the API, which is now for internal use:
This uses the same enum as scroller "movement_block" instead
of 2 separate properties. Less APIs, more consistence.
2. Remove scroll_lock x/y from EO widget. I was told it is not going to
exist in the upcoming scrollable interface.
3. Remove scroll hold/freeze getters.
scroll hold/freeze push/pop are still there but it remains to be seen
how the EO scrollable interface will exploit them. Right now they are
full of bugs.
Ref T5363
This also includes the drag_child_lock APIs. This had nothing to do with
dragging beyond maybe the case where scrolling is done by thumbscroll
(ie. finger drag).
Note that the EAPI were called already scroll_lock, not drag_lock.
Ref T5363
This function is meant to be used by the widgets themselves, or internal
features such as elm_access.
Also remove const tag: this function call is definitely modifying the
widget (panning around and all that).
Ref T5363
Renamed to on_orientation_update
This internal / virtual function is in fact not overridden anywhere. Not
sure it is necessary to expose it in EO API?
Ref T5363
Also prefix with widget.
I want to rename this as child rather than sub. It's inconsistent with
the other parent/child hierarchies. Anyway the various hierarchies are
confusing, so let's keep this name :)
Ref T5363
Cedric BAIL
Marcel Hollerbach
Daniel Kolesa
Mike Blumenkrantz
Shinwoo Kim
Sungtaek Hong
Jean-Philippe Andre
Yeongjong Lee
Amitesh Singh
Marcel Hollerbach