I agree with this all, especially the capitalisation - we need to focus more on consistency. Primary approach should be to provide the path of least surprise for new devs (whilst maintaining the efl way :))
Andy On Thu, 10 Mar 2016 at 17:40, Tom Hacohen <t...@osg.samsung.com> wrote: > On 09/03/16 06:39, Carsten Haitzler wrote: > > On Tue, 08 Mar 2016 18:14:42 +0200 Yakov Goldberg <yako...@samsung.com> > said: > > > >> Hello everyone, > >> I had discussions with Tom and as a result updated wiki page. > >> > >> You can find it here: > >> https://phab.enlightenment.org/w/ui_builders_format/ > >> > >> > >> Most things are clear there are several questions to be discussed: > >> > >> * fixed indentation (4 spaces) or not fixed > > > > i personally think 2 spaces is fine. 4 is just "too much". the reason is > most > > monospace fonts are taller than they are wide so "2" ends up a nice > diagonal > > like: > > > > \ > > \ > > \ > > > > but well more actual 45 degrees. :) > > You call it a nice diagonal, I call it too compact. I don't think this > argument holds any water because it's never really a nice 45, it's more > like: > > \ > | > | > \ > | > \ > | > | > \ > | > | > > So you don't really get any aesthetic benefits, and it's better to > optimise for readability not "prettiness" to support this argument I > bring forth exhibit A: http://www.perlmonks.org/?node_id=45213 > Pretty, but not useful. :) > > > > >> * Widget vs Elm.Widget: all widgets - are they Elm Widgets only and thus > >> "Elm" can be skipped or we want to use namespace > > > > yes. in fact we will skip elm in eo api. they'll be efl.ui.xxxx - you > want the > > ability to strip the efl.ui bit away though so people are not writing > > > > Efl.Ui.Button (...) > > > > as opposed to: > > > > Button (...) > > > > which is what they should > > I say that as a rule it should be Efl.Ui.Button, but as a special case > we allow dropping "Efl.Ui". So "Terminology.Ui.Foo" will have to use the > full namespace, but for example "Efl.Ui.Button" could be called either > like that or without the namespace." > > > > >> * button vs Button: starts with capital letter? > > > > i prefer smalls... i don't see the value of forcing people to hit an > extra > > shift when it provides no extra syntatic/semantic value. > > I'd say capitalised if only to be consistent with Eolian. I don't think > it's that much trouble hitting "shift" compared to the readability and > consistency benefits. > > > > > if you supported variables for example then it may be useful to > differentiate > > object types/constructors as "Button" vs a variable which might be > "button", > > but then this begins to become a programming language. > > Please, no. > > > > > actually you MAY need to support this. edje_cc supports basic math like: > > > > (2+3)/8 > > > > it'll evaluate as edje_cc goes - this is REALLY helpful in making your > stuff > > readable as you can actually give fractions like 2/3 as opposed to > > 0.66666666666666666 :) since edje_cc also supports cpp this effectively > allows > > for variable substitution with math.. > > > > of course loading a file into a gui editor and writing it back out may > lose > > this math magic so it'd only be useful for purely "hand edited" stuff... > > I'm against that. with loss of precision you get visual artefacts. To > take your example, using: 1/3, 1/3 and 1/3 would lead to 0.33 all > around, which is maybe not a big deal when doing weights (because we > deal with it), when doing things that should fill the area (like > percentage or pixels) would cause a missing pixel. It's better to be > explicit and let the user know that 0.33 * 3 is not 100 and they'll deal > with it on their own. Especially for a simplistic UI language that > should be easy and noob friendly. > > > > >> * callbacks format - options: > >> Button() > >> on clicked("callback_name") > >> on("clicked", "callback_name") > > > > the first one... :) > > > >> #and whether allow or not property modification and object > creations in > >> #callbacks: > >> on("clicked", "callback_name", box_1.visible = true, #and more > ui > >> updates) on clicked,double(box_1.visible = true) > >> on clicked,double(create ("window_2", null)) > > > > oh this is where things go bad - this begins to look like code where you > can > > define "properties and objects to modify". > > > > :( i would say "no". be VERY careful walking down this path. it's a > slippery > > slope into a programming language. > > Agreed. I told him *NO*. > > > > >> * snippets support - please read in wiki > >> https://phab.enlightenment.org/w/ui_builders_format/#snippets > > > > beginning to look good i think. i dont have any objections. :) > > For consistency I'd do something like (editing the example from the page): > snippet["mbox"](id="mybox1", self.but1.text) > > Especially note the squared brackets and the use of "self" instead of > the id. > > Though again, this is a later stage thing. > > -- > Tom. > > > > >> > >> Regards > >> Yakov > >> > >> > >> > ------------------------------------------------------------------------------ > >> Transform Data into Opportunity. > >> Accelerate data analysis in your applications with > >> Intel Data Analytics Acceleration Library. > >> Click to learn more. > >> http://makebettercode.com/inteldaal-eval > >> _______________________________________________ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > > > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
