On Wed, Apr 12, 2017 at 10:22 PM, Viacheslav Reutskiy <reutskiy....@gmail.com> wrote: > 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?
Not exactly. The widget that use eolian have all there properties properly described inside the .eo. This properties are what external widget param should be able to set. My idea is to just read the .eo during efl compilation and generate the edje external that goes with every widget following what the .eo contains. Basically making edje external elementary widget always up to date and 100% feature complete. -- 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
