Hello, Sorry, I have been on holliday last week and couldn't answer your email properly.
On Sat, Jul 8, 2017 at 3:09 PM, Andrew Williams <[email protected]> wrote: > 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. The problem with design document is that they become obsolete as the devil is hiding in the details. We have switched now to use phab task to discuss every point in a more detail manner. It is possible to track all of that starting from the monster ticket : https://phab.enlightenment.org/T5301 . I agree that in the general sense we could today likely rewrite a design document starting from where we are today in our work on efl interface. It would be a little bit after the fact, but could be helpful. A lot of the design result from two main constraint, nice to use in C and easy to expose in bindings. This is usually quite a problem as binding have a lot of nice feature that you don't even get close to in C. > On Tue, 4 Jul 2017 at 15:12 Andrew Williams <[email protected]> wrote: >> 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? One of the split we have done is try to keep in Eina and out of Eo/Efl interface all data type that any bindings already support natively. Bindings then do provide a layer that make Eina type matches the binding native type. >> 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. Current design for this kind of problematic is to use a Mixin class. Mixin allow to extend behavior on top of existing class and carry that same code to many object that do have some common interface. For the example of text, we do have a text.set API and a markup API. There will be a markedup.set API that will take the a string with marked up string in it, parse it and call the text.set and all the markup API correctly on that object. On the MVVM side you would just connect the markedup property instead of the text one if that is what you want to achieve. It also means that if we consume to much drugs and support CSS styles for examples, we can add a new mixin to set CSS style on our objects with little code duplication. Ideally this kind of extention could be implemented by an application. They would inherit from an object, add there own format (For example a RTF support), override the connect method to handle this new property and it will then be possible to use it with any data model. Gustavo is advocating for the possibility to do runtime edje external which would enhance the complete idea by allowing application to enable the use of that new object in edje and any view. This is just one of the thing we are trying to achieve here. >> 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! Sadly there isn't. Will try to workout something here as I guess it would be quite neat. -- Cedric BAIL ------------------------------------------------------------------------------ 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
