Re: [E-devel] Eo: Changes to syntax

2016-03-09 Thread Jean-Philippe André 
On 10 March 2016 at 15:58, Daniel Zaoui  wrote:

> On Thu, 10 Mar 2016 15:05:38 +0900
> Carsten Haitzler  (The Rasterman) wrote:
>
> > On Thu, 10 Mar 2016 07:42:22 +0200 Daniel Zaoui
> >  said:
> >
> > > On Wed, 09 Mar 2016 16:23:04 +
> > > Tom Hacohen  wrote:
> > >
> > > > On 03/03/16 10:22, Tom Hacohen wrote:
> > > > > On 01/03/16 09:05, Tom Hacohen wrote:
> > > > >> Hey,
> > > > >>
> > > > >> The Eo syntax is going to be changing once more, and this
> > > > >> time, I really think/hope it'll be the last time. We plan on
> > > > >> stabilizing Eo and all of the functions on top of it in the
> > > > >> next few months, so that doesn't leave us much more time to
> > > > >> change it again. :)
> > > > >>
> > > > >> These changes will remove the need for the eo_do family of
> > > > >> functions. Functions will now look like normal C functions
> > > > >> (which they are). There are many benefits to that, and we have
> > > > >> many cool new ideas.
> > > > >>
> > > > >> For more info: https://phab.enlightenment.org/w/eo/
> > > > >>
> > > > >> I'm sending this email as an head's up, as I'll be starting to
> > > > >> work on migrating to the new Eo syntax (and implementing it)
> > > > >> today. Felipe and I have actually already started (needed to
> > > > >> for the PoC), but I plan on pushing my changes to master soon.
> > > > >>
> > > > >> If you have any issues/suggestions/comments with the proposal,
> > > > >> please let me know, either in pm, irc or just here.
> > > > >>
> > > > >
> > > > > Changes are in! I still haven't migrated eo_add to the new
> > > > > syntax (it uses a non portable gcc extension in the meanwhile),
> > > > > but otherwise everything is in. Took me *much* less time than I
> > > > > thought it would, so yay. :P
> > > > >
> > > > > I decided to push it now instead of letting it rest in my branch
> > > > > for a while because literally every hour that passed introduced
> > > > > more merge conflicts for me, so the benefits from stabilising it
> > > > > more in my branch were diminished by the new conflicts and
> > > > > issues that could arise.
> > > > >
> > > > > If you have an application that uses the Eo api, you can use my
> > > > > script https://devs.enlightenment.org/~tasn/migrate_eo.py to
> > > > > migrate your code. When using the script you should keep two
> > > > > things in mind: 1. You are only allowed to run it *once* per
> > > > > source code, because the changes to eo_add() would otherwise
> > > > > accumulate and your code will be wrong. If you need to correct
> > > > > something you've done wrong, reset the code to the previous
> > > > > state and run the script again on the original code. 2. The
> > > > > migration script is not perfect. In particular it can't deal
> > > > > with some corner cases like: eo_do(obj, a_set(1),
> > > > > /* b_set(2),
> > > > >  g_set(4), */
> > > > > c_set(2));
> > > > > Or abominations like:
> > > > > eo_do(obj, if (a_get())
> > > > > do_something());
> > > > >
> > > > > So please be aware of that and *manually* review your changes
> > > > > after the script has run.
> > > > >
> > > > > If your code does have these cases, I recommend you either get
> > > > > rid of them, or manually migrate that code before running the
> > > > > script (remove the relevant eo_do).
> > > > >
> > > > > Follow the wiki page mentioned in the previous email for more
> > > > > information about Eo and what else needs changing.
> > > > >
> > > > > Please let me know about any regressions (there shouldn't be
> > > > > any) or any issues you may face.
> > > >
> > > > I'm now pushing my changes to eo_add. I'm pushing it now for the
> > > > same reason I pushed the previous changes in.
> > > >
> > > > I created a new script that assumes the code has already been
> > > > migrated with the previous (migrate_eo.py) script. This script is
> > > > called migrate_eo_add.py and can be found at:
> > > > https://devs.enlightenment.org/~tasn/migrate_eo_add.py
> > > >
> > > > When using the script you should keep two things in mind:
> > > > 1. You are only allowed to run it *once* per source code, because
> > > > the changes to eo_add() would otherwise accumulate and your code
> > > > will be wrong. If you need to correct something you've done
> > > > wrong, reset the code to the previous state and run the script
> > > > again on the original code. 2. The migration script is not
> > > > perfect. In particular it can't deal with cases like missing {}
> > > > for if/for/while content so for example,
> > > >
> > > > if ()
> > > > return eo_add(...)
> > > >
> > > > would break.
> > > > 3. If you are fancy and use the same variable inside eo_add and
> > > > outside, for example like:
> > > > parent = eo_add(CLASS, parent);
> > > >
> > > > your code will break. I suggest you use a temporary variable.
> > > >
> > > > So please be aware of that and *manually*

Re: [E-devel] Eo: Changes to syntax

2016-03-09 Thread Daniel Zaoui 
On Thu, 10 Mar 2016 15:48:12 +0900
Jean-Philippe André  wrote:

> Oh and I forgot, those changes add ~60 warnings in EFL with clang:
> 
>   CC   lib/evas/canvas/lib_evas_libevas_la-evas_object_line.lo
> /home/jpeg/e/core/efl/src/lib/evas/canvas/evas_object_line.c:101:5:
> warning: expression result unused [-Wunused-value]
>((Eo *) ( *_obj =
> _eo_add_internal_start("/home/jpeg/e/core/efl/src/lib/evas/canvas/evas_object_line.c",
> 101, evas_line_class_get(), e, ((Eina_Bool)0)), *_obj =
> _eo_add_end(*_obj) ));

You can use the vomit ascii on that too ;-)

> 
> 
> On 10 March 2016 at 15:46, Jean-Philippe André 
> wrote:
> 
> >
> >
> > On 10 March 2016 at 15:05, Carsten Haitzler 
> > wrote: 
> >> On Thu, 10 Mar 2016 07:42:22 +0200 Daniel Zaoui
> >>  said:
> >>  
> >> > On Wed, 09 Mar 2016 16:23:04 +
> >> > Tom Hacohen  wrote:
> >> >  
> >> > > On 03/03/16 10:22, Tom Hacohen wrote:  
> >> > > > On 01/03/16 09:05, Tom Hacohen wrote:  
> >> > > >> Hey,
> >> > > >>
> >> > > >> The Eo syntax is going to be changing once more, and this
> >> > > >> time, I really think/hope it'll be the last time. We plan
> >> > > >> on stabilizing Eo and all of the functions on top of it in
> >> > > >> the next few months, so that doesn't leave us much more
> >> > > >> time to change it again. :)
> >> > > >>
> >> > > >> These changes will remove the need for the eo_do family of
> >> > > >> functions. Functions will now look like normal C functions
> >> > > >> (which they are). There are many benefits to that, and we
> >> > > >> have many cool new ideas.
> >> > > >>
> >> > > >> For more info: https://phab.enlightenment.org/w/eo/
> >> > > >>
> >> > > >> I'm sending this email as an head's up, as I'll be starting
> >> > > >> to work on migrating to the new Eo syntax (and implementing
> >> > > >> it) today. Felipe and I have actually already started
> >> > > >> (needed to for the PoC), but I plan on pushing my changes
> >> > > >> to master soon.
> >> > > >>
> >> > > >> If you have any issues/suggestions/comments with the
> >> > > >> proposal, please let me know, either in pm, irc or just
> >> > > >> here. 
> >> > > >
> >> > > > Changes are in! I still haven't migrated eo_add to the new
> >> > > > syntax (it uses a non portable gcc extension in the
> >> > > > meanwhile), but otherwise everything is in. Took me *much*
> >> > > > less time than I thought it would, so yay. :P
> >> > > >
> >> > > > I decided to push it now instead of letting it rest in my
> >> > > > branch for a while because literally every hour that passed
> >> > > > introduced more merge conflicts for me, so the benefits from
> >> > > > stabilising it more in my branch were diminished by the new
> >> > > > conflicts and issues that could arise.
> >> > > >
> >> > > > If you have an application that uses the Eo api, you can use
> >> > > > my script https://devs.enlightenment.org/~tasn/migrate_eo.py
> >> > > > to migrate your code. When using the script you should keep
> >> > > > two things in mind: 1. You are only allowed to run it *once*
> >> > > > per source code, because the changes to eo_add() would
> >> > > > otherwise accumulate and your code will be wrong. If you
> >> > > > need to correct something you've done wrong, reset the code
> >> > > > to the previous state and run the script again on the
> >> > > > original code. 2. The migration script is not perfect. In
> >> > > > particular it can't deal with some corner cases like:
> >> > > > eo_do(obj, a_set(1), /* b_set(2),
> >> > > >  g_set(4), */
> >> > > >   c_set(2));
> >> > > > Or abominations like:
> >> > > > eo_do(obj, if (a_get())
> >> > > >   do_something());
> >> > > >
> >> > > > So please be aware of that and *manually* review your
> >> > > > changes after the script has run.
> >> > > >
> >> > > > If your code does have these cases, I recommend you either
> >> > > > get rid of them, or manually migrate that code before
> >> > > > running the script (remove the relevant eo_do).
> >> > > >
> >> > > > Follow the wiki page mentioned in the previous email for more
> >> > > > information about Eo and what else needs changing.
> >> > > >
> >> > > > Please let me know about any regressions (there shouldn't be
> >> > > > any) or any issues you may face.  
> >> > >
> >> > > I'm now pushing my changes to eo_add. I'm pushing it now for
> >> > > the same reason I pushed the previous changes in.
> >> > >
> >> > > I created a new script that assumes the code has already been
> >> > > migrated with the previous (migrate_eo.py) script. This script
> >> > > is called migrate_eo_add.py and can be found at:
> >> > > https://devs.enlightenment.org/~tasn/migrate_eo_add.py
> >> > >
> >> > > When using the script you should keep two things in mind:
> >> > > 1. You are only allowed to run it *once* per source code,
> >> > > because the changes to eo_add() would otherwise accumulate and
> >> > > your code will

Re: [E-devel] Eo: Changes to syntax

2016-03-09 Thread Daniel Zaoui 
On Thu, 10 Mar 2016 15:05:38 +0900
Carsten Haitzler  (The Rasterman) wrote:

> On Thu, 10 Mar 2016 07:42:22 +0200 Daniel Zaoui
>  said:
> 
> > On Wed, 09 Mar 2016 16:23:04 +
> > Tom Hacohen  wrote:
> >   
> > > On 03/03/16 10:22, Tom Hacohen wrote:  
> > > > On 01/03/16 09:05, Tom Hacohen wrote:
> > > >> Hey,
> > > >>
> > > >> The Eo syntax is going to be changing once more, and this
> > > >> time, I really think/hope it'll be the last time. We plan on
> > > >> stabilizing Eo and all of the functions on top of it in the
> > > >> next few months, so that doesn't leave us much more time to
> > > >> change it again. :)
> > > >>
> > > >> These changes will remove the need for the eo_do family of
> > > >> functions. Functions will now look like normal C functions
> > > >> (which they are). There are many benefits to that, and we have
> > > >> many cool new ideas.
> > > >>
> > > >> For more info: https://phab.enlightenment.org/w/eo/
> > > >>
> > > >> I'm sending this email as an head's up, as I'll be starting to
> > > >> work on migrating to the new Eo syntax (and implementing it)
> > > >> today. Felipe and I have actually already started (needed to
> > > >> for the PoC), but I plan on pushing my changes to master soon.
> > > >>
> > > >> If you have any issues/suggestions/comments with the proposal,
> > > >> please let me know, either in pm, irc or just here.
> > > >>
> > > >
> > > > Changes are in! I still haven't migrated eo_add to the new
> > > > syntax (it uses a non portable gcc extension in the meanwhile),
> > > > but otherwise everything is in. Took me *much* less time than I
> > > > thought it would, so yay. :P
> > > >
> > > > I decided to push it now instead of letting it rest in my branch
> > > > for a while because literally every hour that passed introduced
> > > > more merge conflicts for me, so the benefits from stabilising it
> > > > more in my branch were diminished by the new conflicts and
> > > > issues that could arise.
> > > >
> > > > If you have an application that uses the Eo api, you can use my
> > > > script https://devs.enlightenment.org/~tasn/migrate_eo.py to
> > > > migrate your code. When using the script you should keep two
> > > > things in mind: 1. You are only allowed to run it *once* per
> > > > source code, because the changes to eo_add() would otherwise
> > > > accumulate and your code will be wrong. If you need to correct
> > > > something you've done wrong, reset the code to the previous
> > > > state and run the script again on the original code. 2. The
> > > > migration script is not perfect. In particular it can't deal
> > > > with some corner cases like: eo_do(obj, a_set(1),
> > > > /* b_set(2),
> > > >  g_set(4), */
> > > > c_set(2));
> > > > Or abominations like:
> > > > eo_do(obj, if (a_get())
> > > > do_something());
> > > >
> > > > So please be aware of that and *manually* review your changes
> > > > after the script has run.
> > > >
> > > > If your code does have these cases, I recommend you either get
> > > > rid of them, or manually migrate that code before running the
> > > > script (remove the relevant eo_do).
> > > >
> > > > Follow the wiki page mentioned in the previous email for more
> > > > information about Eo and what else needs changing.
> > > >
> > > > Please let me know about any regressions (there shouldn't be
> > > > any) or any issues you may face.
> > > 
> > > I'm now pushing my changes to eo_add. I'm pushing it now for the
> > > same reason I pushed the previous changes in.
> > > 
> > > I created a new script that assumes the code has already been
> > > migrated with the previous (migrate_eo.py) script. This script is
> > > called migrate_eo_add.py and can be found at: 
> > > https://devs.enlightenment.org/~tasn/migrate_eo_add.py
> > > 
> > > When using the script you should keep two things in mind:
> > > 1. You are only allowed to run it *once* per source code, because
> > > the changes to eo_add() would otherwise accumulate and your code
> > > will be wrong. If you need to correct something you've done
> > > wrong, reset the code to the previous state and run the script
> > > again on the original code. 2. The migration script is not
> > > perfect. In particular it can't deal with cases like missing {}
> > > for if/for/while content so for example,
> > > 
> > > if ()
> > > return eo_add(...)
> > > 
> > > would break.
> > > 3. If you are fancy and use the same variable inside eo_add and
> > > outside, for example like:
> > > parent = eo_add(CLASS, parent);
> > > 
> > > your code will break. I suggest you use a temporary variable.
> > > 
> > > So please be aware of that and *manually* review your changes
> > > after the script has run.
> > > 
> > > If your code does have these cases, I recommend you either get
> > > rid of them, or manually migrate that code before running the
> > > script (remove the relevant eo_do).
> > > 
> > > 
> > >

Re: [E-devel] UI syntax, letter 2

2016-03-09 Thread Simon Lees 


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=/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=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: Changes to syntax

2016-03-09 Thread Jean-Philippe André 
Oh and I forgot, those changes add ~60 warnings in EFL with clang:

  CC   lib/evas/canvas/lib_evas_libevas_la-evas_object_line.lo
/home/jpeg/e/core/efl/src/lib/evas/canvas/evas_object_line.c:101:5:
warning: expression result unused [-Wunused-value]
   ((Eo *) ( *_obj =
_eo_add_internal_start("/home/jpeg/e/core/efl/src/lib/evas/canvas/evas_object_line.c",
101, evas_line_class_get(), e, ((Eina_Bool)0)), *_obj =
_eo_add_end(*_obj) ));


On 10 March 2016 at 15:46, Jean-Philippe André  wrote:

>
>
> On 10 March 2016 at 15:05, Carsten Haitzler  wrote:
>
>> On Thu, 10 Mar 2016 07:42:22 +0200 Daniel Zaoui 
>> said:
>>
>> > On Wed, 09 Mar 2016 16:23:04 +
>> > Tom Hacohen  wrote:
>> >
>> > > On 03/03/16 10:22, Tom Hacohen wrote:
>> > > > On 01/03/16 09:05, Tom Hacohen wrote:
>> > > >> Hey,
>> > > >>
>> > > >> The Eo syntax is going to be changing once more, and this time, I
>> > > >> really think/hope it'll be the last time. We plan on stabilizing
>> > > >> Eo and all of the functions on top of it in the next few months,
>> > > >> so that doesn't leave us much more time to change it again. :)
>> > > >>
>> > > >> These changes will remove the need for the eo_do family of
>> > > >> functions. Functions will now look like normal C functions (which
>> > > >> they are). There are many benefits to that, and we have many cool
>> > > >> new ideas.
>> > > >>
>> > > >> For more info: https://phab.enlightenment.org/w/eo/
>> > > >>
>> > > >> I'm sending this email as an head's up, as I'll be starting to
>> > > >> work on migrating to the new Eo syntax (and implementing it)
>> > > >> today. Felipe and I have actually already started (needed to for
>> > > >> the PoC), but I plan on pushing my changes to master soon.
>> > > >>
>> > > >> If you have any issues/suggestions/comments with the proposal,
>> > > >> please let me know, either in pm, irc or just here.
>> > > >>
>> > > >
>> > > > Changes are in! I still haven't migrated eo_add to the new syntax
>> > > > (it uses a non portable gcc extension in the meanwhile), but
>> > > > otherwise everything is in. Took me *much* less time than I thought
>> > > > it would, so yay. :P
>> > > >
>> > > > I decided to push it now instead of letting it rest in my branch
>> > > > for a while because literally every hour that passed introduced
>> > > > more merge conflicts for me, so the benefits from stabilising it
>> > > > more in my branch were diminished by the new conflicts and issues
>> > > > that could arise.
>> > > >
>> > > > If you have an application that uses the Eo api, you can use my
>> > > > script https://devs.enlightenment.org/~tasn/migrate_eo.py to
>> > > > migrate your code. When using the script you should keep two things
>> > > > in mind: 1. You are only allowed to run it *once* per source code,
>> > > > because the changes to eo_add() would otherwise accumulate and your
>> > > > code will be wrong. If you need to correct something you've done
>> > > > wrong, reset the code to the previous state and run the script
>> > > > again on the original code. 2. The migration script is not perfect.
>> > > > In particular it can't deal with some corner cases like:
>> > > > eo_do(obj, a_set(1),
>> > > > /* b_set(2),
>> > > >  g_set(4), */
>> > > >   c_set(2));
>> > > > Or abominations like:
>> > > > eo_do(obj, if (a_get())
>> > > >   do_something());
>> > > >
>> > > > So please be aware of that and *manually* review your changes after
>> > > > the script has run.
>> > > >
>> > > > If your code does have these cases, I recommend you either get rid
>> > > > of them, or manually migrate that code before running the script
>> > > > (remove the relevant eo_do).
>> > > >
>> > > > Follow the wiki page mentioned in the previous email for more
>> > > > information about Eo and what else needs changing.
>> > > >
>> > > > Please let me know about any regressions (there shouldn't be any)
>> > > > or any issues you may face.
>> > >
>> > > I'm now pushing my changes to eo_add. I'm pushing it now for the same
>> > > reason I pushed the previous changes in.
>> > >
>> > > I created a new script that assumes the code has already been
>> > > migrated with the previous (migrate_eo.py) script. This script is
>> > > called migrate_eo_add.py and can be found at:
>> > > https://devs.enlightenment.org/~tasn/migrate_eo_add.py
>> > >
>> > > When using the script you should keep two things in mind:
>> > > 1. You are only allowed to run it *once* per source code, because the
>> > > changes to eo_add() would otherwise accumulate and your code will be
>> > > wrong. If you need to correct something you've done wrong, reset the
>> > > code to the previous state and run the script again on the original
>> > > code. 2. The migration script is not perfect. In particular it can't
>> > > deal with cases like missing {} for if/for/while content so for
>> > > example,
>> > >
>> > > if ()
>> > > return eo_add(...)
>> > >

Re: [E-devel] Eo: Changes to syntax

2016-03-09 Thread Jean-Philippe André 
On 10 March 2016 at 15:05, Carsten Haitzler  wrote:

> On Thu, 10 Mar 2016 07:42:22 +0200 Daniel Zaoui 
> said:
>
> > On Wed, 09 Mar 2016 16:23:04 +
> > Tom Hacohen  wrote:
> >
> > > On 03/03/16 10:22, Tom Hacohen wrote:
> > > > On 01/03/16 09:05, Tom Hacohen wrote:
> > > >> Hey,
> > > >>
> > > >> The Eo syntax is going to be changing once more, and this time, I
> > > >> really think/hope it'll be the last time. We plan on stabilizing
> > > >> Eo and all of the functions on top of it in the next few months,
> > > >> so that doesn't leave us much more time to change it again. :)
> > > >>
> > > >> These changes will remove the need for the eo_do family of
> > > >> functions. Functions will now look like normal C functions (which
> > > >> they are). There are many benefits to that, and we have many cool
> > > >> new ideas.
> > > >>
> > > >> For more info: https://phab.enlightenment.org/w/eo/
> > > >>
> > > >> I'm sending this email as an head's up, as I'll be starting to
> > > >> work on migrating to the new Eo syntax (and implementing it)
> > > >> today. Felipe and I have actually already started (needed to for
> > > >> the PoC), but I plan on pushing my changes to master soon.
> > > >>
> > > >> If you have any issues/suggestions/comments with the proposal,
> > > >> please let me know, either in pm, irc or just here.
> > > >>
> > > >
> > > > Changes are in! I still haven't migrated eo_add to the new syntax
> > > > (it uses a non portable gcc extension in the meanwhile), but
> > > > otherwise everything is in. Took me *much* less time than I thought
> > > > it would, so yay. :P
> > > >
> > > > I decided to push it now instead of letting it rest in my branch
> > > > for a while because literally every hour that passed introduced
> > > > more merge conflicts for me, so the benefits from stabilising it
> > > > more in my branch were diminished by the new conflicts and issues
> > > > that could arise.
> > > >
> > > > If you have an application that uses the Eo api, you can use my
> > > > script https://devs.enlightenment.org/~tasn/migrate_eo.py to
> > > > migrate your code. When using the script you should keep two things
> > > > in mind: 1. You are only allowed to run it *once* per source code,
> > > > because the changes to eo_add() would otherwise accumulate and your
> > > > code will be wrong. If you need to correct something you've done
> > > > wrong, reset the code to the previous state and run the script
> > > > again on the original code. 2. The migration script is not perfect.
> > > > In particular it can't deal with some corner cases like:
> > > > eo_do(obj, a_set(1),
> > > > /* b_set(2),
> > > >  g_set(4), */
> > > >   c_set(2));
> > > > Or abominations like:
> > > > eo_do(obj, if (a_get())
> > > >   do_something());
> > > >
> > > > So please be aware of that and *manually* review your changes after
> > > > the script has run.
> > > >
> > > > If your code does have these cases, I recommend you either get rid
> > > > of them, or manually migrate that code before running the script
> > > > (remove the relevant eo_do).
> > > >
> > > > Follow the wiki page mentioned in the previous email for more
> > > > information about Eo and what else needs changing.
> > > >
> > > > Please let me know about any regressions (there shouldn't be any)
> > > > or any issues you may face.
> > >
> > > I'm now pushing my changes to eo_add. I'm pushing it now for the same
> > > reason I pushed the previous changes in.
> > >
> > > I created a new script that assumes the code has already been
> > > migrated with the previous (migrate_eo.py) script. This script is
> > > called migrate_eo_add.py and can be found at:
> > > https://devs.enlightenment.org/~tasn/migrate_eo_add.py
> > >
> > > When using the script you should keep two things in mind:
> > > 1. You are only allowed to run it *once* per source code, because the
> > > changes to eo_add() would otherwise accumulate and your code will be
> > > wrong. If you need to correct something you've done wrong, reset the
> > > code to the previous state and run the script again on the original
> > > code. 2. The migration script is not perfect. In particular it can't
> > > deal with cases like missing {} for if/for/while content so for
> > > example,
> > >
> > > if ()
> > > return eo_add(...)
> > >
> > > would break.
> > > 3. If you are fancy and use the same variable inside eo_add and
> > > outside, for example like:
> > > parent = eo_add(CLASS, parent);
> > >
> > > your code will break. I suggest you use a temporary variable.
> > >
> > > So please be aware of that and *manually* review your changes after
> > > the script has run.
> > >
> > > If your code does have these cases, I recommend you either get rid of
> > > them, or manually migrate that code before running the script (remove
> > > the relevant eo_do).
> > >
> > >
> > >
> > > Sorry, but C++ will break until the C++ guys fix it. I'm now in the
>

Re: [E-devel] Eo: Changes to syntax

2016-03-09 Thread The Rasterman 
On Thu, 10 Mar 2016 07:42:22 +0200 Daniel Zaoui  said:

> On Wed, 09 Mar 2016 16:23:04 +
> Tom Hacohen  wrote:
> 
> > On 03/03/16 10:22, Tom Hacohen wrote:
> > > On 01/03/16 09:05, Tom Hacohen wrote:  
> > >> Hey,
> > >>
> > >> The Eo syntax is going to be changing once more, and this time, I
> > >> really think/hope it'll be the last time. We plan on stabilizing
> > >> Eo and all of the functions on top of it in the next few months,
> > >> so that doesn't leave us much more time to change it again. :)
> > >>
> > >> These changes will remove the need for the eo_do family of
> > >> functions. Functions will now look like normal C functions (which
> > >> they are). There are many benefits to that, and we have many cool
> > >> new ideas.
> > >>
> > >> For more info: https://phab.enlightenment.org/w/eo/
> > >>
> > >> I'm sending this email as an head's up, as I'll be starting to
> > >> work on migrating to the new Eo syntax (and implementing it)
> > >> today. Felipe and I have actually already started (needed to for
> > >> the PoC), but I plan on pushing my changes to master soon.
> > >>
> > >> If you have any issues/suggestions/comments with the proposal,
> > >> please let me know, either in pm, irc or just here.
> > >>  
> > >
> > > Changes are in! I still haven't migrated eo_add to the new syntax
> > > (it uses a non portable gcc extension in the meanwhile), but
> > > otherwise everything is in. Took me *much* less time than I thought
> > > it would, so yay. :P
> > >
> > > I decided to push it now instead of letting it rest in my branch
> > > for a while because literally every hour that passed introduced
> > > more merge conflicts for me, so the benefits from stabilising it
> > > more in my branch were diminished by the new conflicts and issues
> > > that could arise.
> > >
> > > If you have an application that uses the Eo api, you can use my
> > > script https://devs.enlightenment.org/~tasn/migrate_eo.py to
> > > migrate your code. When using the script you should keep two things
> > > in mind: 1. You are only allowed to run it *once* per source code,
> > > because the changes to eo_add() would otherwise accumulate and your
> > > code will be wrong. If you need to correct something you've done
> > > wrong, reset the code to the previous state and run the script
> > > again on the original code. 2. The migration script is not perfect.
> > > In particular it can't deal with some corner cases like:
> > > eo_do(obj, a_set(1),
> > > /* b_set(2),
> > >  g_set(4), */
> > >   c_set(2));
> > > Or abominations like:
> > > eo_do(obj, if (a_get())
> > >   do_something());
> > >
> > > So please be aware of that and *manually* review your changes after
> > > the script has run.
> > >
> > > If your code does have these cases, I recommend you either get rid
> > > of them, or manually migrate that code before running the script
> > > (remove the relevant eo_do).
> > >
> > > Follow the wiki page mentioned in the previous email for more
> > > information about Eo and what else needs changing.
> > >
> > > Please let me know about any regressions (there shouldn't be any)
> > > or any issues you may face.  
> > 
> > I'm now pushing my changes to eo_add. I'm pushing it now for the same 
> > reason I pushed the previous changes in.
> > 
> > I created a new script that assumes the code has already been
> > migrated with the previous (migrate_eo.py) script. This script is
> > called migrate_eo_add.py and can be found at: 
> > https://devs.enlightenment.org/~tasn/migrate_eo_add.py
> > 
> > When using the script you should keep two things in mind:
> > 1. You are only allowed to run it *once* per source code, because the
> > changes to eo_add() would otherwise accumulate and your code will be
> > wrong. If you need to correct something you've done wrong, reset the
> > code to the previous state and run the script again on the original
> > code. 2. The migration script is not perfect. In particular it can't
> > deal with cases like missing {} for if/for/while content so for
> > example,
> > 
> > if ()
> > return eo_add(...)
> > 
> > would break.
> > 3. If you are fancy and use the same variable inside eo_add and
> > outside, for example like:
> > parent = eo_add(CLASS, parent);
> > 
> > your code will break. I suggest you use a temporary variable.
> > 
> > So please be aware of that and *manually* review your changes after
> > the script has run.
> > 
> > If your code does have these cases, I recommend you either get rid of
> > them, or manually migrate that code before running the script (remove
> > the relevant eo_do).
> > 
> > 
> > 
> > Sorry, but C++ will break until the C++ guys fix it. I'm now in the 
> > process of migrating the rest of our applications. Hopefully this
> > will be the last disruption of this sort.
> > 
> 
> Sorry man but the new syntax is ugly. I still don't see why this change was
> needed. Please enlighten me. It reminds me the wonderful eo_do_ret

[E-devel] e www AGAIN can;'t commit

2016-03-09 Thread The Rasterman 
hey beber... dokuwiki is broken yet again - can't commit back to git. why does
this keep happening? now of course we likely will have conflicts as people are
editing on both sides.

-- 
- 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=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: Changes to syntax

2016-03-09 Thread Daniel Zaoui 
On Wed, 09 Mar 2016 16:23:04 +
Tom Hacohen  wrote:

> On 03/03/16 10:22, Tom Hacohen wrote:
> > On 01/03/16 09:05, Tom Hacohen wrote:  
> >> Hey,
> >>
> >> The Eo syntax is going to be changing once more, and this time, I
> >> really think/hope it'll be the last time. We plan on stabilizing
> >> Eo and all of the functions on top of it in the next few months,
> >> so that doesn't leave us much more time to change it again. :)
> >>
> >> These changes will remove the need for the eo_do family of
> >> functions. Functions will now look like normal C functions (which
> >> they are). There are many benefits to that, and we have many cool
> >> new ideas.
> >>
> >> For more info: https://phab.enlightenment.org/w/eo/
> >>
> >> I'm sending this email as an head's up, as I'll be starting to
> >> work on migrating to the new Eo syntax (and implementing it)
> >> today. Felipe and I have actually already started (needed to for
> >> the PoC), but I plan on pushing my changes to master soon.
> >>
> >> If you have any issues/suggestions/comments with the proposal,
> >> please let me know, either in pm, irc or just here.
> >>  
> >
> > Changes are in! I still haven't migrated eo_add to the new syntax
> > (it uses a non portable gcc extension in the meanwhile), but
> > otherwise everything is in. Took me *much* less time than I thought
> > it would, so yay. :P
> >
> > I decided to push it now instead of letting it rest in my branch
> > for a while because literally every hour that passed introduced
> > more merge conflicts for me, so the benefits from stabilising it
> > more in my branch were diminished by the new conflicts and issues
> > that could arise.
> >
> > If you have an application that uses the Eo api, you can use my
> > script https://devs.enlightenment.org/~tasn/migrate_eo.py to
> > migrate your code. When using the script you should keep two things
> > in mind: 1. You are only allowed to run it *once* per source code,
> > because the changes to eo_add() would otherwise accumulate and your
> > code will be wrong. If you need to correct something you've done
> > wrong, reset the code to the previous state and run the script
> > again on the original code. 2. The migration script is not perfect.
> > In particular it can't deal with some corner cases like:
> > eo_do(obj, a_set(1),
> > /* b_set(2),
> >  g_set(4), */
> > c_set(2));
> > Or abominations like:
> > eo_do(obj, if (a_get())
> > do_something());
> >
> > So please be aware of that and *manually* review your changes after
> > the script has run.
> >
> > If your code does have these cases, I recommend you either get rid
> > of them, or manually migrate that code before running the script
> > (remove the relevant eo_do).
> >
> > Follow the wiki page mentioned in the previous email for more
> > information about Eo and what else needs changing.
> >
> > Please let me know about any regressions (there shouldn't be any)
> > or any issues you may face.  
> 
> I'm now pushing my changes to eo_add. I'm pushing it now for the same 
> reason I pushed the previous changes in.
> 
> I created a new script that assumes the code has already been
> migrated with the previous (migrate_eo.py) script. This script is
> called migrate_eo_add.py and can be found at: 
> https://devs.enlightenment.org/~tasn/migrate_eo_add.py
> 
> When using the script you should keep two things in mind:
> 1. You are only allowed to run it *once* per source code, because the
> changes to eo_add() would otherwise accumulate and your code will be
> wrong. If you need to correct something you've done wrong, reset the
> code to the previous state and run the script again on the original
> code. 2. The migration script is not perfect. In particular it can't
> deal with cases like missing {} for if/for/while content so for
> example,
> 
> if ()
> return eo_add(...)
> 
> would break.
> 3. If you are fancy and use the same variable inside eo_add and
> outside, for example like:
> parent = eo_add(CLASS, parent);
> 
> your code will break. I suggest you use a temporary variable.
> 
> So please be aware of that and *manually* review your changes after
> the script has run.
> 
> If your code does have these cases, I recommend you either get rid of
> them, or manually migrate that code before running the script (remove
> the relevant eo_do).
> 
> 
> 
> Sorry, but C++ will break until the C++ guys fix it. I'm now in the 
> process of migrating the rest of our applications. Hopefully this
> will be the last disruption of this sort.
> 

Sorry man but the new syntax is ugly. I still don't see why this change was 
needed. Please enlighten me. It reminds me the wonderful eo_do_ret syntax :-)

So yes Tom I vomit on your eo_add 


  BBEEEUUAH...

%%
    = =
   %%C>
_)' _( .' ,
 __/ |_/\   " *. o
/` \_\ \/ %`= '_  .
   /  )

Re: [E-devel] UI syntax, letter 2

2016-03-09 Thread David Seikel 
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=/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

2016-03-09 Thread The Rasterman 
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=/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=/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=/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

2016-03-09 Thread The Rasterman 
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=/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=/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

2016-03-09 Thread Felipe Magno de Almeida 
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=/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

2016-03-09 Thread thomasg 
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=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Enlightenment DR 0.20.6 Release

2016-03-09 Thread Mike Blumenkrantz 
This bugfix release improves on the 0.20.5 release and resolves a number of
issues.
NOTE: Wayland >= 1.10 is now required for Wayland compositor support.

TICKETS ADDRESSED
https://phab.enlightenment.org/T3152
https://phab.enlightenment.org/T3208
https://phab.enlightenment.org/T3210

SHA256SUM + DOWNLOAD
b4404e15b4388c968d03179171ab82b41a856e473c2adda94ca726050e430a98
http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.20.6.tar.gz

f21fbace15b8ea0e47c7aeb16a3f4d1e8a41cb85bc0035491091518b0ca55085
http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.20.6.tar.xz


See the full announcement for more details:
https://ereleaseblog.wordpress.com/2016/03/09/enlightenment-dr-0-20-6-release/
--
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=/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

2016-03-09 Thread Leif Middelschulte 

> 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=/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=/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

2016-03-09 Thread Simon Lees 


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=/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=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: Changes to syntax

2016-03-09 Thread Tom Hacohen 
On 03/03/16 10:22, Tom Hacohen wrote:
> On 01/03/16 09:05, Tom Hacohen wrote:
>> Hey,
>>
>> The Eo syntax is going to be changing once more, and this time, I really
>> think/hope it'll be the last time. We plan on stabilizing Eo and all of
>> the functions on top of it in the next few months, so that doesn't leave
>> us much more time to change it again. :)
>>
>> These changes will remove the need for the eo_do family of functions.
>> Functions will now look like normal C functions (which they are). There
>> are many benefits to that, and we have many cool new ideas.
>>
>> For more info: https://phab.enlightenment.org/w/eo/
>>
>> I'm sending this email as an head's up, as I'll be starting to work on
>> migrating to the new Eo syntax (and implementing it) today. Felipe and I
>> have actually already started (needed to for the PoC), but I plan on
>> pushing my changes to master soon.
>>
>> If you have any issues/suggestions/comments with the proposal, please
>> let me know, either in pm, irc or just here.
>>
>
> Changes are in! I still haven't migrated eo_add to the new syntax (it
> uses a non portable gcc extension in the meanwhile), but otherwise
> everything is in. Took me *much* less time than I thought it would, so
> yay. :P
>
> I decided to push it now instead of letting it rest in my branch for a
> while because literally every hour that passed introduced more merge
> conflicts for me, so the benefits from stabilising it more in my branch
> were diminished by the new conflicts and issues that could arise.
>
> If you have an application that uses the Eo api, you can use my script
> https://devs.enlightenment.org/~tasn/migrate_eo.py to migrate your code.
> When using the script you should keep two things in mind:
> 1. You are only allowed to run it *once* per source code, because the
> changes to eo_add() would otherwise accumulate and your code will be
> wrong. If you need to correct something you've done wrong, reset the
> code to the previous state and run the script again on the original code.
> 2. The migration script is not perfect. In particular it can't deal with
> some corner cases like:
> eo_do(obj, a_set(1),
> /* b_set(2),
>  g_set(4), */
>   c_set(2));
> Or abominations like:
> eo_do(obj, if (a_get())
>   do_something());
>
> So please be aware of that and *manually* review your changes after the
> script has run.
>
> If your code does have these cases, I recommend you either get rid of
> them, or manually migrate that code before running the script (remove
> the relevant eo_do).
>
> Follow the wiki page mentioned in the previous email for more
> information about Eo and what else needs changing.
>
> Please let me know about any regressions (there shouldn't be any) or any
> issues you may face.

I'm now pushing my changes to eo_add. I'm pushing it now for the same 
reason I pushed the previous changes in.

I created a new script that assumes the code has already been migrated 
with the previous (migrate_eo.py) script. This script is called 
migrate_eo_add.py and can be found at: 
https://devs.enlightenment.org/~tasn/migrate_eo_add.py

When using the script you should keep two things in mind:
1. You are only allowed to run it *once* per source code, because the
changes to eo_add() would otherwise accumulate and your code will be
wrong. If you need to correct something you've done wrong, reset the
code to the previous state and run the script again on the original code.
2. The migration script is not perfect. In particular it can't deal with
cases like missing {} for if/for/while content so for example,

if ()
return eo_add(...)

would break.
3. If you are fancy and use the same variable inside eo_add and outside, 
for example like:
parent = eo_add(CLASS, parent);

your code will break. I suggest you use a temporary variable.

So please be aware of that and *manually* review your changes after the
script has run.

If your code does have these cases, I recommend you either get rid of
them, or manually migrate that code before running the script (remove
the relevant eo_do).



Sorry, but C++ will break until the C++ guys fix it. I'm now in the 
process of migrating the rest of our applications. Hopefully this will 
be the last disruption of this sort.

--
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=/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

2016-03-09 Thread Tom Hacohen 
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=/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

2016-03-09 Thread Simon Lees 


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=/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

2016-03-09 Thread 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


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=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel