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.
>
> > 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.
>
> > 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
>
-------------------------------------------------------------------------
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
