On Wed, 16 Jul 2014 14:56:23 -0400 Chris Michael <devilho...@comcast.net> said:
> Hello devs :) > > There was a brief discussion on IRC today regarding using libinput (of > wayland fame) for other input related things in EFL (aside from drm). > Cedric mentioned that it could be used for fb and various other > engines/platforms. This would allow us to unify handling input devices > under one efl library. > > Ecore_Input seems the likely candidate to me....So I am writing to get > any additional comments/remarks (before going through the effort of > changing things). > > One thing that I have noticed in the current ecore_input code is the > namespacing seems wrong. The actual ecore_input codebase uses > ecore_event as the API namespace (ecore_event_init, etc, etc). This just > seems sooo wrong to me :( One thing I would like to do (open for > discussion), is to unify this into ecore_input_init, etc, etc to make > the API functions match the library namespace...However this would mean > depcreating the existing ecore_event_init APIs (yes, mark them as > deprecated, but internally just make the code call the newer > ecore_input_init, etc). > > Another thing we could do here is to bring in udev dependency and do > input device discovery :) This would unify things so that we don't > duplicate code (ecore_drm does this, ecore_fb could benefit from it, > etc, etc). > > Yet a third thing Could be to (compile time optional) bring in the > systemd deps from ecore_drm and have ecore_input handle opening > /dev/input devices and feeding those events. This would also unify and > reduce code duplication. > > Please bear in mind this is an RFC so nothing is concrete yet. I am just > trying to gather ideas/thoughts/concerns/comments, etc, etc Before I get > started on the work. > > Flame On ! yes ecore input does some evil things namespace-wise - thought tbh we have far too many libraries and namespaces for our own good. so let's not worry about that except in an efl 2.0 view - ie that ecore_input is merely an internal part of efl - not intended for consumption by the general development world and is "external" simply as a bi-product of many years of building layers on layers. as such any udev and systemd deps will need to be ifdefed internally - if not there, then fine - don't have them work. please have it abstracted enough to allow it to be filled in for other environments in the future (eg systemd/udev replaces by other thnigs), but for now - don't worry about making things work outside of systemd+udev (the udev rolled into systemd). it can be up to someone else to do the work of supporting ubuntu (upstart) or gentoo (with their separate udev and dont want systemd in core approach) etc. etc. - if systemd makes life easier - then support it. if that means wayland and efl support only works on systemd systems - so be it. it's the practical course and people who do not want to follow can do their own support work asnd submit patches. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
