On 04/13/17 00:23, Cedric BAIL wrote: > On Wed, Apr 12, 2017 at 1:36 AM, Viacheslav Reutskiy > <reutskiy....@gmail.com> wrote: >> On 04/11/17 01:12, Cedric BAIL wrote: >>> 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. >> I have one more idea about layouts. We can use edje-external feature for >> create a simple layout with elementary widgets. This will provide the >> flow which developers already know, it means write a simple layout with >> edc. Edje external provide some API for get elementary widget from layout >> and can set same attributes, but this API is poor. If we can extend edje- >> external API for set more widget attributes, it's can avoid to make one >> more language for GUI layouts. Also, support External parts can be implement >> in eflete, in this case we have functionality for create a layouts/frame, >> and tool for it. Animations and flexibility already here, because it's edc. >> One more things, this flow can help to separate designer and developer work. >> Developer and designer can use conventions about controls naming in layout, >> that help to work with business logic and GUI separately. > Ok, I think this point has been brought in with enough argument from > you and Gustavo. There is real benefit into supporting external > properly. I think that with eolian we should have a way easier time > than before. I believe, but haven't tried anything, that we can > automatically generate an external for every .eo widget with zero code > being written, documentation included. All the object property would > become an edje external property (We would exclude every @beta one as > we want stable theme). This should lower the maintenance and make sure > it is up to date. > > I am guessing that from eflete point of view, the API for externals in > Edje_Edit.h is enough ?
Edje_Edit already have API for work with the external part params, but need to check does it work properly. I mean 'external_*widget*_param_set' API's. These API need to review and need to a list of params that already supported, and another list - what params need to add. Actually I can not do that now, but I can schedule this task to next week. Please correct me if I'm wrong - You propose to include edje_external API to elementary API? > >> Also, if told about theme and styles, need to decide what to do with embryo >> scripts in 'group' programs. Because now it's problem. Problem to support it, >> almost always what script do does not clear. And script make style more >> difficult for understand, what very important for newcomers. Another problem >> it's script API, it's still beta. As for me need to update styles, and refuse >> to use script in the styles, by one thing - it make styles for clearly, clear >> edc code, clear to understand. Generally scripts used in style only for use >> 'if' statement, but this functionality provide attribute 'filter'. > I agree with you embryo script are not easy at all to write, read and > understand. We have tried to add more logic to edje so that a lot of > this embryo script can be avoided, but still at the end, it isn't > entirely avoidable. Maybe having lua as an alternate to embryo would > work. Right now Lua is just for writing full part, I guess it could > used for this too if that help. > -- Viacheslav Reutskiy (rimmed) ------------------------------------------------------------------------------ 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
