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
