On Thu, 10 Mar 2016 17:39:58 +0000 Tom Hacohen <t...@osg.samsung.com> said:
> 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. :) i find the diagonal more readable. in fact the more you indent, the more you go over 80 columns and have to horiz scroll or wrap or be forced to make very wide windows ... so the less indenting - the MORE usable because it creates LESS side-effects. the more something indents the more the eye has to scan along to find the next line start and that is a cost. i'm not discussing pretty as in "it looks like a nice image". i'm discussing that it looks nicer from the point of view of someone editing text and being able to follow the flow, avoid excess wrapping/scrolling etc. > > > >> * 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
