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.
Summary:
_elm_legacy_add goes back to EINA_FALSE after setting sd->legacy.
if constructor get called again after going back to EINA_FALSE,
sd->legacy should remain EINA_TRUE.
also, elm_legacy_add() should not be called non-elm_widget.
Test Plan:
Run elementary test->Efl.Ui.Text.Label.
Check legacy flag in _elm_theme_object_set() for efl_ui_win.
Check legacy flag for efl_ui_text after scrollable text is added.
Reviewers: jpeg, woohyun
Reviewed By: jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5529
Summary:
Add attribute append and attributes clear API, attributes of widget/widget_item helps in adding additional information
about the widget/widget item in the form of key-value pair.
Test Plan:
Query the attributes using atspi_accessible_get_attributes in atspi_client and an hash table consisting
of updates attributes should be returned.
Signed-Off By: Shilpa Singh <shilpa.singh@samsung.com>
Signed-Off By: Lukasz Wlazly <l.wlazly@partner.samsung.com>
Reviewers: kimcinoo, lukasz.stanislawski
Subscribers: cedric, govi, rajeshps, jpeg
Differential Revision: https://phab.enlightenment.org/D5510
you think there is only one elm_parent behind the elementary property
parent? Oh no! Elm_Notify and Elm_Popup have theire own parent fields,
and those fields are not returned when calleing elm_widget_parent_get,
they are also not given to the elm_widget implementation of
elm_widget_top_get, so a call to elm_widget_top_get stalls at elm.notify
or elm.popup.
fix T6389
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().
This prevents legacy EO classes from being exposed through .eo.h headers
or .eo in share/eolian/includes. Also removes a slew of useless xxx_eo.h
intermediate headers.
Notes:
- elm_systray has no proper API: it's not clear if the EO API should be
released (in which case it needs to be renamed to efl_something) and
there is no legacy API to create a systray object.
- Some files have been placed in a "FIXME" section, as I believe they
are necessary within EO land, but at the same time still don't
conform to the interfaces (eg. name starts with elm_).
- elm_interface_scrollable is required by photocam. This means photocam
needs to be adapted to fit the EO scroller API (still to be
completed, I believe).
Bugs:
- This breaks most C++ examples. I KNOW. And I'm working on it.
Ref T5301
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)
Simply pass in the strbuf and don't expect the callee to own it. This
makes things simpler and safer (it'll crash only if the callee frees
said strbuf, and shouldn't leak). efl_ebug_name is new in the upcoming
release, EFL 1.21.
Realised this after talking with Amitesh. Thanks.
See 999dbd9764
And c4769ff898
This region has little to do with focus, as it's more of a region of
interest within the widget, and not directly related to the highlight
geometry, for instance. It's related to focus in the sense that only
widgets with focus would really care about this region.
I decided to change this name after talking with @bu5hm4n.
Note that gengrid uses this but is also completely broken (the focus
highlight floats around and you don't even see the focused item).
Note: This is very close to show_region but I'm not sure those can be
merged safely (since the default "focus_region" is NULL while the
default "show_region" is the widget's geometry).
Ref T5363
fix CID 1379920 - event_flags is actually never NULL or undefined in
the function logic. it's always set to point to the specific event
flags field depending on struct type or the function will return
before using the pointer.
This removes the last remaining legacy-style part API from Widget.
I think this is redundant with the property "translatable_text"
introduced in Efl.Ui.Translatable.
Ref T5363
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.
This is VERY tricky.
For legacy, just create an internal class that has both. It's easier
this way. For parts that are handled by Layout directly, we know from
Edje which type to return.
For EO objects we should know from the part name which kind of part we
are dealing with:
- text (overridden by the widget)
- content (overridden by the widget)
- special (new efl_part based functions)
- generic (handled by Layout)
Note: Efl.Ui.Slider was handling "span size" on ALL parts. That's bad...
This is now limited to "span" only.
Amitesh Singh
Jaehyun Cho
Jean-Philippe Andre
Sungtaek Hong
Shilpa Singh
Marcel Hollerbach
Pawel Aksiutowicz
Lukasz Stanislawski
Cedric Bail
Marcel Hollerbach
Carsten Haitzler