Originally it was its own object.
There are some valid claims that there is no justification for it to
remain an object.
Furthermore, it's apparent that it added little benefit: changes of
each cursors, in practice, triggered a query for all objects of the
same textblock. There wasn't real advantage to have a finer resolution
of controlling the cursors with their own events.
This ports back a lot of code, and changes a lot of other code in the
higher-up widgets, such as Efl.Ui.Text and co.
The usage was replaces from:
efl_canvas_text_cursor_char_next(cur_obj)
to
efl_canvas_text_cursor_char_next(text_obj, cur_obj)
that is, it is an operations on the TEXT OBJECT, rather than on the
(now removed) cursor object.
So, one less efl object to worry about now.
Hopefully, the port went smooth.
image.zoomable can load edj files now.
usage:
efl_file_set(zoomable, "../somefile.edj", "mygroupname");
test:
elm_test -> photocam
click "open" btn
select an edj file, it would show first group in selected edj file.
@feature
Summary:
Genlist item doesn't change its size when its content size is changed,
but its size is determined in realization.
Therefore, deferred calculations for content should be performed immediately
before swallowing it by genlist item.
Test Plan: make and run attached sample
Reviewers: jpeg, SanghyeonLee, cedric
Differential Revision: https://phab.enlightenment.org/D4705
Summary:
To recieve keyboard events, the entry_edje should have Evas focus.
But, if a non editable Entry widget takes focus, it can't recieve
keyboard events even if it becomes editable after taking focus.
So, elm_entry_editable_set() function should update Entry's focus state.
@fix
Test Plan:
The code of elementary_test - entry is modified to test this issue.
Please, check the issue with the following steps.
1. Run "elementary_test entry"
2. Click "Unfocus" button to make entry to "unfocused" state.
3. Click "Edit" button to make entry to non-editable mode.
4. Click "Focus" button to make entry to "focused" state.
5. Click "Edit" button to make entry to editable mode.
6. See a cursor is blinking in entry.
=> But, you can't edit text without this patch.
Reviewers: raster, herdsman, cedric, jpeg, woohyun
Differential Revision: https://phab.enlightenment.org/D4858
This patch adds support for map with more than 4 points.
However, we only support points with multiples of 4.
This also adds efl_gfx_map_point_count_set/get APIs to
set number of points.
@feature
Summary:
- elm_panel has a property named hidden which stores
open/close status.
- This is updated when:
1. bring_in animation is done(anim_stop_cb).
2. mouse_up on panel.
3. API is called. (elm_panel_toggle, elm_panel_hidden_set)
- In case 3, API changes hidden, and starts bring_in animation
which will call anim_stop_cb() which will update hidden again.
- If bring_in animation is canceled (eg: sizing_eval),
anim_stop_cb will be called and calculate hidden status
which will not guarantee updated hidden state by APIs.
Test Plan:
1. Call any APIs which will call elm_layout_sizing_eval(panel)
right after calling elm_panel_toggle()/elm_panel_hidden_set().
2. Delete content of panel during "toggled" cb.
Reviewers: jpeg, eunue, cedric
Subscribers: conr2d, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4704
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
As Dave pointed out, those are meant for internal use by Edje and
the plugins implementation, rather than for apps. This removes
ugly and complex code. Makes me happy :)
Note that I've kept the composition for now. We can remove it
as efl_content_get() must work on the part handle anyway. But it
can be used as a quick solution.
This effectively replaces edje_object_part_external_object_get
and allows all function calls except those from Efl.Object.
Is this good enough? Or do we need access to the real object?
This adds a new class: Efl.Canvas.Layout.External.
I hate this long name...
This class represents an external part, and for now only
supports param_set/get as well as param_type_get. For now
param_type_get() still returns an Edje_External_Param_Type and
not another more generic type.
TODO: enumerate choices, return object, return content
All windows should be standard, really. Except when using legacy
elm_win_add() or if type_set() was called with a specific type.
I dislike type_set...
Ref T5322
we haven't gotten replies yet on what our position or size should be,
so we should store them so centering works before show but after
resizing is evaluated (that also fixed by forcing an eval).
@fix
This is a copy of the "Flip Page" map usage example that relies
on the new set of APIs for EO. This was used to test the API
and show its usage.
The calculation being done in absolute values, this does not
really exploit the new API, but instead proves that it is on
par feature-wise.
The performance is worse than with legacy, because of extra list
walkings, map calculations, small struct allocations and eo calls.
This fixes the shadow of the page which was broken with the legacy
API (as color_get did not recalc the map).
A better implementation can probably be done without having
to rely so much on absolute coordinates.
This implements an entirely new API model for Evas Map by relying
on high-level transformations on the object rather than an external
Evas_Map structure that needs to be constantly updated manually.
The implementation relies on Evas_Map.
To rotate an object all you need to do now is
efl_gfx_map_rotate(obj, 45.0, NULL, 0.5, 0.5);
Or with a C++ syntax:
obj.rotate(45.0, NULL, 0.5, 0.5);
Or even simply (with default arguments):
obj.rotate(45.0);
The map transformation functions are:
- rotate
- rotate_3d
- rotate_quat
- zoom
- translate (new!)
- perspective_3d
- lightning_3d
@feature
Manual points population will eventually be useless as the
map API will become more like a transformation API, where
the current object geometry doesn't matter as much as which
transformation is applied to it.
If we disable preload, then the second file set on an elm_image
object would not trigger a deletion of the first image. As a
consequence, both images would be visible... really bad if there's
alpha or different dimensions!
Thanks Anand Kumar for the report!
@fix
After talking with @eunue I realised that the way I'd first
implemented the box/grid "pack" API was simply too complicated.
I had tried to make it possible to change the layout function
at runtime, like good old evas box, but since there are no function
pointers in EO the final design was really convoluted.
If someone really needs to change the layout of a box at runtime,
just create your own subclass, or unpack all items and repack them
in a new box.
Note: there are still some issues with the layout params & flow
This make save() work on snapshot objects, provided the call
is done from inside render_post.
Also, this saves the filtered output of an image, rather than
its source pixels. Any call to save() on a filtered image must
be done from post-render as well.
Fixes T2102
@feature
This will reuse existing buffers by resetting only the minimum
required in the filter context (also reused). Work in progress,
as the actual reuse is disabled for now.
When using a snapshot object we have access to exactly all
the pixels below it inside the snapshot surface. So, in order
to produce a nice blur, it is necessary to expand this snapshot
and then clip it otherwise the edges will look a bit ugly.
Unfortunately, there are still places where blurs didn't look
so good, as objects below an opaque region would never get
rendered into the snapshot object. So the edges, inside a
snapshot object, around an opaque region would have blur
artifacts.
This fixes that by shrinking the cutout regions by the radius
of the filter. Eg for blur this is the blur radius.
The test case in elm_test can exhibit this fix very clearly:
a red glow would be visible around the opaque rectangle, but with
these changes we instead see the blurry edges of the objects
below the rectangle.