Only take min & max properties into account if the window is not fullscreen.
Be sure to call update_size before we attach the buffer, as the buffer attach
code makes use of the allocated size to damage the surface.
Add trapping for fullscreen window in the configure callback. This
(along with coming commits) allows us to actually do fullscreen now :)
During window configure, when we check for maximized, we should check
to be sure it is not fullscreen also before adjusting window size.
SVN revision: 75293
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
Certain types of variadic functions use NULL as the last argument instead of a
string format (printf-like). Functions like these are: execl and execlp.
We are in feature freeze, but I believe this is small and simple enough to slip
in with no headaches. These functions are being used in the new edbus library
and it would be good to have it supported in eina now.
SVN revision: 75271
When we create the egl window we should take rotation into
consideration, so account for that. Add an 'edges' variable to the
engine info structure. This is needed so we can implement resizing
windows from the top also. Make sure to use
wl_egl_window_get_attached_size and determine the edge we are resizing
from, so we can calculate the difference in sizes to send to
wl_egl_window_resize.
Add __UNUSED__ to function paramaters where it was missing, and fix
some compiler warnings.
SVN revision: 75215
from the top when asked too (this is akin to the wayland_shm resize
fix). Also, when we update the ecore_wl_window size, we
should be sure to call the buffer attach function so that server size
allocation can be kept in sync with the window allocation.
SVN revision: 75214
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
Looks like we'll need to fix discrete dynamics world destructor
on bullet, but current revision is kind of messed.
I'll see what I can do later.
And yes, it will leak the ddw until it's fixed.
SVN revision: 75145