Subject: Re: review request : ecore x patch for X Gesture extention
Do you remember that I told you X gesture extension patch for ecore x ?
I’d like to put the attached patch to ecore_x in upstream.
This patch is just for initializing/receiving X gesture extension stuff.
Would you please put this in SVN ? : )
Thanks and regards,
Sung-Jin Park
SVN revision: 64732
Actually, basic logic is same,
but added the touch down info structure to store down timestamp (and window, event window...) for each device.
SVN revision: 62980
Now we can get notifications for changes in X selection. This is very useful
for text editors that want to disable their "paste" button when there's
nothing to paste.
SVN revision: 62205
Depth/Visual/Colormap of a given screen.
NB: Added these so that we can remove xlib specific calls in
ecore_evas and just generic ecore_x calls (so we are engine
independant).
SVN revision: 61742
Bonus: Added doxy and the @since stuffs (for Tom) ;)
NB: Needed for changes to ecore_evas as that was using xlib
ScreenCount. This way we can just use ecore_x_screen_count_get and not
have to worry if we are xcb/xlib/etc.
SVN revision: 61728
NB: These are mainly for systray module so that it can be engine
independant in that it can just use ecore_x calls now, instead of
specific xlib stuff.
SVN revision: 61555
Subject: [E-devel] [PATCH] ecore_x_randr_current_output_get ~>
ecore_x_randr_window_outputs_get
find attached a set of patches that do the following:
State before patches:
ecore_x_randr_current_output_get was unimplemented.
State after patches:
Patch1: ecore_x_randr_window_outputs_get implements functionality of
ecore_x_randr_current_output_get
Patch2: ecore_x_randr_current_output_get is deprecated and redirects
calls to ecore_x_randr_window_outputs_get
(also i fixed the function to handle realloc errors and not fail, as
well as properly do rectangle intersects based on ROOT relative coords
which is what you wanted to start with as this would have only worked
right on immediate children of root)
SVN revision: 58513
Subject: [E-devel] [PATCH] EDID decoding functionality
find attached a patch for EDID data extraction. My display's
manufacturer didn't comply with the standard too much, so I can't test
it entirely. But it should work.
... with modifications to make it actually compile and api be cleaner,
code more robust etc.
SVN revision: 58348
When handling xdnd_enter event(s), if we do not support the dnd target
version, then we issue a warning and return from the handling
function. If we are going to return (and not issue the ecore_x_event),
then free the allocated memory of the ecore_x_event_xdnd_enter
structure that we previously allocated.
SVN revision: 58337
NB: _ecore_x_mouse_up_count appears to not be used. It was used in one
code block only and appears to serve no real purpose. Both variable
and code block are now commented out without any ill effects.
SVN revision: 57933
if Ecore_X_Image-->XImage does not exist, we call
_ecore_x_image_shm_create to create it via shm, BUT that function
can return a NULL XImage if shm is not supported, so we need to check
the return of that, else we are calling XShmPutImage with no XImage.
(NB: This should probably be backported to 1.0...if someone could
handle that please ?)
SVN revision: 57130
mappings change (xmodmap or kbd layout change).
fix other events to have proper eina_bool too and enums
also remove already disabled old unimplemented events commented out.
SVN revision: 53942
when trying to free the mode_info. Not much functional difference with
this commit except that we do not call strndup if the nameLength is
<= 0.
SVN revision: 53477
Bad cedric, no cookie for you! While merging r39505 introducing
Ecore_Input you had all the code to go through Xutf8LookupString(),
but its documentation says (man Xutf8LookupString):
{{{
Note
®To ensure proper input processing, it is essential that the
client pass only KeyPress events to XmbLookupString,
XwcLookupString and Xutf8LookupString. Their behavior when a
client passes a KeyRelease event is undefined.
}}}
Yeah, Xlib is quite stupid and this makes no sense.
As this just happens for UP events, it was unnoticed for a long time
(19 months) as most apps just handle DOWN events, as it gets X
keyboard repetition and all.
Thanks to Otavio Pontes that spotted this bug while doing some code
for EPhoto (that for some weird reason uses UP instead of DOWN
events).
SVN revision: 52786
Please review it. i don't have the courage to read
everything again
It should compile on linux (committed from windows, but
corrected at the same time on linux. Thank you, VirtualBox
devs !)
SVN revision: 52784
Essentially the problem is this: For drag and drop Ecore currently handles the
position update calls. But usually the application wants to display some user
feedback - a window to display the drag selection for instance.
Now the way e17 does it is grab the mouse cursor movements and track them
itself. However ecore is already doing this, it's already walking window
trees, calculating real positions, _and_ sending them in an X client message.
So it seems rather silly to duplicate the code in the user app to get the same
info.
We could possibly have added a new event, but then we need to deal the fact
the position update may arrive _After_ the item has been dropped. Hilarity
ensures[1].
This callback is meant for purely the selection owner of the drag to use, so
it is a callback set, not an add.
[1] Segfaults probably. Nothing funnier.
SVN revision: 52181
Apply badzero.cocci, badnull.coci and badnull2.cocci
This should convert all cases where there's a comparison to NULL to simpler
forms. This patch applies the following transformations:
code before patch ||code after patch
===============================================================
return a == NULL; return !a;
return a != NULL; return !!a;
func(a == NULL); func(!a);
func(a != NULL); func(!!a);
b = a == NULL; b = !a;
b = a != NULL; b = !!a;
b = a == NULL ? c : d; b = !a ? c : d;
b = a != NULL ? c : d; b = a ? c : d;
other cases:
a == NULL !a
a != NULL a
SVN revision: 51487