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