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...
This is a new type representing a mutable string (no const).
Regular strings cannot be made mutable with @owned because
they might be hidden behind typedefs.
in some cases loading an xmodmap on enlightenment startup can trigger an infinite
number of identical events which hard locks the xserver for a very, very long time
@fix
Summary:
The ptr_null/nonnull were added in the 0.11 version of libcheck. The
required version in configure.ac is 0.9.10 (some distros still use this
old one).
Reviewers: felipealmeida, stefan_schmidt
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5220
This relies on the new edje API that gives us the exact type of a part.
This fixes the shortcomings of edje_edit_part_type_get() and returns a
proper Text part type for efl_part(slider, "elm.units.max").
See previous commits:
"edje: Add part_type_get API"
"elm: Split off text and content for efl_part"
For now I made this EO-only but this definitely could be expose in
legacy API as well.
This simply gives exact information about the type of part, after doing
a recursive search. Edit Edit doesn't do a recursive search, only a
direct one, which can yield invalid results (eg. RECT or NONE instead of
TEXT in case of "elm.units.max" for a slider).
@feature
The string comparison was invalid for full part names. It worked with
the aliases, by chance, not by design.
This got broken by eee60abbcf but using full part names from the
application side was already broken before that.
@fix
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
This adds the 'async_layout' method.
The 'async layout' method is similar to 'size_formatted_get', but done
outside of the mainloop. When a call is made to this method, a thread
is created (after some preparation like updating the logical text
items), and the visual layout is offloaded to that thread. The result
is returned as Eina.Future.
The mainloop is blocked for operations that manipulate the object, if a
thread has already been created but hasn't complete its work.
Consecutive calls for async layout for the same object are not handled
simultaneously. Each time the threads has complete its work, the next
(if exists) layout will be dispatched.
@feature
Small patch to fix Coverity reported issues of uninitialized variables
Fixes CID1381306, CID1381305, CID1381304, CID1381303
Signed-off-by: Chris Michael <cp.michael@samsung.com>
the content unset in some cases - specifically terminology seems to
put the item back in and doesnt remove it... causing it later to be
deleted if unset to remove it and re-use it (which is rarely done).
@fix
This patch adds support for software rotation in the evas drm engine.
This is a fallback codepath in case hardware rotation is not supported
for a given rotation amount. This patch also fixes a leak of and
pending updates during output buffer free.
ref T5999
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch provides an override in the evas drm engine for the output
resize function. We override this function so that we can reconfigure
the output buffer.
ref T5999
Signed-off-by: Chris Michael <cp.michael@samsung.com>
I think this closes the orientation vs. direction problem.
RTL vs. AnyRTL is not fully handled yet but this becomes a
widget-per-widget issue (eg. should a box in a RTL locale be mirrored if
set to horizontal?).
Fixes T5870
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:
When multi down or multi move occur, state of touch point changes to EVAS_TOUCH_POINT_STILL.
So I add condition, "state == EVAS_TOUCH_POINT_STILL"
Reviewers: jypark, woohyun, cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5157
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:
without it, it was failing with following error
/usr/bin/ld: /tmp/ccnjRcVr.o: undefined reference to symbol 'evas_object_move'
//usr/lib64/libevas.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Test Plan: just try to compile it with and without.
Reviewers: jpeg
Reviewed By: jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5182
Summary:
If the object is outside the parent geometry because of map,
this object would be ignored in determining object is in the event area.
Please refer to below case
1) There are some button in the box object
2) A button has map with 90 degree.
It would be placed outside the box geometry
3) If you press the button part outside the box,
the button event does not work.
Test Plan: sample code
Reviewers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D5180
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
This fixes scrolling in rage.
Lessons learnt:
- Do not trust raster's bisecting skills ^^,
- Do not blame GCC until you're 100% positive about the exact code
triggering an issue,
- va_arg is unsafe, and can lead to crazy issues like this one,
- va_arg passes (int x, int y) differently from Eina_Size2D sz, and
optimization flags may also affect how that's done, or at least what
kind of garbage data is used.
We're not 100% sure yet but there seems to be an issue with GCC and -O2
where rage scrolling doesn't work anymore, since the first patch below:
See 641a58f735
See f53fe993a6
This commit unfortunately doesn't solve the issue.