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.
> 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?
> Cedric
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-------------------------------------------------------------------------
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
