Hello everyone, So there is an ongoing thread about what to do after we are done making EFL easier to use... but I guess it would be nice to share a bit of what we think it means and what we plan for this year. There is a meta ticket to track all of that : https://phab.enlightenment.org/T5301 , but let's discuss a bit more the global goal here.
So for a year now we have been working on a new set of API for EFL, in the idea of first refactoring our API and if possible making it easier. This year, we are going to try focusing on making it easier to use. But first, what does that means and for whom is it going to be easier. EFL has a lot of different developers with different needs and goal using it. Here are my take on it, please if you do have other opinion on this, share now ! It is the right time. - The community/open source developers which has coallesced around Enlightenment, Terminology and EFL over the year. Trying to get something that look neat, is fast and that they enjoy working on. If they stop having fun with EFL, they will move to something else. I think that making it easy for them here, is quite different from other category. There is little designer involved in the community per application, but some are trying to provide coherent theme globally. Everyone have there language of choice and won't have fun being forced on something else. They want to get usable nice looking result quick. Ideally something that integrate together nicely. Most of the developers would like a more direct link to developers to push there application. - Embedded device developers, they usually write a single EFL application that take over the entire screen. It is usually designed by a professional and performance matters. They would like to spend less time writing the UI part and mostly focus on the business part of there application. Also they would like to have better confidance in updating EFL. - Application developers, in the branded proprietary sense of the term. This people usually try to replicate the same visual feeling accross different platform. They usually have little time and money to learn anything on the platform and expect something very close to what Android, iOS and Microsoft provide. The first point here, is that we want to address the need of this 3 differents population. It is obvious from this description that Edje isn't an answer for everyone. For the community Edje is kind of ok, but writing a theme is way to complex, time consuming and lack of documentation on what needs to be provided. For embedded target, as Gustavo describe it, it does the job quite fine. Finally for application developers, it doesn't work at all. Does way to much for there needs and is way to different from what they know. To address this, we have come up with a serie of idea. The first thing is that we should have a small set of defined style that have a defined API (text part, message, signals). As each style is linked with an elementary widget, the idea is to add a style section to .eo file that provide the needed description and would generate a C function dedicated to that style. There is a ticket for this at https://phab.enlightenment.org/T5307 that will track the discussion on how to do so. This should help the community by documenting a minimal theme. To further help application developers, we are going to add more use of efl part and also document it's use per elementary widget. Basically a button would have a background part (accessible with efl_part(button, "bg")) that return a class that allow to directly modify a few aspect of the theme like color and background picture. This helper class will be available accross as many widget as possible to make it easier to do simple branded apllication like other platform provide. There is again a few ticket following this task, the main one to discuss this idea would be https://phab.enlightenment.org/T5306 . Another helper we are going to provide to application developers is an animation framework. Something kind of like efx, but with Eo classes basically (The ticket is there https://phab.enlightenment.org/T5337). Finally something that we are not addressing yet, but would I think make sense, is some way to describe simple layout (Like Android XML file or Microsoft XAML). With Eo property it becomes quite easy to automatically generate code for this. For embedded developers, we do still have idea coming into edje to improve its usability. One of the main idea is to introduce vector graphic support (With limited SVG and maybe Android VG format importer). The second idea that will also benefit for everyone is to finally introduce a modern MVC framework. We have been iterating over a MVC design for more than a year now. I think we are nearing a design that start to look good. The funny part is when I was trying to find some presentation to explain people about MVC and the difference with what we were doing, I stumble on Microsoft MVVM design pattern which is pretty close to the design we have selected. So we will rename the work we have done from ProxyModel to ViewModel to use the same naming convention as everyone else. The main difference between MVC and MVVM is that it allow the definition of a clean interface between View and Model. There isn't really a ProxyModel or ViewModel interface, as they really are just a Model that get data from another Model and interpret them into what the View will actually display. This means you can easily reuse Model and that you can test your Proxy/ViewModel without connecting it to an actual View. And last very nice benefit, I think, is that you are defining a "connection" for each parameter of your widget. So to connect a View with a Model, you are only setting the model and indicating which property to fetch on the model. No need to deal with callback in many case ! For an example (which is broken at the moment) of the idea you can look at layout_model_connect.c in efl elementary example. The most complex work will now be in writing this Proxy or View Model. This is something we have to work on to make it easier. Most likely, we have to make creation and manipulation of Eina_Value together with Promise/Futur easier (And obviously Promise/Futur need to be finally fixed, there is a ticket for this https://phab.enlightenment.org/T5310). There are like 3 or more different ticket related to MVVM in the top ticket, not to sure where any discussion should happen, so maybe here is best. Finally we are going to reduce the amount of widget we do support (This should help people writing theme) and focus on a more useful set of them (Merging feature when it makes sense and so on). There is way too much ticket for this discussion, but they are all under that top ticket. If there is anything specific to discuss, it should be on those ticket, otherwise here. There is a lot of work. Really. It is huge ! Also as pointed out in other thread, until we try this new API, we won't know if we have achieved the goal we have in mind. So as we roll this new API in, just trying to use them in a branch and giving feedback will help. Have fun ! -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
