On Fri, 12 Feb 2016 16:00:49 +0900 Conrad Um <con...@gmail.com> said:
> #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. actually it was implemented this way PARTLY because the child can be anything, but also because of sandboxing. an edc (edje file result) can talk to itself all it likes, but when it hits a boundary it doesn't control - then any information (signals/messages) have to be explicitly forwarded. > 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) so what kind of communication exactly? signals? messages? how do you specify which messages and which signals should be forward to a parent or toa child and to WHICH child? this all reminds me of all the discussions we had about bob :) > #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) do you have more details on how you split this up? also note - this lets you modify a theme but it doesn't help at runtime when you ant to inherit whatever the default system theme is and just change the alignment of text. :) this leads to the whole complexity of inherit + modify. inheriting basically means everything you see (and can touch.modify) is STANDARD and will always be there with those names and that state. thats hard a as tom said - we change these details all the time. only some fairly broad/simple things are standard like a swallow part name, or a text part that has to be therr to accept a text label etc. again - reminds me of talk of bob where we were looking at standardizing property sets for any object and this set of exposed properties is the objects "interface" and that is then very well standardized and exposed. if we wanted alignment to be configurable it would simply have to be a property that is exposed. :) then the actual implementation is hidden and can change, as long as the properties are supported and used "as expected". > 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. a bunch of guys in the ukrain (ask nika) proposed there being an object template/spec and validator that would basically solve this. it would efine what parts need to exist (and their types) and what signals etc. need to be handled (and what they do). this would provide something that could then logically produce a template edc blob for you that meets the specs (and you fill it in as you desire). > #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. edje's box and table support are far more primitve than elm. we'de have to do far better. again - reminds me of bob. > #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. i did. and i think you need to be introduced to bob. the real issue is that no one has had time to begin on bob. q66 has been putting together bits and pieces that will allow bob to be created, but no one has started yet. so we can either just keep messing with edje and massaging it, or we can build something clean that solves all of the above (and more). that was what bob was intended for. > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
