Summary:
When evas selects a strike of embedded bitmap font,
calculate ratio and use it for scaling embedded bitmap.
@feature
Reviewers: jpeg, tasn, woohyun, raster, herdsman
Reviewed By: raster
Subscribers: charlesmilette, Francesco149, cedric
Differential Revision: https://phab.enlightenment.org/D2713
pause event means that the window is not visible anymore to any user.
resume is triggered when the window became visible again or just
became visible again.
pause event is triggered when no more windows are visible to any user.
resume event is triggered when a window make the application visible
for the first time to the user after a pause or when starting the application.
Thanks @JackDanielZ for the report!
This makes efl_content_set/get/unset APIs work on the inwin, even though
this is a legacy-only widget (at least right now).
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