On Tue, 10 Apr 2007 13:02:56 +0200 Cedric BAIL <[EMAIL PROTECTED]> babbled:
> 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.
in x, when you get a key repeat, you simply get a key up event then another key
down. you actually can't tell its a key repeat event at all. so in x you won't
be able to flag a repeated key 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.
>
> 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;
> };
and this is meant to cover keyboards as well? i think this isn't THAT useful
without many more extensions like:
int buttons;
int axes;
etc.
i think we may be going a bit too far in trying to generalise all devices as a
series of properties in a single device framework.
> 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
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
