This make EFL_MAIN available and working with just Ecore. For simplicity
it is available with Efl_Core.h. Ideally it should also work with Efl_Net.h
alone and finally with an Efl_Ui.h.
T6262
indicator_format_set/get & indicator_format_function_set are
now legacy APIs.
indicator format can be set by using generic Ui.Format function
e.g.
efl_ui_format_string_set(efl_part(sliderObj, "indicator"), "1.0%f");
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
Summary:
This calendar widget will support basic functionality of calendar.
I've separated this widget from elm_calendar since elm_calendar had
lots of unuseful things inside.
Reviewers: jpeg, singh.amitesh, cedric, CHAN, Jaehyun_Cho
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5346
Summary: @ref T5358
Reviewers: woohyun, jpeg, cedric, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Subscribers: Jaehyun, bu5hm4n, cedric, jpeg
Maniphest Tasks: T5358
Differential Revision: https://phab.enlightenment.org/D5169
JP's note:
MBE currently has quite a few issues, probably related to focus
handling. This needs to be fixed.
This creates efl_ui.eot
It's not called efl_ui_types.eot because a file with that name already
exists in efl/interfaces (for Efl.Ui.Drag functions).
Also add some FIXME comments, and move some types to elm_widget_item.eo.
Ref T5329
#finally
For now we focus the widgets of a item, the item content can be cycled
by tab / Ctrl + tab. up/down/right/left are for now handled by gengrid
and move the focused item (everything else feels super weird with
multiple contents in a item)
ref T6181
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)
Efl.Animation.Group.Sequential is a class for animations started in
sequence.
Efl.Animation.Object.Group.Sequential is a class which provides
methods for an object of Efl.Animation.Group.Sequential.
The objects added into the sequential group animation object start
in sequence.
Efl.Animation.Group.Parallel is a class for animations started in
parallel.
Efl.Animation.Object.Group.Parallel is a class which provides methods
for an object of Efl.Animation.Group.Parallel.
The objects added into the parallel group animation object start in
parallel.
the focus rectangle is basically just a normal efl.canvas.rectangle, but
with the focus interface implemented.
This fixes alot of errors which gets called when the root_focus manager
is used, with the submanager as mixin.
Summary:
elm_bg was supposed to be used only in legacy,
but since we need a common object to be used as a background of widgets,
it is now renamed as efl_ui_bg and supports EO APIs.
Reviewers: cedric, jpeg, woohyun
Differential Revision: https://phab.enlightenment.org/D5147
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.
Reasons:
- This API has been confused with the min size of the widget, resulting
in badly laid out applications.
- The EO API was not very nice (Range is about numbers, the Gfx size
hint in a part is really ugly).
While I understand the value of this API and how it can be used in
scalable applications, it is in fact not absolutely necessary.
Alternatively to that span size, the widget min size can already be
defined from the application side, or the widget can simply be expanded
to fill in its parent.
This can obviously be reinstated later if the need arises for EO. For
now, keep this feature as legacy-only.
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.
This means that ALL part handles inherit from the base part class
Efl.Ui.Widget.Part. Layout is the only exception where Efl.Part is
specially overridden.
This is a first step towards generic part APIs, including background in
all widgets.
Adds "Efl.Ui.Text_Async" object.
This new widget uses the "async_layout" functionality of the underlying
Efl.Canvas.Text object.
Currently, if "editable" mode is enabled, there is no asynchronous
layout, as interactive operations (e.g. typing) should get processed
immediately. Thus, only "non-editable" instructs the text object to do
asynchronous layout.
@feature
In Edje and Elementary, we have part objects, which are what is returned
by the interface efl_part(). Those objects can't be of an opaque type as
this doesn't work nicely with strongly typed languages such as C++ or
C#. In JS, Lua, C the types are weak and mostly runtime-based so it
doesn't matter much.
As a consequence, the documentation and the types need to look nice in
this EO API. Thus, we remove the abusive term "internal" and explicitly
call all those classes "part" something.
Eventually we want the types to be declared in the EO file so bindings
(C#, C++, ...) can generate the proper access methods, returning the
best possible types.
Note that right now a few of those part types are used in the legacy API
but don't actually need to be exposed externally.
This is kind of a mega commit that does all the renaming at once, but
it's really just a big sed operation. The power of good IDEs :)
Ref T5315
Ref T5306
This reverts commit 9836116cab.
This is based on discussion today i had.
There would be a separate minimal spinner class instead
which facilates ways to extend it.
Cedric Bail
Carsten Haitzler
Amitesh Singh
WooHyun Jung
Jean-Philippe Andre
Woochan Lee
smohanty
Lukasz Stanislawski
Marcel Hollerbach
Jaehyun Cho
Marcel Hollerbach
Sungtaek Hong
Lukasz Stanislawski
Daniel Hirt