On Tue, 10 Apr 2007 01:13:16 +0200 "Jorge Luis Zapata Muga"
<[EMAIL PROTECTED]> babbled:
> 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.
that is an interesting point - though for now - i'll disagree. from a purely
technical view this sounds good - you break a device down into its elements -
i.e. - what KIND of input does it provide, BUT now what you do is move the
interpreting of a set of such properties up to the applications. if an app
wants to know if this was a mouse event or not it has to guess if something is
a mouse or not based on properties - and if 2 devices have similar properties
it might not know which is which.
in my opinion we have probably seen most of the interesting input devices to
come out already. any other new devices likely will just emulate an existing
one (mouse, keyboard etc.). think of the extreme - the ps3 controller as best i
know has like 10 bits of accuracy per control (per button, knob, dial, trigger
etc.) so you literally can get 10 bits of "pressure" or position. so the
controller just looks like a bit set of analogue controls - but you really
don't want to make it "control1, control2, control3" etc. with some number as
each control has a name or use - it's a trigger, button, tilt etc. you want to
interpret this at a higher level then provide it to apps. something like the
wiimote would simply be an absolute position "mouse" with 6 or 7 buttons (not
sure how many it actually has). probably with extra events to also send in the
tilt/angle and rotation as it changes (the mouse events being emulated for
on-screen positioning of some cursor and the angle/tilt events for use when you
are not pointing at something on the screen)
> >
> > > 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
> >
>
--
------------- 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
