On Tuesday 10 April 2007 01:13:16 Jorge Luis Zapata Muga wrote:
> On 4/7/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote:
> > On Wed, 21 Mar 2007 17:45:43 +0100 Cedric BAIL <[EMAIL PROTECTED]>
> > babbled:
> >
> > i'll do this one first - it's less work than the sdl engine + cache +....
> > one :)
:)
> > > Another discussion, this time about events. During my test of SDL
> > > engine, I did like the key repeat functionnality of SDL, but it wasn't
> > > possible to easily expose it to evas. So I just added a
> > > EVAS_CALLBACK_KEY_REPEAT with the corresponding
> > > 'evas_event_feed_key_repeat'. It seems quite logic and work. See
> > > evas_key_repeat.diff.
> > hmmm- is the point of this to send a key repeat event diferently to a
> > normal keydown/up - the reason i never had this is basically from the
> > hardware or x point of view - it's just more key down/up events. key
> > repeat is done by the keyboard controller - or if not inside x itself. x
> > apps dont know it's a repeat event.
Yes, it's basically more keydown event (no up corresponding to the repeat
event). I tested sdl key repeat, and fowarded them, just like keydown. In
some case, I started to put code in the keydown event just to know if it was
a repeat (basically testing a boolean, if a previous keydown event occur and
without keyup). Looking at the result, I just think evas could send me
directly the right even, removing the need to handle the special keydown in
apps, but just in Ecore.
I don't know how X handle it, and taking a look at how SDL does the job
when
running in X didn't look really obvious to me.
> > > I don't know what is the policy for adding new events, but SDL
> > > could also expose some Joystick events:
> > > SDL_JoyAxisEvent -- Joystick axis motion event structure
> > > SDL_JoyButtonEvent -- Joystick button event structure
> > > SDL_JoyHatEvent -- Joystick hat position change event structure
> > > SDL_JoyBallEvent -- Joystick trackball motion event structure
> > > Would people object if I come up with some evas event for this also ?
> > > This would be nice, if an Ecore SDL was able to directly feed them to
> > > evas. But I will understand that it's not the primary usage/goal of
> > > evas.
> >
> > i wouldn't object at all. the evas events are intended to be extended and
> > become a superset of whatever input devices exist. if it makes sens to
> > re-use existing systems (key events or mouse) then use them (eg remote
> > controls imho should be key events). one thing i think i do need to do is
> > exten evas and ecore etc. events to allow for multiple mice and keyboards
> > so you can tell which one is which. this of course means an abi break -
> > add members to structs, but thats why we are still at 0.x :) so summary -
> > yes. adding these is perfectly fine.
> >
> > > On the same subject, it would also be nice if we could handle
> > > multiple device easily in evas. From what I see, the only thing that is
> > > needed is a 'char* device' in all struct _Evas_Event and breaking all
> > > evas_event_feed functions prototype by adding a device parameter. The
> > > device could be set to NULL, so all existing code will still work with
> > > very few modification (mainly in ecore).
> > > Would people be interested/object to this kind of patch ?
> >
> > yes - definitely. i think you need to actually do 2 things. you need to
> > add an typedef enum _Evas_Device_Class {
> > EVAS_DEVICE_CLASS_MOUSE,
> > EVAS_DEVICE_CLASS_KEYBOARD,
> > /* Extend as needed */
> > } Evas_Device_Class;
> > typedef struct _Evas_Device Evas_Device;
> >
> > struct _Evas_Device {
> > int version; /* starting version 1 */
> > int num; /* device number - guaranteed to always be there. the "default"
> > device is 0, but extra devices may be 1, 2, 3 etc. this is unique with
> > the device class so the first mouse is device 0, the 2nd is device 1. the
> > first keyboard is device 0, the second is device 1 etc. */
> > Evas_Device_Class clas; /* The class of device - EVAS_DEVICE_CLASS_MOUSE,
> > EVAS_DEVICE_CLASS_KEYBOARD etc. */
> > const char *name; /* This may not exist - or
> > may be synthesized. this only lets you get a better idea of the device
> > (eg "Logitech Mouse" or "Microsoft Keyboard
> > - Natural Media" etc.) */
> > /* NB: This structure may be extended in the future - version will
> > indicate how much it has extended */
> > };
> >
> > then every event in evas that comes FROM a device add a
> >
> > const Evas_Device *dev;
> >
> > to the structure - this way in future we can extend the meaning of a
> > device without breaking event structs. (same with event feed calls)
> >
> > of course we will need ways to add and delete devices from evas in
> > general and modify them, list them etc.
> >
> > i.e.
> >
> > Evas_Device *evas_device_add(void);
> > void evas_device_del(Evas_Device *dev);
> > const Evas_List *evas_device_list(void);
> > void evas_device_class_set(Evas_Device *dev, Evas_Device_Class clas);
> > void evas_device_name_set(Evas_Device *dev, const char *name);
> >
> > etc.
> >
> > it would be ecore_evas's job to init evas with at least basic devices
> > (mouse, keyboard - you can add joystick etc. to this too).
> >
> > sound useful?
> Sounds very similar to what i did to ecore_fb a while ago, indeed very
> usefull. Just one thing, instead of defining the device classes as
> "device types" (keyboard, joystick, mouse, touchpad, touchscreen, etc)
> wouldnt be better to define them as "device capabilities"
> (absolute/relative axes, buttons/keys, etc) so a keyboard has only
> capabilities of button/keys, a mouse has relative axes, a touchscreen
> absolute axes, and so on ... ? In case of a special device it just
> need to "or" the different capabilities it has.
Hmmm, I don't know how we can use this extra bit of information. The
evas_event_feed_mouse_move and evas_event_feed_mouse_wheel will need to be
merged in that case (not saying we will need to handle the long list of
others defined relative/absolute axes from the Linux kernel). Computing move
and wheel event from inside evas sound strange to me.
I would rather define 3 class :
#define EVAS_DEVICE_CLASS_KEYS 0x1
#define EVAS_DEVICE_CLASS_MOTION 0x2
#define EVAS_DEVICE_CLASS_WHEEL 0x4
Changing the struct _Evas_Device to :
struct _Evas_Device {
int version; /* Already version 2 ;) */
int number; /* Unique number given by evas. */
/* A bitmask of the different class. */
int class;
/* Number of "motion" plane. */
int motions;
/* Number of wheel. */
int wheels;
/* Could be NULL, synthetized or provided during initialization, just
to give
a better idea of the device. */
const char* name;
};
The functions initializing this structure are almost the same :
Evas_Device *evas_device_add(void);
void evas_device_del(Evas_Device *dev);
const Evas_List *evas_device_list(void);
void evas_device_class_set(Evas_Device *dev, int class, int motions,
int
wheels);
void evas_device_name_set(Evas_Device *dev, const char *name);
But feeding event will need some change:
void evas_event_feed_motion(Evas *e, int x, int y, unsigned int
timestamp,
const Evas_Device *device, int plane, const void *data);
void evas_event_feed_wheel(Evas *e, int z, unsigned int timestamp,
const
Evas_Device *device, int index, const void *data);
The others should look the same:
void evas_event_feed_mouse_in(Evas *e, unsigned int timestamp, const
Evas_Device *device, const void *data);
void evas_event_feed_mouse_out(Evas *e, unsigned int timestamp, const
Evas_Device *device, const void *data);
void evas_event_feed_key_down(Evas *e, const char *keyname, const char
*key,
const char *string, const char *compose, unsigned int timestamp, const
Evas_Device *device, const void *data);
void evas_event_feed_key_up(Evas *e, const char *keyname, const char
*key,
const char *string, const char *compose, unsigned int timestamp, const
Evas_Device *device, const void *data);
What do you think about this proposition ?
Cedric
PS: Sorry for the previous mail, with huge line, don't know what my mailer was
thinking...
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
