deadkeys and composition are involved. i don't know if they are or are
not. anything else is an issue outside of efl i believe. (eg keymap)
SVN revision: 75398
1 textclasses were repeated per object list and (segv free same tc 2x)
2. we returend if size OR font name match - BOTH have to match to be
"the same". so && not ||
SVN revision: 74980
Really ? A return at the end of a function ?? Would the function
actually return without this or would it just sit inside this function
forever ? ;) </joke>
SVN revision: 74848
edje error was a mess. First someone (maybe myself) added eina log,
then people changed it to be a mix with printf()... then they replaced
eina_log with printf() + colors so it would be less verbose.
It's fixed now! Using eina log infrastructure.
If all that is wanted is specific messages for edje_cc domain, do it
with a specific log print function (eina_log_print_cb_set()). I made
it produce messages in the format:
<levelcolor><progname>: <levelprefix><message>
Where:
- levelcolor is defined by eina_log (I hacked the win32 version,
since no public api to resolve level to color).
- levelprefix is "Error. " or "Warning. " to cope with traditional
output.
If it does not look as you wanted, let me know before stuffing some
printf() again.
Bonus point: reduced 2 global variables (progname and verbose),
removed lots of code.
SVN revision: 74701
<anisse@astier.eu>
On Mon, Jul 9, 2012 at 7:09 AM, Anisse Astier <anisse@astier.eu> wrote:
> Trying to make the description more explicit
SVN revision: 73478
This shouldn't break stuff, just make things easier. Think of all that lost
time " 0.0". Not anymore. Not even in Embryo scripts. Indexes should only
be provided when you need them (which is quite rare).
Note that if you use ``set_state("new state")'' in your Embryo scripts, the
produced .edj files will be incompatible with older versions of Edje. This
backwards incompatibility only applies to Embryo scripts; edje_cc will
generate a ``0.0'' value if the index is omitted from state declarations and
programs.
Sachiel said this patch was OK; our benevolent release manager acked as
well. Blame them if this breaks stuff.
SVN revision: 73424
Add a key in edje.pc to help third-party applications detect if the library
has been compiled with multisense support. This will be eventually reverted
if multisense becomes a requirement for edje. For the time being, people can
check multisense availability by "pkg-config edje --variable=multisense".
SVN revision: 73324
Subject: [E-devel] Patch for Edje: added const to obj parameter of
edje_object_part_table_child_get
The obj parameter is used only for read access so the const can be
added to its type.
SVN revision: 73231
Subject: [E-devel] [Patch] [Edje] Fix for seg fault during edje
decompilation
Fix decompile of sound samples to use sound source file, not name
Fix decompile of sound samples not double-free
Fix alsa configure option to be alsa, not flac.
SVN revision: 72117
crashes too in real life. try with valgrind again some tiome. rp's
(parts) freed before callbacks called thus cb data is invalid by the
time its called.
SVN revision: 72090
NOTE: VIRTUAL part are almost like rectangle except they don't create any object
on the canvas. This part can't be visible, nor have any color, nor be used as a
clip, nor receive any event.
SVN revision: 71674
Subject: [E-devel] [Edje]: Bug Fix: Edje draggable jumps when external
events is used.
Please find attached bug fix patch for edje draggable jump issue when
external event area is used.
Bug: When an external event area is used for edje draggable and when
after mouse move if immediate mouse down
is done then the draggable jumps back to its original position.
Analysis: In _edje_mouse_down_signal_cb When an external event area
is set i.e., when rp->events_to is set.
tmp.x value is set to 0, need_reset is set to 1 and also
_edje_recalc_do is called including emitting "drag" signal. this code
is
unnecessary/buggy and instead it causes the jump.
1. In mouse down only drag->down.x and drag->down.y needs to be set
which is being set below and tmp value need not be reset to
0 as tmp value is calculated in mouse move based on drag->down.x and
drag->down.y values.
2. need_reset is already set in mouse up hence need not be set in
mouse down again.
3. edje_recalc_do is the function which actually causes the movement
of draggable based on tmp value hence need not be called in mouse down.
because of the above code race condition happens and as tmp value is
being set to 0 and need reset is also enabled the draggable jumps back
to where it
started.
4. "drag": is sent even before "drag,start" [ should not /need not be
sent in mouse down ]
All the above code is added only when external event area is set and
the above code is not even related to whether external event is set or
not.
Solution: When an external event area is set directly equating rp =
rp->events_to and sending mouse,down would be enough, as down.x and
down.y is set below
including sending drag,start. Recalc_do should be called only in mouse
move as its responsible for movement including setting tmp value.
need_reset is already set in mouse up. drag should not be sent from
mouse down.
Change Description:
Bug Fix: Edje Draggable jumps when mouse down is done immediately
after mouse move when an external
event area is used.
demo edc pasted below to reproduce the issue.
Please find attached bug fix patch for edje draggable jump issue when external event area is used.
Bug: When an external event area is used for edje draggable and when after mouse move if immediate mouse down
is done then the draggable jumps back to its original position.
Analysis: In _edje_mouse_down_signal_cb When an external event area is set i.e., when rp->events_to is set.
tmp.x value is set to 0, need_reset is set to 1 and also _edje_recalc_do is called including emitting "drag" signal. this code is
unnecessary/buggy and instead it causes the jump.
1. In mouse down only drag->down.x and drag->down.y needs to be set which is being set below and tmp value need not be reset to
0 as tmp value is calculated in mouse move based on drag->down.x and drag->down.y values.
2. need_reset is already set in mouse up hence need not be set in mouse down again.
3. edje_recalc_do is the function which actually causes the movement of draggable based on tmp value hence need not be called in mouse down.
because of the above code race condition happens and as tmp value is being set to 0 and need reset is also enabled the draggable jumps back to where it
started.
4. "drag": is sent even before "drag,start" [ should not /need not be sent in mouse down ]
All the above code is added only when external event area is set and the above code is not even related to whether external event is set or not.
Solution: When an external event area is set directly equating rp = rp->events_to and sending mouse,down would be enough, as down.x and down.y is set below
including sending drag,start. Recalc_do should be called only in mouse move as its responsible for movement including setting tmp value. need_reset is already set in mouse up. drag should not be sent from mouse down.
Change Description:
Bug Fix: Edje Draggable jumps when mouse down is done immediately after mouse move when an external
event area is used.
demo edc pasted below to reproduce the issue.
Please find attached bug fix patch for edje draggable jump issue when
external event area is used.
Bug: When an external event area is used for edje draggable and when
after mouse move if immediate mouse down
is done then the draggable jumps back to its original position.
Analysis: In _edje_mouse_down_signal_cb When an external event area
is set i.e., when rp->events_to is set.
tmp.x value is set to 0, need_reset is set to 1 and also
_edje_recalc_do is called including emitting "drag" signal. this code
is
unnecessary/buggy and instead it causes the jump.
1. In mouse down only drag->down.x and drag->down.y needs to be set
which is being set below and tmp value need not be reset to
0 as tmp value is calculated in mouse move based on drag->down.x and
drag->down.y values.
2. need_reset is already set in mouse up hence need not be set in
mouse down again.
3. edje_recalc_do is the function which actually causes the movement
of draggable based on tmp value hence need not be called in mouse down.
because of the above code race condition happens and as tmp value is
being set to 0 and need reset is also enabled the draggable jumps back
to where it
started.
4. "drag": is sent even before "drag,start" [ should not /need not be
sent in mouse down ]
All the above code is added only when external event area is set and
the above code is not even related to whether external event is set or
not.
Solution: When an external event area is set directly equating rp =
rp->events_to and sending mouse,down would be enough, as down.x and
down.y is set below
including sending drag,start. Recalc_do should be called only in mouse
move as its responsible for movement including setting tmp value.
need_reset is already set in mouse up. drag should not be sent from
mouse down.
Change Description:
Bug Fix: Edje Draggable jumps when mouse down is done immediately
after mouse move when an external
event area is used.
demo edc pasted below to reproduce the issue.
Please find attached bug fix patch for edje draggable jump issue when external event area is used.
Bug: When an external event area is used for edje draggable and when after mouse move if immediate mouse down
is done then the draggable jumps back to its original position.
Analysis: In _edje_mouse_down_signal_cb When an external event area is set i.e., when rp->events_to is set.
tmp.x value is set to 0, need_reset is set to 1 and also _edje_recalc_do is called including emitting "drag" signal. this code is
unnecessary/buggy and instead it causes the jump.
1. In mouse down only drag->down.x and drag->down.y needs to be set which is being set below and tmp value need not be reset to
0 as tmp value is calculated in mouse move based on drag->down.x and drag->down.y values.
2. need_reset is already set in mouse up hence need not be set in mouse down again.
3. edje_recalc_do is the function which actually causes the movement of draggable based on tmp value hence need not be called in mouse down.
because of the above code race condition happens and as tmp value is being set to 0 and need reset is also enabled the draggable jumps back to where it
started.
4. "drag": is sent even before "drag,start" [ should not /need not be sent in mouse down ]
All the above code is added only when external event area is set and the above code is not even related to whether external event is set or not.
Solution: When an external event area is set directly equating rp = rp->events_to and sending mouse,down would be enough, as down.x and down.y is set below
including sending drag,start. Recalc_do should be called only in mouse move as its responsible for movement including setting tmp value. need_reset is already set in mouse up. drag should not be sent from mouse down.
Change Description:
Bug Fix: Edje Draggable jumps when mouse down is done immediately after mouse move when an external
event area is used.
SVN revision: 71277
NOTE: know issue, in elementary_config the size of the icon
change after a theme reload. I don't know what information is
lost between to reload. If someone can point at them, thanks.
SVN revision: 71235