at first i tried to implement that with composition, however, this does
not work, caused by the fact that the edje_object does not implement
efl.gfx.image nor load controller. which would mean i would have to
differentiate based on the type what kind of composition i would attach,
additionally, i would have to write an additional object which would
implement the correct behaviour.
To shortcut this overdone approach, this commit simply implements the
APIs in the image object.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D10068
the API calls have not been implemented, this revision implements these
APIs as redirects to the image if those are a edje object.
Normally this should be a calling the legacy edje API. However, this is
here really hard as imitating the correct callback behaviour is hard.
And the correct behaviour with the eina value type is also just leading
to copying the implementation from edje. So in order to keep the amount
of code low here, this just uses the efl-api to redirect the requests.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9989
Eolian @properties should be documented at the property level, and
documentation at the setter or getter level should be left to setter-
or getter-specific comments. There is usually no need at all to have
setter- or getter- specific comments.
Also, a property is not a method so descriptions should match that.
This patch removes lots of duplicated text, and will allow enabling
by default the eolian check that ensures that properties have proper
property-level docs.
No functional changes.
this should probably be removed altogether but until dnd exists ensure
that this doesn't accidentally get released
ref T7873
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9705
this removes the property from the image class to use the properties
from the interface
ref T7873
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9704
this is effectively the same thing. no uses of this functionality exist anywhere
ref T7873
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9688
Summary:
Efl.Gfx.Image_Orientable and Efl.Ui.Layout_Orientable have same property name.
So when class extends both interfaces, it makes conflict.
Relates to T7924
Reviewers: woohyun, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9299
Summary:
This will help disambiguate later on when we rename Efl.Ui.Direction
to Efl.Ui.Layout_Orientation.
Relates to T7919
Test Plan: Everything still builds and passes tests.
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8934
Summary:
And the Efl.Orientation interface -> Efl.Gfx.Orientable
(with proper c_prefix so it is not too cumbersome to use from C).
Also, turned the theme_rotation_apply() parameter into an int to avoid confusion.
Fixes T7919
Depends on D8912
Test Plan: Everything continues to build and pass tests
Reviewers: zmike, bu5hm4n, cedric, Hermet, Jaehyun_Cho
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7919
Differential Revision: https://phab.enlightenment.org/D8926
Summary:
This is similar to how it is in Evas, and simplifies the Efl.Orientation
interface, which only needs one property now.
Relates to T7919
Test Plan: Everything builds and tests pass. There's only one example of efl_orientation_set() so there's not much to test yet.
Reviewers: zmike, bu5hm4n, cedric, Hermet, Jaehyun_Cho
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7919
Differential Revision: https://phab.enlightenment.org/D8912
Summary:
All legacy @since tags have already moved to the *.legacy.h files.
EO files are now devoid of @since tags (except some eldbus still
needed for legacy).
Upcoming patches will add @since 1.22 to those APIs which come out
of beta in this release.
APIs marked @beta do not need @since tags.
Test Plan: Everything builds, EO docs (like DocFX) have no Since tags.
Reviewers: zmike, bu5hm4n, lauromoura, cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8430
Summary:
these are all types that we do not currently want to release
Depends on D8102
Reviewers: segfaultxavi
Reviewed By: segfaultxavi
Subscribers: segfaultxavi, cedric
Tags: #efl_api
Differential Revision: https://phab.enlightenment.org/D8241
Summary:
the previous implementation/api had a number of issues:
* "file" property contained both "file" and "key" values
- also performed file loading operation
* "load_error" property which was specific to image objects
* no methods for controlling file loading/unloading
this patch attempts the following changes:
* split "file" property into "file" and "key" properties
- also remove "key" from existing "mmap" property
* remove "load_error"
* directly return error codes from operations
* add "load" and "unload" methods for directly controlling load state
* add implicit file loading if file/mmap is set during construction
* rewrite all efl.file implementations to move file loading into load() method
* rewrite all usage of efl.file api based on these changes
* add C extension functions to mimic previous behavior
ref T7577
Reviewers: segfaultxavi, bu5hm4n, cedric
Reviewed By: segfaultxavi
Subscribers: vitor.sousa, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7577
Differential Revision: https://phab.enlightenment.org/D8018
Summary:
Instead of surrounding all the #include "*.eo.h" lines in Efl.h
with #ifdef EFL_BETA_API_SUPPORT, include these files unconditionally, but mark
all classes as @beta in the eo files.
This will allow taking them out of beta one by one as we deem them stable enough.
Otherwise, the current procedure involves moving the #include line out of the
ifdef block, which is cumbersome and messes include order.
Depends on D7950
Fixes T7692
Test Plan: Nothing changes
Reviewers: zmike, bu5hm4n, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7692
Differential Revision: https://phab.enlightenment.org/D7951
As we discussed in T7469 with V40,
efl_ui_model_connect
efl_ui_factory_model_connect
need to be renamed to
efl_ui_bind_property
efl_ui_bind_factory
for this work,
Efl.Ui.Model.Connect interface is changed as Efl.Ui.Bind,
and bind_property and bind_factory both method is supported by this interface.
bind_factory need Efl.Ui.Factory,
and Efl.Ui.Factory inheritted Efl.Ui.Bind,
so I little bit concerned about circular referencing, but so far, it works well.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7529
this returns the current file, though the result is that the "current file"
could be changed asynchronously after this function is called
ref T5719
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D7781
this is just proxying the method calls onto the inner edje object if
the image is an edje object
ref T5719
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D7741
Summary:
this just takes the API and redirects it to the internal edje object if
there is any. If there is no edje object, then just default values are
returned.
ref T5719
Depends on D7738
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T5719
Differential Revision: https://phab.enlightenment.org/D7739
Summary:
All events must have a type now, otherwise bindings don't know how to handle
the event_info field.
Most of the missing event types were actually "void" (no event_info present).
Some struct definitions had to be moved to eo instead of h files, so they
are available to bindings. Some have not, and are marked with FIXME.
Some namespaces have been fixed (like Efl_Event_Cb -> Efl.Event_Cb).
In general, there are hundreds of changed files, but mostly to add a type which
was not present before, so there's no harm done.
Also, A lot of FIXMEs have been added which should be, like, fixed.
For example, some events can send different types of event_info, which is
very inconvenient (and error prone).
Test Plan: make with c# bindings works, make check and make examples work too.
Reviewers: cedric, q66, lauromoura
Subscribers: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6169
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
No need to split: those two are used in all the same classes, since the
split between Orientation and Ui.Dir.
Note that the enum types remain in the main namespace.
Summary:
- Previous class efl_ui_bg moved to efl_ui_bg_widget.
- Scale_type moved to efl_image from efl_ui_image.
- Previous enum Efl_Ui_Image_Scale_Type moved to Efl_Image_Scale_Type.
Test Plan:
Run elementary_test
1.Image Scale Type
2.Efl.Ui.Bg
3.Efl.Ui.Win
4.Part Background
Reviewers: jpeg, woohyun, cedric
Differential Revision: https://phab.enlightenment.org/D5616
Summary:
Tile is common type which can be used eg: background.
This is added to scale type which can be set/get by
efl_ui_image_scale_type_set/get()
@feature
Test Plan:
Run elementary test
Run Image Scale Type
Check radio "Tile".
Reviewers: jpeg, cedric, woohyun
Differential Revision: https://phab.enlightenment.org/D5119
This merges them with the now standard interface:
Efl.Canvas.Layout_Signal
Some wrapping work was required for legacy API which
takes no user_data in del() but instead returns it. The
new EO function, while harder to use, is more correct
(you can't delete the invalid callback by accident, and
this follows EO events design).
Another crazy wrapping was done in entry/text in order
to add the callbacks to 2 objects instead of just one,
and still return the user data.
As for Naviframe and Popup, those two widgets override
signal_emit to forward the call to another object than
the resize object, but not callback_add/del. So they
are definitely broken.
Ref T5315
Those APIs can then be used by Elm.Layout, hopefully
simplifying the API.
I wonder if the APIs should be prefixed "calc_" (as is)
or "layout_calc_". The extra "layout_" prefix would make
it common with other layout APIs (eg. signals, data,
size min/max, ...).
Ref T5315
This changes a few method names:
- freeze -> calc_freeze
- thaw -> calc_thaw
- update_hints -> calc_update_hints
Otherwise this is mostly about reshuffling the EO file itself
and changing documentation.
Ref T5315
Marcel Hollerbach
Xavi Artigas
Mike Blumenkrantz
WooHyun Jung
Cedric BAIL
Hosang Kim
SangHyeon Jade Lee
Woochanlee
Mike Blumenkrantz
Sungtaek Hong
Jean-Philippe Andre
Amitesh Singh
Andy Williams
Lukasz Stanislawski
Lukasz Stanislawski