elm_colorselector is legacy only (for now, unfortunately).
This means that elm_colorselector_class_get() crashes with weak linking.
Strong linking would make the compilation fail.
Apparently this isn't well supported by dash, which will print an
error and return a 2, where zsh and bash will return 255.
Explicitly returning 255 seems least surprising.
see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772322
#IHaveNoIdeaWhatThisScriptDoes
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:
**@feature** T6241
This feature enables genlist to pin an item to viewport which will
be available always for user to view/select.
**Use Case**:
In a big list of music, most times when user finds a song which they
like, before playing that they may want to go through the entire list
to check whether there is some other good songs, but
after seeing the entire list user have to again scroll back to the
position of item which they liked to play it then.
In this case item pinning can be used, so that the item
which they want to keep for future selection can be pinned
and then it will remain in viewport, finally when user want to do
operation on item, it will be readily available in viewport.
Signed-off-by: Godly T.Alias <godlytalias@yahoo.co.in>
Test Plan: Elementary Test -> Genlist -> Double click on items to enable/disable pinning
Reviewers: raster, cedric, prince.dubey, SanghyeonLee
Subscribers: rajeshps, jpeg, shilpasingh
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D5340
If you have undefined color_class, edje will use solid white for its
colors. If you define color_class name without colors edje_cc now has
same defaults instead of 0 0 0 0.
@fix
there already was this flag but only set implicitly with anchor stuff.
allow to be able to set this flag explicitly to allow offsets to be
scaled if part is marked to scale
@feature
Summary:
When inherit_script is set to 1, script of current group contains
variables and funtions from script of parent groups. If there is same
name variable or function, newly defined one will replace that of
parents.
Reviewers: cedric, jpeg
Subscribers: taxi2se
Differential Revision: https://phab.enlightenment.org/D5062
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
This is the result of a really quick review of the new VG code. Most of
it was moved around, but this merge includes the following:
- Move logic from edje to evas
- Create static lib for common VG handling
- Add file_set() API
- Add a basic VG cache in evas side
- Add savers modules, implement loaders and savers.
Most of the time you need to retrieve the class from the string
anyway, so remove this relic of old Eolian and gain some small
performance benefits and extra convenience.
Subtly breaks API but everything should be updated.
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.
Some things have clearly not been tested. Some APIs have not been
modified after repeated review comments. C++ failed to build due to
"long" being used as a namespace.
Remaining issues:
- The original finger_list API was broken by design. I didn't try to
replace it yet.
- Long tap is also broken by design: if no move happens the recognizer
gets no event, and doesn't trigger anything when the timeout is
reached. An API or event is lacking here.
- Only 2 very basic gestures have been implemented. All the gestures
from elm_gesture_layer need to be covered. None of the multi touch
support has been really implemented, except for a single bool flag.
- The configuration must be loaded from elm_config, passed on to the
recognizers.
- Some micro optimization may be required, especially if the input
device is high frequency (eg. 1KHz gaming mouse).
Because of a typo in generator source (and overlooked error in
tests) we were previously generating incorrect code for setters
with the @auto qualifier. This was brought up in D5306 and is
now fixed.
Summary:
If there is no given pathes for image files as parameter of edje_cc,
"img_dirs" will be NULL. Then, a local variable "load_err" is always
EVAS_LOAD_ERROR_NONE. Because of this, the "if" condition just after
EINA_LIST_FOREACH() will fail. It causes memory leak from "iw".
@fix
Test Plan: N/A
Reviewers: raster, cedric, jpeg, woohyun
Differential Revision: https://phab.enlightenment.org/D5285
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
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.
Coverity reports that the eina_strbuf 'param_call' leaks when it goes
out of scope here, so fix the leak by freeing the strbuf
Fixes CID1381502
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
efl_del() is valid but bindings such as C++ should be using efl_unref()
and not efl_del() in this situation: a reference was given, so it should
be released.
After the previous patch, the caller of efl_input_dup() clearly owns the
reference on the returned object, which means she must absolutely delete
or unref if manually.
Note that the previous patch changed the bug from use of invalid eo
pointer to leaking of objects. But the only way to support bindings with
something like dup() is to ensure we give a ref to the caller, and thus
the parent should be null.
Note: eo_debug was used extensively to reach this point.
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
These types are of questionable value and the API was not entirely
thought out - remove for now, and if a legitimate use is found
later, they may be readded (with a better API), but typically it
seems best to redesign the bad APIs around safe containers...
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.
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
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
Summary:
If user call tooltip_orient_set or tooltip_style_set or tooltip_window_mode_set
before tooltip_test_set or tooltip_content_cb_set, those functions doesn't work.
Because elm_tooltip will be created when tooltip_content_cb_set is called.
I fixed logic to use some functions before tooltip_test_set or tooltip_content_cb_set.
Test Plan: elementary_test -> Popups -> Tooltip
Reviewers: jpeg, Jaehyun
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5183
Summary:
In elm_map_overlay_show and elm_map_overlays_show,
it frees overlays list members. This lists are used
in elm_map_overlay functions, so should remain.
Test Plan:
1. Run elementary_test -> Geographic -> Map
2. Click group overlay (whose text is "3") -> bubble appears
3. Click "Show" button -> observe no more Eina Magic Check Failure appear.
Reviewers: jpeg, cedric, woohyun
Differential Revision: https://phab.enlightenment.org/D5191
For this patch I decided to add a pseudo legacy wrapper as the function
is called in a very large number of places. Fixing all those calls to
use the size2d form is a lot of work and a greater risk of b0rking
something.
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