On Fri, Feb 12, 2016 at 6:26 PM, Davide Andreoli <d...@gurumeditation.it> wrote:
> 2016-02-12 18:14 GMT+01:00 Cedric BAIL <cedric.b...@free.fr>: > > > Hello, > > > > Good to see someone investing serious time in Edje ! > > > > On Fri, Feb 12, 2016 at 8:00 AM, Conrad Um <con...@gmail.com> wrote: > > > #1. Swallowed objects need to communicate with its parent Edje.Object > > > > > > In EDC syntax, there are several useful features to provide flexible > way > > to > > > construct edje object. > > > For example, for part type "GROUP", edje can send signal or make an > alias > > > name for group's sub part. However, group part is a fixed one that > should > > > be defined before compile, it is not changeable at runtime like swallow > > > part. > > > > > > I don't know the history or design exactly, but I assume that > > communication > > > between swallowed object and parent edje object is not implemented > > because > > > swallowed part can accept any evas object which is not edje object. > > > However, we can check swallowed object class type with eo_isa(obj, > > > EDJE_OBJECT_CLASS), so allowing swallowed object to communicate with > > parent > > > edje object is not dangerous. > > > > There is also sandboxing issue at play. The theme designer as no idea > > what is the object it got in a swallow, this could lead potentially to > > unusable scenario. I do think it would be best if we do only enable > > this kind of behavior with edje external as they are explicitely > > requested to interact by the theme itself. Arguably, we could have a > > new boolean that enable that behavior and let the theme designer take > > their bet. > > > > > Moreover, this communication should be allowed for Elm.Layout also. > > > Elm.Layout is a wrapper of Edje.Object, but it doesn't inherits from > > > Edje.Object, so many useful edje features don't work for it. I think > that > > > it seems good that when swallowed object's class is not > > EDJE_OBJECT_CLASS, > > > edje checks "key" data or something to get eo id of Edje.Object. (like > > > internal Edje.Object of Elm.Layout) > > > > That is a completely different discussion ! So part of the work I am > > doing on cleaning up our EFL Eo interface, there is something to be > > done with Elm.Layout and Edje.Object who should really be seen as a > > same Efl.Widgets.Layout. My current idea, taking Eo limitation into > > consideration, would be to have an Efl.Gfx.Layout that expose all the > > interface an Edje object is going to publicly follow. Make Edje become > > Efl.Canvas.Layout and Elm.Layout become Efl.Widgets.Layout with both > > of them inheriting from Efl.Gfx.Layout and Efl.Widgets.Layout using a > > composite to automatically map all its function to its internal > > Efl.Canvas.Layout object. This way you should be able to use an > > Efl.Widgets.Layout like you would use an Efl.Canvas.Layout. > > > > Just to sumurize the proposal for Efl interface here (I know, I am > > kind of diverting the discussion and should start a thread just on > > that topic, but I am not ready yet, so...) : > > Efl.Gfx -> Global interface for all common graphical class > > Efl.Canvas -> Raw canvas objects with no integration with the system > > Efl.Widgets -> Widgets objects that integrate to each other, handle > > theming, scaling, ... > > > > > #2. Seperate EDC for customizable part of Elementary Widgets > > > > > > As a matter of fact, this idea comes from customizing Elementary > widget. > > I > > > tried making a dropdown menu with hoversel. I wanted hoversel to have a > > > fixed size, so swallowed it in layout's swallow part which has min > size. > > > Then I found that hoversel's items' text are aligned to the left, but > > > hoversel's text is center-aligned, so it seems not arranged well. > > > > > > I just wanted change alignment of hoversel text, but I should write > whole > > > EDC for hoversel. It's too wasteful, and will become very very Big > > obstacle > > > for novice developers. > > > What about splitting default theme into main EDC and customizable parts > > EDC? > > > > I don't think we really need to split anything. What if we just add > > the possibility to inherit from an external theme ? > > > > You mean the ability for a custom theme to inherit from a compiled edj? so > for example my app theme can inherit from the default theme and just change > a > single part in a specific group? this would be AMAZING and extremely useful > ! > > Unfortunately that can never happen. The problem is that the theme is full of smaller parts that are not part of the theme api. They can change at the theme maker's will. This is not theoretical, this is already the case with our existing themes. > > > > > > > For example, Elm.Button can have EDCs like the next: > > > "elm/button/base/default"; > > > "elm/button/bg/default"; > > > "elm/button/label/default"; > > > > > > "elm/button/label/default" group has only one text part to define > > button's > > > label area. I made a prototype and succeed in making a various buttons > > with > > > simple EDC groups. (text min size, ellipsis, alignment, etc) > > > > Where you using inherit for that ? Or class ? > > > > The main issue with this proposal is that it makes clear that our > > theme become a very strong part of our ABI. There was the beginning of > > a work to mark some part of our theme as ABI and have a tool checking > > it. It is clear that with the direction you are proposing, we need a > > tool to extract the ABI of an existing theme and check it against a > > new one (Or maybe against an online one). We also need to make sure > > that when we do inherit from an external theme, the group and part we > > are modifying are actually marked as ABI or that would get broken at > > some point. > > > > Also there is 2 levels of ABI now with this. One is the inherit ABI > > from the new theme point of view and the other one is the ABI theme > > from point of view of elementary. Both of which should already be > > something we care about, but we have been quite bad in the past at it, > > breaking it regularly. It would be best to have tool that enforce that > > to make sure application don't get screwed after an update. > > > > > If there is a simple way to set the string which indicates Elm.Button's > > > label group and Elementary makes a layout with that group and swallowed > > > label group automatically, it will not a hard work, but give big > > > flexibility to developers. (Making layout, Setting edje group, > Swallowing > > > object ... or something should be automated, or it will cause another > > > complains about difficulty of EFL.) > > > However, to implement this, #1 feature should be made first. Because > > label > > > group is a swallowed object of Elm.Button's edje, so we should pass > > > elm_layout_text_set() to internal swallowed label group. (alias can be > > > used) Also signals should be passed, because text part of label group > > > changes its state by button's signal.) > > > > Your last point is not to clear to me. Could you try to explain it > > differently maybe ? > > > > > #3. Separate Elementary widgets' EDC into Function part and View Part > > > > > > This idea can be connected to #2 or be independent. > > > > > > Elementary widgets' edc files communicate with C code too much. (by > > sending > > > message, emitting signal etc.). > > > At this moment, it's impossible to modify widget's view without writing > > own > > > EDC, but developers who want customize EDC should know C code totally. > > > (When, which signal is emitted for which purpose blah blah....) > > > This is a conceptual idea, but if view parts can be divided from > function > > > parts, developers can read edc more intuitively, and modify it easily. > > > > I am not to sure what you have in mind here, but EDC is by design > > declarativ. I don't see how much we can switch that to function. Also > > I dislike macro in Edje they tend to make things hard to understand. > > > > Wouldn't we address this issue by having external inherit with a > > defined ABI and some example/tutorial ? > > > > > #4. Make (almost) all Elm.Widget inherits from Elm.Layout > > > > > > This idea is a little radical, why don't we make almost all widget > > inherits > > > from Elm.Layout. (I used "almost" because I don't know elementary > > > completely.) > > > For example, we can use edje box or table for Elm.Box or Elm.Table. The > > > advantage of doing this is that we can provide common way to set > > background > > > image or color even for box or table. I think that if box or table keep > > > their behavior same but change its internal object to edje object, they > > > will not break ABI. > > > > I agree with this proposal as it would make things more orthogonal and > > logical. Also the price to pay for using an intermediary Edje object > > shouldn't be that high, and if it is, we should optimize it ! > > > > This also means, that we need to move interface to Efl.Gfx.Box/Table > > and make an Efl.Canvas.Box/Table which inherit from them, but also > > Efl.Canvas.Layout should have an Efl.Gfx.Box/Table interface and same > > for Efl.Widgets.Box/Table. I am sure you get the pattern, but that's > > quite some work. > > > > > #5. Edje Externals? > > > > > > I found edje externals not long ago. In many cases, I can make > scalable > > > and well arranged beautiful layouts easily with edje externals of > > > elementary. > > > > The main issue with edje externals today is that most of the property > > are not binded in it correctly. I am waiting for us to be done with > > the efl interface reorganization, but once that done, we could start > > generating edje external object from Eo API. This would make them up > > to date, fully featured and permanently useful. > > > > > I have thought that EDC is difficult for novice EFL developers, and we > > > should allow more things with C code. Of course, that way is also > > > > I personnally disagree with the idea of moving to much things to C as > > it is a road that can end up breaking portability. Obviously done > > carefully, like the various edje class, it does help, but this is > > something to do very carefully. > > > > > necessary, but I have studied other frameworks, but they also have > their > > > own way to build their layout. (Qt which has good impression among > > > developers has QML syntax, but it is similar to our LazEDC. I don't > know > > > the exact history but if QML comes from QEdje, their similarity is > > > reasonable.) > > > > > > By improving external, and making an introduction level of using EDC (I > > > think #2 idea can be this one, firstly developers try making simple EDC > > > group for button label only, but finally they will be able to make a > > whole > > > EDC for one widget.), we can change the paradigm of developing > > application > > > with EFL. > > > > > > I don't know who will read this from the beginning to the end. lol > > > Thank you for your time to read this long email. > > > > I did ! And I think I can honestly say, you are third in line for the > > longest mail after onefang and raster... How old are you ? :-D > > > > Thanks for your interest in properly fixing Edje ! > > -- > > Cedric BAIL > > > > > > > ------------------------------------------------------------------------------ > > Site24x7 APM Insight: Get Deep Visibility into Application Performance > > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > > Monitor end-to-end web transactions and take corrective actions now > > Troubleshoot faster and improve end-user experience. Signup Now! > > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
