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

[Yakov Goldberg]

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] Enlightenment DR 0.20.6 Release

[Vasiliy Tolstov]

2016-03-09 21:04 GMT+03:00 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/


Where i can find info how to build enlightenment and efl with wayland
support and run enlightenment under wayland?

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

--
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] Enlightenment DR 0.20.6 Release

[Simon Lees]

On 03/10/2016 10:04 AM, Vasiliy Tolstov wrote:
> 2016-03-09 21:04 GMT+03:00 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/
> 
> 
> Where i can find info how to build enlightenment and efl with wayland
> support and run enlightenment under wayland?
> 
https://git.enlightenment.org/core/enlightenment.git/tree/README.wayland

is probably still up to date.



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] Eo: Changes to syntax

[Tom Hacohen]

On 10/03/16 06: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(...)

 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 

[E-devel] Probie proposal: youngbok (Youngbok Shin)

[Daniel Hirt]

Hello,

I would like to promote Youngbok Shin to probie. We are working together
a lot to add features and fixes to both efl and elementary.

He has quite a few patches in EFL already, and personally, it really is
going to make my life easier during our current work for Elementary
Interfaces and future patches.

I doubt there's gonna be any objections, but will wait until Sunday if
anyone wants to reply.

Best regards,

--
Daniel Hirt (aka herdsman aka D4)

--
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] Eo: Changes to syntax

[Tom Hacohen]

Is it possible that your clang is buggy? I'm also using clang with the 
following cflags: -g3 -O2 -Wall -Wextra -Wshadow -Wno-type-limits 
-Wpointer-arith -Wno-missing-field-initializers -Wstrict-prototypes 
-fvisibility=hidden
Clang version: 3.7.1

Zero warnings.

Looking at the code, zero warnings is correct, because the result is used.

--
Tom.


On 10/03/16 06:48, 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 *) ( *&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)), *&eo_obj =
> _eo_add_end(*&eo_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

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

[Tom Hacohen]

On 10/03/16 05:43, Carsten Haitzler wrote:
> 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.
>

Adding his personal email. I guess ssh-agent died again?

Nothing has changed in the gitolite side.

--
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] 1.18 schedule proposal

[Stefan Schmidt]

Hello.

On 07/03/16 10:21, Stefan Schmidt wrote:
> Hello.
>
> On 03/03/16 11:41, Stefan Schmidt wrote:
>> Hello.
>>
>> Some people might be wondering why there was no schedule for 1.18 yet
>> while we are already in the development phase of it after 1.17 was
>> released. The simple reason is that 1.18 will be different from the
>> normal 3 months rhythm we had the last 9 (!) release cycles. It should
>> be an exception though and we should go back to the normal rhythm with 1.19.
>>
>> 1.18 will be on a longer schedule as we have two major things we need to
>> coordinate together and that would just not work in our three months
>> schedule. We are merging Elementary into EFL and getting the EFL
>> Interface (aka EFL 2.0 API) finalised.
>>
>> If you have comments please let me know. I will give it a week to gather
>> comments before making it final.
>>
>> === Schedule ===
>> 2016-02-02 Merge window for 1.18 opens
>> (2016-05-14 Enlightenment Developer Days in Paris. This should be the
>> point where the major work is done and we discuss left overs and how to
>> fix them for 1.18)
>> 2016-05-17 Technical preview tarballs for packagers
>> 2016-05-30 Notice about soon ending merge window
>> 2016-06-06 Merge window is over.
>> * Only bug fixes from this point
>> * Alpha release tarball
>> * One month stabilization phase starts
>> 2016-06-13 Beta1 release tarball
>> * Only critical fixes from this point
>> 2016-06-20 Beta2 release tarball
>> 2016-06-27 Beta3 release tarball
>> 2016-07-04 EFL 1.18 is out (First Monday in July)
>>
>> https://phab.enlightenment.org/w/efl_and_elementary_1_18/
>>
> Are there any more comments to this schedule proposal? If not I would
> consider it fixed in the next days.

I got only positive feedback here and nobody spoke up that they disagree 
with the schedule. I consider it finalised now. Add the dates to your 
calendar.

regards
Stefan Schmidt


--
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] Probie proposal: youngbok (Youngbok Shin)

[Hermet Park]

+1 

-Original Message-
From: "Daniel Hirt" 
To: "Enlightenment developer list"; 
Cc: 
Sent: 2016-03-10 (목) 18:59:06
Subject: [E-devel] Probie proposal: youngbok (Youngbok Shin)
 
Hello,

I would like to promote Youngbok Shin to probie. We are working together
a lot to add features and fixes to both efl and elementary.

He has quite a few patches in EFL already, and personally, it really is
going to make my life easier during our current work for Elementary
Interfaces and future patches.

I doubt there's gonna be any objections, but will wait until Sunday if
anyone wants to reply.

Best regards,

--
Daniel Hirt (aka herdsman aka D4)

--
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] Enlightenment DR 0.20.6 Release

[Vasiliy Tolstov]

2016-03-10 12:09 GMT+03:00 Simon Lees :
>> Where i can find info how to build enlightenment and efl with wayland
>> support and run enlightenment under wayland?
>>
> https://git.enlightenment.org/core/enlightenment.git/tree/README.wayland
>
> is probably still up to date.


Thanks! What needed to fix this: * Keyboard layout switching is not
available  - Requires various improvements ?


-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

--
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] e www AGAIN can;'t commit

[Bertrand Jacquin]

It's been just fixed now. I have some fix (again) to apply to the init 
script.

On 10/03/2016 05:43, Carsten Haitzler wrote:
> 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.

-- 
Bertrand

--
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] [EGIT] [core/elementary] master 01/01: Scaling test: reorder instructions to set the correct scale

[Hermet Park]

Sounds like elm scale function is broken. :(
 
-Original Message-
From: "Daniel Zaoui" 
To: ; 
Cc: 
Sent: 2016-03-03 (목) 17:54:51
Subject: [EGIT] [core/elementary] master 01/01: Scaling test: reorder 
instructions to set the correct scale
 
jackdanielz pushed a commit to branch master.

http://git.enlightenment.org/core/elementary.git/commit/?id=36669f1eccc3b6c320fb4c4ecc0e029b95834f57

commit 36669f1eccc3b6c320fb4c4ecc0e029b95834f57
Author: Daniel Zaoui 
Date:   Thu Mar 3 10:25:22 2016 +0200

Scaling test: reorder instructions to set the correct scale

If the scale is set on an object before contents are set, it will not
pass to them. Because of this, in the test, scale of the first label
remains 1.0, i.e the window scale, instead of 0.5.
The patch modifies the order of the instructions by setting the scale
after setting the label as content of the frame.
---
 src/bin/test_scaling.c  2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/bin/test_scaling.c b/src/bin/test_scaling.c
index d0d0f3c..84b20c6 100644
--- a/src/bin/test_scaling.c
+++ b/src/bin/test_scaling.c
@@ -76,7 +76,6 @@ test_scaling2(void *data EINA_UNUSED, Evas_Object *obj 
EINA_UNUSED, void *event_
evas_object_show(bx);
 
fr = elm_frame_add(win);
-   elm_object_scale_set(fr, 0.5);
elm_object_text_set(fr, "Scale: 0.5");
lb = elm_label_add(win);
elm_object_text_set(lb,
@@ -84,6 +83,7 @@ test_scaling2(void *data EINA_UNUSED, Evas_Object *obj 
EINA_UNUSED, void *event_
"is 0.5. Child should"
"inherit it.");
elm_object_content_set(fr, lb);
+   elm_object_scale_set(fr, 0.5);
evas_object_show(lb);
elm_box_pack_end(bx, fr);
evas_object_show(fr);

-- 

--
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] [EGIT] [core/elementary] master 01/01: Scaling test: reorder instructions to set the correct scale

[Tom Hacohen]

It's not the elm scale function, it's elm widget that needs to propagate 
scale when adding a child. Jack, you should update elm_widget instead of 
hiding the bug.

--
Tom.

On 10/03/16 10:57, Hermet Park wrote:
> Sounds like elm scale function is broken. :(
>
> -Original Message-
> From: "Daniel Zaoui"
> To: ;
> Cc:
> Sent: 2016-03-03 (목) 17:54:51
> Subject: [EGIT] [core/elementary] master 01/01: Scaling test: reorder 
> instructions to set the correct scale
>
> jackdanielz pushed a commit to branch master.
>
> http://git.enlightenment.org/core/elementary.git/commit/?id=36669f1eccc3b6c320fb4c4ecc0e029b95834f57
>
> commit 36669f1eccc3b6c320fb4c4ecc0e029b95834f57
> Author: Daniel Zaoui 
> Date:   Thu Mar 3 10:25:22 2016 +0200
>
>  Scaling test: reorder instructions to set the correct scale
>
>  If the scale is set on an object before contents are set, it will not
>  pass to them. Because of this, in the test, scale of the first label
>  remains 1.0, i.e the window scale, instead of 0.5.
>  The patch modifies the order of the instructions by setting the scale
>  after setting the label as content of the frame.
> ---
>   src/bin/test_scaling.c  2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/bin/test_scaling.c b/src/bin/test_scaling.c
> index d0d0f3c..84b20c6 100644
> --- a/src/bin/test_scaling.c
> +++ b/src/bin/test_scaling.c
> @@ -76,7 +76,6 @@ test_scaling2(void *data EINA_UNUSED, Evas_Object *obj 
> EINA_UNUSED, void *event_
>  evas_object_show(bx);
>
>  fr = elm_frame_add(win);
> -   elm_object_scale_set(fr, 0.5);
>  elm_object_text_set(fr, "Scale: 0.5");
>  lb = elm_label_add(win);
>  elm_object_text_set(lb,
> @@ -84,6 +83,7 @@ test_scaling2(void *data EINA_UNUSED, Evas_Object *obj 
> EINA_UNUSED, void *event_
>  "is 0.5. Child should"
>  "inherit it.");
>  elm_object_content_set(fr, lb);
> +   elm_object_scale_set(fr, 0.5);
>  evas_object_show(lb);
>  elm_box_pack_end(bx, fr);
>  evas_object_show(fr);
>


--
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] Eo: Changes to syntax

[Andrew Williams]

I'd be quite tempted by 1) - should it not only be the class or its
children that are able to inject functionality before finalisation?

Andy

On Thu, 10 Mar 2016 at 06:56, 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 <
> daniel.za...@samsung.com>
> > 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

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

[Tom Hacohen]

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] Eo: Changes to syntax

[Tom Hacohen]

On 10/03/16 09:57, Tom Hacohen wrote:
> On 10/03/16 06: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(...)
>
> 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 t

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

[Andrew Williams]

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] [EGIT] [core/elementary] master 01/01: Scaling test: reorder instructions to set the correct scale

[Hermet Park]

that's the elm scale function.
 
-Original Message-
From: "Tom Hacohen" 
To: ; 
Cc: 
Sent: 2016-03-10 (목) 20:14:34
Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: Scaling test: 
reorder instructions to set the correct scale
 
It's not the elm scale function, it's elm widget that needs to propagate 
scale when adding a child. Jack, you should update elm_widget instead of 
hiding the bug.

--
Tom.

On 10/03/16 10:57, Hermet Park wrote:
> Sounds like elm scale function is broken. :(
>
> -Original Message-
> From: "Daniel Zaoui"
> To: ;
> Cc:
> Sent: 2016-03-03 (목) 17:54:51
> Subject: [EGIT] [core/elementary] master 01/01: Scaling test: reorder 
> instructions to set the correct scale
>
> jackdanielz pushed a commit to branch master.
>
> http://git.enlightenment.org/core/elementary.git/commit/?id=36669f1eccc3b6c320fb4c4ecc0e029b95834f57
>
> commit 36669f1eccc3b6c320fb4c4ecc0e029b95834f57
> Author: Daniel Zaoui 
> Date:   Thu Mar 3 10:25:22 2016 +0200
>
>  Scaling test: reorder instructions to set the correct scale
>
>  If the scale is set on an object before contents are set, it will not
>  pass to them. Because of this, in the test, scale of the first label
>  remains 1.0, i.e the window scale, instead of 0.5.
>  The patch modifies the order of the instructions by setting the scale
>  after setting the label as content of the frame.
> ---
>   src/bin/test_scaling.c  2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/bin/test_scaling.c b/src/bin/test_scaling.c
> index d0d0f3c..84b20c6 100644
> --- a/src/bin/test_scaling.c
> +++ b/src/bin/test_scaling.c
> @@ -76,7 +76,6 @@ test_scaling2(void *data EINA_UNUSED, Evas_Object *obj 
> EINA_UNUSED, void *event_
>  evas_object_show(bx);
>
>  fr = elm_frame_add(win);
> -   elm_object_scale_set(fr, 0.5);
>  elm_object_text_set(fr, "Scale: 0.5");
>  lb = elm_label_add(win);
>  elm_object_text_set(lb,
> @@ -84,6 +83,7 @@ test_scaling2(void *data EINA_UNUSED, Evas_Object *obj 
> EINA_UNUSED, void *event_
>  "is 0.5. Child should"
>  "inherit it.");
>  elm_object_content_set(fr, lb);
> +   elm_object_scale_set(fr, 0.5);
>  evas_object_show(lb);
>  elm_box_pack_end(bx, fr);
>  evas_object_show(fr);
>


--
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] [EGIT] [apps/ephoto] master 01/01: Ephoto: Move to Ecore_File_Monitor: It behaves better than Eio at this point.

[Hermet Park]

fyi,
Enventor removed eio monitor calls because of the annoying corruptions on win32
 
-Original Message-
From: "Stephen Houston" 
To: "Enlightenment developer list"; 
Cc: 
Sent: 2016-03-01 (화) 07:15:54
Subject: Re: [E-devel] [EGIT] [apps/ephoto] master 01/01: Ephoto: Move to 
Ecore_File_Monitor: It behaves better than Eio at this point.
 
On Mon, Feb 29, 2016 at 4:04 PM, Cedric BAIL  wrote:

> On Mon, Feb 29, 2016 at 12:52 PM, Stephen Houston 
> wrote:
> > According to the docs, Ecore_File_Monitors do work on Windows.
>
> Docs is wrong :-)
>
So efl/src/lib/ecore_file/ecore_file_monitor_win32.c :
https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_file/ecore_file_monitor_win32.c
is useless? Old code that doesn't work?  Should probably be a note of that
somewhere.

>
> > As for the question of why I switched from Eio, I already answered it.
>
> Yes, but your bug report doesn't really help. You don't describe how
> to see the issue even if it is irregularly. I have not even the
> beginning of an idea of what you are complaining about. If I said to
> you ephoto is not working, I am switching back to Eye of Gnome because
> of it. How would you be able to address the problem ?
>
> Cedric
>
As zmike and I discussed and then pinged you into on IRC,  There were
irregularities with taking a file "test.jpg", saving it as "test.jpg2",
then saving it as "test.jpg3".  The monitor would not notify after the
first save of the file (keep in mind it is the same file so I wonder if
that has something to do with it).  Saving the file via the elm file
selector triggered this behavior every single time.  Using the command line
triggered it only occasionally.  As I said, I would really like to get a
release out this month and I'm in a hurry, and already have a slew of other
bugs I'm chasing down so I didn't take the time on this one as I fear it is
going to be a rabbit hole.  Ecore_File just worked (tm) so I went with it.
That would suck if Ecore_File_Monitor indeed does not work on Windows.

My response to your question would be that I would look at finding the
problem when I get a chance.  I would also point out that none of your
development's timeline would be effected by using/not using Ephoto in it's
current state.  I will get down to business and start hunting for the
problem with this Eio issues when I get a chance.  I do intend on switching
back when I have more time to make it work.

>
> > On Mon, Feb 29, 2016 at 2:40 PM, Cedric BAIL 
> wrote:
> >
> >> On Feb 29, 2016 11:30, "Davide Andreoli" 
> wrote:
> >> >
> >> > 2016-02-29 18:16 GMT+01:00 Stephen okra Houston <
> smhousto...@gmail.com>:
> >> >
> >> > > okra pushed a commit to branch master.
> >> > >
> >> > >
> >> > >
> >>
> >>
> http://git.enlightenment.org/apps/ephoto.git/commit/?id=97e82b216f0191697691d768451cca6824d447e6
> >> > >
> >> > > commit 97e82b216f0191697691d768451cca6824d447e6
> >> > > Author: Stephen okra Houston 
> >> > > Date:   Mon Feb 29 11:15:52 2016 -0600
> >> > >
> >> > > Ephoto: Move to Ecore_File_Monitor: It behaves better than Eio
> at
> >> this
> >> > > point.
> >> > >
> >> >
> >> > oh, really? I have plans to port my usage of Ecore_File_Monitor to
> Eio in
> >> > the near future, because
> >> > the ecore one is not able to manage 2 monitors on the same folder at
> the
> >> > same time.
> >>
> >> It also doesn't work on Windows as far as I know and is pretty much
> lacking
> >> behind.
> >>
> >> > What problems are you getting using Eio?
> >>
> >> Would be interested to know too.
> >>
> >> > > ---
> >> > >  src/bin/ephoto.h   6 +-
> >> > >  src/bin/ephoto_main.c234 ++
> >> > >  src/bin/ephoto_single_browser.c   55 +++--
> >> > >  src/bin/ephoto_thumb_browser.c   431
> >> > > ++--
> >> > >  4 files changed, 280 insertions(+), 446 deletions(-)
> >> > >
> >> > > diff --git a/src/bin/ephoto.h b/src/bin/ephoto.h
> >> > > index c828b60..adc1d61 100644
> >> > > --- a/src/bin/ephoto.h
> >> > > +++ b/src/bin/ephoto.h
> >> > > @@ -171,8 +171,7 @@ struct _Ephoto
> >> > > Eina_List *searchentries;
> >> > > Eina_List *thumbs;
> >> > >
> >> > > -   Eio_Monitor *monitor;
> >> > > -   Eina_List *monitor_handlers;
> >> > > +   Ecore_File_Monitor *monitor;
> >> > >
> >> > > const char *top_directory;
> >> > >
> >> > > @@ -203,8 +202,7 @@ struct _Ephoto_Entry
> >> > > const char *label;
> >> > > double size;
> >> > > Ephoto *ephoto;
> >> > > -   Eio_Monitor *monitor;
> >> > > -   Eina_List *monitor_handlers;
> >> > > +   Ecore_File_Monitor *monitor;
> >> > > Elm_Object_Item *item;
> >> > > Elm_Object_Item *parent;
> >> > > Eina_List *free_listeners;
> >> > > diff --git a/src/bin/ephoto_main.c b/src/bin/ephoto_main.c
> >> > > index 9b35096..62c3c83 100644
> >> > > --- a/src/bin/ephoto_main.c
> >> > > +++ b/src/bin/ephoto_main.c
> >> > > @@ -166,13 +166,7 @@ _win_free(void *data, Evas *e EINA_UNUSED,
> >> > > Evas_Object *

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

[The Rasterman]

On Thu, 10 Mar 2016 15:46:19 +0900 Jean-Philippe André  said:

> 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 r

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

[The Rasterman]

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] Eo part - request for comments

[Hermet Park]

IMHO,
efl_text_set(eo_part(obj, "part"), "text");  is  too ugly and counterintuitive.

I'm curious how this will be (really) serious in point of total symbol size if 
we support both efl_text_set(), efl_text_part_set()

and

We should assume a scenario how to set a default part with efl_text_part_set() 
API.
For instance,

VALUE = {{"default", "xxx"}, {"partA", ""}, {"partB", ""}};

for (i = 0; i < 3; i ++) {
   efl_text_part_set(obj,  VALUE[i].part, VALUE[i].value);
}

If so, will the api accept the default name as NULL? or always "default"?
NULL would be also acceptable than "default"?
 
-Original Message-
From: "Tom Hacohen" 
To: "Enlightenment developer list"; 
Cc: 
Sent: 2016-03-09 (수) 00:07:57
Subject: [E-devel] Eo part - request for comments
 
Hey,

As casually mentioned a while back, and as I put in the wiki page 
(https://phab.enlightenment.org/w/eo/), we came up with an idea called 
eo_part().

Introduction to the problem:
We have a "part" type in many places in our API. Consider for example 
the eolian property Efl.Text.text_part, at the moment we'll generate: 
efl_text_part_set(obj, "part", "text");
This is very annoying to use because in most cases it'll actually be 
efl_text_part_set(obj, NULL, "text");

Generating two variations for each function (one that accepts a part and 
one that assumes null) is ugly and will create twice as many symbols, 
which is bad.

In order to solve that, we came up with an alternative. We will only 
generate one variation efl_text_set(obj, "text"), and if you want to set 
the part, the syntax becomes:
efl_text_set(eo_part(obj, "part"), "text");
which is similar to how we do eo_do.

An example to how that would look is already available in the eolian 
wiki page (https://phab.enlightenment.org/w/eolian/), namely the part 
that looks like: "@property some_text @part {"..

The implementation function will look the same and will get the 
following parameter: "const char *part" automatically, whether eo_part 
was called, or not (the NULL is passed). So from the implementation side 
it looks exactly like efl_text_part_set.

We could make it general purpose, but that means using "void *", which 
means we lose type checking capabilities, so the idea is to limit part 
to only be const char * to avoid any confusion with types.

To summarise, what I would like to know:
1. What do you think about limiting only to const char *part. Can you 
think of any reasonable cases where part can be non string? Will we 
actually use those cases?
2. Do you hate the idea/have a better one?
3. Any other comments?

Thanks,
Tom.

--
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] Probie proposal: youngbok (Youngbok Shin)

[Jihoon Kim]

He has been contributed good patch related to evas textblock, font, and etc.

+1
2016. 3. 10. 오후 7:11에 "Hermet Park" 님이 작성:

> +1
>
> -Original Message-
> From: "Daniel Hirt"
> To: "Enlightenment developer list"<
> enlightenment-devel@lists.sourceforge.net>;
> Cc:
> Sent: 2016-03-10 (목) 18:59:06
> Subject: [E-devel] Probie proposal: youngbok (Youngbok Shin)
>
> Hello,
>
> I would like to promote Youngbok Shin to probie. We are working together
> a lot to add features and fixes to both efl and elementary.
>
> He has quite a few patches in EFL already, and personally, it really is
> going to make my life easier during our current work for Elementary
> Interfaces and future patches.
>
> I doubt there's gonna be any objections, but will wait until Sunday if
> anyone wants to reply.
>
> Best regards,
>
> --
> Daniel Hirt (aka herdsman aka D4)
>
>
> --
> 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
>
--
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] Eo part - request for comments

[The Rasterman]

On Thu, 10 Mar 2016 21:51:22 +0900 (KST) Hermet Park  said:

> IMHO,
> efl_text_set(eo_part(obj, "part"), "text");  is  too ugly and
> counterintuitive.
> 
> I'm curious how this will be (really) serious in point of total symbol size
> if we support both efl_text_set(), efl_text_part_set()
> 
> and
> 
> We should assume a scenario how to set a default part with efl_text_part_set
> () API. For instance,
> 
> VALUE = {{"default", "xxx"}, {"partA", ""}, {"partB", ""}};
> 
> for (i = 0; i < 3; i ++) {
>efl_text_part_set(obj,  VALUE[i].part, VALUE[i].value);
> }
> 
> If so, will the api accept the default name as NULL? or always "default"?
> NULL would be also acceptable than "default"?

well the other alternative was put part name as last arg

efl_text_set(obj, "text", "partname");

and if you don't address a part:

efl_text_set(obj, "text", NULL);

other than the above eo_part and having lots of duplicate funcs (with and
without part)

> -Original Message-
> From: "Tom Hacohen" 
> To: "Enlightenment developer
> list"; Cc: 
> Sent: 2016-03-09 (수) 00:07:57
> Subject: [E-devel] Eo part - request for comments
>  
> Hey,
> 
> As casually mentioned a while back, and as I put in the wiki page 
> (https://phab.enlightenment.org/w/eo/), we came up with an idea called 
> eo_part().
> 
> Introduction to the problem:
> We have a "part" type in many places in our API. Consider for example 
> the eolian property Efl.Text.text_part, at the moment we'll generate: 
> efl_text_part_set(obj, "part", "text");
> This is very annoying to use because in most cases it'll actually be 
> efl_text_part_set(obj, NULL, "text");
> 
> Generating two variations for each function (one that accepts a part and 
> one that assumes null) is ugly and will create twice as many symbols, 
> which is bad.
> 
> In order to solve that, we came up with an alternative. We will only 
> generate one variation efl_text_set(obj, "text"), and if you want to set 
> the part, the syntax becomes:
> efl_text_set(eo_part(obj, "part"), "text");
> which is similar to how we do eo_do.
> 
> An example to how that would look is already available in the eolian 
> wiki page (https://phab.enlightenment.org/w/eolian/), namely the part 
> that looks like: "@property some_text @part {"..
> 
> The implementation function will look the same and will get the 
> following parameter: "const char *part" automatically, whether eo_part 
> was called, or not (the NULL is passed). So from the implementation side 
> it looks exactly like efl_text_part_set.
> 
> We could make it general purpose, but that means using "void *", which 
> means we lose type checking capabilities, so the idea is to limit part 
> to only be const char * to avoid any confusion with types.
> 
> To summarise, what I would like to know:
> 1. What do you think about limiting only to const char *part. Can you 
> think of any reasonable cases where part can be non string? Will we 
> actually use those cases?
> 2. Do you hate the idea/have a better one?
> 3. Any other comments?
> 
> Thanks,
> Tom.
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[Hermet Park]

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 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] Probie proposal: youngbok (Youngbok Shin)

[Amitesh Singh]

+1
On Mar 10, 2016 6:23 PM, "Jihoon Kim"  wrote:

> He has been contributed good patch related to evas textblock, font, and
> etc.
>
> +1
> 2016. 3. 10. 오후 7:11에 "Hermet Park" 님이 작성:
>
> > +1
> >
> > -Original Message-
> > From: "Daniel Hirt"
> > To: "Enlightenment developer list"<
> > enlightenment-devel@lists.sourceforge.net>;
> > Cc:
> > Sent: 2016-03-10 (목) 18:59:06
> > Subject: [E-devel] Probie proposal: youngbok (Youngbok Shin)
> >
> > Hello,
> >
> > I would like to promote Youngbok Shin to probie. We are working together
> > a lot to add features and fixes to both efl and elementary.
> >
> > He has quite a few patches in EFL already, and personally, it really is
> > going to make my life easier during our current work for Elementary
> > Interfaces and future patches.
> >
> > I doubt there's gonna be any objections, but will wait until Sunday if
> > anyone wants to reply.
> >
> > Best regards,
> >
> > --
> > Daniel Hirt (aka herdsman aka D4)
> >
> >
> >
> --
> > 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
> >
>
> --
> 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] [EGIT] [core/elementary] master 01/01: Scaling test: reorder instructions to set the correct scale

[Tom Hacohen]

If I'm understanding the issue correctly (judging by his code changes 
and commit message) elm_scale properly applies to the children. The 
problem is that widgets that have scale set don't set the correct scale 
on the children if the children are added *after* the scale was set.

On 10/03/16 11:59, Hermet Park wrote:
> that's the elm scale function.
>
> -Original Message-
> From: "Tom Hacohen"
> To: ;
> Cc:
> Sent: 2016-03-10 (목) 20:14:34
> Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: Scaling test: 
> reorder instructions to set the correct scale
>
> It's not the elm scale function, it's elm widget that needs to propagate
> scale when adding a child. Jack, you should update elm_widget instead of
> hiding the bug.
>
> --
> Tom.
>
> On 10/03/16 10:57, Hermet Park wrote:
>> Sounds like elm scale function is broken. :(
>>
>> -Original Message-
>> From: "Daniel Zaoui"
>> To: ;
>> Cc:
>> Sent: 2016-03-03 (목) 17:54:51
>> Subject: [EGIT] [core/elementary] master 01/01: Scaling test: reorder 
>> instructions to set the correct scale
>>
>> jackdanielz pushed a commit to branch master.
>>
>> http://git.enlightenment.org/core/elementary.git/commit/?id=36669f1eccc3b6c320fb4c4ecc0e029b95834f57
>>
>> commit 36669f1eccc3b6c320fb4c4ecc0e029b95834f57
>> Author: Daniel Zaoui 
>> Date:   Thu Mar 3 10:25:22 2016 +0200
>>
>>   Scaling test: reorder instructions to set the correct scale
>>
>>   If the scale is set on an object before contents are set, it will not
>>   pass to them. Because of this, in the test, scale of the first label
>>   remains 1.0, i.e the window scale, instead of 0.5.
>>   The patch modifies the order of the instructions by setting the scale
>>   after setting the label as content of the frame.
>> ---
>>src/bin/test_scaling.c  2 +-
>>1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/bin/test_scaling.c b/src/bin/test_scaling.c
>> index d0d0f3c..84b20c6 100644
>> --- a/src/bin/test_scaling.c
>> +++ b/src/bin/test_scaling.c
>> @@ -76,7 +76,6 @@ test_scaling2(void *data EINA_UNUSED, Evas_Object *obj 
>> EINA_UNUSED, void *event_
>>   evas_object_show(bx);
>>
>>   fr = elm_frame_add(win);
>> -   elm_object_scale_set(fr, 0.5);
>>   elm_object_text_set(fr, "Scale: 0.5");
>>   lb = elm_label_add(win);
>>   elm_object_text_set(lb,
>> @@ -84,6 +83,7 @@ test_scaling2(void *data EINA_UNUSED, Evas_Object *obj 
>> EINA_UNUSED, void *event_
>>   "is 0.5. Child should"
>>   "inherit it.");
>>   elm_object_content_set(fr, lb);
>> +   elm_object_scale_set(fr, 0.5);
>>   evas_object_show(lb);
>>   elm_box_pack_end(bx, fr);
>>   evas_object_show(fr);
>>
>
>
> --
> 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
>


--
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] Eo: Changes to syntax

[Tom Hacohen]

On 10/03/16 12:36, Carsten Haitzler wrote:
> On Thu, 10 Mar 2016 15:46:19 +0900 Jean-Philippe André  
> said:
>
>> 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 part - request for comments

[Tom Hacohen]

On 10/03/16 12:51, Hermet Park wrote:
> IMHO,
> efl_text_set(eo_part(obj, "part"), "text");  is  too ugly and 
> counterintuitive.
>
> I'm curious how this will be (really) serious in point of total symbol size 
> if we support both efl_text_set(), efl_text_part_set()
>
> and
>
> We should assume a scenario how to set a default part with 
> efl_text_part_set() API.
> For instance,
>
> VALUE = {{"default", "xxx"}, {"partA", ""}, {"partB", ""}};
>
> for (i = 0; i < 3; i ++) {
> efl_text_part_set(obj,  VALUE[i].part, VALUE[i].value);
> }
>
> If so, will the api accept the default name as NULL? or always "default"?
> NULL would be also acceptable than "default"?

That is a another alternative, and to be honest, not a bad one. 
Duplicating. At the moment we have a total of ~20 functions that use the 
"keys" eolian directive (part candidates), and I suspect it'll actually 
become less with interfaces. I wonder if maybe duplicating is in fact 
the best idea. To me it sounds like the cleanest solution.

--
Tom

>
> -Original Message-
> From: "Tom Hacohen"
> To: "Enlightenment developer list";
> Cc:
> Sent: 2016-03-09 (수) 00:07:57
> Subject: [E-devel] Eo part - request for comments
>
> Hey,
>
> As casually mentioned a while back, and as I put in the wiki page
> (https://phab.enlightenment.org/w/eo/), we came up with an idea called
> eo_part().
>
> Introduction to the problem:
> We have a "part" type in many places in our API. Consider for example
> the eolian property Efl.Text.text_part, at the moment we'll generate:
> efl_text_part_set(obj, "part", "text");
> This is very annoying to use because in most cases it'll actually be
> efl_text_part_set(obj, NULL, "text");
>
> Generating two variations for each function (one that accepts a part and
> one that assumes null) is ugly and will create twice as many symbols,
> which is bad.
>
> In order to solve that, we came up with an alternative. We will only
> generate one variation efl_text_set(obj, "text"), and if you want to set
> the part, the syntax becomes:
> efl_text_set(eo_part(obj, "part"), "text");
> which is similar to how we do eo_do.
>
> An example to how that would look is already available in the eolian
> wiki page (https://phab.enlightenment.org/w/eolian/), namely the part
> that looks like: "@property some_text @part {"..
>
> The implementation function will look the same and will get the
> following parameter: "const char *part" automatically, whether eo_part
> was called, or not (the NULL is passed). So from the implementation side
> it looks exactly like efl_text_part_set.
>
> We could make it general purpose, but that means using "void *", which
> means we lose type checking capabilities, so the idea is to limit part
> to only be const char * to avoid any confusion with types.
>
> To summarise, what I would like to know:
> 1. What do you think about limiting only to const char *part. Can you
> think of any reasonable cases where part can be non string? Will we
> actually use those cases?
> 2. Do you hate the idea/have a better one?
> 3. Any other comments?
>
> Thanks,
> Tom.
>
> --
> 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] Eo part - request for comments

[Tom Hacohen]

On 10/03/16 15:54, Tom Hacohen wrote:
> On 10/03/16 12:51, Hermet Park wrote:
>> IMHO,
>> efl_text_set(eo_part(obj, "part"), "text");  is  too ugly and
>> counterintuitive.
>>
>> I'm curious how this will be (really) serious in point of total symbol
>> size if we support both efl_text_set(), efl_text_part_set()
>>
>> and
>>
>> We should assume a scenario how to set a default part with
>> efl_text_part_set() API.
>> For instance,
>>
>> VALUE = {{"default", "xxx"}, {"partA", ""}, {"partB", ""}};
>>
>> for (i = 0; i < 3; i ++) {
>> efl_text_part_set(obj,  VALUE[i].part, VALUE[i].value);
>> }
>>
>> If so, will the api accept the default name as NULL? or always "default"?
>> NULL would be also acceptable than "default"?
>
> That is a another alternative, and to be honest, not a bad one.
> Duplicating. At the moment we have a total of ~20 functions that use the
> "keys" eolian directive (part candidates), and I suspect it'll actually
> become less with interfaces. I wonder if maybe duplicating is in fact
> the best idea. To me it sounds like the cleanest solution.

Correction: there are actually a few more because the previous count 
didn't include methods, only properties. So the previous ones are 
probably ~40 (double because of set + get for properties) + ~40 for the 
methods. I guess we end up with 80 relevant functions that could be 
extended (maybe for some of them it doesn't make sense not to pass a 
part), so around 80 extra symbols. Doesn't sound too bad.

--
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] [EGIT] [core/efl] master 01/01: eo del interceptor: add the ability to intercept deletions of eo objects

[Tom Hacohen]

On 08/03/16 13:39, Tom Hacohen wrote:
> Hey,
>
> Wouldn't it better if the intercept function could return a value saying
> "actually, the object is good to go, just delete it normally", like in
> your example, if the object is already in the right thread, it should
> just delete immediately, no?

To be honest, giving it a bit more thought I don't see how that is 
useful. I think that it's an extreme corner case that is not worth the 
trouble, and I'm very much against adding this kind of API because we 
actually have uses for them. I'm talking about code using them. Adding 
this won't break API so we can wait with adding it until when we 
actually need it.

An alternative would be to deal with the cleanup in the destructor. So 
you for example free data that is thread agnostic, and when you have 
code that needs to be run in a specific loop, you can set manual free 
and defer the cleanup to that thread, so most of the object is 
destructed in the destructing thread, but the relevant parts are cleaned 
in the correct thread. This is implemented per object and is much cleaner.

I like it better, but even if we choose to go with the idea in this 
commit, I'd say: revert it until needed. I talked to Felipe about it on 
IRC and he agrees.

--
Tom.

>
> --
> Tom
>
> On 08/03/16 08:33, Carsten Haitzler wrote:
>> raster pushed a commit to branch master.
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=3df71ab0f668967cf37813cc2322d1993a4d5db1
>>
>> commit 3df71ab0f668967cf37813cc2322d1993a4d5db1
>> Author: Carsten Haitzler (Rasterman) 
>> Date:   Tue Mar 8 16:57:22 2016 +0900.
>>
>>   eo del interceptor: add the ability to intercept deletions of eo 
>> objects
>>
>>   Imagine this. You have an object. You pass this object handle as a
>>   message to another thread. Let's say it's not a UI object, so
>>   something you might expect to be able to be accessed from multiple
>>   threads. In order to keep the object alive you eo_ref() it when
>>   placing the message on a queue and eo_unref() it once the message is
>>   "done" in the other thread. If the original sender unref()ed the
>>   object before the message is done, then the object will be destroyed
>>   in the reciever thread. This is bad for objects "expecting" not to be
>>   destroyed outside their owning thread.
>>
>>   This allows thius situation to be fixed. A constructor in a class of
>>   an object can set up a delete interceptor. For example if we have a
>>   "loop ownership" class you multi-ple-inherit from/use as a mixin. This
>>   class will set up the interceptor to ensure that on destruction if
>>   pthread_self() != owning loop thread id, then add object to "delete
>>   me" queue on the owning loop and wake it up. the owning loop thread
>>   will wake up and then process this queue and delete the queued objects
>>   nicely and safely within the "owning context".
>>
>>   This can also be used in this same manner to defer deletion within a
>>   loop "until later" in the same delete_me queue.
>>
>>   You can even use this as a caching mechanism for objects to prevernt
>>   their actual destruction and instead place them in a cached area to be
>>   picked from at a later date.
>>
>>   The uses are many for this and this is a basic building block for
>>   future EFL features like generic messages where a message payload
>>   could be an eo object and thus the above loop onwership issue can
>>   happen and needs fixing.
>>
>>   This adds APIs, implementation, documentation (doxy reference) and 
>> tests.
>>
>>   @feature
>> ---
>>src/lib/eo/Eo.h  | 58 
>> 
>>src/lib/eo/eo.c  | 16 ++
>>src/lib/eo/eo_private.h  |  9 ++
>>src/tests/eo/suite/eo_test_general.c | 55 
>> ++
>>4 files changed, 138 insertions(+)
>>
>> diff --git a/src/lib/eo/Eo.h b/src/lib/eo/Eo.h
>> index cf10bb3..4bfae97 100644
>> --- a/src/lib/eo/Eo.h
>> +++ b/src/lib/eo/Eo.h
>> @@ -166,6 +166,16 @@ typedef struct _Eo_Event Eo_Event;
>> */
>>typedef Eina_Bool (*Eo_Event_Cb)(void *data, const Eo_Event *event);
>>
>> +/**
>> + * @typedef Eo_Del_Intercept
>> + *
>> + * A function to be called on object deletion/destruction instead of normal
>> + * destruction taking place.
>> + *
>> + * @param obj_id The object needing destruction
>> + */
>> +typedef void (*Eo_Del_Intercept) (Eo *obj_id);
>> +
>>#include "eo_base.eo.h"
>>#define EO_CLASS EO_BASE_CLASS
>>
>> @@ -787,6 +797,54 @@ EAPI void eo_unref(const Eo *obj);
>>EAPI int eo_ref_get(const Eo *obj);
>>
>>/**
>> + * @brief Set a deletion interceptor function
>> + * @param obj The object to set the interceptor on
>> + * @param del_intercept_func The interceptor function to call
>> + *
>> + * This sets the function @p del_intercept_func to be called wh

Re: [E-devel] [EGIT] [core/elementary] master 04/04: combobox: fix borkage after eo_add change.

[Tom Hacohen]

Huh? It is valid and the code is correct. What seems to be the problem? 
Works here with no warnings (clang), but anyhow, the code is correct.

--
Tom.

On 10/03/16 00:59, Cedric BAIL wrote:
> cedric pushed a commit to branch master.
>
> http://git.enlightenment.org/core/elementary.git/commit/?id=da8287fa370bb579a4a592dd280ac5c8a6a25830
>
> commit da8287fa370bb579a4a592dd280ac5c8a6a25830
> Author: Cedric BAIL 
> Date:   Wed Mar 9 16:57:02 2016 -0800
>
>  combobox: fix borkage after eo_add change.
>
>  toto = titi = eo_add is no longer valid.
> ---
>   src/lib/elc_combobox.c | 6 --
>   1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/lib/elc_combobox.c b/src/lib/elc_combobox.c
> index 4227cea..8f2b141 100644
> --- a/src/lib/elc_combobox.c
> +++ b/src/lib/elc_combobox.c
> @@ -359,7 +359,8 @@ _elm_combobox_eo_base_constructor(Eo *obj, 
> Elm_Combobox_Data *sd)
>  elm_table_pack(sd->tbl, sd->spacer, 0, 0, 1, 1);
>
>  // This is the genlist object that will take over the genlist call
> -   sd->genlist = gl = eo_add(&gl, ELM_GENLIST_CLASS, obj);
> +   eo_add(&gl, ELM_GENLIST_CLASS, obj);
> +   sd->genlist = gl;
>  elm_genlist_filter_set(gl, NULL);
>  elm_widget_mirrored_automatic_set(gl, EINA_FALSE);
>  elm_widget_mirrored_set(gl, elm_widget_mirrored_get(obj));
> @@ -373,7 +374,8 @@ _elm_combobox_eo_base_constructor(Eo *obj, 
> Elm_Combobox_Data *sd)
>  elm_table_pack(sd->tbl, gl, 0, 0, 1, 1);
>
>  // This is the entry object that will take over the entry call
> -   sd->entry = entry = eo_add(&entry, ELM_ENTRY_CLASS, obj);
> +   eo_add(&entry, ELM_ENTRY_CLASS, obj);
> +   sd->entry = entry;
>  elm_widget_mirrored_automatic_set(entry, EINA_FALSE);
>  elm_widget_mirrored_set(entry, elm_widget_mirrored_get(obj));
>  elm_scroller_policy_set(entry, ELM_SCROLLER_POLICY_OFF,
>


--
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] [EGIT] [apps/ephoto] master 01/01: Ephoto: Move to Ecore_File_Monitor: It behaves better than Eio at this point.

[Cedric BAIL]

On Mar 10, 2016 4:07 AM, "Hermet Park"  wrote:
>
> fyi,
> Enventor removed eio monitor calls because of the annoying corruptions on
win32

If I remember correctly, the issue was all about Windows inability to open
file for reading, writing and still allow them to be destroyed. To fix that
properly, eio monitor wasn't needed anymore, but that wasn't a bug or
design issue in eio monitor.

> -Original Message-
> From: "Stephen Houston"
> To: "Enlightenment developer list"<
enlightenment-devel@lists.sourceforge.net>;
> Cc:
> Sent: 2016-03-01 (화) 07:15:54
> Subject: Re: [E-devel] [EGIT] [apps/ephoto] master 01/01: Ephoto: Move to
Ecore_File_Monitor: It behaves better than Eio at this point.
>
> On Mon, Feb 29, 2016 at 4:04 PM, Cedric BAIL  wrote:
>
> > On Mon, Feb 29, 2016 at 12:52 PM, Stephen Houston 
> > wrote:
> > > According to the docs, Ecore_File_Monitors do work on Windows.
> >
> > Docs is wrong :-)
> >
> So efl/src/lib/ecore_file/ecore_file_monitor_win32.c :
>
https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_file/ecore_file_monitor_win32.c
> is useless? Old code that doesn't work?  Should probably be a note of that
> somewhere.
>
> >
> > > As for the question of why I switched from Eio, I already answered it.
> >
> > Yes, but your bug report doesn't really help. You don't describe how
> > to see the issue even if it is irregularly. I have not even the
> > beginning of an idea of what you are complaining about. If I said to
> > you ephoto is not working, I am switching back to Eye of Gnome because
> > of it. How would you be able to address the problem ?
> >
> > Cedric
> >
> As zmike and I discussed and then pinged you into on IRC,  There were
> irregularities with taking a file "test.jpg", saving it as "test.jpg2",
> then saving it as "test.jpg3".  The monitor would not notify after the
> first save of the file (keep in mind it is the same file so I wonder if
> that has something to do with it).  Saving the file via the elm file
> selector triggered this behavior every single time.  Using the command
line
> triggered it only occasionally.  As I said, I would really like to get a
> release out this month and I'm in a hurry, and already have a slew of
other
> bugs I'm chasing down so I didn't take the time on this one as I fear it
is
> going to be a rabbit hole.  Ecore_File just worked (tm) so I went with it.
> That would suck if Ecore_File_Monitor indeed does not work on Windows.
>
> My response to your question would be that I would look at finding the
> problem when I get a chance.  I would also point out that none of your
> development's timeline would be effected by using/not using Ephoto in it's
> current state.  I will get down to business and start hunting for the
> problem with this Eio issues when I get a chance.  I do intend on
switching
> back when I have more time to make it work.
>
> >
> > > On Mon, Feb 29, 2016 at 2:40 PM, Cedric BAIL 
> > wrote:
> > >
> > >> On Feb 29, 2016 11:30, "Davide Andreoli" 
> > wrote:
> > >> >
> > >> > 2016-02-29 18:16 GMT+01:00 Stephen okra Houston <
> > smhousto...@gmail.com>:
> > >> >
> > >> > > okra pushed a commit to branch master.
> > >> > >
> > >> > >
> > >> > >
> > >>
> > >>
> >
http://git.enlightenment.org/apps/ephoto.git/commit/?id=97e82b216f0191697691d768451cca6824d447e6
> > >> > >
> > >> > > commit 97e82b216f0191697691d768451cca6824d447e6
> > >> > > Author: Stephen okra Houston 
> > >> > > Date:   Mon Feb 29 11:15:52 2016 -0600
> > >> > >
> > >> > > Ephoto: Move to Ecore_File_Monitor: It behaves better than
Eio
> > at
> > >> this
> > >> > > point.
> > >> > >
> > >> >
> > >> > oh, really? I have plans to port my usage of Ecore_File_Monitor to
> > Eio in
> > >> > the near future, because
> > >> > the ecore one is not able to manage 2 monitors on the same folder
at
> > the
> > >> > same time.
> > >>
> > >> It also doesn't work on Windows as far as I know and is pretty much
> > lacking
> > >> behind.
> > >>
> > >> > What problems are you getting using Eio?
> > >>
> > >> Would be interested to know too.
> > >>
> > >> > > ---
> > >> > >  src/bin/ephoto.h   6 +-
> > >> > >  src/bin/ephoto_main.c234 ++
> > >> > >  src/bin/ephoto_single_browser.c   55 +++--
> > >> > >  src/bin/ephoto_thumb_browser.c   431
> > >> > > ++--
> > >> > >  4 files changed, 280 insertions(+), 446 deletions(-)
> > >> > >
> > >> > > diff --git a/src/bin/ephoto.h b/src/bin/ephoto.h
> > >> > > index c828b60..adc1d61 100644
> > >> > > --- a/src/bin/ephoto.h
> > >> > > +++ b/src/bin/ephoto.h
> > >> > > @@ -171,8 +171,7 @@ struct _Ephoto
> > >> > > Eina_List *searchentries;
> > >> > > Eina_List *thumbs;
> > >> > >
> > >> > > -   Eio_Monitor *monitor;
> > >> > > -   Eina_List *monitor_handlers;
> > >> > > +   Ecore_File_Monitor *monitor;
> > >> > >
> > >> > > const char *top_directory;
> > >> > >
> > >> > > @@ -203,8 +202,7 @@ struct _Ephoto_Entry
> > >> > > const char *

Re: [E-devel] [EGIT] [core/elementary] master 04/04: combobox: fix borkage after eo_add change.

[Cedric BAIL]

On Mar 10, 2016 8:10 AM, "Tom Hacohen"  wrote:
>
> Huh? It is valid and the code is correct. What seems to be the problem?
> Works here with no warnings (clang), but anyhow, the code is correct.

>From gcc point of view gl was undefined when set to sd->genlist and that
did come with a big fat warning :-)

> --
> Tom.
>
> On 10/03/16 00:59, Cedric BAIL wrote:
> > cedric pushed a commit to branch master.
> >
> >
http://git.enlightenment.org/core/elementary.git/commit/?id=da8287fa370bb579a4a592dd280ac5c8a6a25830
> >
> > commit da8287fa370bb579a4a592dd280ac5c8a6a25830
> > Author: Cedric BAIL 
> > Date:   Wed Mar 9 16:57:02 2016 -0800
> >
> >  combobox: fix borkage after eo_add change.
> >
> >  toto = titi = eo_add is no longer valid.
> > ---
> >   src/lib/elc_combobox.c | 6 --
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/lib/elc_combobox.c b/src/lib/elc_combobox.c
> > index 4227cea..8f2b141 100644
> > --- a/src/lib/elc_combobox.c
> > +++ b/src/lib/elc_combobox.c
> > @@ -359,7 +359,8 @@ _elm_combobox_eo_base_constructor(Eo *obj,
Elm_Combobox_Data *sd)
> >  elm_table_pack(sd->tbl, sd->spacer, 0, 0, 1, 1);
> >
> >  // This is the genlist object that will take over the genlist call
> > -   sd->genlist = gl = eo_add(&gl, ELM_GENLIST_CLASS, obj);
> > +   eo_add(&gl, ELM_GENLIST_CLASS, obj);
> > +   sd->genlist = gl;
> >  elm_genlist_filter_set(gl, NULL);
> >  elm_widget_mirrored_automatic_set(gl, EINA_FALSE);
> >  elm_widget_mirrored_set(gl, elm_widget_mirrored_get(obj));
> > @@ -373,7 +374,8 @@ _elm_combobox_eo_base_constructor(Eo *obj,
Elm_Combobox_Data *sd)
> >  elm_table_pack(sd->tbl, gl, 0, 0, 1, 1);
> >
> >  // This is the entry object that will take over the entry call
> > -   sd->entry = entry = eo_add(&entry, ELM_ENTRY_CLASS, obj);
> > +   eo_add(&entry, ELM_ENTRY_CLASS, obj);
> > +   sd->entry = entry;
> >  elm_widget_mirrored_automatic_set(entry, EINA_FALSE);
> >  elm_widget_mirrored_set(entry, elm_widget_mirrored_get(obj));
> >  elm_scroller_policy_set(entry, ELM_SCROLLER_POLICY_OFF,
> >
>
>
>
--
> 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

[Tom Hacohen]

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] enlightenment systems

[Stefan Schmidt]

Hello.

Sorry, for the delay here. I was on vacation when it arrived and nearly 
missed it. Good that Mike pointed it out to me.

On 18/02/16 08:13, Jonathan Aquilina wrote:
> Good Morning,
>
> I noticed a thread about the apache user and having a single system
> admin who has very little time. I am willing to step up to the plate and
> help out in a sys admin fashion. What time zone is the current sysadmin
> in? I am based in europe if that helps at all having someone available
> when the other person is asleep. I can hop on irc if anyone would like
> to chat.

Its great to hear that you have interested in helping out with it!

Beber  (cc'ed) handles our systems and he would be the one you should 
talk to.
He is also in Europe so the timezone benefit would be void. :)

Obviously we are not handing out root access to our servers 
light-heartedly. Many of our core devs do not have root access either.
Its about building trust over time and actions. In the end this is 
really up to beber how he wants to handle this.

Never the less there should be a way to work it all out and having a 
second admin available would be great!

regards
Stefan Schmidt

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

[Tom Hacohen]

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] [EGIT] [core/elementary] master 04/04: combobox: fix borkage after eo_add change.

[Tom Hacohen]

On 10/03/16 17:02, Cedric BAIL wrote:
> On Mar 10, 2016 8:10 AM, "Tom Hacohen"  wrote:
>>
>> Huh? It is valid and the code is correct. What seems to be the problem?
>> Works here with no warnings (clang), but anyhow, the code is correct.
>
>>From gcc point of view gl was undefined when set to sd->genlist and that
> did come with a big fat warning :-)
>

GCC is wrong, but I guess you had to silence it. :|

--
Tom.

>> --
>> Tom.
>>
>> On 10/03/16 00:59, Cedric BAIL wrote:
>>> cedric pushed a commit to branch master.
>>>
>>>
> http://git.enlightenment.org/core/elementary.git/commit/?id=da8287fa370bb579a4a592dd280ac5c8a6a25830
>>>
>>> commit da8287fa370bb579a4a592dd280ac5c8a6a25830
>>> Author: Cedric BAIL 
>>> Date:   Wed Mar 9 16:57:02 2016 -0800
>>>
>>>   combobox: fix borkage after eo_add change.
>>>
>>>   toto = titi = eo_add is no longer valid.
>>> ---
>>>src/lib/elc_combobox.c | 6 --
>>>1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/lib/elc_combobox.c b/src/lib/elc_combobox.c
>>> index 4227cea..8f2b141 100644
>>> --- a/src/lib/elc_combobox.c
>>> +++ b/src/lib/elc_combobox.c
>>> @@ -359,7 +359,8 @@ _elm_combobox_eo_base_constructor(Eo *obj,
> Elm_Combobox_Data *sd)
>>>   elm_table_pack(sd->tbl, sd->spacer, 0, 0, 1, 1);
>>>
>>>   // This is the genlist object that will take over the genlist call
>>> -   sd->genlist = gl = eo_add(&gl, ELM_GENLIST_CLASS, obj);
>>> +   eo_add(&gl, ELM_GENLIST_CLASS, obj);
>>> +   sd->genlist = gl;
>>>   elm_genlist_filter_set(gl, NULL);
>>>   elm_widget_mirrored_automatic_set(gl, EINA_FALSE);
>>>   elm_widget_mirrored_set(gl, elm_widget_mirrored_get(obj));
>>> @@ -373,7 +374,8 @@ _elm_combobox_eo_base_constructor(Eo *obj,
> Elm_Combobox_Data *sd)
>>>   elm_table_pack(sd->tbl, gl, 0, 0, 1, 1);
>>>
>>>   // This is the entry object that will take over the entry call
>>> -   sd->entry = entry = eo_add(&entry, ELM_ENTRY_CLASS, obj);
>>> +   eo_add(&entry, ELM_ENTRY_CLASS, obj);
>>> +   sd->entry = entry;
>>>   elm_widget_mirrored_automatic_set(entry, EINA_FALSE);
>>>   elm_widget_mirrored_set(entry, elm_widget_mirrored_get(obj));
>>>   elm_scroller_policy_set(entry, ELM_SCROLLER_POLICY_OFF,
>>>
>>
>>
>>
> --
>> 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
>


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

[Andrew Williams]

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

[E-devel] EFL API Docs

[Andreas Volz]

Hello,

https://docs.enlightenment.org/efl/current/group__Edje__Object__Part.html

could you explain me why I don't see any functions in the EFL
documentation? (Here: Edje Object Part)

regards
  Andreas

-- 
Technical Blog 

--
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] Modify edje properties

[Andreas Volz]

Am Sat, 5 Mar 2016 23:45:55 +0100 schrieb Andreas Volz:

Ok, seems not possible or nobody knows.

Is there a good way to find out in my application code if a part is a
external type or a text part? Should I use edje_edit_part_type_get()
for this? I just like to change a text from a common API interface in
my higher level API independent is it's a native Edje TEXT object or a
elm/label.

Another idea would be to do something like this (meta code)

val = edje_object_part_external_object_get(...); 
if(!val)
{
  // seems not to be an external
  edje_object_part_text_set(...);
}
else
{
  // edje external, so access params
  // modify e.g label param of elm/label
  ...
}

> Hello,
> 
> I use edje_object_part_external_param_set() to be able to modify all
> params from a EXTERNAL type (here: elm/entry) in my application code.
> Very flexible and nice.
> 
>  part { name: "Entry01";
> type: EXTERNAL;
> source: "elm/entry";
> description { state: "default" 0;
>rel1 {
>   offset: 139 120;
>}
>rel2 {
>   relative: 0 0;
>   offset: 299 436;
>}
>params {
>   string: "style" "default";
>   string: "label" "";
>   bool: "scrollable" "1";
>   bool: "single line" "0";
>   bool: "password" "0";
>   bool: "horizontal bounce" "0";
>   bool: "vertical bounce" "0";
>   bool: "editable" "0";
>}
> }
>  }
> 
> I use mostly elm objects in my application, but also some internal
> edje types like TEXT type. I can't use
> edje_object_part_external_param_set() in this case to access the text
> parameters like e.g. size. Ok, I could use
> edje_object_part_text_set() at least to change the text, but that's
> not the same. I like the generic param mechanism and I don't see how
> to change e.g. size from my application.
> 
>  part { name: "Text01";
> type: TEXT;
> mouse_events: 0;
> description { state: "default" 0;
>rel1 {
>   offset: 76 -102;
>}
>rel2 {
>   relative: 0 0;
>   offset: 226 130;
>}
>text {
>   text: "4:30 PM";
>   font: "Arial:style=Fett";
>   size: 10;
>}
> }
>  }
> 
> Could you help me here? Maybe I didn't understood the concept at this
> point.
> 
> -- 
> Technical Blog 
> 
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
Technical Blog 

--
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] Modify edje properties

[Cedric BAIL]

Hello,

On Thu, Mar 10, 2016 at 2:24 PM, Andreas Volz  wrote:
> Am Sat, 5 Mar 2016 23:45:55 +0100 schrieb Andreas Volz:
> Ok, seems not possible or nobody knows.

Well, current state of edje external is a serious lack of
maintainership activity. It is missing function and the API to access
it is not that good. You may have seen that their is some effort going
on with what is called Efl interface. The idea being that we will have
only one API to do the same thing on many different object/part. In
your case we are working on providing an efl_text_set that will do
work on a part in edje, be it an Edje internal TEXT part or an
elementary external entry. Both should be working. We are not there
yet.

> Is there a good way to find out in my application code if a part is a
> external type or a text part? Should I use edje_edit_part_type_get()
> for this? I just like to change a text from a common API interface in
> my higher level API independent is it's a native Edje TEXT object or a
> elm/label.

In general it is advised to not use edje_edit_* API, but in your case
and looking at what you want to do, I think that's the only solution.

> Another idea would be to do something like this (meta code)
>
> val = edje_object_part_external_object_get(...);
> if(!val)
> {
>   // seems not to be an external
>   edje_object_part_text_set(...);
> }
> else
> {
>   // edje external, so access params
>   // modify e.g label param of elm/label
>   ...

You can use here an eo_isa call to figure out which API you can use on
the object.
-- 
Cedric BAIL

--
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] Modify edje properties

[The Rasterman]

On Thu, 10 Mar 2016 23:24:10 +0100 Andreas Volz  said:

> Am Sat, 5 Mar 2016 23:45:55 +0100 schrieb Andreas Volz:
> 
> Ok, seems not possible or nobody knows.

nope - don't know. i know these properties are meant for the elm external
plugins - not for edje parts so it's up to whatever plugin it is to deal with
property names and do whatever it needs/wants.

> Is there a good way to find out in my application code if a part is a
> external type or a text part? Should I use edje_edit_part_type_get()
> for this? I just like to change a text from a common API interface in
> my higher level API independent is it's a native Edje TEXT object or a
> elm/label.
> 
> Another idea would be to do something like this (meta code)
> 
> val = edje_object_part_external_object_get(...); 
> if(!val)
> {
>   // seems not to be an external
>   edje_object_part_text_set(...);
> }
> else
> {
>   // edje external, so access params
>   // modify e.g label param of elm/label
>   ...
> }
> 
> > Hello,
> > 
> > I use edje_object_part_external_param_set() to be able to modify all
> > params from a EXTERNAL type (here: elm/entry) in my application code.
> > Very flexible and nice.
> > 
> >  part { name: "Entry01";
> > type: EXTERNAL;
> > source: "elm/entry";
> > description { state: "default" 0;
> >rel1 {
> >   offset: 139 120;
> >}
> >rel2 {
> >   relative: 0 0;
> >   offset: 299 436;
> >}
> >params {
> >   string: "style" "default";
> >   string: "label" "";
> >   bool: "scrollable" "1";
> >   bool: "single line" "0";
> >   bool: "password" "0";
> >   bool: "horizontal bounce" "0";
> >   bool: "vertical bounce" "0";
> >   bool: "editable" "0";
> >}
> > }
> >  }
> > 
> > I use mostly elm objects in my application, but also some internal
> > edje types like TEXT type. I can't use
> > edje_object_part_external_param_set() in this case to access the text
> > parameters like e.g. size. Ok, I could use
> > edje_object_part_text_set() at least to change the text, but that's
> > not the same. I like the generic param mechanism and I don't see how
> > to change e.g. size from my application.
> > 
> >  part { name: "Text01";
> > type: TEXT;
> > mouse_events: 0;
> > description { state: "default" 0;
> >rel1 {
> >   offset: 76 -102;
> >}
> >rel2 {
> >   relative: 0 0;
> >   offset: 226 130;
> >}
> >text {
> >   text: "4:30 PM";
> >   font: "Arial:style=Fett";
> >   size: 10;
> >}
> > }
> >  }
> > 
> > Could you help me here? Maybe I didn't understood the concept at this
> > point.
> > 
> > -- 
> > Technical Blog 
> > 
> > --
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > 
> 
> 
> -- 
> Technical Blog 
> 
> --
> 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

[The Rasterman]

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)
> > 
> >  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)r

Re: [E-devel] EFL API Docs

[The Rasterman]

On Thu, 10 Mar 2016 23:04:33 +0100 Andreas Volz  said:

> Hello,
> 
> https://docs.enlightenment.org/efl/current/group__Edje__Object__Part.html
> 
> could you explain me why I don't see any functions in the EFL
> documentation? (Here: Edje Object Part)
> 
> regards
>   Andreas

i don't know. the functions for edje parts are doxy documented, but often they
are unfindable (generated somewhere on a page but not where you expect or
simply vanish despite there being doxy comments).

several years ago i spent a while tyring to fix up docs. i gave up because its
too slow. make doc was taking multiple minutes to see any changes i was making
and often i had to guess/poke and see how it wobbled to fix and since the
going was far too slow i abandoned trying to fix our docs. i gave up on doxygen
as a tool for our codebase because it just is too slow, too much of a mess by
now and going from here to "fixed" will take such a huge investment of time...
i'd rather do something else instead.

:)

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

[The Rasterman]

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] [EGIT] [core/elementary] master 04/04: combobox: fix borkage after eo_add change.

[The Rasterman]

On Thu, 10 Mar 2016 17:43:01 + Tom Hacohen  said:

> On 10/03/16 17:02, Cedric BAIL wrote:
> > On Mar 10, 2016 8:10 AM, "Tom Hacohen"  wrote:
> >>
> >> Huh? It is valid and the code is correct. What seems to be the problem?
> >> Works here with no warnings (clang), but anyhow, the code is correct.
> >
> >>From gcc point of view gl was undefined when set to sd->genlist and that
> > did come with a big fat warning :-)
> >
> 
> GCC is wrong, but I guess you had to silence it. :|

gcc generates warnings because it sees this as a possible code bug - you pass
in a reference and fill it then also re-assign the value again as a return from
the same func. in any sane world most people reading that code would go "wtf?
is that a bug? did they may to pass in &somethingelse instead of &gl because
this assigns it twice? are we losing a reference to something here?". gcc is
saying that. the code itself wasn't broken. it would work, BUT it LOOKS like a
bug to any "sane person". and gcc warns. the more warnings we let through, the
more real issues hide in warnings we now ignore in the sea of warnings
scrolling by. thus why it is being "shut up".

but it is a point - it looks insane. imho eo_add given its current use of &
should not return anything and we assign return by reference. at least then it
doesn't look like a bug.

> --
> Tom.
> 
> >> --
> >> Tom.
> >>
> >> On 10/03/16 00:59, Cedric BAIL wrote:
> >>> cedric pushed a commit to branch master.
> >>>
> >>>
> > http://git.enlightenment.org/core/elementary.git/commit/?id=da8287fa370bb579a4a592dd280ac5c8a6a25830
> >>>
> >>> commit da8287fa370bb579a4a592dd280ac5c8a6a25830
> >>> Author: Cedric BAIL 
> >>> Date:   Wed Mar 9 16:57:02 2016 -0800
> >>>
> >>>   combobox: fix borkage after eo_add change.
> >>>
> >>>   toto = titi = eo_add is no longer valid.
> >>> ---
> >>>src/lib/elc_combobox.c | 6 --
> >>>1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/src/lib/elc_combobox.c b/src/lib/elc_combobox.c
> >>> index 4227cea..8f2b141 100644
> >>> --- a/src/lib/elc_combobox.c
> >>> +++ b/src/lib/elc_combobox.c
> >>> @@ -359,7 +359,8 @@ _elm_combobox_eo_base_constructor(Eo *obj,
> > Elm_Combobox_Data *sd)
> >>>   elm_table_pack(sd->tbl, sd->spacer, 0, 0, 1, 1);
> >>>
> >>>   // This is the genlist object that will take over the genlist call
> >>> -   sd->genlist = gl = eo_add(&gl, ELM_GENLIST_CLASS, obj);
> >>> +   eo_add(&gl, ELM_GENLIST_CLASS, obj);
> >>> +   sd->genlist = gl;
> >>>   elm_genlist_filter_set(gl, NULL);
> >>>   elm_widget_mirrored_automatic_set(gl, EINA_FALSE);
> >>>   elm_widget_mirrored_set(gl, elm_widget_mirrored_get(obj));
> >>> @@ -373,7 +374,8 @@ _elm_combobox_eo_base_constructor(Eo *obj,
> > Elm_Combobox_Data *sd)
> >>>   elm_table_pack(sd->tbl, gl, 0, 0, 1, 1);
> >>>
> >>>   // This is the entry object that will take over the entry call
> >>> -   sd->entry = entry = eo_add(&entry, ELM_ENTRY_CLASS, obj);
> >>> +   eo_add(&entry, ELM_ENTRY_CLASS, obj);
> >>> +   sd->entry = entry;
> >>>   elm_widget_mirrored_automatic_set(entry, EINA_FALSE);
> >>>   elm_widget_mirrored_set(entry, elm_widget_mirrored_get(obj));
> >>>   elm_scroller_policy_set(entry, ELM_SCROLLER_POLICY_OFF,
> >>>
> >>
> >>
> >>
> > --
> >> 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
> >
> 
> 
> --
> 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


-

Re: [E-devel] [EGIT] [core/efl] master 01/01: eo del interceptor: add the ability to intercept deletions of eo objects

[The Rasterman]

On Thu, 10 Mar 2016 16:07:58 + Tom Hacohen  said:

> On 08/03/16 13:39, Tom Hacohen wrote:
> > Hey,
> >
> > Wouldn't it better if the intercept function could return a value saying
> > "actually, the object is good to go, just delete it normally", like in
> > your example, if the object is already in the right thread, it should
> > just delete immediately, no?
> 
> To be honest, giving it a bit more thought I don't see how that is 
> useful. I think that it's an extreme corner case that is not worth the 
> trouble, and I'm very much against adding this kind of API because we 
> actually have uses for them. I'm talking about code using them. Adding 
> this won't break API so we can wait with adding it until when we 
> actually need it.

actually it will be used soon - specifically for generic messages between lop
objects. this is the only way to ensure "safe destruction" of an Eo * payload.

> An alternative would be to deal with the cleanup in the destructor. So 
> you for example free data that is thread agnostic, and when you have 
> code that needs to be run in a specific loop, you can set manual free 
> and defer the cleanup to that thread, so most of the object is 
> destructed in the destructing thread, but the relevant parts are cleaned 
> in the correct thread. This is implemented per object and is much cleaner.

this is far more complex than just queing the deletion as a whole on another
thread.

> I like it better, but even if we choose to go with the idea in this 
> commit, I'd say: revert it until needed. I talked to Felipe about it on 
> IRC and he agrees.

see above. i added this because it will be needed soon. like in the coming
weeks/months.

> --
> Tom.
> 
> >
> > --
> > Tom
> >
> > On 08/03/16 08:33, Carsten Haitzler wrote:
> >> raster pushed a commit to branch master.
> >>
> >> http://git.enlightenment.org/core/efl.git/commit/?id=3df71ab0f668967cf37813cc2322d1993a4d5db1
> >>
> >> commit 3df71ab0f668967cf37813cc2322d1993a4d5db1
> >> Author: Carsten Haitzler (Rasterman) 
> >> Date:   Tue Mar 8 16:57:22 2016 +0900.
> >>
> >>   eo del interceptor: add the ability to intercept deletions of eo
> >> objects
> >>
> >>   Imagine this. You have an object. You pass this object handle as a
> >>   message to another thread. Let's say it's not a UI object, so
> >>   something you might expect to be able to be accessed from multiple
> >>   threads. In order to keep the object alive you eo_ref() it when
> >>   placing the message on a queue and eo_unref() it once the message is
> >>   "done" in the other thread. If the original sender unref()ed the
> >>   object before the message is done, then the object will be destroyed
> >>   in the reciever thread. This is bad for objects "expecting" not to be
> >>   destroyed outside their owning thread.
> >>
> >>   This allows thius situation to be fixed. A constructor in a class of
> >>   an object can set up a delete interceptor. For example if we have a
> >>   "loop ownership" class you multi-ple-inherit from/use as a mixin.
> >> This class will set up the interceptor to ensure that on destruction if
> >>   pthread_self() != owning loop thread id, then add object to "delete
> >>   me" queue on the owning loop and wake it up. the owning loop thread
> >>   will wake up and then process this queue and delete the queued
> >> objects nicely and safely within the "owning context".
> >>
> >>   This can also be used in this same manner to defer deletion within a
> >>   loop "until later" in the same delete_me queue.
> >>
> >>   You can even use this as a caching mechanism for objects to prevernt
> >>   their actual destruction and instead place them in a cached area to
> >> be picked from at a later date.
> >>
> >>   The uses are many for this and this is a basic building block for
> >>   future EFL features like generic messages where a message payload
> >>   could be an eo object and thus the above loop onwership issue can
> >>   happen and needs fixing.
> >>
> >>   This adds APIs, implementation, documentation (doxy reference) and
> >> tests.
> >>
> >>   @feature
> >> ---
> >>src/lib/eo/Eo.h  | 58 ++
> >> ++ src/lib/eo/eo.c  | 16 ++
> >>src/lib/eo/eo_private.h  |  9 ++
> >>src/tests/eo/suite/eo_test_general.c | 55 ++
> >>  4 files changed, 138 insertions(+)
> >>
> >> diff --git a/src/lib/eo/Eo.h b/src/lib/eo/Eo.h
> >> index cf10bb3..4bfae97 100644
> >> --- a/src/lib/eo/Eo.h
> >> +++ b/src/lib/eo/Eo.h
> >> @@ -166,6 +166,16 @@ typedef struct _Eo_Event Eo_Event;
> >> */
> >>typedef Eina_Bool (*Eo_Event_Cb)(void *data, const Eo_Event *event);
> >>
> >> +/**
> >> + * @typedef Eo_Del_Intercept
> >> + *
> >> + * A function to be called on object deletion/destruction instead of
> >> normal
> >> + * destruction taking pla

Re: [E-devel] [EGIT] [core/elementary] master 04/04: combobox: fix borkage after eo_add change.

[Cedric BAIL]

On Thu, Mar 10, 2016 at 3:40 PM, Carsten Haitzler  wrote:
> On Thu, 10 Mar 2016 17:43:01 + Tom Hacohen  said:
>> On 10/03/16 17:02, Cedric BAIL wrote:
>> > On Mar 10, 2016 8:10 AM, "Tom Hacohen"  wrote:
>> >> Huh? It is valid and the code is correct. What seems to be the problem?
>> >> Works here with no warnings (clang), but anyhow, the code is correct.
>> >
>> >>From gcc point of view gl was undefined when set to sd->genlist and that
>> > did come with a big fat warning :-)
>> >
>>
>> GCC is wrong, but I guess you had to silence it. :|
>
> gcc generates warnings because it sees this as a possible code bug - you pass
> in a reference and fill it then also re-assign the value again as a return 
> from
> the same func. in any sane world most people reading that code would go "wtf?
> is that a bug? did they may to pass in &somethingelse instead of &gl because
> this assigns it twice? are we losing a reference to something here?". gcc is
> saying that. the code itself wasn't broken. it would work, BUT it LOOKS like a
> bug to any "sane person". and gcc warns. the more warnings we let through, the
> more real issues hide in warnings we now ignore in the sea of warnings
> scrolling by. thus why it is being "shut up".
>
> but it is a point - it looks insane. imho eo_add given its current use of &
> should not return anything and we assign return by reference. at least then it
> doesn't look like a bug.

Agreed. It is surely very confusing to have something like obj =
eo_add(&obj, ...
-- 
Cedric BAIL

--
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] T-shirt for the upcoming 2016 EDDs

[The Rasterman]

On Wed, 2 Mar 2016 16:12:49 +0100 Stefan Schmidt  said:

> Hello.
> 
> At our initial Enlightenment Developer Day in Barcelona 2012 we had some 
> T-shirts for the event.
> We failed since to do this again which is a bit sad. Luckily we have a 
> bit more time in advance for the 2016 edition this year and I wonder if 
> someone wants to pick this up.
> 
> o We would need a new design (maybe a contest if we have some more 
> proposals)
> o We would need to query the sizes from attendees
> o We would need to get the shirts printed and shipped to some place in 
> Paris (or someone needs to arrange getting them there)

or printed in paris and someone local picks them up?

> Money wise I think we can ask the foundation to pay for them upfront and 
> we cash the money in at the event. Say 15-20€ per shirt?

they should be a bit cheaper than that no? like ~10?

> Does this sounds like a good idea? Anyone picking this up? Unlikely 
> Cedric or myself will be able to handle this.

cedric is a bit far away... :)

> regards
> Stefan Schmidt
> 
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&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] Eo: Changes to syntax

[Jean-Philippe André]

On 11 March 2016 at 00:51, Tom Hacohen  wrote:

> On 10/03/16 12:36, Carsten Haitzler wrote:
> > On Thu, 10 Mar 2016 15:46:19 +0900 Jean-Philippe André <
> j...@videolan.org> said:
> >
> >> On 10 March 2016 at 15:05, Carsten Haitzler 
> wrote:
> >>
> >>> On Thu, 10 Mar 2016 07:42:22 +0200 Daniel Zaoui <
> daniel.za...@samsung.com>
> >>> 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
>

Re: [E-devel] [EGIT] [core/elementary] master 01/01: Scaling test: reorder instructions to set the correct scale

[Hermet Park]

I know.
The Only different is I named the process(about scale propagation) in one 
abstract name.
Because most people will expect the exact problem like you.

-Original Message
From: "Tom Hacohen" 
To: ; 
Cc: 
Sent: 2016-03-10 (목) 23:39:56
Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: Scaling test: 
reorder instructions to set the correct scale
 
If I'm understanding the issue correctly (judging by his code changes 
and commit message) elm_scale properly applies to the children. The 
problem is that widgets that have scale set don't set the correct scale 
on the children if the children are added *after* the scale was set.

On 10/03/16 11:59, Hermet Park wrote:
> that's the elm scale function.
>
> -Original Message-
> From: "Tom Hacohen"
> To: ;
> Cc:
> Sent: 2016-03-10 (목) 20:14:34
> Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: Scaling test: 
> reorder instructions to set the correct scale
>
> It's not the elm scale function, it's elm widget that needs to propagate
> scale when adding a child. Jack, you should update elm_widget instead of
> hiding the bug.
>
> --
> Tom.
>
> On 10/03/16 10:57, Hermet Park wrote:
>> Sounds like elm scale function is broken. :(
>>
>> -Original Message-
>> From: "Daniel Zaoui"
>> To: ;
>> Cc:
>> Sent: 2016-03-03 (목) 17:54:51
>> Subject: [EGIT] [core/elementary] master 01/01: Scaling test: reorder 
>> instructions to set the correct scale
>>
>> jackdanielz pushed a commit to branch master.
>>
>> http://git.enlightenment.org/core/elementary.git/commit/?id=36669f1eccc3b6c320fb4c4ecc0e029b95834f57
>>
>> commit 36669f1eccc3b6c320fb4c4ecc0e029b95834f57
>> Author: Daniel Zaoui 
>> Date:   Thu Mar 3 10:25:22 2016 +0200
>>
>>   Scaling test: reorder instructions to set the correct scale
>>
>>   If the scale is set on an object before contents are set, it will not
>>   pass to them. Because of this, in the test, scale of the first label
>>   remains 1.0, i.e the window scale, instead of 0.5.
>>   The patch modifies the order of the instructions by setting the scale
>>   after setting the label as content of the frame.
>> ---
>>src/bin/test_scaling.c  2 +-
>>1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/bin/test_scaling.c b/src/bin/test_scaling.c
>> index d0d0f3c..84b20c6 100644
>> --- a/src/bin/test_scaling.c
>> +++ b/src/bin/test_scaling.c
>> @@ -76,7 +76,6 @@ test_scaling2(void *data EINA_UNUSED, Evas_Object *obj 
>> EINA_UNUSED, void *event_
>>   evas_object_show(bx);
>>
>>   fr = elm_frame_add(win);
>> -   elm_object_scale_set(fr, 0.5);
>>   elm_object_text_set(fr, "Scale: 0.5");
>>   lb = elm_label_add(win);
>>   elm_object_text_set(lb,
>> @@ -84,6 +83,7 @@ test_scaling2(void *data EINA_UNUSED, Evas_Object *obj 
>> EINA_UNUSED, void *event_
>>   "is 0.5. Child should"
>>   "inherit it.");
>>   elm_object_content_set(fr, lb);
>> +   elm_object_scale_set(fr, 0.5);
>>   evas_object_show(lb);
>>   elm_box_pack_end(bx, fr);
>>   evas_object_show(fr);
>>
>
>
> --
> 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
>


--
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-d