I guess no-one is biting on this which is a shame. There is one key question that I would like to get the answer to, however:
What is the closest to a design document that we have for the EFL Interfaces? The document https://phab.enlightenment.org/w/efl_interfaces/ seems like a good start but that's nearly 3 years old now. I'd like to see how we're trying to keep on top of the growing list of requirements or design decisions and how we are keeping all the APIs consistent as we head toward a first version. Thanks, Andy On Tue, 4 Jul 2017 at 15:12 Andrew Williams <[email protected]> wrote: > 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 > -- 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
