function, we should do the same for events. This fixes the cursor
position in elm widgets.
NB: I have been running this patch for 2 days and see not bad side
effects in either wayland engines, or X11 engines. Patch from Robert
Bradford @ Intel, slightly modified by myself to avoid the overhead of
another function call.
SVN revision: 75309
adjust the clip size and position if something changed.
NB: Found this during final fullscreen testing where, when fullscreen,
the clip was not getting moved or resized.
SVN revision: 75291
now here's the rub. from the glibc manual page:
...
int memcmp(const void *s1, const void *s2, size_t n);
DESCRIPTION
The memcmp() function compares the first n bytes (each interpreted as
unsigned char) of the memory areas s1 and s2. It returns an integer
less than, equal to, or greater than zero if s1 is found, respectively,
to be less than, to match, or be greater than s2.
RETURN VALUE
The memcmp() function returns an integer less than, equal to, or
greater than zero if the first n bytes of s1 is found, respectively, to
be less than, to match, or be greater than the first n bytes of s2.
...
this explicitly says that s1 and s2 have their BYTES compared... and
then returns just some value < 0, 0 or > 0 based on the difference. what
that value is and means is not defined, as long as it is < 0, 0 or > 0.
so the C standard has this to say:
6.3.1.3 Signed and unsigned integers
2. Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value that
can be represented in the new type until the value is in the range of
the new type.
so a result of -255 (possible) is converted by REPEATEDLY adding the
max size of the new type (255) until within range... so ...
-255 + 255 = 0 ... within range.. BUT FALSE!
so why do we see this now? something changed in memcpy behavior.
before we ONLY saw values of -1, 0 or 1 - nothing else, NOW we see
thins like:
-12288
49152
4096
16384
61440
-53248
so memcpy changed behavior, though within specs of the manual page
anyway, but now the values can be ones that break the simple assignment.
SVN revision: 75159
position. Fix bug when clipping to viewport/framespace. These changes
fix Several buggers on Trac which related to the Wayland Engine(s).
Fix minor bug in evas_render where clipping for framespace would
not take into account the frame height and also move the frame clip to
the values specified in framespace (not viewport).
Fix buggers in evas_object_main which was causing objects (when created using
the wayland engines) to be an incorrect size & position (objects will now
be the same size/position in EFL Wayland as they are in X11).
Fix evas_object_geometry_get to return values based on where they were
moved (in relation to framespace). (These fixes are for the Wayland
Engines and do not affect X11).
Remove nw/nh from evas_object_resize (not needed variables anymore).
SVN revision: 74565
Used to just go for the first match in the cache which means it would always
think we only have the wrong size in the cache, and it would just add
new entries all the time.
SVN revision: 74435
Subject: [E-devel] [PATCH]Evas.h comments patch
When reading the comments of 'evas_object_textgrid_update_add' I
noticed
a little cnp err. The enclosed patch is just a suggestion, but the
misleading comment was driving me nuts...
SVN revision: 74331
NOTE: That one is nasty and I do admit that this doesn't
sounds like the proper fix, but as it doesn't trigger other
issue and is simple/reasonable I took to defeat that damn
beast.
SVN revision: 74180
evas_object_image_file_set tries to load the file even if the file is NULL,
this in turn makes proxies always report about an error, although there
isn't really one.
I'm not sure whether evas_object_image_file_set should behave the way it
does, but I'm sure the proxy needs to reset the error anyway (because of
potential previous errors).
SVN revision: 74073