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 ! > > > 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
