Summary:
Current layout_update doesn't consider max hint priority. for example, if it
has hint_max, the size is hint_max value regardless of weight or fill.
moreover, if it has hint_aspect with hint_max, hint_min can be ignored.
(test that aspect(1,3) max(50,150), min(70, 70) then, size has (50, 150))
It seems that hint_max is considered as high priority. however, if hint_min
greater than hint_max, hint_max is ignored.
In order to resolve the hint priority conflict, this refactoring supports
following hint priority.
1) HintMin
2) HintMin + HintAspect
3) HintMargin
4) HintMax
5) HintAspect
6) HintWeight, HintFill
7) HintAlign
ref T5487
Specific unit test is D7463
Test Plan:
make check
elementary_test -to 'efl.ui.box'
Reviewers: jpeg, Jaehyun_Cho, zmike
Reviewed By: zmike
Subscribers: segfaultxavi, zmike, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T5487
Differential Revision: https://phab.enlightenment.org/D7750
Summary:
evas_object_image_pixels_dirty_set(img B, False) means
1. app want to mark image object's data is not dirty anymore
2. app don't want to be called get_pixels callback.
that does not mean image need to be redraw.
evas_object_image_pixels_dirty_set(img B, True) means
1. image object's data is dirty, so image object need to be redraw.
2. app want to be called get_pixels callback.
but pixels_dirty_set(img B, FALSE) function also set o->changed to true,
it cause problem related with rendering
Below case is the example of problem.
1. Smart object A
2. Child image object B
3. app call pixels_dirty_set(FALSE) inside pixels_get_callback
pixels_get_callback is called inside the image object B's rendering.
enlightenment's e_comp_object_render do upper job.
After adding preload fetch,
evas_object_image_render_post can call evas_object_change.
https://phab.enlightenment.org/D7157
evas_render_updates_internal
0. enlightenment call evas_object_image_pixels_dirty_set(img B, TRUE)
o->changed = 1;
evas_object_change(img B)
1. smart obj A is in render_objects
2. evas_object_image_render_pre B, o->change=0
3. evas_render_mapped (Smart A)
3-1. evas_render_mapped (img B)
: enlightenment call evas_object_image_pixels_dirty_set(img B, False)
: o->changed=1
3-2. evas_object_change_reset(img B)
4. pending_change(img B)
4-1. evas_object_image_render_post(img B)
o->changed=1 (3-1 step) evas_object_change(img B)->evas_object_change(Smart A)
5. render_post_reset
smart A is chaged(4-1 step), so, called evas_object_change_reset(Smart A)
###smart A is reset(5 step), img B is changed(4-1 step). after this case,
img B never get change to be redraw.
Reviewers: Hermet, cedric, zmike, ManMower
Reviewed By: Hermet
Subscribers: zmike, ManMower, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7821
This reverts commit a57c7f7510.
I pretty much hate to just revert your revert, but you failed to read my
replies, and failed to understand what i was talking about.
And YES we talked at fosdem about the platform issue, and do you
remember my answer, that back in time this might be the case, today is
different freebsd suppoerts setenv, and for windows we have a setenv
implementation in evil. And yes, vtorri also created a issue how bad and
evil this commit is, however, i still fail to see the issue since setenv
unsetenv and clearenv usages are taken as needed. (T7693)
The ownership question is answered in
https://phab.enlightenment.org/D7516#137367.
Can we please get into a state of technical discussions, and not *oh
shit, i am going to revert this* this has been in review for a long
time, a lots of people have tested it, we discussed things on it, and
there was 3 weeks of no reply from you.
The issues that exist will be dealed with. Feel free to create tasks if
you want :)
setenv and unsetenv are not portable. i explained to you at fosdem
there are issues and it's why i used putenv in the original
implementation and even though it's a pain (the string tou pass to
putenv is a pointer used literallt from there on in and you get it
from getenv, thus making ownership a pain -this is a libc issue we
can't readily solve). use putenv like the original code. then put it
back in. vtorri now has windows porting issues with the setenv use. i
knew there was a reason that still existed...
in addition your in_sync stuff is broken. psuedocode:
// assuming BLAGH env is not set to anything here
c = efl_core_env_get(global_env, "BLAH");
...
putenv("BLAH=10");
...
c = efl_core_env_Get(global_env, "BLAH");
i will get NULL in both cases for c ... but i should get "10" for the
2nd in reality. reality is lots of code across application code and
libraries will at times mess with the environment. it has to work with
this. the prior implementation did work with this.
Revert "ecore: here comes a env object"
This reverts commit 2373d5db5b.
Revert "efl_task: remove env from this object"
This reverts commit c3d69f66a6.
Revert "ecore: get rid of commands in efl_task."
This reverts commit 616381e9cf.
Revert "ecore: here comes a command line object"
This reverts commit 48e5684b3c.
1. this is broken:
EOLIAN static const char*
_efl_core_command_line_command_get(const Eo *obj EINA_UNUSED, Efl_Core_Command_Line_Data *pd)
{
return eina_strdup(pd->string_command);
}
it returns a const char * BUT it duplicates it on return. no. a big
fat honking NO. return a char * or don't duplicate. pick.
2. _efl_core_command_line_command_array_set() is broken by design. it
accepts an array of strings, but the strings are owned by the caller
who creates the array (requiring they free them up themselves after
this call) but the array becomes owned by the callee. the code here frees the
incoming array but doesn't care about the string content of it. it's
leak heaven waiting to happen (or bugs when someone wants to access
the array they create to walk it to free the strings they put into it
after it is set).
i brought this up and it was dismissed. now exactly he issue i brought
up is there with mixed ownership and the added complexity as well as
transfer of some ownership but not others.
go back and think about this so it isn't broken by design.
this checks that eo-dbg is also working in the same manner as normal eo
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D7911
this lead to ERR's. A element is invalidated while the composition
element is invalidated, which means, not yet deleted, but the Pointer
will fail a call to efl_isa.
Differential Revision: https://phab.enlightenment.org/D7623
this is important, as basically every single class etc. can be a
EFL_OVERRIDE_CLASS. This makes efl_override work with eo_debug.
Differential Revision: https://phab.enlightenment.org/D7910
this while loop is actaully iterating obj->xref, therefore we should not
take the pointer of data_xrefs.
Differential Revision: https://phab.enlightenment.org/D7908
Note that the usage in efl_thread.c should and could be removed.
the problem with its usage is that when the ARGUMENTS event is fired,
noone ever had the chance to subscribe to the loop of the thread yet. So
all in all this is unneccessary, since noone could ever touch that.
Differential Revision: https://phab.enlightenment.org/D7517
the mixin for now can carry a command, which can be setted as an string.
The string is then parsed again, this is done in order to make sure that
everything that needs escaping really is escaped or parsed correctly.
Differential Revision: https://phab.enlightenment.org/D7516
the env object can be used to alter and edit the content of environment
variables. Additionally, the class efl.core.env can be used to to setup
a not applied set of environment variables, which then can be applied
later (in the future) to set it directly to a spawned process for
example, or as a general key/data storage. A efl.core.env object can
also be forked off, which makes it easy to customize predefined objects.
ref T7514
Differential Revision: https://phab.enlightenment.org/D7510
This fixes 2 things as follows.
1. Displays format string "%%" as "%".
Like printf does, "%%" is displayed as "%".
2. Displays unknown format element as it is.
In format string "(50%)", ")" is an unknown format element.
Although format string has unknown format element, the format string
is displayed like printf does.
The cause of the issue displaying "0%" which was mentioned on
a96933f964 is as follows.
The default format string of progressbar is set as "%.0f%%".
Therefore, if progressbar's format string is not set, then "%" postfix
is always displayed.
This commit reverts commit a96933f964.
This commit restores commit b4112b9735.
This commit restores commit be770d37fb.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7856
This adds a test that sets a custom progressbar format string that includes a custom percent (%%) that should be escaped to just one percent (%). This case has been broken and fixed many times and is broken again so it makes sense to now add a check for it to try and prevent the continual breakage.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7745
when a map is applied to an edje part, it is expected that all components of
the part respect the map attributes. this requires that, in the case of
textblock parts, all the sub-parts which are internal to the textblock
(entry) object also go through the map populate and apply codepaths
fix T4977
@fix
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7648
Summary:
A large number of cache invalidation calls are doing pointer
indirection that is completely avoidable.
Depends on D7852
Reviewers: devilhorns, cedric
Reviewed By: devilhorns, cedric
Subscribers: devilhorns, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7853
As we discussed in T7469 with V40,
efl_ui_model_connect
efl_ui_factory_model_connect
need to be renamed to
efl_ui_bind_property
efl_ui_bind_factory
for this work,
Efl.Ui.Model.Connect interface is changed as Efl.Ui.Bind,
and bind_property and bind_factory both method is supported by this interface.
bind_factory need Efl.Ui.Factory,
and Efl.Ui.Factory inheritted Efl.Ui.Bind,
so I little bit concerned about circular referencing, but so far, it works well.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7529
Summary:
It was mistakenly being called as static functions.
Fixes T7619
Test Plan: See attached testcase.
Reviewers: segfaultxavi, bu5hm4n, vitor.sousa
Reviewed By: vitor.sousa
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7619
Differential Revision: https://phab.enlightenment.org/D7904
Summary:
These templates add the following features:
- Collapsible sections for simpler reading
- Full class names in ancestors list
(Could not make it work for descendants)
- Removed duplicated Implements section
- Removed huge Inherited Members section
- Extended maximum number of hierarchy levels from 5 to 10
(because our hierarchy is really that big)
Test Plan:
Follow the doc/docfx README to generate the HTML pages and enjoy the improved
and slightly-more-usable docs.
Reviewers: lauromoura, bu5hm4n, zmike, cedric
Reviewed By: lauromoura
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7832
Summary:
color_class_code seems to only have been added to efl_gfx_color in order to
share the hex conversion code, but this is trivial to do when it's in another
class and makes the api more sensible
ref T7559
Reviewers: segfaultxavi, bu5hm4n, cedric
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7559
Differential Revision: https://phab.enlightenment.org/D7898
the source should be used in the dependency. However, only the generated
header source, not the .c files or we will get duplicated sources.
This is another attempt to fix the build OSX travis failure
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D7896
its not required anymore, our wonderfull new syntax solves the original
problem it was trying to solve.
fixes T7565
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7893
Summary:
These constructors aren't checked for in the finalize step of the
initialization and may be given the @optional tag.
For C# this means they can be ommitted from the constructor call.
This also adds `Efl.Ui.View.model` as a constructor of
`Efl.Composite_Model` as the finalizer checks for it.
Fixes T7673
Test Plan: make check
Reviewers: segfaultxavi, zmike, bu5hm4n, cedric, felipealmeida
Reviewed By: segfaultxavi, cedric
Tags: #efl, #do_not_merge
Maniphest Tasks: T7673
Differential Revision: https://phab.enlightenment.org/D7855
this adds support in eo to generate a reflection API. To get the actaul
reflection to the klass, the API efl_class_reflection_table_set needs to
be called, the table in the end can be generated by eolian. Reflection
API is inherited by the extended class. This means, if you have two
reflection tables, first, the most upperst is called, then the next
lower one is called.
For now this API accepts NULL setter or getter, and will ignore them
silently when they are called.
fix T7681
Differential Revision: https://phab.enlightenment.org/D7879
The next commit will bring support for something like reflection. This
commit prepares the whole tree for getting another argument in
efl_class_functions_set.
ref T7681
Differential Revision: https://phab.enlightenment.org/D7882
Summary:
this is a user-triggered change so it must emit the event
ref T6979
Depends on D7886
Reviewers: bu5hm4n, cedric, segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T6979
Differential Revision: https://phab.enlightenment.org/D7887
Summary:
this is emitted on the internal object and must be propagated
fix T6535
Depends on D7885
Reviewers: bu5hm4n, cedric, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T6535
Differential Revision: https://phab.enlightenment.org/D7886
Summary:
these are emitted on the internal object and need to be propagated
ref T7621
Depends on D7884
Reviewers: bu5hm4n, cedric, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T7621
Differential Revision: https://phab.enlightenment.org/D7885
Summary:
these should be emitted any time text is changed in the object
fix T7615, T7417, T6978, T6979
Depends on D7883
Reviewers: bu5hm4n, cedric, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T7615, T7417, T6979, T6978
Differential Revision: https://phab.enlightenment.org/D7884
Summary: The constructing method is not used anymore after D7789 landed.
Test Plan: run tests
Reviewers: segfaultxavi, felipealmeida, vitor.sousa
Reviewed By: segfaultxavi, vitor.sousa
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7875
By default, dependency files are now generated only for headers.
This makes sense for the C generator and our dependency tracking
needs. If full dependencies are needed, there is now the 'D'
output, which has the old behavior.
remove the whitespaces from this file. Every editor in this world
removes unneccessay whitespaces at the end of a line. So every time i am
touching this header, i need to get rid of them, which is super
annoying. I know we are used to *not* doing such patches, but this is
just a waste of time, getting them out of the header every and every
single time.
Differential Revision: https://phab.enlightenment.org/D7880
Yeongjong Lee
Jaeun Choi
Marcel Hollerbach
Xavi Artigas
Jiyoun Park
Carsten Haitzler
Jaehyun Cho
Stephen 'Okra' Houston
Mike Blumenkrantz
Derek Foreman
SangHyeon Jade Lee
Lauro Moura
Lauro Moura
Cedric BAIL
Christopher Michael
Daniel Kolesa