Good points and good suggestions. I read twice. :-2 Here is my idea.
#1. Swallowed objects need to communicate with its parent Edje.Object -> communication between swallow object and parent edje object means both will have a dependency for something special on the other hand. This symptom looks bad to me. If edje object, A sends signals to swallowed object B, then this A and B sould be in a strong dependency and people cannot easily reuse nor fix them without whole understanding between them. This is totally different with group part. Because group A and parent edje object B has to be one edj. #2. Seperate EDC for customizable part of Elementary Widgets -> I don't see any disadvantage in your idea if it doesn't harm any performance or memory usage. But I'm worring if controls were too complex so each parts were organically connected each others. We could think this further, but right moment, a convenient tool is better idea than letting people manually customizing theme, I think. #3. Separate Elementary widgets' EDC into Function part and View Part -> I agreen on this idea. function and view parts should be divided. Problem is which parts are related with functions or not?Programs? We could hide some complex parts in customizing tools so people don't touch nor struggle with complex stuff when they customize them. You know, app developers usually change background, text(font), icon and color (.. also padding?) Basically, our widge theme should define those parts for customizing scenario by apps. In the meantime, Other parts and programs should be invisible to users. I think theme customizing tool can help this also. Or we could divide a theme resource into 2 parts - A(customizable basic parts), B(complex advanced parts). A will be consisted of background, text, icons... and the other ones in B. #4. Make (almost) all Elm.Widget inherits from Elm.Layout -> Those box, table, grid are is non-visiual objects containers. I don't think container should not support visuals. I partially agreen with you, but I'm not sure how many scenarios requires setting bg to the containers. We have a bg widget. //Same this. Evas_Object *bg = elm_bg_add(); elm_bg_file_set(bg, "xxx.png"); Evas_Object *table = elm_table_add(); elm_object_content_set(bg, table); #5. Edje Externals? I haven't thought this further. . Here problem is nature of edc is too unfamiliar and unnecessarily complex to use. Compare one example to set button label text. 1. "label": "Back"; // json 2. label="Back"; // xml 3. params.string: "label" "Back"; //edc I belive we could improve this in the next edc generation. -----Original Message----- From: "Conrad Um"<con...@gmail.com> To: "Enlightenment developer list"<enlightenment-devel@lists.sourceforge.net>; Cc: Sent: 2016-02-12 (금) 16:00:49 Subject: [E-devel] Suggestions for improving usability of Edje and Elementary #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 ------------------------------------------------------------------------------ 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
