[E-devel] UI syntax, letter 2
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
* Widget vs Elm.Widget: all widgets - are they Elm Widgets only and thus "Elm"
can be skipped or we want to use namespace
* button vs Button: starts with capital letter?
* callbacks format - options:
Button()
on clicked("callback_name")
on("clicked", "callback_name")
#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))
* snippets support - please read in wiki
https://phab.enlightenment.org/w/ui_builders_format/#snippets
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
Re: [E-devel] UI syntax, letter 2
Hey,
this is more of a question/feature request. Do you consider constraints
definition compatible to Cassowary[0] (Apple speak: auto-layout) yet?
An example of how such constraint definition could look like can be found in
the following DSL: https://github.com/s4cha/Stevia
Would be nice to have that considered (reserved keywords, etc.).
Cheers,
Leif
[0] http://www.cs.washington.edu/research/constraints/cassowary/
> Am 08.03.2016 um 17:14 schrieb Yakov Goldberg :
>
> 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
> * Widget vs Elm.Widget: all widgets - are they Elm Widgets only and thus
> "Elm" can be skipped or we want to use namespace
> * button vs Button: starts with capital letter?
> * callbacks format - options:
> Button()
> on clicked("callback_name")
> on("clicked", "callback_name")
>
> #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))
>
> * snippets support - please read in wiki
> https://phab.enlightenment.org/w/ui_builders_format/#snippets
>
>
> 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://makebettercode.com/inteldaal-eval
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] UI syntax, letter 2
On Tue, 08 Mar 2016 18:14:42 +0200 Yakov Goldberg 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. :)
> * 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. - 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
> * 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.
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.
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.6 :) 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...
> * 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.
> * 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. :)
>
> 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
>
--
- 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
Re: [E-devel] UI syntax, letter 2
On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman) wrote: > > * 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: Aren't you the guy that made 3 space indenting the standard around here? ;-P Though I agree, two spaces is what I prefer. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- 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
Re: [E-devel] UI syntax, letter 2
On Wed, 9 Mar 2016 17:08:54 +1000 David Seikel said: > On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman) > wrote: > > > > * 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: > > Aren't you the guy that made 3 space indenting the standard around > here? ;-P :-P~ > Though I agree, two spaces is what I prefer. > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- - 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
Re: [E-devel] UI syntax, letter 2
On 08/03/16 18:14, Leif Middelschulte wrote: > Hey, > > this is more of a question/feature request. Do you consider constraints > definition compatible to Cassowary[0] (Apple speak: auto-layout) yet? > An example of how such constraint definition could look like can be found in > the following DSL: https://github.com/s4cha/Stevia > > Would be nice to have that considered (reserved keywords, etc.). > You love mentioning this one. :P This is out of scope. This language is a description language for describing eo objects. It is not a constraint solver or a layout engine. For that we'll need bob, where I think this is a much needed feature. -- Tom. -- 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
Re: [E-devel] UI syntax, letter 2
On 03/09/2016 08:29 AM, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 9 Mar 2016 17:08:54 +1000 David Seikel said:
>
>> On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman)
>> wrote:
>>
* 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:
>>
>> Aren't you the guy that made 3 space indenting the standard around
>> here? ;-P
>
> :-P~
Well 4 is what most of the civilized world has agreed / standardized on
so I guess its not going to be that :P
On a more serious note, as someone who's brain is more visual spacial
oriented and much prefers and finds it much easyer to look at shapes and
colors rather then a wall of text 4 is significantly easier to read but
if were going to keep doing the crazyness of indenting braces then 2 is
fine because it really ends up being 4 ie
if (bob.isABogan())
{
doSomething();
}
is pretty similar to what a "Normal person" would do
if (bob.isABogan())
{
doSomething();
}
3 just messes with the musician in me that likes everything in multiples
of 4.
Cheers
Simon
>
>> Though I agree, two spaces is what I prefer.
>>
>> --
>> A big old stinking pile of genius that no one wants
>> coz there are too many silver coated monkeys in the world.
>
>
--
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
Re: [E-devel] UI syntax, letter 2
On 09/03/16 14:44, Simon Lees wrote:
>
>
> On 03/09/2016 08:29 AM, Carsten Haitzler (The Rasterman) wrote:
>> On Wed, 9 Mar 2016 17:08:54 +1000 David Seikel said:
>>
>>> On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman)
>>> wrote:
>>>
> * 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:
>>>
>>> Aren't you the guy that made 3 space indenting the standard around
>>> here? ;-P
>>
>> :-P~
>
> Well 4 is what most of the civilized world has agreed / standardized on
> so I guess its not going to be that :P
>
> On a more serious note, as someone who's brain is more visual spacial
> oriented and much prefers and finds it much easyer to look at shapes and
> colors rather then a wall of text 4 is significantly easier to read but
> if were going to keep doing the crazyness of indenting braces then 2 is
> fine because it really ends up being 4 ie
>
> if (bob.isABogan())
>{
> doSomething();
>}
>
> is pretty similar to what a "Normal person" would do
>
> if (bob.isABogan())
> {
> doSomething();
> }
>
> 3 just messes with the musician in me that likes everything in multiples
> of 4.
I said "anything but 3, but probably 4". Look at the proposal, it's
Python-like indentation based, no {}, so for it to be sane it has to be
4. I also think 2 is too compact.
--
Tom.
--
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
Re: [E-devel] UI syntax, letter 2
On 03/09/2016 04:03 PM, Tom Hacohen wrote:
> On 09/03/16 14:44, Simon Lees wrote:
>>
>>
>> On 03/09/2016 08:29 AM, Carsten Haitzler (The Rasterman) wrote:
>>> On Wed, 9 Mar 2016 17:08:54 +1000 David Seikel said:
>>>
On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman)
wrote:
>> * 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:
Aren't you the guy that made 3 space indenting the standard around
here? ;-P
>>>
>>> :-P~
>>
>> Well 4 is what most of the civilized world has agreed / standardized on
>> so I guess its not going to be that :P
>>
>> On a more serious note, as someone who's brain is more visual spacial
>> oriented and much prefers and finds it much easyer to look at shapes and
>> colors rather then a wall of text 4 is significantly easier to read but
>> if were going to keep doing the crazyness of indenting braces then 2 is
>> fine because it really ends up being 4 ie
>>
>> if (bob.isABogan())
>>{
>> doSomething();
>>}
>>
>> is pretty similar to what a "Normal person" would do
>>
>> if (bob.isABogan())
>> {
>> doSomething();
>> }
>>
>> 3 just messes with the musician in me that likes everything in multiples
>> of 4.
>
> I said "anything but 3, but probably 4". Look at the proposal, it's
> Python-like indentation based, no {}, so for it to be sane it has to be
> 4. I also think 2 is too compact.
>
Sorry I was being lazy and just replying to the mail thread :)
> --
> Tom.
>
>
> --
> 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
Re: [E-devel] UI syntax, letter 2
> Am 09.03.2016 um 15:26 schrieb Tom Hacohen : > > On 08/03/16 18:14, Leif Middelschulte wrote: >> Hey, >> >> this is more of a question/feature request. Do you consider constraints >> definition compatible to Cassowary[0] (Apple speak: auto-layout) yet? >> An example of how such constraint definition could look like can be found in >> the following DSL: https://github.com/s4cha/Stevia >> >> Would be nice to have that considered (reserved keywords, etc.). >> > > You love mentioning this one. :P Sure I do. Qt and others already have integration. Thus layouts working with iOS (autolayout) also work with Qt :-O > > > This is out of scope. This language is a description language for > describing eo objects. Ah, the subject of this thread is "UI syntax", so I thought it was about a User Interface description DSL syntax. Maybe it just got me confused then ;-) > It is not a constraint solver or a layout engine. Sure, but the language discussed on this thread will be a replacement for edje's DSL, thus should contain keywords to configure bob (the future layout engine)? > For that we'll need bob, where I think this is a much needed feature. Well afaii, bob would be an implementation of Cassowary for Evas_Objects, wouldn't it? > > -- > Tom. Cheers, Leif > > > -- > 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
Re: [E-devel] UI syntax, letter 2
On Wed, Mar 9, 2016 at 3:44 PM, Simon Lees wrote: > 3 just messes with the musician in me that likes everything in multiples > of 4. > https://upload.wikimedia.org/wikipedia/commons/transcoded/b/b6/Waltz.oggtheora.ogv/Waltz.oggtheora.ogv.480p.webm Sorry, I just had to do this. :P -- 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
Re: [E-devel] UI syntax, letter 2
On Wed, Mar 9, 2016 at 4:08 AM, David Seikel wrote: > On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman) > wrote: > >> > * 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: > > Aren't you the guy that made 3 space indenting the standard around > here? ;-P > > Though I agree, two spaces is what I prefer. 2 spaces are the best IMO. > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. [snip] -- Felipe Magno de Almeida -- 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
Re: [E-devel] UI syntax, letter 2
On Wed, 9 Mar 2016 15:44:57 +0100 Simon Lees said:
>
>
> On 03/09/2016 08:29 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 9 Mar 2016 17:08:54 +1000 David Seikel said:
> >
> >> On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman)
> >> wrote:
> >>
> * 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:
> >>
> >> Aren't you the guy that made 3 space indenting the standard around
> >> here? ;-P
> >
> > :-P~
>
> Well 4 is what most of the civilized world has agreed / standardized on
> so I guess its not going to be that :P
>
> On a more serious note, as someone who's brain is more visual spacial
> oriented and much prefers and finds it much easyer to look at shapes and
> colors rather then a wall of text 4 is significantly easier to read but
> if were going to keep doing the crazyness of indenting braces then 2 is
> fine because it really ends up being 4 ie
>
> if (bob.isABogan())
> {
> doSomething();
> }
>
> is pretty similar to what a "Normal person" would do
>
> if (bob.isABogan())
> {
> doSomething();
> }
since there are no {}'s then you end up with (with 4 spaces):
blahblah(xxx)
blah2whatever(yyy)
blah3boo(zzz)
wootwoot(x)
boobooboo(7)
weee(y)
abracadabra(hey)
with 2 it just looks nicer:
blahblah(xxx)
blah2whatever(yyy)
blah3boo(zzz)
wootwoot(x)
boobooboo(7)
weee(y)
abracadabra(hey)
each indent comes out at a "visually" approximate 45 degrees due to general
font sizing. also it's far nicer on the typer if they have to indent - hit
space twice not 4 times. sure you COULD modify your editor to make tab == 4
spaces and force that BUT then you break your editor for the rest of the unix
world that has agreed on tab == 8 spaces. windows thinks tab == 4 spaces. so -
make people hit space 4 times instead of 2? why? that's a bit silly.
> 3 just messes with the musician in me that likes everything in multiples
> of 4.
>
> Cheers
> Simon
>
> >
> >> Though I agree, two spaces is what I prefer.
> >>
> >> --
> >> A big old stinking pile of genius that no one wants
> >> coz there are too many silver coated monkeys in the world.
> >
> >
>
> --
> 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
Re: [E-devel] UI syntax, letter 2
On Wed, 9 Mar 2016 19:03:27 +0100 Leif Middelschulte said: > > > Am 09.03.2016 um 15:26 schrieb Tom Hacohen : > > > > On 08/03/16 18:14, Leif Middelschulte wrote: > >> Hey, > >> > >> this is more of a question/feature request. Do you consider constraints > >> definition compatible to Cassowary[0] (Apple speak: auto-layout) yet? An > >> example of how such constraint definition could look like can be found in > >> the following DSL: https://github.com/s4cha/Stevia > >> > >> Would be nice to have that considered (reserved keywords, etc.). > >> > > > > You love mentioning this one. :P > Sure I do. Qt and others already have integration. Thus layouts working with > iOS (autolayout) also work with Qt :-O > > > > > > This is out of scope. This language is a description language for > > describing eo objects. > Ah, the subject of this thread is "UI syntax", so I thought it was about a > User Interface description DSL syntax. Maybe it just got me confused then ;-) > > It is not a constraint solver or a layout engine. > Sure, but the language discussed on this thread will be a replacement for > edje's DSL, thus should contain keywords to configure bob (the future layout > engine)? no. this has nothing to do with bob or replacing or modifying edje. it's simply widget layout description. > > For that we'll need bob, where I think this is a much needed feature. > Well afaii, bob would be an implementation of Cassowary for Evas_Objects, > wouldn't it? no - bob would literally be simpler and immediate. it literally would be "smart objects implemented in lua" with a system to on-the-fly generate all the lua needed from a combination of data files shipped + hosted system ones + user ones and be able to patch/modify (in a limited way) the code on the fly along with a lot of efl api exposed to the bob lua code (in a sandboxed way) and then most of bob work is in writing lots of pre-made lua objects that conform to a standard api out to the host program (c/c++/whatever). some of bob is standardizing what these api's will look like too - likely property + mvc based with a bit of one-off signals. this will also be how one bobject would see another and interact with it. in edje you have to glue objects together manually on the native side (they are VERY sandboxed) but in bob i think we'd want objects to talk to each other much more directly - saving a lot of code. > > -- > > Tom. > > Cheers, > > Leif > > > > > > -- > > 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 > -- - 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
Re: [E-devel] UI syntax, letter 2
On Wed, 9 Mar 2016 15:44:57 +0100 Simon Lees wrote: > 3 just messes with the musician in me that likes everything in > multiples of 4. No waltzes for you. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- 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
Re: [E-devel] UI syntax, letter 2
On 03/10/2016 02:14 AM, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 9 Mar 2016 15:44:57 +0100 Simon Lees said:
>
>>
>>
>> On 03/09/2016 08:29 AM, Carsten Haitzler (The Rasterman) wrote:
>>> On Wed, 9 Mar 2016 17:08:54 +1000 David Seikel said:
>>>
On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman)
wrote:
>> * 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:
Aren't you the guy that made 3 space indenting the standard around
here? ;-P
>>>
>>> :-P~
>>
>> Well 4 is what most of the civilized world has agreed / standardized on
>> so I guess its not going to be that :P
>>
>> On a more serious note, as someone who's brain is more visual spacial
>> oriented and much prefers and finds it much easyer to look at shapes and
>> colors rather then a wall of text 4 is significantly easier to read but
>> if were going to keep doing the crazyness of indenting braces then 2 is
>> fine because it really ends up being 4 ie
>>
>> if (bob.isABogan())
>> {
>> doSomething();
>> }
>>
>> is pretty similar to what a "Normal person" would do
>>
>> if (bob.isABogan())
>> {
>> doSomething();
>> }
>
> since there are no {}'s then you end up with (with 4 spaces):
>
> blahblah(xxx)
> blah2whatever(yyy)
> blah3boo(zzz)
> wootwoot(x)
> boobooboo(7)
> weee(y)
> abracadabra(hey)
>
> with 2 it just looks nicer:
>
> blahblah(xxx)
> blah2whatever(yyy)
> blah3boo(zzz)
> wootwoot(x)
> boobooboo(7)
> weee(y)
> abracadabra(hey)
>
> each indent comes out at a "visually" approximate 45 degrees due to general
> font sizing. also it's far nicer on the typer if they have to indent - hit
> space twice not 4 times. sure you COULD modify your editor to make tab == 4
> spaces and force that BUT then you break your editor for the rest of the unix
> world that has agreed on tab == 8 spaces. windows thinks tab == 4 spaces. so -
> make people hit space 4 times instead of 2? why? that's a bit silly.
Normally people don't hit space 4 times, normally they have there editor
configured so that the tab key inserts 4 spaces rather then a \t :)
Is the following still legal syntax, as I find that much easier to read
(Not sure if i'll ever have to read / write it though.
blahblah(xxx)
blah2whatever(yyy)
blah3boo(zzz)
wootwoot(x)
boobooboo(7)
weee(y)
abracadabra(hey)
>
>> 3 just messes with the musician in me that likes everything in multiples
>> of 4.
>>
>> Cheers
>> Simon
>>
>>>
Though I agree, two spaces is what I prefer.
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
>>>
>>>
>>
>> --
>> 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
>>
>
>
signature.asc
Description: OpenPGP digital signature
--
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
Re: [E-devel] UI syntax, letter 2
Thank you for all comments about indentation! :)
Could you please direct part of your discussion passion to callback's
and snippet's style :)
On 03/08/2016 06:14 PM, Yakov Goldberg wrote:
> 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
> * Widget vs Elm.Widget: all widgets - are they Elm Widgets only and thus
> "Elm" can be skipped or we want to use namespace
> * button vs Button: starts with capital letter?
> * callbacks format - options:
> Button()
> on clicked("callback_name")
> on("clicked", "callback_name")
>
> #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))
>
> * snippets support - please read in wiki
> https://phab.enlightenment.org/w/ui_builders_format/#snippets
>
>
> 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
Re: [E-devel] UI syntax, letter 2
On 10/03/16 06:51, Simon Lees wrote:
>
>
> On 03/10/2016 02:14 AM, Carsten Haitzler (The Rasterman) wrote:
>> On Wed, 9 Mar 2016 15:44:57 +0100 Simon Lees said:
>>
>>>
>>>
>>> On 03/09/2016 08:29 AM, Carsten Haitzler (The Rasterman) wrote:
On Wed, 9 Mar 2016 17:08:54 +1000 David Seikel said:
> On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman)
> wrote:
>
>>> * 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:
>
> Aren't you the guy that made 3 space indenting the standard around
> here? ;-P
:-P~
>>>
>>> Well 4 is what most of the civilized world has agreed / standardized on
>>> so I guess its not going to be that :P
>>>
>>> On a more serious note, as someone who's brain is more visual spacial
>>> oriented and much prefers and finds it much easyer to look at shapes and
>>> colors rather then a wall of text 4 is significantly easier to read but
>>> if were going to keep doing the crazyness of indenting braces then 2 is
>>> fine because it really ends up being 4 ie
>>>
>>> if (bob.isABogan())
>>>{
>>> doSomething();
>>>}
>>>
>>> is pretty similar to what a "Normal person" would do
>>>
>>> if (bob.isABogan())
>>> {
>>> doSomething();
>>> }
>>
>> since there are no {}'s then you end up with (with 4 spaces):
>>
>> blahblah(xxx)
>> blah2whatever(yyy)
>> blah3boo(zzz)
>> wootwoot(x)
>> boobooboo(7)
>> weee(y)
>> abracadabra(hey)
>>
>> with 2 it just looks nicer:
>>
>> blahblah(xxx)
>>blah2whatever(yyy)
>>blah3boo(zzz)
>> wootwoot(x)
>>boobooboo(7)
>> weee(y)
>>abracadabra(hey)
>>
>> each indent comes out at a "visually" approximate 45 degrees due to general
>> font sizing. also it's far nicer on the typer if they have to indent - hit
>> space twice not 4 times. sure you COULD modify your editor to make tab == 4
>> spaces and force that BUT then you break your editor for the rest of the unix
>> world that has agreed on tab == 8 spaces. windows thinks tab == 4 spaces. so
>> -
>> make people hit space 4 times instead of 2? why? that's a bit silly.
>
> Normally people don't hit space 4 times, normally they have there editor
> configured so that the tab key inserts 4 spaces rather then a \t :)
>
> Is the following still legal syntax, as I find that much easier to read
> (Not sure if i'll ever have to read / write it though.
>
> blahblah(xxx)
>
> blah2whatever(yyy)
> blah3boo(zzz)
>
> wootwoot(x)
> boobooboo(7)
> weee(y)
>
> abracadabra(hey)
>
The plan is to allow for manual editing, and I agree, this is much nicer
than 2 spaces. I think 2 spaces are too compact.
--
Tom.
--
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
Re: [E-devel] UI syntax, letter 2
Aside from the irony of insisting on 3, 5, 8 etc spaces elsewhere I really
don't get the idea of defining language layout based on individuals text
editor preferences. Everyone has a different setup so we have effectively
free reign to define what works for us and require its followed.
If folk are willing to set up editors to emulate the current efl
indentation I'm certain that 4 spaces is not going to cause much trouble.
Amusingly EDI is 4 space soft tab by default these days :-D
Andy
On Thu, 10 Mar 2016 at 11:43, Tom Hacohen wrote:
> On 10/03/16 06:51, Simon Lees wrote:
> >
> >
> > On 03/10/2016 02:14 AM, Carsten Haitzler (The Rasterman) wrote:
> >> On Wed, 9 Mar 2016 15:44:57 +0100 Simon Lees said:
> >>
> >>>
> >>>
> >>> On 03/09/2016 08:29 AM, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 9 Mar 2016 17:08:54 +1000 David Seikel
> said:
>
> > On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman)
> > wrote:
> >
> >>> * 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:
> >
> > Aren't you the guy that made 3 space indenting the standard around
> > here? ;-P
>
> :-P~
> >>>
> >>> Well 4 is what most of the civilized world has agreed / standardized on
> >>> so I guess its not going to be that :P
> >>>
> >>> On a more serious note, as someone who's brain is more visual spacial
> >>> oriented and much prefers and finds it much easyer to look at shapes
> and
> >>> colors rather then a wall of text 4 is significantly easier to read but
> >>> if were going to keep doing the crazyness of indenting braces then 2 is
> >>> fine because it really ends up being 4 ie
> >>>
> >>> if (bob.isABogan())
> >>>{
> >>> doSomething();
> >>>}
> >>>
> >>> is pretty similar to what a "Normal person" would do
> >>>
> >>> if (bob.isABogan())
> >>> {
> >>> doSomething();
> >>> }
> >>
> >> since there are no {}'s then you end up with (with 4 spaces):
> >>
> >> blahblah(xxx)
> >> blah2whatever(yyy)
> >> blah3boo(zzz)
> >> wootwoot(x)
> >> boobooboo(7)
> >> weee(y)
> >> abracadabra(hey)
> >>
> >> with 2 it just looks nicer:
> >>
> >> blahblah(xxx)
> >>blah2whatever(yyy)
> >>blah3boo(zzz)
> >> wootwoot(x)
> >>boobooboo(7)
> >> weee(y)
> >>abracadabra(hey)
> >>
> >> each indent comes out at a "visually" approximate 45 degrees due to
> general
> >> font sizing. also it's far nicer on the typer if they have to indent -
> hit
> >> space twice not 4 times. sure you COULD modify your editor to make tab
> == 4
> >> spaces and force that BUT then you break your editor for the rest of
> the unix
> >> world that has agreed on tab == 8 spaces. windows thinks tab == 4
> spaces. so -
> >> make people hit space 4 times instead of 2? why? that's a bit silly.
> >
> > Normally people don't hit space 4 times, normally they have there editor
> > configured so that the tab key inserts 4 spaces rather then a \t :)
> >
> > Is the following still legal syntax, as I find that much easier to read
> > (Not sure if i'll ever have to read / write it though.
> >
> > blahblah(xxx)
> >
> > blah2whatever(yyy)
> > blah3boo(zzz)
> >
> > wootwoot(x)
> > boobooboo(7)
> > weee(y)
> >
> > abracadabra(hey)
> >
>
> The plan is to allow for manual editing, and I agree, this is much nicer
> than 2 spaces. I think 2 spaces are too compact.
>
> --
> Tom.
>
>
>
> --
> 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
Re: [E-devel] UI syntax, letter 2
On Thu, 10 Mar 2016 07:51:01 +0100 Simon Lees said:
>
>
> On 03/10/2016 02:14 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 9 Mar 2016 15:44:57 +0100 Simon Lees said:
> >
> >>
> >>
> >> On 03/09/2016 08:29 AM, Carsten Haitzler (The Rasterman) wrote:
> >>> On Wed, 9 Mar 2016 17:08:54 +1000 David Seikel said:
> >>>
> On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman)
> wrote:
>
> >> * 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:
>
> Aren't you the guy that made 3 space indenting the standard around
> here? ;-P
> >>>
> >>> :-P~
> >>
> >> Well 4 is what most of the civilized world has agreed / standardized on
> >> so I guess its not going to be that :P
> >>
> >> On a more serious note, as someone who's brain is more visual spacial
> >> oriented and much prefers and finds it much easyer to look at shapes and
> >> colors rather then a wall of text 4 is significantly easier to read but
> >> if were going to keep doing the crazyness of indenting braces then 2 is
> >> fine because it really ends up being 4 ie
> >>
> >> if (bob.isABogan())
> >> {
> >> doSomething();
> >> }
> >>
> >> is pretty similar to what a "Normal person" would do
> >>
> >> if (bob.isABogan())
> >> {
> >> doSomething();
> >> }
> >
> > since there are no {}'s then you end up with (with 4 spaces):
> >
> > blahblah(xxx)
> > blah2whatever(yyy)
> > blah3boo(zzz)
> > wootwoot(x)
> > boobooboo(7)
> > weee(y)
> > abracadabra(hey)
> >
> > with 2 it just looks nicer:
> >
> > blahblah(xxx)
> > blah2whatever(yyy)
> > blah3boo(zzz)
> > wootwoot(x)
> > boobooboo(7)
> > weee(y)
> > abracadabra(hey)
> >
> > each indent comes out at a "visually" approximate 45 degrees due to general
> > font sizing. also it's far nicer on the typer if they have to indent - hit
> > space twice not 4 times. sure you COULD modify your editor to make tab == 4
> > spaces and force that BUT then you break your editor for the rest of the
> > unix world that has agreed on tab == 8 spaces. windows thinks tab == 4
> > spaces. so - make people hit space 4 times instead of 2? why? that's a bit
> > silly.
>
> Normally people don't hit space 4 times, normally they have there editor
> configured so that the tab key inserts 4 spaces rather then a \t :)
that is what i said.. and they have it configured to 8 spaces because that is
the standard (except on windows), so they have to reconfigure their editor JUSt
for this... or they have fucked up tab sizes as now tab != 8 spaces for many
documents... so they are going to be stuck really hitting space 4 times or
dealing with the above pain.
> Is the following still legal syntax, as I find that much easier to read
> (Not sure if i'll ever have to read / write it though.
>
> blahblah(xxx)
>
> blah2whatever(yyy)
> blah3boo(zzz)
>
> wootwoot(x)
> boobooboo(7)
> weee(y)
>
> abracadabra(hey)
>
> >
> >> 3 just messes with the musician in me that likes everything in multiples
> >> of 4.
> >>
> >> Cheers
> >> Simon
> >>
> >>>
> Though I agree, two spaces is what I prefer.
>
> --
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.
> >>>
> >>>
> >>
> >> --
> >> 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
Re: [E-devel] UI syntax, letter 2
efl already has a rule to have 3 spaces for edc and code.
I don't think there is any necessities to have one more rules. :(
-Original Message-
From: "Carsten Haitzler"
To: "Enlightenment developer list";
Cc:
Sent: 2016-03-10 (목) 21:44:20
Subject: Re: [E-devel] UI syntax, letter 2
On Thu, 10 Mar 2016 07:51:01 +0100 Simon Lees said:
>
>
> On 03/10/2016 02:14 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 9 Mar 2016 15:44:57 +0100 Simon Lees said:
> >
> >>
> >>
> >> On 03/09/2016 08:29 AM, Carsten Haitzler (The Rasterman) wrote:
> >>> On Wed, 9 Mar 2016 17:08:54 +1000 David Seikel said:
> >>>
> >>>> On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman)
> >>>> wrote:
> >>>>
> >>>>>> * 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:
> >>>>
> >>>> Aren't you the guy that made 3 space indenting the standard around
> >>>> here? ;-P
> >>>
> >>> :-P~
> >>
> >> Well 4 is what most of the civilized world has agreed / standardized on
> >> so I guess its not going to be that :P
> >>
> >> On a more serious note, as someone who's brain is more visual spacial
> >> oriented and much prefers and finds it much easyer to look at shapes and
> >> colors rather then a wall of text 4 is significantly easier to read but
> >> if were going to keep doing the crazyness of indenting braces then 2 is
> >> fine because it really ends up being 4 ie
> >>
> >> if (bob.isABogan())
> >> {
> >> doSomething();
> >> }
> >>
> >> is pretty similar to what a "Normal person" would do
> >>
> >> if (bob.isABogan())
> >> {
> >> doSomething();
> >> }
> >
> > since there are no {}'s then you end up with (with 4 spaces):
> >
> > blahblah(xxx)
> > blah2whatever(yyy)
> > blah3boo(zzz)
> > wootwoot(x)
> > boobooboo(7)
> > weee(y)
> > abracadabra(hey)
> >
> > with 2 it just looks nicer:
> >
> > blahblah(xxx)
> > blah2whatever(yyy)
> > blah3boo(zzz)
> > wootwoot(x)
> > boobooboo(7)
> > weee(y)
> > abracadabra(hey)
> >
> > each indent comes out at a "visually" approximate 45 degrees due to general
> > font sizing. also it's far nicer on the typer if they have to indent - hit
> > space twice not 4 times. sure you COULD modify your editor to make tab == 4
> > spaces and force that BUT then you break your editor for the rest of the
> > unix world that has agreed on tab == 8 spaces. windows thinks tab == 4
> > spaces. so - make people hit space 4 times instead of 2? why? that's a bit
> > silly.
>
> Normally people don't hit space 4 times, normally they have there editor
> configured so that the tab key inserts 4 spaces rather then a \t :)
that is what i said.. and they have it configured to 8 spaces because that is
the standard (except on windows), so they have to reconfigure their editor JUSt
for this... or they have fucked up tab sizes as now tab != 8 spaces for many
documents... so they are going to be stuck really hitting space 4 times or
dealing with the above pain.
> Is the following still legal syntax, as I find that much easier to read
> (Not sure if i'll ever have to read / write it though.
>
> blahblah(xxx)
>
> blah2whatever(yyy)
> blah3boo(zzz)
>
> wootwoot(x)
> boobooboo(7)
> weee(y)
>
> abracadabra(hey)
>
> >
> >> 3 just messes with the musician in me that likes everything in multiples
> >> of 4.
> >>
> >> Cheers
> >> Simon
> >>
> >>>
> >>>> Though I agree, two spaces is what I prefer.
> >>>>
> >>>> --
> >>>> A big old stinking pile of genius that no one wants
> >>>> coz there are too many silver coated monkeys in the world.
> >>>
> >>>
> >>
> >> --
> >> Transform Data into Opportunity.
> >> Accelerate data analysis in your application
Re: [E-devel] UI syntax, letter 2
As I said, I don't like the space delimited "on".
I prefer
on("state,changed", cb)
or
on.state,changed(cb)
or
on:state,changed(cb)
or
on: state,changed(cb)
I already said the "create" is an extremely bad idea, raster concurs.
Variable manipulation is probably also a bad idea (as I said), though I
can see some uses for it. I'd still start with *not* supporting that and
maybe add it in the future.
Otherwise snippets are just normal.
--
Tom.
On 10/03/16 08:28, Yakov Goldberg wrote:
> Thank you for all comments about indentation! :)
>
> Could you please direct part of your discussion passion to callback's
> and snippet's style :)
>
>
> On 03/08/2016 06:14 PM, Yakov Goldberg wrote:
>> 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
>> * Widget vs Elm.Widget: all widgets - are they Elm Widgets only and thus
>> "Elm" can be skipped or we want to use namespace
>> * button vs Button: starts with capital letter?
>> * callbacks format - options:
>>Button()
>> on clicked("callback_name")
>> on("clicked", "callback_name")
>>
>>#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))
>>
>> * snippets support - please read in wiki
>>https://phab.enlightenment.org/w/ui_builders_format/#snippets
>>
>>
>> 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
Re: [E-devel] UI syntax, letter 2
On 09/03/16 06:39, Carsten Haitzler wrote:
> On Tue, 08 Mar 2016 18:14:42 +0200 Yakov Goldberg 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. - 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.6 :) 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-deve
Re: [E-devel] UI syntax, letter 2
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 wrote:
> On 09/03/16 06:39, Carsten Haitzler wrote:
> > On Tue, 08 Mar 2016 18:14:42 +0200 Yakov Goldberg
> 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. - 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.6 :) 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 s
Re: [E-devel] UI syntax, letter 2
On Thu, 10 Mar 2016 22:22:13 +0900 (KST) Hermet Park said:
> efl already has a rule to have 3 spaces for edc and code.
>
> I don't think there is any necessities to have one more rules. :(
that is for efl's own code. it is the code formatting of a specific project. we
are discussing formatting rules applied to everyone using this tool/file format.
> -Original Message-
> From: "Carsten Haitzler"
> To: "Enlightenment developer
> list"; Cc:
> Sent: 2016-03-10 (목) 21:44:20
> Subject: Re: [E-devel] UI syntax, letter 2
>
> On Thu, 10 Mar 2016 07:51:01 +0100 Simon Lees said:
>
> >
> >
> > On 03/10/2016 02:14 AM, Carsten Haitzler (The Rasterman) wrote:
> > > On Wed, 9 Mar 2016 15:44:57 +0100 Simon Lees said:
> > >
> > >>
> > >>
> > >> On 03/09/2016 08:29 AM, Carsten Haitzler (The Rasterman) wrote:
> > >>> On Wed, 9 Mar 2016 17:08:54 +1000 David Seikel said:
> > >>>
> > >>>> On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman)
> > >>>> wrote:
> > >>>>
> > >>>>>> * 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:
> > >>>>
> > >>>> Aren't you the guy that made 3 space indenting the standard around
> > >>>> here? ;-P
> > >>>
> > >>> :-P~
> > >>
> > >> Well 4 is what most of the civilized world has agreed / standardized on
> > >> so I guess its not going to be that :P
> > >>
> > >> On a more serious note, as someone who's brain is more visual spacial
> > >> oriented and much prefers and finds it much easyer to look at shapes and
> > >> colors rather then a wall of text 4 is significantly easier to read but
> > >> if were going to keep doing the crazyness of indenting braces then 2 is
> > >> fine because it really ends up being 4 ie
> > >>
> > >> if (bob.isABogan())
> > >> {
> > >> doSomething();
> > >> }
> > >>
> > >> is pretty similar to what a "Normal person" would do
> > >>
> > >> if (bob.isABogan())
> > >> {
> > >> doSomething();
> > >> }
> > >
> > > since there are no {}'s then you end up with (with 4 spaces):
> > >
> > > blahblah(xxx)
> > > blah2whatever(yyy)
> > > blah3boo(zzz)
> > > wootwoot(x)
> > > boobooboo(7)
> > > weee(y)
> > > abracadabra(hey)
> > >
> > > with 2 it just looks nicer:
> > >
> > > blahblah(xxx)
> > > blah2whatever(yyy)
> > > blah3boo(zzz)
> > > wootwoot(x)
> > > boobooboo(7)
> > > weee(y)
> > > abracadabra(hey)
> > >
> > > each indent comes out at a "visually" approximate 45 degrees due to
> > > general font sizing. also it's far nicer on the typer if they have to
> > > indent - hit space twice not 4 times. sure you COULD modify your editor
> > > to make tab == 4 spaces and force that BUT then you break your editor for
> > > the rest of the unix world that has agreed on tab == 8 spaces. windows
> > > thinks tab == 4 spaces. so - make people hit space 4 times instead of 2?
> > > why? that's a bit silly.
> >
> > Normally people don't hit space 4 times, normally they have there editor
> > configured so that the tab key inserts 4 spaces rather then a \t :)
>
> that is what i said.. and they have it configured to 8 spaces because that is
> the standard (except on windows), so they have to reconfigure their editor
> JUSt for this... or they have fucked up tab sizes as now tab != 8 spaces for
> many documents... so they are going to be stuck really hitting space 4 times
> or dealing with the above pain.
>
> > Is the following still legal syntax, as I find that much easier to read
> > (Not sure if i'll ever have to read / write it though.
> >
> > blahblah(xxx)
> >
> > blah2whatever(yyy)
> > blah3boo(zzz)
> >
> > wootwoot(x)
> > boobooboo(7)
> > weee(y)
> >
Re: [E-devel] UI syntax, letter 2
On Thu, 10 Mar 2016 17:39:58 + Tom Hacohen said:
> On 09/03/16 06:39, Carsten Haitzler wrote:
> > On Tue, 08 Mar 2016 18:14:42 +0200 Yakov Goldberg
> > 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. - 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.6 :) 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:
Re: [E-devel] UI syntax, letter 2
On 03/11/2016 12:35 AM, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 10 Mar 2016 17:39:58 + Tom Hacohen said:
>
>> On 09/03/16 06:39, Carsten Haitzler wrote:
>>> On Tue, 08 Mar 2016 18:14:42 +0200 Yakov Goldberg
>>> 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.
The thing here is that not everyone's eyes / brain work the same, yours
for example "scans along to find the next line start" mine on the other
had picks out the shapes from the indentation and spacing and breaks
them into blocks then uses that to figure out flow etc which is why I
find more spacing easier then less and your probably the opposite.
>
>>>
* 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. - 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.6 :) 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
Re: [E-devel] UI syntax, letter 2
On 10/03/16 12:44, Carsten Haitzler wrote:
> On Thu, 10 Mar 2016 07:51:01 +0100 Simon Lees said:
>
>>
>>
>> On 03/10/2016 02:14 AM, Carsten Haitzler (The Rasterman) wrote:
>>> On Wed, 9 Mar 2016 15:44:57 +0100 Simon Lees said:
>>>
On 03/09/2016 08:29 AM, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 9 Mar 2016 17:08:54 +1000 David Seikel said:
>
>> On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman)
>> wrote:
>>
* 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:
>>
>> Aren't you the guy that made 3 space indenting the standard around
>> here? ;-P
>
> :-P~
Well 4 is what most of the civilized world has agreed / standardized on
so I guess its not going to be that :P
On a more serious note, as someone who's brain is more visual spacial
oriented and much prefers and finds it much easyer to look at shapes and
colors rather then a wall of text 4 is significantly easier to read but
if were going to keep doing the crazyness of indenting braces then 2 is
fine because it really ends up being 4 ie
if (bob.isABogan())
{
doSomething();
}
is pretty similar to what a "Normal person" would do
if (bob.isABogan())
{
doSomething();
}
>>>
>>> since there are no {}'s then you end up with (with 4 spaces):
>>>
>>> blahblah(xxx)
>>> blah2whatever(yyy)
>>> blah3boo(zzz)
>>> wootwoot(x)
>>> boobooboo(7)
>>> weee(y)
>>> abracadabra(hey)
>>>
>>> with 2 it just looks nicer:
>>>
>>> blahblah(xxx)
>>>blah2whatever(yyy)
>>>blah3boo(zzz)
>>> wootwoot(x)
>>>boobooboo(7)
>>> weee(y)
>>>abracadabra(hey)
>>>
>>> each indent comes out at a "visually" approximate 45 degrees due to general
>>> font sizing. also it's far nicer on the typer if they have to indent - hit
>>> space twice not 4 times. sure you COULD modify your editor to make tab == 4
>>> spaces and force that BUT then you break your editor for the rest of the
>>> unix world that has agreed on tab == 8 spaces. windows thinks tab == 4
>>> spaces. so - make people hit space 4 times instead of 2? why? that's a bit
>>> silly.
>>
>> Normally people don't hit space 4 times, normally they have there editor
>> configured so that the tab key inserts 4 spaces rather then a \t :)
>
> that is what i said.. and they have it configured to 8 spaces because that is
> the standard (except on windows), so they have to reconfigure their editor
> JUSt
> for this... or they have fucked up tab sizes as now tab != 8 spaces for many
> documents... so they are going to be stuck really hitting space 4 times or
> dealing with the above pain.
I don't know what backwards editor you're using (well, I do), but for me
it's very easy to change configuration per project (and I do), and
anyhow tabs are 4 spaces for me by default (my configuration).
I'm forced to do very bad things to my configuration just to write code
for the EFL because the EFL uses crazy weird indentation rules, so that
same logic already doesn't apply for the EFL.
--
Tom.
--
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
