Hi all, This topic is something that has crossed my mind as I look at our current APIs and consider the big push to Eo stable. We have focussed so far on exposing the current APIs in an object oriented manner which is great for inheritance and standardising events etc and also powerful for generating bindings in object oriented languages.
What I am unsure about, however, is are we matching expectations from users of those languages when it comes to seperation of concerns, thin display layers and packaging data logic/behaviour with the related data types? Cedric's presentation about MVC was an inspiring introduction to what we can do to reduce writing a lot of ui code where the data really defines what should be displayed. However this does not necessarily solve how many APIs we have on our elm widgets (for example) which relate to data manipulation rather than display logic. Do we have an opportunity here to split these apart so that (taking text markup as an example) we could have e.g. String (especially important when binding to languages that understand ;) ) that provides insert/replace etc then MarkedUpString which provides additional markup handling. Both of these could be passed to, for example, entry as the text model so we can avoid exposing all the data related apis of widgets in the process. This would save a tonne of apis on the widgets and other graphical components. Is there a central document to the core types and design principles of our new API? I think it's going to be critical to the success of a compelling developer experience for efl going forward! Thanks for reading, Andy -- http://andywilliams.me http://ajwillia.ms ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
