#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. 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) #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? 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) 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.) #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. #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. #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. 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 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. Best regards, conr2d ------------------------------------------------------------------------------ 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
