Somehow I was seeing a ton of errors with "prefs_iface" not found in
make check. This code could not have worked since the merge of
elementary in EFL tree...
@fix
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
This removes the last remaining legacy-style part API from Widget.
I think this is redundant with the property "translatable_text"
introduced in Efl.Ui.Translatable.
Ref T5363
This moves the API entry points from Widget to Layout parts. I don't
think the other widgets support translation, but that is easy to fix.
The actual code implementation remains in elm_widget.c.
Legacy-only widgets are covered by Part_Legacy, while all EO widgets
that have text inherit from Layout (except Win but I don't think the
window title was translatable in legacy).
This removes 2/3 remaining part APIs from Widget.
Ref T5363
This will be used to replace the part translation API in Elm.Widget. It
should work for both parts and non-parts (ie. the main text of a button,
for instance).
For now I'm taking the following approach:
- All efl_text_set/get strings are untranslatable, i.e. get() returns
the visible string, set replaces and can not be translated.
- translatable_text_set/get needs to be used to enable automatic
translation, which in turns calls efl_text_set to modify the visible
string. Thus, translatable applications will have to use
efl_ui_translatable_text_set a lot more than efl_text_set, unless
they translate strings application-side.
Note that some other frameworks take a simpler approach equivalent to
calling efl_text_set() with an already translated text. This prevents
runtime language changes of the application, unless the application
handles them specifically.
This is a follow-up to 4d4401f3a6.
The format line adjustment (e.g. linegap) should calculate the current
item's ascent/descent, and then update c->ascent/c->descent.
Otherwise we accumulate calculations like linegap values
ref D5217
Since elm_popup_item.eo.h is only included in elc_popup.h, the EAPI is
not well defined, resulting in a crash when, in a simple C file, the
item class is tried to be accessed.
By including the H file in elc_popup_eo.h, we make it public (as the
other item classes) and solve the EAPI issue.
Thanks @jpeg for helping me to solve this issue.
Summary:
Textblock uses ascent, descent from primary font when there is no text.
If a text is set which need other font, Textblock uses ascent, descent from
actually loaded font. If loaded font has smaller size, text cursor and text
looks jerky in elm_entry. At least, primary font's size should be respected
as minimum size of a line for avoiding this issue.
In addition, the patch will allow negative line gap values.
@fix
Test Plan:
Put your hamburger(🍔) in Ecrire. And put an english character.
(Put a text which will load smaller font. And put a text which will load primary font.)
Reviewers: raster, cedric, herdsman, jpeg, woohyun
Reviewed By: raster
Differential Revision: https://phab.enlightenment.org/D5217
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
Jean-Philippe Andre
Sungtaek Hong
Lukasz Stanislawski
Daniel Hirt
Carsten Haitzler
Daniel Zaoui
Youngbok Shin
Felipe Magno de Almeida
Cedric BAIL
Jeeyong Um
Marcel Hollerbach
Daniel Kolesa
Mike Blumenkrantz
Vincent Torri
Lauro Moura
Andy Williams