elm_layout_sizing_eval() marks an object as requiring recalc.
Unfortunately, it's been massively abused by various widgets into
actually doing the calc, or the min calc. So we end up with one API
that has 3 different definitions depending on the widget type:
1. Mark as requiring recalc (correct, respects doc, elm_layout)
2. Calculate min size and other size hints
3. Actually do some geometry modification
I believe we need to clarify these 3 requirements into 3 very clear
and specific APIs in elementary. Right now we have similar functions
in evas for 1 (evas_object_smart_changed) and 3 (smart_calculate).
But their exact definition also isn't necessarily what we want for
elementary.
Another clear problem is that layout_eval does not do any calculation
(in theory), so the "eval" word is a bit of a stretch here.
Once we're sure about the exact API we want, we can add this back to
EO and make it work across our EO widgets. For now let's just keep
the legacy API, and its EO overrides, as is.
Ref T5315
In some case, detected during eo test suite, the vtable does fail to
be fully assigned, but it is still being assigned as the new vtable.
Of course when later destroying it, it has already been freed. Leading
to a double free.
forcing a full eval here is unnecessary and broken since such an eval could
either change geometry in unexpected ways or fail to accurately change
the underlying canvas geometry
@fix
For programs without specific names edje_cc generated default names in
the form of program_$MEMORY_ADDRESS. That worked well enough for keeping
the names unique, but it causes problems if one wants to have these files
being binary reproducible due to different memory layouts, compilers,
etc. Simply using a counter as unique part should work well enough for
our use case and help people who want to verify builds.
Thanks a lot to Bernhard M. Wiedemann for review and testing.
Fixes T5113
Ref T5495
This reverts commit 9368eedd35.
The release is out so we can revert this bandaid again. In the hope to
find the real culprit and solution before the next release.
i found a crash today where a heme could cause a crash if it just did
the right things. the run program was freed while still being
accessed. so add some ref counting to keep it alive until references
go to 0. and add soem refs while we store it in lists.
@fix
Accidentally used functions in the library directly instead of through
the sym_* dlsym looked-up variants.
Why this only caused problems in some installations may still be worth
investigating - we may be pulling in libdrm at link time from some
other library?
Summary:
In _elm_layout_text_set function, text_signal_emit is called.
But in that case, check text whether it is null or not null before call signal_emit.
So "text" is not null always, and text_signal_emit's parameter "visible" is also always EINA_TRUE.
Reviewers: Jaehyun_Cho, cedric, jpeg
Reviewed By: Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5049
This merges them with the now standard interface:
Efl.Canvas.Layout_Signal
Some wrapping work was required for legacy API which
takes no user_data in del() but instead returns it. The
new EO function, while harder to use, is more correct
(you can't delete the invalid callback by accident, and
this follows EO events design).
Another crazy wrapping was done in entry/text in order
to add the callbacks to 2 objects instead of just one,
and still return the user data.
As for Naviframe and Popup, those two widgets override
signal_emit to forward the call to another object than
the resize object, but not callback_add/del. So they
are definitely broken.
Ref T5315
Here's the reasoning:
1. We will expose as many edje APIs as possible (and meaningful)
through the elm layout class.
2. Access to internal objects is usually risky, as it allows apps
to bypass EFL in some ways, leading to potentially undefined
behaviours.
3. If the need arises we can still add a similar API back to EO,
later.
Back to #1, it seems that the need for edje_get() was mostly to
call manual sizing functions, or the missing message_send(). I will
make sure these are accessible from the layout itself.
Ref T5315
This:
efl_content_set(efl_part(scroller, "default"), obj)
worked fine, but, this:
efl_content_set(scroller, obj)
didn't work as expected.
Thanks @JackDanielz for the report.
Note: There is a problem still... "default" should not work
with efl_part. This is quite bad, actually. It should
probably be "content" instead.
This makes layout parts implement Efl.Ui.Cursor.
This also adds the missing bool returns from that interface.
This removes 7 APIs from Elm.Layout.
Ref T5315
This is an API enabling accessibility on text(block) parts
in a layout. But it is said to have many issues. I can already
see that it only changes a flag but doesn't trigger any code
to create the appropriate objects, so definitely not fully
working.
According to @kimcinoo this may remain in legacy land for now.
Those APIs can then be used by Elm.Layout, hopefully
simplifying the API.
I wonder if the APIs should be prefixed "calc_" (as is)
or "layout_calc_". The extra "layout_" prefix would make
it common with other layout APIs (eg. signals, data,
size min/max, ...).
Ref T5315
Summary:
Implement efl_provider_find function for efl_ui_win class.
This will support to search window class by efl_provider_find function.
Reviewers: jpeg, cedric, Jaehyun_Cho, thiepha, woohyun, Blackmole
Reviewed By: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D5045
This is really only a demonstration of what kind of information
we can print with efl_debug_name_get(). Hopefully this can help
debugging with printf/ERR logs and even help with live debugging
inside gdb.
This shouldn't be used for other purposes than debugging, as the
exact string format is not defined.
@feature
This will include the following information, by default:
- class name
- whether the class is an override
- eo id (pointer)
- refcount
- name if one was set (Efl.Object property)
This also supports classes, which is why it's an EAPI in eo.c
and not only a method of Efl.Object
This can be overriden by subclasses using the empty method
Efl.Object.debug_name_override.get
If the function is overriden, then the returned string is used
as is and so it is left to the subclass to include all the
necessary information (as above). This can easily be achieved
by calling efl_debug_name_get(efl_super()) and then concatenating
the strings.
Think of this function as something like Java's toString(), but
only for debugging (i.e. a string class should not just return
its string value).
@feature
This allows two things:
- adding new override functions on an object that already has
overrides
- resetting a specific function (or list of functions) to the
parent class implementation by passing NULL as implementation
Fixes T5580
@feature
All legacy objects remain invisible by default. Any call to
visible_set() will prevent the automatic show() to happen.
show() will be done just before render time, which may be a
bit too late in order to propagate the necessary changes.
This may break some things where some objects are created
internally using efl_add() instead of the legacy API, and
the intent was not to show the object.
@feature
As this function is not called from anywhere outside of
ecore_wl2_window.c file, this can be declared static.
NB: This patch also changes the function name to match the library
(ecore_wl2).
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Currently, elementary programs crash on termination on macOS (seems
Sierra-specific). This is very nasty, looks like deep memory corruption...
Without valgrind (or like) support on Sierra, it is difficult to
pinpoint the origin of the problem.
Due to the imminient release, and after discussion with @stefan, this
kludge will allow the release to happen.
This commit MUST be reverted just after the release, so we don't
blindfold ourselves!
Ref T5245
When a virtualized file is created the file->global_map will not
point to a mmapped region, thus it's not safe to use munmap() during
the file cleanup. Only use munmap() if the file is backed by a FD.
Fixes: T5234.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
In order to perform IO operations the copier will create futures using
efl_future_use(&pd->job, ...), which will set pd->job to NULL once the
future is destroyed. However this may lead to problems, because in some
cases the copier may be deleted at the _efl_io_copier_job() function,
which is the future's callback. Since the copier may be deleted before
the future, the area pointed by pd->job will have disappeared by the time the future
tries to set pd->job to NULL. To avoid this problem the copier must
explicily call efl_wref_del().
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
bad endian... code... see the comment in the src about why i think
this is bad as obviously the buffer pointed to is a 64bit type always
that is a pointer to something...
Summary:
If user use the evas_object_smart_callback_add with no smart object,
it should be returned
@fix
Test Plan: self
Reviewers: jpeg, cedric, jypark
Differential Revision: https://phab.enlightenment.org/D5056
This happens in E with software compositing, since E's commit
5702f0975e890f07cfb. E should be fixed shortly but segv is not
acceptable. Without segv E is still massively broken so it's
not like the bug would be hidden (large black areas in windows,
after switch vdesks with enough windows).
This reverts commit 936ea58cb9.
this is an ideal change, but it breaks previously-expected behaviors
for interceptors and thus enlightenment is completely broken
it turns out that xlib is going to copy the complete struct into
something internal. This might lead to the condition that a uninitalized
value might be part of the struct, and when later the struct is read
again the code might do wrong stuff since that value could be set now to
a randomly other meaningfull value.
This turned out on me in e as i could not write any letters like ßöäü,
since that lead to a not returning call to _XReply internal of xlib.
Dugging that showed that xlib was waiting on a reply of a call that
never got executed, and the XEvent it is waiting on just contians a
randomly correct value.
@fix
This reverts commit 2d4d836018.
Don't pretend to fix an issue found by a static analyzer by
introducing another issue that even clang warns about.
Fixes:
elm_gesture_layer.c:2533: warning: using floating point absolute value
function 'fabs' when argument is of integer type [-Wabsolute-value]
if ((fabs(st->info.mx) > ELM_GESTURE_MINIMUM_MOMENTUM) ||
^
The elm_access a widget makes primitive object accessible. If a primitive
object is not visible, then the elm_access should NOT have state VISIBLE, and
SHOWING. From now the elm_access is checking visibility of primitive object.
Summary:
Whatever the dbus_connection_send_with_reply returns, the serial value
should be checked, because if the seral value is invalid a process could be aborted.
There is backtrace as below.
The dbus_connection_send_with_reply could return TRUE
even though it has a problem. Please refer to following comment:
/* Refuse to send fds on a connection that cannot handle
them. Unfortunately we cannot return a proper error here, so
the best we can do is return TRUE but leave *pending_return
as NULL. */
Test Plan:
There is not a exact reproduce step. If the Tizen login manager is relaunched
repeatedly, then the dbus and other service processes are relaunched.
If a service process tries to use dbus when the dbus has problem as above,
then it could be possilbe to get above backtrace.
Reviewers: raster, zehortigoza
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5053
@fix
this culd optentially use large offsets before accessing the ptr thus
it may not segv inthe first page but actually work if positionoffsets
are large enouh, so handle this case explicitly.
@fix
found by PVS studio
this culd optentially use large offsets before accessing the ptr thus
it may not segv inthe first page but actually work if positionoffsets
are large enouh, so handle this case explicitly.
@fix
found by PVS studio
Jean-Philippe Andre
Cedric BAIL
Mike Blumenkrantz
Daniel Hirt
Stefan Schmidt
Marcel Hollerbach
Amitesh Singh
Carsten Haitzler
Derek Foreman
JinYong Park
Taehyub Kim
Chris Michael
Jean Guyomarc'h
Guilherme Iscaro
jiin.moon
Andy Williams
Jiyoun Park
Shinwoo Kim
Jihoon Kim