so since this uses new pos - cur pos to move BY x pixels... there is
an issue that if the move of the obj ends up re-moving the current obj
TO the same pos. it moved BY the same delta again thus racing ahead.
not great. because x/y is not stored until the call stack returns to
after the smart move func and the pos set storce the new position in
the object struct. the easiest way atm until we have relative
positioning etc. is to store this in the smart obj and use the delta
at that time of the call then store it immediately so a recursion ends
up with a delta of 0 if its the same pos, so go back to where we were.
this fixes a nasty issue i spotted in fileselector that made filesel
icons race along when scrolling 2x as fast as everything else. oddly i
couldnt see this in any other widget that scrolled when i looked...
which is odd, but... either way a nasty issue... subtle... and now
fixed. never saw this before so this seems new.
This was broken for smart objects that are not "clipped smart
objects". This fixes the example evas_smart_object.
NOTE: This EAPI was removed in efl-1.18!
/!\ This was an uncaught API break between 1.17 and 1.18 /!\
@fix
Lacking a proper internal tag, I'm using both protected (it is
in fact a protected access function) and beta (to mark as unstable,
not real API).
New smart objects based on EO only should rely on constructor,
finalize and destructor exclusively. In theory, this should be fine.
Unfortunately it may be impossible to inherit from the Efl.Ui.Win
class as it uses a really bad hack and calls super.constructor
inside the finalize method.
This is an override of efl_gfx_position_set.
As for the other patches, I hope I didn't break anything.
A problem likely to happen is that the super call was inserted
too early or too late in the call flow. For instance:
_myclass_position_set(obj, x, y) {
position_set(super(obj), x, y);
position_get(obj, &prevx, &prevy);
do_something_with_delta_xy();
}
The above code flow is obvisouly wrong, but may have crept in this
patch (such a bug sneaked in inside smart object, breaking
everything at first).
While this kind of API seems to make sense with smart objects
(relative coordinates), it is currently not used apart from
the smart object class itself.
So, for now, I'm moving this to legacy to clean up Efl.Canvas.Group
and we can later add the equivalent in a clean "group" API.
These should be just overrides of Efl.Gfx.visible.set. Many
widgets were handling smart show() and hide() manually, which
means this patch is quite large.
Hopefully this doesn't break anything, obviously. But here are
some widgets known to be problematic, as the old code flow was
really strange (sometimes not calling the efl_super function):
- window
- notify
Similarly to group_color_set, group_clip_[un]set should not
exist and should be a result of efl_super and inheritance.
This patch also removes clip_unset from the EO API and keeps
only clip_set(NULL). The reason is that it will avoid bad overrides
of clip_unset() vs. clip_unset(NULL). This also simplifies the code
a bit. Ideally we should be able to reintroduce clip_unset in EO
if we can have a "@final" tag (like java's final keyword), to
prevent overrides.
Widgets should simply override efl_gfx_color_set and call
super all the way up to evas object.
Legacy compatibility with call interceptors and early call
abortion (eg. delete_me or obj->layer == NULL) are implemented
with an internal call. See the previous commit introducing the
API.
Most of the smart functions "Efl.Canvas.Group.group_xxx" should
not exist and be overrides of the base object function instead.
Cleaning this up is necessary if we want an EO API for custom
smart objects. This patch is the first attempt at removing a
method (the simplest one).
As for no_render, I wonder if propagating to the children
really is necessary. evas_render should skip them already.
This is legacy stuff. I wish we could hide it from our inheritance
entirely. Instead, just make it abstract, remove all functions from
eo (doable here) and rename with the keyword "internal" in the new
ugly java style name.
This allows doing ugly things such as setting a clipper/mask
on any smart object, without having to worry about seeing a
white rectangle cover the whole screen.
While the above scenario is not a great idea (bypass elementary in
its handling of the clipper), having a big white rect covering the
entire UI seems even worse.
I wonder if elm objects shouldn't simply allow user clippers, and
somehow manage them along with the smart object internal clipper.
I just ran my script (email to follow) to migrate all of the EFL
automatically. This commit is *only* the automatic conversion, so it can
be easily reverted and re-run.
From now on, constructors should return a value, usually the object
being worked on, or NULL (if the constructor failed). This can also
be used for implementing singletons, by just always returning the same
object from the constructor.
This is one of the final steps towards stabilizing Eo.
@feature
const have been added in object parameter of two legacy APIs to fit
Eolian generated files.
Since these functions retrieve information from object, it is logic that
the object would be const.
This reverts commit 1714fe93f4.
We actually want this type, it makes things clearer.
Conflicts:
src/tests/eo/function_overrides/function_overrides_inherit2.c
src/tests/eo/function_overrides/function_overrides_simple.c
src/tests/eo/suite/eo_test_class_simple.c
Evas_Common.h should be used for the public header, and rather rename
evas_common.h internal header to another name.
Sa:
Evas_Common_Header.h -> Evas_Common.h
evas_common.h -> evas_common_private.h
Shouldn't have both Evas_Common.h and evas_common.h because of case
insensitive filesystems.
- mark all children of a given smart object as "is_frame" if the smart
object is also marked as a frame;
- when moving a smart object, use the originally requested move
coordinate to calculate the offset that the children should be moved
too;
- _smart_move_children_relative will fetch the child position with
geometry_get(), this way getting the corrected object position, before
adding the offset.
I've tested make -j 3 install and it works nicely
I've tested expedite with software and opengl xlib,
and it works. Not tested other engines, so please
report any problems (engines or other) on the ML.
TODO: examples and tests, I'll add them later
ISSUE: Eina_Unicode size check. It indirectly depends on
eina_config.h, which is created at the end of the
configure script. So its size is always 0. I don't
know how that size is used, so I can't do a lot,
for now.
SVN revision: 78895
Jean-Philippe Andre
Carsten Haitzler
Tom Hacohen
Cedric BAIL
Daniel Zaoui
Jérémy Zurcher
Sebastian Dransfeld
Rafael Antognolli
Cedric Bail
Rafael Antognolli
Vincent Torri