Re: [E-devel] break;

[Jean-Philippe André]

Hi,

I made a "quick" recap of the work that remains to be done for the
interfaces.
I might have missed some points but that should cover most of it.

Link: https://phab.enlightenment.org/T5301

Also, thanks a lot for the warm wishes, let's keep in touch!

Best regards,


On Tue, Feb 6, 2018 at 9:34 PM, Jean-Philippe André <j...@videolan.org>
wrote:

> Hello,
>
> As some of you may already know, I am going to take an indefinitely long
> break away from work and away from EFL.
>
>
> I believe Andy has clearly hilighted some of the problems with our project
> and community, from his point of view. I tried really hard to push the
> interfaces forward but after so much time & efforts we still haven't
> reached our goal. But more than the weight of legacy, the relative lack of
> fun and the insanely long time all this is taking, it is the degrading
> atmosphere that pushed me to finally make this decision, earlier this year.
> This choice is personal and unrelated to Andy's proposal.
>
> Please feel free to keep contacting me privately, preferrably about
> non-technical issues.
>
>
> Best regards,
>
> --
> Jean-Philippe André
>
> PS: Commit and contributor counts are on a sharp decline:
> https://devs.enlightenment.org/~jpeg/efl-stats/activity.
> html#commits_by_year
> https://www.openhub.net/p/efl/contributors/summary
>
>


-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] break;

[Jean-Philippe André]

Hello,

As some of you may already know, I am going to take an indefinitely long
break away from work and away from EFL.


I believe Andy has clearly hilighted some of the problems with our project
and community, from his point of view. I tried really hard to push the
interfaces forward but after so much time & efforts we still haven't
reached our goal. But more than the weight of legacy, the relative lack of
fun and the insanely long time all this is taking, it is the degrading
atmosphere that pushed me to finally make this decision, earlier this year.
This choice is personal and unrelated to Andy's proposal.

Please feel free to keep contacting me privately, preferrably about
non-technical issues.


Best regards,

-- 
Jean-Philippe André

PS: Commit and contributor counts are on a sharp decline:
https://devs.enlightenment.org/~jpeg/efl-stats/activity.html#commits_by_year
https://www.openhub.net/p/efl/contributors/summary
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL_UI_BG_WIDGET_DATA_GET_OR_RETURN

[Jean-Philippe André]

Hi~

On Thu, Feb 1, 2018 at 11:34 AM, cnook <kimci...@gmail.com> wrote:

> Dear all, Hello!
>
> As you konw, we have macro EFL_UI_GB_WIDGET_DATA_GET_OR_RETURN and we can
> find similar MACROs.
> As you probably do not know, the Tizen is maintaing test suite including
> negative test cases.
> One of TCs is calling elm_bg_load_size_set with NULL obj parameter.
> In this case, CRI message occurs, and abort occurs. Then the result of TC
> is ERROR.
> In my opinion the api elm_bg_load_size_set should have to check if the
> parameter is NULL or  not.
> My question is that do I have to add a line checking NULL to the macro
> EFL_UI_WIDGET_DATA_GET_OR_RETURN? or add separated line?
> Which one is better? Please let me know. Thank you in advance.
>

I think CRI here is a bit excessive, especially since this macro only
calls efl_data_scope_get() (not efl_data_scope_safe_get).
We might want to change this to ERR(), instead of CRI.

Best regards,

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] GPL icons in theme

[Jean-Philippe André]

On Tue, Jan 30, 2018 at 9:30 PM, Simon Lees <sfl...@suse.de> wrote:

>
>
> On 30/01/18 22:20, Jean-Philippe André wrote:
> > Hi,
> >
> > Sungtaek pointed out to me that we have GPLv3-licensed artworks (unsual
> for
> > images) in our theme, under data/elementary/theme/fdo. Those images are
> are
> > then included in the compiled theme default.edj. One source is clearly
> > GPLv3:
> > https://tiheum.deviantart.com/art/Faenza-Icons-173323228
> >
> > Now I wonder what the implications of this are...
> > 1. Does Elementary become GPL because we load the theme and it contains
> > executable code (embryo & edje programs), so the theme is to be
> considered
> > a library, contaminating everything??
> > 2. Or only the theme itself is GPL, by contamination from those images?
> > 3. Or is the compiled theme file not GPL because we're not linking or
> > derivating, merely archiving those images like in a Zip file, in which
> case
> > only what's in the tree is GPL? This would be same as HTML:
> > https://news.slashdot.org/story/13/06/26/2113242/when-
> gpl-becomes-almost-gpl-the-css-images-and-javascript-
> loophole/informative-comments#comments
> >
> > In the FAQ I only found a mention about fonts:
> > https://www.gnu.org/licenses/gpl-faq.en.html#FontException
> > We don't have such an exception.
> >
> > Pretty sure there is no problem (i.e. #3 is right), but IANAL so I'd
> rather
> > ask away :)
> >
>
> Licence wise i've always considered themes to be separate, whether that
> is correct or not is another question. GPL with images is silly anyway
> and we really should be asking upstream to relicense with some form of
> creative commons anyway which makes far more sense, but I guess the
> theme is probably technically GPL-3 as a binary.


Not so sure. HTML seems to be a crazy exception: An HTML file containing
GPL licensed JS code is not GPL itself. Not consistent but makes sense. EDJ
probably also falls under the category of "container".


> Probably the biggest actual real life issue is if the theme is being
> used in consumer devices such as tizen you would need to provide
> consumers a way to swap there stock theme for one of there choice.
>

Yeah that's partly why I'm asking. :)

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Committer proposal: taxi2se

[Jean-Philippe André]

On Mon, Jan 29, 2018 at 3:25 PM, Jean-Philippe André <j...@videolan.org>
wrote:

> Hi~
>
> I would like to propose "proper" committer access for taxi2se also known
> as Sungtaek Hong in real life. He has recently been doing a lot of very
> complex changes, mainly to elementary, which I believe are all going in the
> right direction for the Unified API or EFL2.
>
> As per usual, any comment or objection?
>

Unfortunately I have to retract this proposal myself.
It seems taxi2se will shift to another project soon.
I still believe taxi2se would be a great contributor to EFL.
Sorry for the noise, this was a very strange timing.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] GPL icons in theme

[Jean-Philippe André]

Hi,

Sungtaek pointed out to me that we have GPLv3-licensed artworks (unsual for
images) in our theme, under data/elementary/theme/fdo. Those images are are
then included in the compiled theme default.edj. One source is clearly
GPLv3:
https://tiheum.deviantart.com/art/Faenza-Icons-173323228

Now I wonder what the implications of this are...
1. Does Elementary become GPL because we load the theme and it contains
executable code (embryo & edje programs), so the theme is to be considered
a library, contaminating everything??
2. Or only the theme itself is GPL, by contamination from those images?
3. Or is the compiled theme file not GPL because we're not linking or
derivating, merely archiving those images like in a Zip file, in which case
only what's in the tree is GPL? This would be same as HTML:
https://news.slashdot.org/story/13/06/26/2113242/when-gpl-becomes-almost-gpl-the-css-images-and-javascript-loophole/informative-comments#comments

In the FAQ I only found a mention about fonts:
https://www.gnu.org/licenses/gpl-faq.en.html#FontException
We don't have such an exception.

Pretty sure there is no problem (i.e. #3 is right), but IANAL so I'd rather
ask away :)

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Committer proposal: taxi2se

[Jean-Philippe André]

Hi~

I would like to propose "proper" committer access for taxi2se also known as
Sungtaek Hong in real life. He has recently been doing a lot of very
complex changes, mainly to elementary, which I believe are all going in the
right direction for the Unified API or EFL2.

As per usual, any comment or objection?

Best regards,

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eolian template based generator presentation

[Jean-Philippe André]

Hey,

On Sat, Jan 27, 2018 at 9:36 PM, Davide Andreoli <d...@gurumeditation.it>
wrote:

> 2018-01-27 12:40 GMT+01:00 Felipe Magno de Almeida <
> felipe.m.alme...@gmail.com>:
>
> > On Fri, Jan 26, 2018 at 11:20 AM, Gustavo Sverzut Barbieri
> > <barbi...@gmail.com> wrote:
> > > On Fri, Jan 26, 2018 at 12:50 AM, Jean-Philippe André <
> j...@videolan.org>
> > wrote:
> > >>
> > >> Hi,
> >
> > [snip]
> >
> > >> So what I think is that this is a great tool that you provide here,
> but
> > I
> > >> doubt other languages than Python will adopt this straight away.
> Unless
> > we
> > >> start working on a new binding, maybe?
> > >
> > > well, point is you can create a new binding just replacing the text
> > > files that are the template... so maybe even c++ and c# could be
> > > changed to use that without major issues...
> > >
> > > not sure if Felipe thinks maintaining an eolian generator on his own is
> > worth.
> > >
> > > as for python dep... it will come with meson anyway.
>

The Python dep is only for compilation anyway.

> We will test pyolian with a test generator. Not sure about bindings yet
> > because we need some flexibility that templating might not be enough,
> > for example for JS which generates registration functions etc. "Loops"
> > are weirder in that case, but indeed maintaining more code is not
> > exactly my goal.
> >
>
> The template engine is really powerfull, it have access to the whole eolian
> api and db. And provide various control structures (if/then/else, for
> loops,
> macros, variables, etc...)
> It should be able to generate whatever complexity you need.
>

I was thinking the complexity may be too big for the templates generation,
but then again it may be just a matter of more templating?

Anyway if pyolian works out for esoteric bindings, then this is absolutely
for the best.
One generator in one language could be easier to maintain. :)
Also, the C++ generator is VERY hard to maintain (for C devs), so that
could help.



>
> > I do think pyolian will help with new ideas that are going to be easier
> > to put in practice, which we might not even have seriously considered
> > yet.
> >
> > @Davide: Could you create a EFL branch with pyolian inside? I think
> > this should not be outside EFL IMO.
> >
>
> pyolian (and the template generator) is aready in the EFL master branch.
>
> look at src/scripts/pyolian/ for them, there is also a quite complete docs
> in README.md
>
> and look at src/scripts/gendoc/ for an example usage.
>
> Let me know when you try it :)
>
>
> >
> > > --
> > > Gustavo Sverzut Barbieri
> > > --
> > > Mobile: +55 (16) 99354-9890
> >
> >
> > Regards,
> > --
> > Felipe Magno de Almeida
> >
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

Best regards,

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eolian template based generator presentation

[Jean-Philippe André]

Hi,

On Fri, Jan 26, 2018 at 6:51 AM, Davide Andreoli <d...@gurumeditation.it>
wrote:

> Hi guys,
>
> it's time for me to promote and receive some feedback on this really neat
> and powerfull tool I'm working on: an eolian generator fully based on a
> modern template engine, like the one you found in webtools like Django and
> Jinja2.
>
> All the documentation is hosted at:
> https://phab.enlightenment.org/w/pyolian/
>
>
> I initially wrote this generator to create the next-coming python-efl based
> on the Unified API,
> but It comes out so much powerfull and flexible that I suggest it's usage
> for every eolian based generation needs.
>
>
> Please give it a try and report any issue/idea/suggestion to me.
>
> ...at least, if you are so much lazy, please run (inside the
> efl/src/scripts/pyolian folder):
> ./generator.py test_gen_class.template --cls Efl.Loop.Timer
> ./generator.py test_gen_namespace.template --ns Efl.Ui
>
> and report any issue, It need testing !
>

Well... The first command gives me this:
  AttributeError: 'Type' object has no attribute 'c_type'

The other command works fine :)


Anyway, what's the plan for this?
Is this the tool generating the doc in our website? Aren't we using a
Lua-based generator?
I don't care much which one we use but it would be a shame to have 2
competing tools to maintain :)

As you know, each binding is generated using a custom generator written in
the maintainer's choice of language (so, Lua or C++, now Python).
This makes sense as it means anyone maintaining a binding only needs to
know C and that language (not 100% true for C# as it's using the C++
generator).

So what I think is that this is a great tool that you provide here, but I
doubt other languages than Python will adopt this straight away. Unless we
start working on a new binding, maybe?

One way or another, good job! Thanks a lot :)



> The only issue I know atm is that you must build the efl source IN-TREE,
> otherwise it will not work; this will be fixed once we will switch to meson
> (I don't want to make the works twice)
>

Good to know!


-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/03: widget: Rename orientation_mode_disabled

[Jean-Philippe André]

On Fri, Jan 19, 2018 at 2:14 PM, Jean-Philippe André <j...@videolan.org>
wrote:

> Hi,
>
> On Fri, Jan 19, 2018 at 12:56 AM, Davide Andreoli <d...@gurumeditation.it>
> wrote:
>
>> 2018-01-18 9:35 GMT+01:00 Jean-Philippe ANDRÉ <j...@videolan.org>:
>>
>> > jpeg pushed a commit to branch master.
>> >
>> > http://git.enlightenment.org/core/efl.git/commit/?id=
>> > f312ed6db9cb64e1c4685fa27d1c41c347c382a6
>> >
>> > commit f312ed6db9cb64e1c4685fa27d1c41c347c382a6
>> > Author: Jean-Philippe Andre <jp.an...@samsung.com>
>> > Date:   Thu Jan 18 17:13:59 2018 +0900
>> >
>> > widget: Rename orientation_mode_disabled
>> >
>> > Name is stupid and long, why not just invert this bool?
>> >
>>
>> The *_mode usually suffix imply a mode to be set (an enum).
>>
>> obj.orientation_mode = TRUE/FALSE   is not really well readable, you
>> really need to read the docs to understand it.
>>
>> I suggest to change the name to "orientation_automatic", "auto_orient",
>> "orientation_enabled", or something like that.
>>
>> ... Or maybe better to leave the name as "orientation_mode" and make it
>> an enum so that we can also extend it in the future, fe:
>> ORIENT_NONE
>> ORIENT_AUTO
>> and maybe also:
>> ORIENT_MANUAL
>> ORIENT_LANDSCAPE_ONLY
>> ORIENT_PORTRAIT_ONLY
>> etc...
>>
>
> Right, an enum makes sense here. Even if for now it would only have two
> values, acting like the boolean it is now.
> As always, thanks for your input! :)
>
>
Done.


>
>>
>>
>>
>> > ---
>> >  src/lib/elementary/efl_ui_widget.c  | 10 +-
>> >  src/lib/elementary/efl_ui_widget.eo | 17 +++--
>> >  src/lib/elementary/elm_main.c   |  4 ++--
>> >  src/lib/elementary/elm_widget.h |  2 --
>> >  4 files changed, 14 insertions(+), 19 deletions(-)
>> >
>> > diff --git a/src/lib/elementary/efl_ui_widget.c
>> > b/src/lib/elementary/efl_ui_widget.c
>> > index dfe47d7661..e8ee8ca9be 100644
>> > --- a/src/lib/elementary/efl_ui_widget.c
>> > +++ b/src/lib/elementary/efl_ui_widget.c
>> > @@ -3456,11 +3456,11 @@ elm_widget_display_mode_set(Evas_Object *obj,
>> > Evas_Display_Mode dispmode)
>> >  }
>> >
>> >  EOLIAN static void
>> > -_efl_ui_widget_orientation_mode_disabled_set(Eo *obj,
>> > Elm_Widget_Smart_Data *sd, Eina_Bool disabled)
>> > +_efl_ui_widget_orientation_mode_set(Eo *obj, Elm_Widget_Smart_Data
>> *sd,
>> > Eina_Bool enabled)
>> >  {
>> > int orient_mode = -1;
>> >
>> > -   if (!disabled)
>> > +   if (enabled)
>> >   {
>> >  //Get current orient mode from it's parent otherwise, 0.
>> >  sd->orient_mode = 0;
>> > @@ -3472,10 +3472,10 @@ _efl_ui_widget_orientation_mode_disabled_set(Eo
>> > *obj, Elm_Widget_Smart_Data *sd,
>> >  }
>> >
>> >  EOLIAN static Eina_Bool
>> > -_efl_ui_widget_orientation_mode_disabled_get(Eo *obj EINA_UNUSED,
>> > Elm_Widget_Smart_Data *sd)
>> > +_efl_ui_widget_orientation_mode_get(Eo *obj EINA_UNUSED,
>> > Elm_Widget_Smart_Data *sd)
>> >  {
>> > -   if (sd->orient_mode == -1) return EINA_TRUE;
>> > -   else return EINA_FALSE;
>> > +   if (sd->orient_mode == -1) return EINA_FALSE;
>> > +   else return EINA_TRUE;
>> >  }
>> >
>> >  EOLIAN static void
>> > diff --git a/src/lib/elementary/efl_ui_widget.eo
>> > b/src/lib/elementary/efl_ui_widget.eo
>> > index b50f2d7da0..46c66c23d0 100644
>> > --- a/src/lib/elementary/efl_ui_widget.eo
>> > +++ b/src/lib/elementary/efl_ui_widget.eo
>> > @@ -112,8 +112,8 @@ abstract Efl.Ui.Widget (Efl.Canvas.Group,
>> Efl.Access,
>> >   return: bool; [[$true on success, $false otherwise]]
>> >   legacy: null;
>> >}
>> > -  @property orientation_mode_disabled {
>> > - [[Whether the widget's automatic orientation is disabled or
>> not.
>> > +  @property orientation_mode {
>> > + [[Whether the widget's automatic orientation is enabled or
>> not.
>> >
>> > Orientation mode is used for widgets to change their style
>> or
>> > send
>> > signals based on the canvas rotation (i.e. the window
>> > orientation).
>> 

Re: [E-devel] [EGIT] [core/efl] master 02/03: widget: Rename orientation_mode_disabled

[Jean-Philippe André]

Hi,

On Fri, Jan 19, 2018 at 12:56 AM, Davide Andreoli <d...@gurumeditation.it>
wrote:

> 2018-01-18 9:35 GMT+01:00 Jean-Philippe ANDRÉ <j...@videolan.org>:
>
> > jpeg pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=
> > f312ed6db9cb64e1c4685fa27d1c41c347c382a6
> >
> > commit f312ed6db9cb64e1c4685fa27d1c41c347c382a6
> > Author: Jean-Philippe Andre <jp.an...@samsung.com>
> > Date:   Thu Jan 18 17:13:59 2018 +0900
> >
> > widget: Rename orientation_mode_disabled
> >
> > Name is stupid and long, why not just invert this bool?
> >
>
> The *_mode usually suffix imply a mode to be set (an enum).
>
> obj.orientation_mode = TRUE/FALSE   is not really well readable, you
> really need to read the docs to understand it.
>
> I suggest to change the name to "orientation_automatic", "auto_orient",
> "orientation_enabled", or something like that.
>
> ... Or maybe better to leave the name as "orientation_mode" and make it
> an enum so that we can also extend it in the future, fe:
> ORIENT_NONE
> ORIENT_AUTO
> and maybe also:
> ORIENT_MANUAL
> ORIENT_LANDSCAPE_ONLY
> ORIENT_PORTRAIT_ONLY
> etc...
>

Right, an enum makes sense here. Even if for now it would only have two
values, acting like the boolean it is now.
As always, thanks for your input! :)


>
>
>
> > ---
> >  src/lib/elementary/efl_ui_widget.c  | 10 +-
> >  src/lib/elementary/efl_ui_widget.eo | 17 +++--
> >  src/lib/elementary/elm_main.c   |  4 ++--
> >  src/lib/elementary/elm_widget.h |  2 --
> >  4 files changed, 14 insertions(+), 19 deletions(-)
> >
> > diff --git a/src/lib/elementary/efl_ui_widget.c
> > b/src/lib/elementary/efl_ui_widget.c
> > index dfe47d7661..e8ee8ca9be 100644
> > --- a/src/lib/elementary/efl_ui_widget.c
> > +++ b/src/lib/elementary/efl_ui_widget.c
> > @@ -3456,11 +3456,11 @@ elm_widget_display_mode_set(Evas_Object *obj,
> > Evas_Display_Mode dispmode)
> >  }
> >
> >  EOLIAN static void
> > -_efl_ui_widget_orientation_mode_disabled_set(Eo *obj,
> > Elm_Widget_Smart_Data *sd, Eina_Bool disabled)
> > +_efl_ui_widget_orientation_mode_set(Eo *obj, Elm_Widget_Smart_Data *sd,
> > Eina_Bool enabled)
> >  {
> > int orient_mode = -1;
> >
> > -   if (!disabled)
> > +   if (enabled)
> >   {
> >  //Get current orient mode from it's parent otherwise, 0.
> >  sd->orient_mode = 0;
> > @@ -3472,10 +3472,10 @@ _efl_ui_widget_orientation_mode_disabled_set(Eo
> > *obj, Elm_Widget_Smart_Data *sd,
> >  }
> >
> >  EOLIAN static Eina_Bool
> > -_efl_ui_widget_orientation_mode_disabled_get(Eo *obj EINA_UNUSED,
> > Elm_Widget_Smart_Data *sd)
> > +_efl_ui_widget_orientation_mode_get(Eo *obj EINA_UNUSED,
> > Elm_Widget_Smart_Data *sd)
> >  {
> > -   if (sd->orient_mode == -1) return EINA_TRUE;
> > -   else return EINA_FALSE;
> > +   if (sd->orient_mode == -1) return EINA_FALSE;
> > +   else return EINA_TRUE;
> >  }
> >
> >  EOLIAN static void
> > diff --git a/src/lib/elementary/efl_ui_widget.eo
> > b/src/lib/elementary/efl_ui_widget.eo
> > index b50f2d7da0..46c66c23d0 100644
> > --- a/src/lib/elementary/efl_ui_widget.eo
> > +++ b/src/lib/elementary/efl_ui_widget.eo
> > @@ -112,8 +112,8 @@ abstract Efl.Ui.Widget (Efl.Canvas.Group, Efl.Access,
> >   return: bool; [[$true on success, $false otherwise]]
> >   legacy: null;
> >}
> > -  @property orientation_mode_disabled {
> > - [[Whether the widget's automatic orientation is disabled or
> not.
> > +  @property orientation_mode {
> > + [[Whether the widget's automatic orientation is enabled or not.
> >
> > Orientation mode is used for widgets to change their style or
> > send
> > signals based on the canvas rotation (i.e. the window
> > orientation).
> > @@ -123,11 +123,10 @@ abstract Efl.Ui.Widget (Efl.Canvas.Group,
> Efl.Access,
> > the theme in order to provide a different look for the widget
> > based
> > on the canvas orientation.
> >
> > -   By default orientation mode is enabled, which means this
> > property
> > -   is $false.
> > +   By default orientation mode is enabled, i.e. this is $true.
> >   ]]
> >   values {
> > -disabled: bool(false); [[$true if the orientation 

Re: [E-devel] [EGIT] [core/efl] master 02/05: selection: add efl_selection interface

[Jean-Philippe André]

On Thu, Jan 18, 2018 at 11:07 PM, Andrew Williams <a...@andywilliams.me>
wrote:

> Pretty sure that efl.ui.selection, efl.ui.cnp and efl.ui.dnd would be good
> namespaces.
>
> Efl.Ui.Selectable should probably go into the selection namespace too.
>

No because it's a different kind of selection :)
Selectable -> item select in a list (work in progress...)
Selection -> text selection for cnp & dnd. This one belongs more to cnp I
think, and selection may be an abusive name.
So I think cnp, dnd and selection (NOT selectable!) belong to the same
category.


>
> Andy
>
> On Thu, 18 Jan 2018 at 07:54 Jean-Philippe André <j...@videolan.org>
> wrote:
>
> > Hi,
> >
> > On Fri, Jan 12, 2018 at 4:23 AM, Gustavo Sverzut Barbieri <
> > barbi...@gmail.com> wrote:
> >
> > > i guess davemds will get mad, since he was complaining about
> > > namespaces and this one, Efl.Selection clearly misses a proper
> > > namespace.
> > >
> >
> > Well, I kinda agree. All selection stuff could go in Efl.Ui. Or
> > Efl.Ui.Util.
> > All CnP and Dnd stuff should be in the same namespace.
> >
> > But I can't find any better name for Efl.Selection itself (assuming it's
> in
> > Ui or Util or whatnot).
> >
> > Any proposition? Dave? Andy? Thiep?
> >
> >
> > >
> > > On Thu, Jan 11, 2018 at 7:02 AM, Thiep Ha <thie...@gmail.com> wrote:
> > > > thiep pushed a commit to branch master.
> > > >
> > > > http://git.enlightenment.org/core/efl.git/commit/?id=f191d68
> > > 21f0fd94389dc92c8353b769eaacad28a
> > > >
> > > > commit f191d6821f0fd94389dc92c8353b769eaacad28a
> > > > Author: Thiep Ha <thie...@gmail.com>
> > > > Date:   Tue Jan 9 15:34:12 2018 +0900
> > > >
> > > > selection: add efl_selection interface
> > > >
> > > > Efl_Selection is the object interface for selection api of
> elm_cnp.
> > > > It allows get, set, clear, check selection.
> > > > ---
> > > >  src/Makefile_Elementary.am |  2 +
> > > >  src/lib/elementary/Elementary.h|  1 +
> > > >  src/lib/elementary/efl_selection.c | 62
> > > ++
> > > >  src/lib/elementary/efl_selection.eo| 45
> ++
> > > >  src/lib/elementary/efl_selection_manager.c |  4 +-
> > > >  src/lib/elementary/efl_ui_widget.eo|  2 +-
> > > >  6 files changed, 113 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/src/Makefile_Elementary.am b/src/Makefile_Elementary.am
> > > > index b1ac2657ae..a1712eca5e 100644
> > > > --- a/src/Makefile_Elementary.am
> > > > +++ b/src/Makefile_Elementary.am
> > > > @@ -97,6 +97,7 @@ elm_public_eolian_files = \
> > > > lib/elementary/efl_access_window.eo \
> > > > lib/elementary/efl_config_global.eo \
> > > > lib/elementary/elm_code_widget.eo \
> > > > +   lib/elementary/efl_selection.eo \
> > > > $(NULL)
> > > >
> > > >  # More public files -- FIXME
> > > > @@ -761,6 +762,7 @@ lib_elementary_libelementary_la_SOURCES = \
> > > > lib/elementary/efl_ui_scroll_manager.c \
> > > > lib/elementary/efl_ui_pan.c \
> > > > lib/elementary/efl_selection_manager.c \
> > > > +   lib/elementary/efl_selection.c \
> > > > $(NULL)
> > > >
> > > >
> > > > diff --git a/src/lib/elementary/Elementary.h
> > > b/src/lib/elementary/Elementary.h
> > > > index b5c58c77f7..2e5e4cb5b7 100644
> > > > --- a/src/lib/elementary/Elementary.h
> > > > +++ b/src/lib/elementary/Elementary.h
> > > > @@ -324,6 +324,7 @@ EAPI extern Elm_Version *elm_version;
> > > >  # include "efl_selection_types.eot.h"
> > > >  # include "efl_ui_dnd_types.eot.h"
> > > >  # include 
> > > > +# include "efl_selection.eo.h"
> > > >  #endif
> > > >
> > > >  /* include deprecated calls last of all */
> > > > diff --git a/src/lib/elementary/efl_selection.c
> > > b/src/lib/elementary/efl_selection.c
> > > > new file mode 100644
> > > > index 00..9f086e340e
> > > > --- /dev/null
> > > > +++ b/src/lib/elementary/efl_selection.c
> > > > @@ -0,0 +

Re: [E-devel] Eo/Eolian namespace definition

[Jean-Philippe André]

On Thu, Jan 18, 2018 at 8:59 PM, Felipe Magno de Almeida <
felipe.m.alme...@gmail.com> wrote:

> On Sat, Jan 13, 2018 at 8:43 AM, Davide Andreoli <d...@gurumeditation.it>
> wrote:
> > 2018-01-11 6:18 GMT+01:00 Jean-Philippe André <j...@videolan.org>:
>
> [snip]
>
> > If all the bindings we have written so far need this
> > lowercase-on-namespaces hack
> > then It's probably correct to lowercase them directly in eo files, so
> that
> > Efl.Ui.Button will
> > become efl.ui.Button
>
> It is even worse that in C++ the normal is all lower-case, so we
> use the classes-start-with-uppercase-hack. But I agree with you
> here. If we do have to deal with name clashes between namespaces
> and classes anyway for bindings, why not prohibit clashes in Eolian
> and force a style that avoids the clash.
>
> +1 for lowercase namespaces.
>

Good idea, but that will impact A LOT of files :)


>
> > This way we will have:
> > * consistent names between different languages
> > * no more clashes between namespaces and class names.
> > * lowered namespaces also seems more readable to me, as it give more
> weight
> > to the
> > class name and a bit less to the namespace.
>
> We also have a problem with events: are they in a different "namespace"
> or the same as methods? Couldn't get an answer for this yet. We shouldn't
> allow clashes between events and methods because they will live in the same
> namespace (the class itself) for most bindings anyway and using
> prefixes/suffixes do not help because they can't guarantee a clash
> is not possible anyway.
>

I think they should not clash with property or method names.
In my view they are a member of the class, just like a property, or
property_get/set, or method.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo/Eolian namespace definition

[Jean-Philippe André]

On Sun, Jan 14, 2018 at 9:18 AM, Andrew Williams <a...@andywilliams.me>
wrote:

> Hi,
>
> Thanks for pointing out the bug in the API docs that have been generated. I
> have now updated this to show the true impact of incomplete namespaces.
> Go to https://www.enlightenment.org/develop/api/start now and you will see
> a very long list of classes and interfaces at the top which are not part of
> a larger namespace.
>
> This does look more confusing (for example: Efl.Canas is not in the same
> space as Efl.Canvas.Group) but it highlights this issue well.
> We should come up with a method for fixing these in a way that our bound
> languages will be happy with too.
>

Any proposal?

Efl.Canvas -> Efl.Canvas.Canvas would be fine to me, but then need the C
names to remain unchanged (EFL_CANVAS_CLASS, efl_canvas_blah_call, etc...)
Same for Efl.Selection.

Efl.VG has been mentioned too, does it belong to Efl.Gfx? Should Efl.Vg
itself be Efl.Vg.Object / Efl.Vg.Node? Or Efl.Gfx.Vector.Node?
Same for Animation & Interpolator, Player & Playable, Gesture, etc...

Should we have a "Util" namespace for non ui common tools, like
Interpolator, Observable/Observer, Config, Vpath?,

Whatever the solution I doubt we can find a solution that works beautifully
in all languages. C has its own restrictions unless we accept awkward &
long names (then how would that be any better than legacy?) while various
languages have their own issues. C++ and C# are now fine with having a

As a side note, the documentation lacks a section "these classes use /
implement / inherit from this class / interface".


> Thanks,
> Andy
>
> On Sat, 13 Jan 2018 at 10:45 Davide Andreoli <d...@gurumeditation.it>
> wrote:
>
> > 2018-01-11 6:18 GMT+01:00 Jean-Philippe André <j...@videolan.org>:
> >
> > > Hi Dave,
> > >
> > > On Thu, Jan 11, 2018 at 7:43 AM, Davide Andreoli <
> d...@gurumeditation.it
> > >
> > > wrote:
> > >
> > > > 2018-01-08 19:52 GMT+01:00 Cedric Bail <ced...@ddlm.me>:
> > > >
> > > > > Hi Dave,
> > > > >
> > > > > >  Original Message 
> > > > > > Subject: [E-devel] Eo/Eolian namespace definition
> > > > > > Local Time: January 7, 2018 9:28 AM
> > > > > > UTC Time: January 7, 2018 5:28 PM
> > > > > > From: d...@gurumeditation.it
> > > > > > To: Enlightenment <enlightenment-devel@lists.sourceforge.net>
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I'm playing again with eolian and python, and I'm facing an issue
> > > with
> > > > > > regards class names and namespaces separation (I already raised
> > this
> > > in
> > > > > the
> > > > > > past)
> > > > > >
> > > > > > A first intro to python namespaces (I think apply to any other
> > > > high-level
> > > > > > language):
> > > > > >
> > > > > > - in py every class must live in a given namespace and you use
> the
> > > > class
> > > > > as:
> > > > > > from  import 
> > > > > > - every namespace in python is a separate .so file
> > > > > >
> > > > > > The basic question is:
> > > > > > is the Efl.Text (interface) inside the Efl.Text namespace?
> > > > > > do I need to put the Text interface inide the Efl.Text .so file?
> > > > > >
> > > > > > NO) if the resonse is no, then in python will become:
> > > > > > from efl.ui import Button
> > > > > > from efl import Text
> > > > > > from efl.text import Font
> > > > > >
> > > > > > this feels wrong to me, as Text is not in the text namespace
> > > > > >
> > > > > > YES) if the response is YES:
> > > > > > from efl.ui import Button
> > > > > > from efl.text import Text
> > > > > > from efl.text import Font
> > > >
> > >
> > > Would interfaces need to be imported in Python?
> > > Can't we just use obj.font_foo() and obj.text_bar()?
> > >
> >
> > nono, in py you need to import the simbols you want to explicity use.
> > C objecs that implement the Text interface will translate to Python in an
> > object that inherit from the Text interface, thus all the interface
> > method/properties will be available

Re: [E-devel] [EGIT] [core/efl] master 02/05: selection: add efl_selection interface

[Jean-Philippe André]

_callback_call(sel->request_obj,
> EFL_SELECTION_EVENT_SELECTION_CHANGED, );
> >
> > return ECORE_CALLBACK_RENEW;
> >  }
> > diff --git a/src/lib/elementary/efl_ui_widget.eo
> b/src/lib/elementary/efl_ui_widget.eo
> > index f4933d4438..d0c1797c80 100644
> > --- a/src/lib/elementary/efl_ui_widget.eo
> > +++ b/src/lib/elementary/efl_ui_widget.eo
> > @@ -17,7 +17,7 @@ struct Efl.Ui.Widget.Focus_State {
> >  abstract Efl.Ui.Widget (Efl.Canvas.Group, Efl.Access,
> >  Efl.Access.Component, Efl.Ui.Focus.User,
> Efl.Part,
> >  Efl.Ui.Focus.Object, Efl.Ui.Base, Efl.Ui.Cursor,
> > -Efl.Ui.Translatable)
> > +Efl.Ui.Translatable, Efl.Selection)
> >  {
> > [[Elementary widget abstract class]]
> > legacy_prefix: elm_widget;
> >
> > --
> >
> >
>
>
>
> --
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (16) 99354-9890
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>


-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] efl_add causing confusion

[Jean-Philippe André]

[ignoring everything else in this thread]

Hi,

I have some early prototype work in my branch devs/jpeg/efl_invalidate to
experiment with efl_invalidate.
I am not sure how to exploit it, or if this idea is right, so it's on hold
for now.
If you're interested, have a look, and let us know what your experiments
lead to.

Best regards,

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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/02: eina: remove usless newline

[Jean-Philippe André]

Quick note: I think this patch affects ABI for anything that uses EO files
outside of EFL tree (which isn't a stable feature).

On Tue, Jan 16, 2018 at 7:53 PM, Jean-Philippe André <j...@videolan.org>
wrote:

> Hi,
>
> This broke make check (I fixed it now).
>
> Note that this patch probably should not have been merged as a single
> commit, as the Phab Diff contains multiple patches.
>
> Best regards,
>
> On Tue, Jan 16, 2018 at 5:50 PM, Jean Guyomarc'h <j...@guyomarch.bzh>
> wrote:
>
>> raster pushed a commit to branch master.
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=34d9f20
>> 70696027199a56cb621c0526ea1430e8f
>>
>> commit 34d9f2070696027199a56cb621c0526ea1430e8f
>> Author: Jean Guyomarc'h <j...@guyomarch.bzh>
>> Date:   Tue Jan 16 14:58:38 2018 +0900
>>
>> eina: remove usless newline
>>
>> Summary:
>> ecore_evas: remove debug
>>
>> eina: unregister log level when done with
>>
>> Fixes a constant memory leak.
>>
>> eina: introduce EINA_HOT and EINA_COLD
>>
>> These attributes respectivelly expand to __attribute__ ((hot)) and
>> __attribute__ ((cold)) when available. They allow to mark functions
>> are
>> being hot/cold (frequently used or not) as well as to qualify labels
>> within a function (likely/unlikely branches).
>>
>> eo: speed-up generated calls by removing call cache
>>
>> The call cache needed to by thread-local, to avoid concurrency issues.
>> Problem with TLS is that is adds an extra overhead, which appears to
>> be
>> greater than the optimization the cache provides.
>>
>> Op is naturally atomic, because it is an unsigned integer. As such, it
>> cannot be tempered with while another thread is reading it. When
>> entering the generated function, the first operation done is reading
>> 'op'. If we have concurrency, we will have access sequences returning
>> either EFL_NOOP or a VALID op, because 'op' is not set until the very
>> end of the function, when everything has been computed. As such, we
>> now
>> use the 'op' atomic integer to instore a lock-free/wait-free
>> mechanism,
>> which allows to drop the TLS nature of the cache, speeding up the
>> access
>> to the cache, and therefore making functions execute faster.
>>
>> We don't test anymore the generation count. This can be put as a
>> limitation. If means that if you call efl_object_shutdown() and
>> re-initialize it later with different data, opcodes will be invalid.
>> I am not sure there is any usecase for this to ever happen.
>> We could move all the caches in a dedicated section, that can be
>> overwritten after a call to efl_object_shutdown(), but I am not sure
>> it
>> will be very portable.
>>
>> Benchmark: mean over 3 executions of
>>ELM_TEST_AUTOBOUNCE=100 time elementary_test -to genlist
>>
>> ```
>>  BEFORE   AFTER
>> 
>> time (ns)4111647.09147676220.0
>> frames   2872.5   2904.5
>> time per frame (ns)  3869364.65   3149535.35
>> user time (s)11.096   9.22
>> cpu (%)  22.668   18.332
>> ```
>>
>> Ref T6580
>>
>> Reviewers: raster, cedric
>>
>> Subscribers: cedric, jpeg
>>
>> Maniphest Tasks: T6580
>>
>> Differential Revision: https://phab.enlightenment.org/D5738
>> ---
>>  src/lib/ecore_evas/ecore_evas_private.h |  2 +-
>>  src/lib/eina/eina_cow.c |  1 +
>>  src/lib/eina/eina_safepointer.c |  2 +-
>>  src/lib/eina/eina_types.h   |  8 +
>>  src/lib/eo/Eo.h | 56
>> +++--
>>  src/lib/eo/eo.c | 64
>> ++---
>>  6 files changed, 33 insertions(+), 100 deletions(-)
>>
>> diff --git a/src/lib/ecore_evas/ecore_evas_private.h
>> b/src/lib/ecore_evas/ecore_evas_private.h
>> index 7b83589347..13002402a4 100644
>> --- a/src/lib/ecore_evas/ecore_evas_private.h
>> +++ b/src/lib/ecore_evas/ecore_evas_private.h
>> @@ -347,7 +347,7 @@ struct _Ecore_Evas
>> } delayed;
>>
>> int refcount;
>> -#define ECORE_EVAS_ASYNC_RENDER_DEBUG 1 /* TODO:

Re: [E-devel] [EGIT] [core/efl] master 01/02: eina: remove usless newline

[Jean-Philippe André]

Hi,

(skip this mail if you don't care about micro optimization^^)

On Tue, Jan 16, 2018 at 9:13 PM, Carsten Haitzler <ras...@rasterman.com>
wrote:

> On Tue, 16 Jan 2018 20:25:37 +0900 Jean-Philippe André <j...@videolan.org>
> said:
>
> > Oh, another point.
> >
> > I'm pretty sure that the many very ugly goto we have in the code to "not
> > pollute L1 cache" are in fact not useful. I had a look at the ASM
> produced
> > by GCC -O2 and it strictly follows EINA_(UN)LIKELY. If goto is used for
> > error handling, fine, but if it's used with "goto label_back",
> readability
> > is really bad, while apparently not having any meaningful impact on the
> > binary code (for GCC, clang differs a bit). EINA_LIKELY is good enough,
> > IMHO. And hardware branch prediction happens no matter what.
>
> at the time i used EINA_LIKELY/UNLIKELY and also tried goto's and the gotos
> reshuffled the code and ended up with speedups, the likely/unlikely didn't.
> it's not about branch prediction BUT keeping code that might be fetched
> within
> the same cacheline of instructions as linear as possible without skips
> ahead
> skipping error or rare case code.
>


Yeah except it seems not be be true with GCC 7.2.1 and CFLAGS=-O2.
HW branch prediction will not affect L1 code cache but EINA_[UN]LIKELY will.

Let's have a quick look at the ASM produced, I think it's quite interesting
:)


Code A:

  if(EINA_UNLIKELY(!condition)) goto label.
  
  label: 

This will inline hot code after "jne":
  test !condition
  jne label
  hot code
  label: cold code



Code B:

  if (EINA_UNLIKELY(!condition)) {  }
  

This will inline hot code after "jne". The ASM is exactly the same as Code
A except the labelID's may differ a bit (probably depending on how they are
allocated by GCC).

  test !condition
  jne label
  hot code
  label: cold code



Code C:

  if (!condition) goto label
  
  label: 

This will inline  after "je" (the condition for a jump becomes
inversed, of course), which is the opposite of what we wanted.

  test !condition
  je label2
  (supposedly) cold code
  label2: (supposedly) hot code


Conclusions:
- EINA_LIKELY has a direct impact on what GCC decides to do at ASM level
(at least with -O2 on my x64 system).
- A goto without EINA_LIKELY might even be inlined. GCC probably assumes
the true path (the goto branch) is most likely.

I think goto harms readability and maintenance for dubious performance
gains (which, if the above ASM is correct, are nil).
goto remains useful for exception handling, and should be exclusively
limited to that case, together with EINA_[UN]LIKELY.

Clang/LLVM produces different code in all cases and my lack of knowledge in
ASM doesn't allow me to easily analyse said differences :)

GCC remains a good option for optimization, and follows our hints. :)

Best regards,



ANNEX.


Tested in Eo.h: EFL_FUNC_COMMON_OP / EFL_FUNC_COMMON_OP_END
The following output comes from gcc -S.
Observe the first jump in BB#1 (je or jne).

Snippet for A/B:

# BB#1:
movl efl_key_data_set.___generation(%rip), %eax
movq _efl_object_init_generation@GOTPCREL(%rip), %rdx
cmpl (%rdx), %eax
jne .LBB0_2
.LBB0_3:
leaq .L.str(%rip), %rsi
leaq .L.str.1(%rip), %r8
leaq 8(%rsp), %rdx
movl $302, %r9d  # imm = 0x12E
movq %rbx, %rdi
callq _efl_object_call_resolve@PLT
testb %al, %al
je .LBB0_5
# BB#4:
movq 8(%rsp), %rdi
movq 32(%rsp), %rsi
movq %r15, %rdx
movq %r14, %rcx
callq *24(%rsp)
leaq 8(%rsp), %rdi
callq _efl_object_call_end@PLT
.LBB0_5:
movq %fs:40, %rax
cmpq 72(%rsp), %rax
jne .LBB0_7
# BB#6:
addq $80, %rsp
popq %rbx
popq %r14
popq %r15
retq
.LBB0_2:
leaq efl_key_data_set(%rip), %rdi
leaq .L.str(%rip), %rdx
leaq .L.str.1(%rip), %rcx
movl $302, %r8d  # imm = 0x12E
movq %rbx, %rsi
callq _efl_object_op_api_id_get@PLT
movl %eax, %ecx
movl %ecx, efl_key_data_set.___op(%rip)
movq _efl_object_init_generation@GOTPCREL(%rip), %rax
movl (%rax), %eax
movl %eax, efl_key_data_set.___generation(%rip)
testl %ecx, %ecx
jne .LBB0_3
jmp .LBB0_5


Patch for B:

diff --git a/src/lib/eo/Eo.h b/src/lib/eo/Eo.h
index a26e9fb7a6..2518680765 100644
--- a/src/lib/eo/Eo.h
+++ b/src/lib/eo/Eo.h
@@ -1183,8 +1183,11 @@ typedef struct _Efl_Object_Op_Call_Data
_Eo_##Name##_func _func_;\
if (EINA_UNLIKELY((___op == EFL_NOOP) ||   \
  (___generation != _efl_object_init_generation))) \
- goto __##Name##_op_create; /* yes a goto - see below */ \
-   __##Name##_op_create_done: EINA_HOT; \
+ { \
+___op = _efl_object_op_api_id_get(EFL_FUNC_COMMON_OP_FUNC(Name),
Obj, #Name, __FILE__, __LINE__); \
+___generation = _efl_object_init_generation; \
+if (EINA_UNLIKELY(___op == EFL_NOOP)) goto __##Name##_failed; \
+ } \
if (EINA_UNLIKELY(!_efl_obj

Re: [E-devel] [EGIT] [core/efl] master 01/02: eina: remove usless newline

[Jean-Philippe André]

Oh, another point.

I'm pretty sure that the many very ugly goto we have in the code to "not
pollute L1 cache" are in fact not useful. I had a look at the ASM produced
by GCC -O2 and it strictly follows EINA_(UN)LIKELY. If goto is used for
error handling, fine, but if it's used with "goto label_back", readability
is really bad, while apparently not having any meaningful impact on the
binary code (for GCC, clang differs a bit). EINA_LIKELY is good enough,
IMHO. And hardware branch prediction happens no matter what.

So, for at least Eo.h I think it would be very good to remove the goto.

On Tue, Jan 16, 2018 at 7:53 PM, Jean-Philippe André <j...@videolan.org>
wrote:

> Hi,
>
> This broke make check (I fixed it now).
>
> Note that this patch probably should not have been merged as a single
> commit, as the Phab Diff contains multiple patches.
>
> Best regards,
>
> On Tue, Jan 16, 2018 at 5:50 PM, Jean Guyomarc'h <j...@guyomarch.bzh>
> wrote:
>
>> raster pushed a commit to branch master.
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=34d9f20
>> 70696027199a56cb621c0526ea1430e8f
>>
>> commit 34d9f2070696027199a56cb621c0526ea1430e8f
>> Author: Jean Guyomarc'h <j...@guyomarch.bzh>
>> Date:   Tue Jan 16 14:58:38 2018 +0900
>>
>> eina: remove usless newline
>>
>> Summary:
>> ecore_evas: remove debug
>>
>> eina: unregister log level when done with
>>
>> Fixes a constant memory leak.
>>
>> eina: introduce EINA_HOT and EINA_COLD
>>
>> These attributes respectivelly expand to __attribute__ ((hot)) and
>> __attribute__ ((cold)) when available. They allow to mark functions
>> are
>> being hot/cold (frequently used or not) as well as to qualify labels
>> within a function (likely/unlikely branches).
>>
>> eo: speed-up generated calls by removing call cache
>>
>> The call cache needed to by thread-local, to avoid concurrency issues.
>> Problem with TLS is that is adds an extra overhead, which appears to
>> be
>> greater than the optimization the cache provides.
>>
>> Op is naturally atomic, because it is an unsigned integer. As such, it
>> cannot be tempered with while another thread is reading it. When
>> entering the generated function, the first operation done is reading
>> 'op'. If we have concurrency, we will have access sequences returning
>> either EFL_NOOP or a VALID op, because 'op' is not set until the very
>> end of the function, when everything has been computed. As such, we
>> now
>> use the 'op' atomic integer to instore a lock-free/wait-free
>> mechanism,
>> which allows to drop the TLS nature of the cache, speeding up the
>> access
>> to the cache, and therefore making functions execute faster.
>>
>> We don't test anymore the generation count. This can be put as a
>> limitation. If means that if you call efl_object_shutdown() and
>> re-initialize it later with different data, opcodes will be invalid.
>> I am not sure there is any usecase for this to ever happen.
>> We could move all the caches in a dedicated section, that can be
>> overwritten after a call to efl_object_shutdown(), but I am not sure
>> it
>> will be very portable.
>>
>> Benchmark: mean over 3 executions of
>>ELM_TEST_AUTOBOUNCE=100 time elementary_test -to genlist
>>
>> ```
>>  BEFORE   AFTER
>> 
>> time (ns)4111647.09147676220.0
>> frames   2872.5   2904.5
>> time per frame (ns)  3869364.65   3149535.35
>> user time (s)11.096   9.22
>> cpu (%)  22.668   18.332
>> ```
>>
>> Ref T6580
>>
>> Reviewers: raster, cedric
>>
>> Subscribers: cedric, jpeg
>>
>> Maniphest Tasks: T6580
>>
>> Differential Revision: https://phab.enlightenment.org/D5738
>> ---
>>  src/lib/ecore_evas/ecore_evas_private.h |  2 +-
>>  src/lib/eina/eina_cow.c |  1 +
>>  src/lib/eina/eina_safepointer.c |  2 +-
>>  src/lib/eina/eina_types.h   |  8 +
>>  src/lib/eo/Eo.h | 56
>> +++--
>>  src/lib/eo/eo.c | 64
>> ++---
>>  6 files change

Re: [E-devel] [EGIT] [core/efl] master 01/02: eina: remove usless newline

[Jean-Philippe André]

)call->data -
> (char *)obj));
> -# if EFL_OBJECT_CALL_CACHE_SIZE > 1
> - cache->next_slot = (slot + 1) % EFL_OBJECT_CALL_CACHE_SIZE;
> -# endif
> -  }
> -#endif
>  return EINA_TRUE;
>   }
>
> @@ -570,7 +527,7 @@ end:
>   EO_OBJ_POINTER_PROXY(emb_obj_id, emb_obj);
>   if (EINA_UNLIKELY(!emb_obj)) continue;
>
> - func = _vtable_func_get(EO_VTABLE(emb_obj), cache->op);
> + func = _vtable_func_get(EO_VTABLE(emb_obj), op);
>   if (func == NULL) goto composite_continue;
>
>   if (EINA_LIKELY(func->func && func->src))
> @@ -594,7 +551,7 @@ composite_continue:
> if (cur_klass)
>   {
>  ERR("in %s:%d: func '%s' (%d) could not be resolved for class
> '%s' for super of '%s'.",
> -file, line, func_name, cache->op, main_klass->desc->name,
> +file, line, func_name, op, main_klass->desc->name,
>  cur_klass->desc->name);
>  goto err;
>   }
> @@ -602,7 +559,7 @@ composite_continue:
>   {
>  /* we should not be able to take this branch */
>  ERR("in %s:%d: func '%s' (%d) could not be resolved for class
> '%s'.",
> -file, line, func_name, cache->op, main_klass->desc->name);
> +file, line, func_name, op, main_klass->desc->name);
>  goto err;
>   }
>  err_cache_op:
> @@ -612,7 +569,7 @@ err_cache_op:
> goto err;
>  err_func_src:
> ERR("in %s:%d: you called a pure virtual func '%s' (%d) of class
> '%s'.",
> -   file, line, func_name, cache->op, klass->desc->name);
> +   file, line, func_name, op, klass->desc->name);
>  err:
> if (is_obj)
>   {
> @@ -629,7 +586,7 @@ err:
> // yes - special "move out of hot path" code blobs with goto's for
> // speed reasons to have intr prefetches work better and miss less
>  ok_cur_klass:
> -   func = _eo_kls_itr_next(klass, cur_klass, cache->op, super);
> +   func = _eo_kls_itr_next(klass, cur_klass, op, super);
> if (!func) goto end;
> klass = func->src;
> goto ok_cur_klass_back;
> @@ -661,7 +618,6 @@ obj_super:
> cur_klass = NULL;
>  }
>
> -  is_override = _obj_is_override(obj) && (cur_klass == NULL);
> }
> goto obj_super_back;
>
>
> --
>
> --
> Jean-Philippe André
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] efl_add causing confusion

[Jean-Philippe André]

e_child());
>
>// EFL:
>container = efl_new(CONTAINER_CLS, loop, );
>child = efl_new(CHILD_CLS, container, efl_container_pack(container,
> efl_added), efl_adopt_ref(container, efl_added));
>
> this is explicit, clear what's happening. Since "efl_adopt_ref()" was
> written explicitly there, or called afterwards, it's easy to spot you
> don't own the reference anymore. Maybe coccinelle, coverity and the
> likes can told that rule to spot errors.
>

ah i really don't like efl_adopt_ref


others may claim efl_adopt_ref() is always the case, in that case
> keeping efl_invalidate() UNRELATED to efl_unref() is also helpful:
>
> --> NOTE: using efl_add(), since here parents keep the reference
>
> WRONG/BUG usage:
> o = efl_add(cls, parent, ...); // refcnt = 1, the PARENT's reference
> efl_unref(o); // refcnt = 0, but parent held the reference
>

so this should ERR like now?


basic usage:
> o = efl_add(cls, parent, ...); // refcnt = 1, the PARENT's reference
> efl_invalidate(o); // refcnt = 0, since parent will unref based on
> invalidate event
>
> cascade delete usage:
> o = efl_add(cls, parent, ...); // refcnt = 1, the PARENT's reference
> efl_invalidate(parent); // refcnt = 0, cascade invalidate, leading
> to parents unref children.
>
> ref usage (when you can't monitor EFL_EVENT_INVALIDATE or weak-ref):
> o = efl_add(cls, parent, ...); // refcnt = 1, the PARENT's reference
> efl_ref(o); // refcnt = 2, PARENT + caller
> efl_invalidate(o); // refcnt = 1, since parent will unref based on
> invalidate event
> efl_unref(o); // refcnt = 0
>

probably more like:
  efl_ref(o)
  efl_invalidate(o) -> triggers "invalidate"
  some "invalidate" cb calls efl_unref(o)

one question is:
- why keep a ref? how useful is a ref'ed object that has been invalidated?
if you can't call any function on it, then what's the point of the ref? the
eo id indirection already makes most invalid calls safe from crashes and
show ERR
if you can call functions, then maybe invalidate must do very little work
(eg. evas: hide+mark for deletion, io/net: close fd) or it'll render
objects unsafe to use
parent objects may listen to "invalidate" events from their children and
unparent them


should we consider:
- efl_new() - no parent - you own the ref
- efl_add() - always a parent - you don't own any ref - the only way to
create evas objects (they need a parent, always, except the window)
- efl_add_ref() - always a parent + you get a ref (for bindings)
- efl_invalidate() - no ref change on itself - evas parents will unparent
and recursively also invalidate their children. unparenting is left to the
individual classes (efl.canvas.object being the one for all of evas)
- efl_unref() - if 0 without a parent, calls efl_invalidate() if needed &
destroy - if 0 with a parent, ERR but invalidate & destroy (like now)
- efl_del() - is it needed? is it invalidate + unref? (

then:
- parent_set() always adds a ref (so we can get rid of the parent_sunk
madness)
- parent_set(null) removes the parent ref
- parent_set(other) transfers a ref, refcount unchanged

the base class also presents:
- invalidator
- destructor
to be implemented by most subclasses


anyway it is clear that not everyone agrees on the idea that all objects
must have a parent.
that's indeed an unusual requirement for an object model (think any OO
language)

for efl, the loop object can trivially be found using a TLS so that
shouldn't be a blocker.


one more point to consider is evas object manual_free, but i don't think
any of the above can fix this:
 - invalidator (called by efl_invalidate) just hides and triggers an event
- but no ref change
 - destructor (called when refs = 0) remains unchanged: delete most things
but keep internal evas object data safe for 2 frames for cur/prev stuff
 - manual_free done by evas itself. already 0 ref here


as a last note to this long email, shall we opt to use the "parent
> keeps a ref" method, since we use the eoid abstraction, I'd highly
> recommend that efl_ref() creates ANOTHER eoid for the same object,
> with associated WARN_UNUSED_RESULT/MALLOC and efl_unref() behaves like
> free(), considering the handle to be destroyed. This should help
> finding bugs... it's worth since efl_ref() will be rarely used.
>

interesting idea... hard to do in practice without changing our existing
344 use cases of efl_ref :)



On Wed, Jan 10, 2018 at 5:31 AM, Jean-Philippe André <j...@videolan.org>
> wrote:
> > Hi,
> >
> > I created a new event "destruct" in Efl.Object.
> > It's triggered just before removing the callbacks, in the base class
> > destructor, as it's both easier and safer this way. I guess this can be
> > used in bindings too.
> >
> > As for the rest

Re: [E-devel] [EGIT] [core/efl] master 01/03: efl thread signal masks - fix up for various threads manually created

[Jean-Philippe André]

sed later in the build.
> > >>>>>>
> > >>>>>>>  why? the changes still use signal handlers and every
> > >>>>>>> signal is write()n down a pipe that the main loop reads and thus
> > >>>>>>> handles as events... ? unless a write() went missing ... which i
> > >>>>>>> doubt, or a signal handler wasn't called for a sigchld... but the
> > >>>>>>> signal handlers are not enabled/disabled or blocked/unblocked as
> > >>>>>>> things run... as i said - can remove the thread but i doubt that
> > >>>>>>> makes any difference. it shouldn't.
> > >>>>>> To be honest I have no clue about the different behaviors of
> thread
> > >>>>>> handling in osx.
> > >>>>>>
> > >>>>>> I will try a revert of your patches in a branch to get Travis
> building
> > >>>>>> them (Travis and thus osx builds are now being done for all
> branches
> > >>>>>> not only master. It only gets triggered after the github sync each
> > >>>>>> full hour, though).
> > >>>>>>
> > >>>>>> That should at least give us an idea if latest master works again
> with
> > >>>>>> them reverted. Not really debugged, but at least verified that it
> is
> > >>>>>> one of these patches and not something else.
> > >>>>> I can at least confirm that it comes from these three patches.
> Master
> > >>>>> with with these three reverted works fine again:
> > >>>>> https://travis-ci.org/Enlightenment/efl/builds/326702304
> > >>>> can you try narrowing it down to just 1 patch?
> > >>>>
> > >>> Two of them have a inter-dependency, but I pushed branches for all
> other
> > >>> combinations. I should have some results tomorrow morning.
> > >> Results are in.
> > >>
> > >> Reverted
> > >> efl signals - add signal callbacks for minimal signal set on loops
> > >> -> failed
> > >>
> > >> Reverted
> > >> efl signals - add signal callbacks for minimal signal set on loops
> > >> ecore signal - move to using a pipe (and optional thread) tfor signals
> > >> -> worked
> > >>
> > >> Reverted
> > >> efl thread signal masks - fix up for various threads manually created
> > >> -> failed
> > >>
> > >> Reverted
> > >> efl thread signal masks - fix up for various threads manually created
> > >> efl signals - add signal callbacks for minimal signal set on loops
> > >> -> failed
> > >>
> > >> This would point to the ecore signal - move to using a pipe commit
> which
> > >> breaks things. Which is also the biggest one. :(
> > > but this also fixes race conditions... :(
> >
> > And I got word from Netstar that he has seen this before. It is just so
> that
> > it was working reliable on the Travis osx instances before and not at all
> > anymore now. I hope netstar can give you some more details and maybe
> > debugging with instructions from you.
> > >
> > > can you try comment out
> > >
> > > #define ECORE_SIGNAL_THREAD 1
> > >
> > > ? that one line? just to see...
> > >
> > You mean normal master with just this line commented out (no revert at
> all?)
> > I will push a branch with it now and report back when I have the result.
>
> let me just push some things to master and see if they work... as i have
> no osx
> to play with it's remotely stabbing in the dark. my latest commit:
> 21c8e7311151931b88568ff11e604907182a8054 may or may not help. works on
> linux
> and freebsd.
>

you can push to a dev branch and verify that it builds and make checks
passes.

the link is here:
https://travis-ci.org/Enlightenment/efl/branches


-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo/Eolian namespace definition

[Jean-Philippe André]

Hi Dave,

On Thu, Jan 11, 2018 at 7:43 AM, Davide Andreoli <d...@gurumeditation.it>
wrote:

> 2018-01-08 19:52 GMT+01:00 Cedric Bail <ced...@ddlm.me>:
>
> > Hi Dave,
> >
> > >  Original Message 
> > > Subject: [E-devel] Eo/Eolian namespace definition
> > > Local Time: January 7, 2018 9:28 AM
> > > UTC Time: January 7, 2018 5:28 PM
> > > From: d...@gurumeditation.it
> > > To: Enlightenment <enlightenment-devel@lists.sourceforge.net>
> > >
> > > Hi all,
> > >
> > > I'm playing again with eolian and python, and I'm facing an issue with
> > > regards class names and namespaces separation (I already raised this in
> > the
> > > past)
> > >
> > > A first intro to python namespaces (I think apply to any other
> high-level
> > > language):
> > >
> > > - in py every class must live in a given namespace and you use the
> class
> > as:
> > > from  import 
> > > - every namespace in python is a separate .so file
> > >
> > > The basic question is:
> > > is the Efl.Text (interface) inside the Efl.Text namespace?
> > > do I need to put the Text interface inide the Efl.Text .so file?
> > >
> > > NO) if the resonse is no, then in python will become:
> > > from efl.ui import Button
> > > from efl import Text
> > > from efl.text import Font
> > >
> > > this feels wrong to me, as Text is not in the text namespace
> > >
> > > YES) if the response is YES:
> > > from efl.ui import Button
> > > from efl.text import Text
> > > from efl.text import Font
>

Would interfaces need to be imported in Python?
Can't we just use obj.font_foo() and obj.text_bar()?

from efl.text import Text
With a Text obj -> obj.font_foo()?



> > >
> > > this one seems correct to me, but this means that the full name of the
> > Text
> > > class should be Efl.Text.Text (this is a must in python, and probably
> in
> > > all other langs)
> >
> > I think that Text is maybe a bad example as it might be best to move it
> to
> > the Efl.Gfx namespace. In general I think our Efl top namespace is to
> > crowded and would be better cleaned up. I am guessing this would solve
> many
> > problem for python, no ? In general, do you have rules for naming and
> > namespaces that you would like us enforcing ? If we had, we could enforce
> > them in eolian.
> >
>
> For the moment the only problem I found for python is that a name-space
> cannot have the same name as a class, f.e. Efl.Text (class) and Efl.Text
> (namespace) cannot be made available to python with this exact names. I
> already "fixed" this issue using lowercased namespace names like: efl.Text
> (class) and efl.text.* (namespace). At the end this is a no-problem for py
> because lowercased namespaces is the raccomended  standard in python, so it
> fit well.
>

Yes, this is what's done for C++ and C# as well.
That was the intent since we started allowing some classes to have the same
name as a namespace (eg. efl.Canvas and efl.canvas.Object).


The main intent of this thread is to try to define and standardize the way
> we are naming classes, in particular wrt to the namespace hierarchy.
> I understand that coding in C this seems a no-problem, but for languages
> that support/require namespaces this must be defined cleanly, at the eolian
> level;
> to ensure that we will produce/generate conformant and standardized
> namespace hierarchy in differetn bindings.
> I mean: the Button class should be in the same namespace (Efl.Ui) in all
> different bindings we will produce.
>

That is the intent. And in C we probably could (ab)use eo_prefix more to
have nice names despite long namespaces.


TBH I'm really surprised that a plan has not been done on this, I cannot
> really undestand how we expect to create a consistent and clean API if
> everyone choose "quite random names" (exageration intended and for joking)
> imo we really need to write down the full hierarchy (also with planned
> classes) and discuss on that !
>

Believe me or not, we've actually been trying to have consistent names :)

I was actually assuming the generated doc would be a good way to verify
that the names are good.
The amazing work that's been done on the docs can help us already :)
https://www.enlightenment.org/develop/api/start

Should we open a phab ticket and list names that are thought to be
problematic?
Andy suggested to at least try to reduce the number of top-level namespaces.
Some namespaces (Efl.Ui) are also quite messy.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] efl_add causing confusion

[Jean-Philippe André]

;
>container_add_child (container, create_child());
>
>// EFL:
>container = efl_new(CONTAINER_CLS, loop, );
>child = efl_new(CHILD_CLS, container, efl_container_pack(container,
> efl_added), efl_adopt_ref(container, efl_added));
>
> this is explicit, clear what's happening. Since "efl_adopt_ref()" was
> written explicitly there, or called afterwards, it's easy to spot you
> don't own the reference anymore. Maybe coccinelle, coverity and the
> likes can told that rule to spot errors.
>
> others may claim efl_adopt_ref() is always the case, in that case
> keeping efl_invalidate() UNRELATED to efl_unref() is also helpful:
>
> --> NOTE: using efl_add(), since here parents keep the reference
>
> WRONG/BUG usage:
> o = efl_add(cls, parent, ...); // refcnt = 1, the PARENT's reference
> efl_unref(o); // refcnt = 0, but parent held the reference
>
> basic usage:
> o = efl_add(cls, parent, ...); // refcnt = 1, the PARENT's reference
> efl_invalidate(o); // refcnt = 0, since parent will unref based on
> invalidate event
>
> cascade delete usage:
> o = efl_add(cls, parent, ...); // refcnt = 1, the PARENT's reference
> efl_invalidate(parent); // refcnt = 0, cascade invalidate, leading
> to parents unref children.
>
> ref usage (when you can't monitor EFL_EVENT_INVALIDATE or weak-ref):
> o = efl_add(cls, parent, ...); // refcnt = 1, the PARENT's reference
> efl_ref(o); // refcnt = 2, PARENT + caller
> efl_invalidate(o); // refcnt = 1, since parent will unref based on
> invalidate event
> efl_unref(o); // refcnt = 0
>
>
> as a last note to this long email, shall we opt to use the "parent
> keeps a ref" method, since we use the eoid abstraction, I'd highly
> recommend that efl_ref() creates ANOTHER eoid for the same object,
> with associated WARN_UNUSED_RESULT/MALLOC and efl_unref() behaves like
> free(), considering the handle to be destroyed. This should help
> finding bugs... it's worth since efl_ref() will be rarely used.
>
>
>
>
> On Wed, Jan 10, 2018 at 5:31 AM, Jean-Philippe André <j...@videolan.org>
> wrote:
> > Hi,
> >
> > I created a new event "destruct" in Efl.Object.
> > It's triggered just before removing the callbacks, in the base class
> > destructor, as it's both easier and safer this way. I guess this can be
> > used in bindings too.
> >
> > As for the rest, I need to think about it more.
> >
> > Best regards,
> >
> >
> > On Wed, Jan 10, 2018 at 1:50 AM, Carsten Haitzler <ras...@rasterman.com>
> > wrote:
> >
> >> On Tue, 9 Jan 2018 21:03:53 +0900 Jean-Philippe André <
> j...@videolan.org>
> >> said:
> >>
> >> > On Tue, Jan 9, 2018 at 3:17 PM, Carsten Haitzler <
> ras...@rasterman.com>
> >> > wrote:
> >> >
> >> > > On Mon, 8 Jan 2018 18:15:13 +0900 Jean-Philippe André <
> >> j...@videolan.org>
> >> > > said:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > >
> >> > > > Some of the argumentation here seems to lack a bit of a scientific
> >> > > > approach...
> >> > > > So, I looked for all occurrences of efl_add() (see PS for
> >> methodology).
> >> > > >
> >> > > > In all of EFL, without specific filters:
> >> > > >
> >> > > > Overall: 244 unique classes / 1572 occurrences
> >> > > > No parent: 119 unique classes / 472 occurrences
> >> > > > 48% of classes used without parent, accounting for 30% of all
> uses.
> >> > >
> >> > > i argue that the vast majority of those no parent cases should have
> a
> >> > > parent. i
> >> > > actually did a grep -r through efl too looking and almost all the
> cases
> >> > > with a
> >> > > null parent i noted were bugs and should be fixed. :) i specifically
> >> noted
> >> > > some
> >> > > of those examples (the efl_anim stuff for example - i filed a bug
> for
> >> it
> >> > > too).
> >> > > so while i didn't do numbers... i did do an analysis. quickly in
> about
> >> 2
> >> > > minutes. for a more detailed analysis. note when i say "loop should
> be
> >> > > parent"
> >> > > i mean loop directly OR some object that ultimately has a parent
> that
> >> is
> >> > > loop
> >> > > at the top of the ob

Re: [E-devel] efl_add causing confusion

[Jean-Philippe André]

Hi

On Wed, Jan 10, 2018 at 11:39 PM, Carsten Haitzler <ras...@rasterman.com>
wrote:

> On Wed, 10 Jan 2018 16:31:33 +0900 Jean-Philippe André <j...@videolan.org>
> said:
>
> > Hi,
> >
> > I created a new event "destruct" in Efl.Object.
> > It's triggered just before removing the callbacks, in the base class
> > destructor, as it's both easier and safer this way. I guess this can be
> > used in bindings too.
>
> shouldn't  it be called AFTER all the callbacks EXCEPT this one have been
> removed? so only callbacks left on the list are these ones? and
> double-check
> that callback removal is the very last thing before the actual object data
> free
> (ie last thing in base class destructor) ?
>

Well that's "almost" the case.
What's left of the object at this point are:
 - name & comment
 - generic data pointers
 - list of event callbacks
 - pending futures to cancel

The futures should probably be canceled before (I didn't spot that until
just now).
It's debatable if the generic data should be cleaned up first (in
particular for the eo values, which trigger efl_unref). Could be cleaned up
first.

But there is no point in cleaning up the list of callbacks as the cleanup
process is a call to mempool free.
I doubt it would be better to send the event after the eo id itself becomes
invalid.


> > As for the rest, I need to think about it more.
> >
> > Best regards,
> >
> >
> > On Wed, Jan 10, 2018 at 1:50 AM, Carsten Haitzler <ras...@rasterman.com>
> > wrote:
> >
> > > On Tue, 9 Jan 2018 21:03:53 +0900 Jean-Philippe André <
> j...@videolan.org>
> > > said:
> > >
> > > > On Tue, Jan 9, 2018 at 3:17 PM, Carsten Haitzler <
> ras...@rasterman.com>
> > > > wrote:
> > > >
> > > > > On Mon, 8 Jan 2018 18:15:13 +0900 Jean-Philippe André <
> > > j...@videolan.org>
> > > > > said:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > >
> > > > > > Some of the argumentation here seems to lack a bit of a
> scientific
> > > > > > approach...
> > > > > > So, I looked for all occurrences of efl_add() (see PS for
> > > methodology).
> > > > > >
> > > > > > In all of EFL, without specific filters:
> > > > > >
> > > > > > Overall: 244 unique classes / 1572 occurrences
> > > > > > No parent: 119 unique classes / 472 occurrences
> > > > > > 48% of classes used without parent, accounting for 30% of all
> uses.
> > > > >
> > > > > i argue that the vast majority of those no parent cases should
> have a
> > > > > parent. i
> > > > > actually did a grep -r through efl too looking and almost all the
> cases
> > > > > with a
> > > > > null parent i noted were bugs and should be fixed. :) i
> specifically
> > > noted
> > > > > some
> > > > > of those examples (the efl_anim stuff for example - i filed a bug
> for
> > > it
> > > > > too).
> > > > > so while i didn't do numbers... i did do an analysis. quickly in
> about
> > > 2
> > > > > minutes. for a more detailed analysis. note when i say "loop
> should be
> > > > > parent"
> > > > > i mean loop directly OR some object that ultimately has a parent
> that
> > > is
> > > > > loop
> > > > > at the top of the object tree:
> > > > >
> > > > > src/benchmarks/eo/eo_bench_* (11)
> > > > >   just benchmarking so not real code. (ignore)
> > > > > src/bin/elementary/test_*.c (86)
> > > > >   all are bugs. every one should have loop as parent.
> > > > > src/examples/ecore/ecore_audio*.c: (7)
> > > > >   all are bugs. loop should be parent (loop drives i/o for audio
> and
> > > cb's)
> > > > > src/examples/ecore/ecore_idler_example.c: (1)
> > > > >   bug. loop as parent (commented out though)
> > > > > src/examples/ecore/ecore_poller_*.c (3)
> > > > >   bug. loop should be parent
> > > > > src/examples/ecore/efl_io_*.c (8)
> > > > >   bug. loop should be parent
> > > > > src/examples/ecore/efl_net_*.c (6)
> > > > >   bug. loop should be parent
> > > > > src/examples/eio/eio_sentry.c (1)
> > > > >   unknown
> > > > >

Re: [E-devel] efl_add causing confusion

[Jean-Philippe André]

Hi,

I created a new event "destruct" in Efl.Object.
It's triggered just before removing the callbacks, in the base class
destructor, as it's both easier and safer this way. I guess this can be
used in bindings too.

As for the rest, I need to think about it more.

Best regards,


On Wed, Jan 10, 2018 at 1:50 AM, Carsten Haitzler <ras...@rasterman.com>
wrote:

> On Tue, 9 Jan 2018 21:03:53 +0900 Jean-Philippe André <j...@videolan.org>
> said:
>
> > On Tue, Jan 9, 2018 at 3:17 PM, Carsten Haitzler <ras...@rasterman.com>
> > wrote:
> >
> > > On Mon, 8 Jan 2018 18:15:13 +0900 Jean-Philippe André <
> j...@videolan.org>
> > > said:
> > >
> > > > Hi,
> > > >
> > > >
> > > > Some of the argumentation here seems to lack a bit of a scientific
> > > > approach...
> > > > So, I looked for all occurrences of efl_add() (see PS for
> methodology).
> > > >
> > > > In all of EFL, without specific filters:
> > > >
> > > > Overall: 244 unique classes / 1572 occurrences
> > > > No parent: 119 unique classes / 472 occurrences
> > > > 48% of classes used without parent, accounting for 30% of all uses.
> > >
> > > i argue that the vast majority of those no parent cases should have a
> > > parent. i
> > > actually did a grep -r through efl too looking and almost all the cases
> > > with a
> > > null parent i noted were bugs and should be fixed. :) i specifically
> noted
> > > some
> > > of those examples (the efl_anim stuff for example - i filed a bug for
> it
> > > too).
> > > so while i didn't do numbers... i did do an analysis. quickly in about
> 2
> > > minutes. for a more detailed analysis. note when i say "loop should be
> > > parent"
> > > i mean loop directly OR some object that ultimately has a parent that
> is
> > > loop
> > > at the top of the object tree:
> > >
> > > src/benchmarks/eo/eo_bench_* (11)
> > >   just benchmarking so not real code. (ignore)
> > > src/bin/elementary/test_*.c (86)
> > >   all are bugs. every one should have loop as parent.
> > > src/examples/ecore/ecore_audio*.c: (7)
> > >   all are bugs. loop should be parent (loop drives i/o for audio and
> cb's)
> > > src/examples/ecore/ecore_idler_example.c: (1)
> > >   bug. loop as parent (commented out though)
> > > src/examples/ecore/ecore_poller_*.c (3)
> > >   bug. loop should be parent
> > > src/examples/ecore/efl_io_*.c (8)
> > >   bug. loop should be parent
> > > src/examples/ecore/efl_net_*.c (6)
> > >   bug. loop should be parent
> > > src/examples/eio/eio_sentry.c (1)
> > >   unknown
> > > src/examples/elementary/efl_ui_*.c (4)
> > >   bug. loop should be parent
> > > src/examples/elementary/file*.c (9)
> > >   bug. loop should be parent
> > > src/lib/ecore/ecore.c (1)
> > >   bug. singleton vpath object will fail with multiple loops, so loop
> > > should be
> > > parent, but this is unused atm so it doesn't matter yet.
> > > src/lib/ecore/efl_loop.c (1)
> > >   correct null parent usage
> > > src/lib/ecore/efl_model_composite_*.c (2)
> > >   relatively sure these are bugs. in fact these files do a lot of:
> > >   Efl_Promise *promise = efl_add(EFL_PROMISE_CLASS,
> efl_main_loop_get());
> > >   and similar assuming only the main loop... which is wrong. they
> should
> > > get
> > >   the correct loop, not always the main loop. lots of examples of this
> > > through
> > >   efl.
> > > src/lib/ecore_con/ecore_con_*.c (5)
> > >   bug. should use loop as parent
> > > src/lib/ector/cairo/ector_cairo_surface.c: (3)
> > > src/lib/ector/gl/ector_gl_surface.c: (3)
> > > src/lib/ector/software/ector_software_surface.c: (3) (9 total)
> > >   this is actually ok since ector doesn't use any async events and
> needs
> > > no loop
> > > src/lib/edje/edje_*.c (10)
> > >   bug. loop should be parent
> > > src/lib/efl/interfaces/efl_vpath_core.c: (1)
> > >   bug. vpath needs to be loop driven due to the ability to do async
> lookups
> > > src/lib/efl/interfaces/efl_vpath_manager.c (1)
> > >   bug. same as above
> > > src/lib/eio/eio_model.c: (1)
> > >   smells like a bug. eoi would need a loop to drive it
> > > src/lib/elementary/efl_access.c: (1)
> > >   bug. access relies on events and async

Re: [E-devel] efl_add causing confusion

[Jean-Philippe André]

On Tue, Jan 9, 2018 at 3:17 PM, Carsten Haitzler <ras...@rasterman.com>
wrote:

> On Mon, 8 Jan 2018 18:15:13 +0900 Jean-Philippe André <j...@videolan.org>
> said:
>
> > Hi,
> >
> >
> > Some of the argumentation here seems to lack a bit of a scientific
> > approach...
> > So, I looked for all occurrences of efl_add() (see PS for methodology).
> >
> > In all of EFL, without specific filters:
> >
> > Overall: 244 unique classes / 1572 occurrences
> > No parent: 119 unique classes / 472 occurrences
> > 48% of classes used without parent, accounting for 30% of all uses.
>
> i argue that the vast majority of those no parent cases should have a
> parent. i
> actually did a grep -r through efl too looking and almost all the cases
> with a
> null parent i noted were bugs and should be fixed. :) i specifically noted
> some
> of those examples (the efl_anim stuff for example - i filed a bug for it
> too).
> so while i didn't do numbers... i did do an analysis. quickly in about 2
> minutes. for a more detailed analysis. note when i say "loop should be
> parent"
> i mean loop directly OR some object that ultimately has a parent that is
> loop
> at the top of the object tree:
>
> src/benchmarks/eo/eo_bench_* (11)
>   just benchmarking so not real code. (ignore)
> src/bin/elementary/test_*.c (86)
>   all are bugs. every one should have loop as parent.
> src/examples/ecore/ecore_audio*.c: (7)
>   all are bugs. loop should be parent (loop drives i/o for audio and cb's)
> src/examples/ecore/ecore_idler_example.c: (1)
>   bug. loop as parent (commented out though)
> src/examples/ecore/ecore_poller_*.c (3)
>   bug. loop should be parent
> src/examples/ecore/efl_io_*.c (8)
>   bug. loop should be parent
> src/examples/ecore/efl_net_*.c (6)
>   bug. loop should be parent
> src/examples/eio/eio_sentry.c (1)
>   unknown
> src/examples/elementary/efl_ui_*.c (4)
>   bug. loop should be parent
> src/examples/elementary/file*.c (9)
>   bug. loop should be parent
> src/lib/ecore/ecore.c (1)
>   bug. singleton vpath object will fail with multiple loops, so loop
> should be
> parent, but this is unused atm so it doesn't matter yet.
> src/lib/ecore/efl_loop.c (1)
>   correct null parent usage
> src/lib/ecore/efl_model_composite_*.c (2)
>   relatively sure these are bugs. in fact these files do a lot of:
>   Efl_Promise *promise = efl_add(EFL_PROMISE_CLASS, efl_main_loop_get());
>   and similar assuming only the main loop... which is wrong. they should
> get
>   the correct loop, not always the main loop. lots of examples of this
> through
>   efl.
> src/lib/ecore_con/ecore_con_*.c (5)
>   bug. should use loop as parent
> src/lib/ector/cairo/ector_cairo_surface.c: (3)
> src/lib/ector/gl/ector_gl_surface.c: (3)
> src/lib/ector/software/ector_software_surface.c: (3) (9 total)
>   this is actually ok since ector doesn't use any async events and needs
> no loop
> src/lib/edje/edje_*.c (10)
>   bug. loop should be parent
> src/lib/efl/interfaces/efl_vpath_core.c: (1)
>   bug. vpath needs to be loop driven due to the ability to do async lookups
> src/lib/efl/interfaces/efl_vpath_manager.c (1)
>   bug. same as above
> src/lib/eio/eio_model.c: (1)
>   smells like a bug. eoi would need a loop to drive it
> src/lib/elementary/efl_access.c: (1)
>   bug. access relies on events and async (e.g. dbus) and so must have loop
> src/lib/elementary/efl_ui_*.c: (15)
>   bug. need loop parent
> src/lib/elementary/elm_*.c (5)
>   all look like bugs. need loop parent
> src/lib/evas/canvas/efl_animation*.c (7)
>   bug. need loop parent
> src/lib/evas/canvas/efl_canvas_vg.c: (1)
>   bug. need loop parent
>
> src/lib/evas/canvas/evas_main.c: (1)
>   bug. need loop parent
> src/lib/evas/canvas/evas_vg_node.c: (1)
>   bug. vg nodes should have a parent object - always
> src/lib/evas/gesture/efl_gesture_manager.c: (1)
>   bug. need loop parent
> src/modules/evas/engines/gl_generic/evas_engine.c (3)
> src/modules/evas/engines/software_generic/evas_engine.c: (3) (6 total)
>   correct. ector objects
> src/tests/ecore/ecore_test_ecore_audio.c (16)
>   bug. need loop parent
> src/tests/ecore/ecore_test_promise2.c: (2)
>   bug. need loop parent
> src/tests/ecore_con/ecore_con_test_efl_net_ip_address.c: (14)
>   bug. need loop parent
> src/tests/efl/efl_test_model_*.c: (5)
>   bug. need loop parent
> src/tests/efl_js/benchmark_object_impl.cc: (1)
>   artificial benchmarking (so ignore)
> src/tests/efl_mono/libefl_mono_native_test.c: (1)
>   artificial benchmarking (ignore)
> src/tests/eina_cxx/eina_cxx_test_*.cc (54)
>   artificial testing of basic input/output thro

Re: [E-devel] efl_add causing confusion

[Jean-Philippe André]

On Tue, Jan 9, 2018 at 7:30 AM, Cedric Bail <ced...@ddlm.me> wrote:

> >  Original Message 
> > Subject: Re: [E-devel] efl_add causing confusion
> > Local Time: January 8, 2018 1:15 AM
> > UTC Time: January 8, 2018 9:15 AM
> > From: j...@videolan.org
> > To: Enlightenment developer list <enlightenment-de...@lists.sou
> rceforge.net>
>
> 
>
> > - Those numbers differ from the values given in the below email.
> > While I understand where this "maybe 1 or 2% of all objects [are created
> > without a parent]" comes from, it's not based on facts.
> > @noparent makes sense. A NULL check in efl_add would then help.
> > A different API then wouldn't hurt either IMHO (maybe efl_new?
> > efl_add_single? efl_create? or whatever -- efl_add then can NOT be called
> > with NULL).
>
> I am not sure of the semantic you expect here. Could you clarify ?
>

Ah sorry it wasn't clear:

#define efl_add(CLASS, parent, ...)
#define efl_new(CLASS, ...)

efl_add checks that parent != NULL and have EINA_ARG_NONNULL
efl_new simply cannot pass a parent (unless of course you call
efl_parent_set(efl_added))
the internal code can be the same (the null check being added in eo.c, if
we want it -- it relies on @noparent)


> > - The argumentation in this email chain again leads nowhere. The original
> > confusion remains mostly unaddressed.
> > Felipe mentioned that ownership and references are mixed. So the proposal
> > for efl_release (or detach, close, invalidate, ...) makes sense to me.
> > In fact we have issues sometimes with efl_del as inside a destructor we
> > already lost our parent (thus all efl_provider_find and related calls
> will
> > fail).
> > Also, quite a few times I've also been looking for a "deleted" event that
> > would happen after destruction, and not before.
> > I had to introduce a very ugly API very badly called "allow_parent_unref"
> > in efl.object because some objects need a parent but they should be
> > unref'ed by someone else (efl_part objects but not only).
> >
> > So, I think it would make sense to investigate efl_terminate, and
> > evas_object_del would just call efl_terminate, hiding the object or
> > starting destruction, then let the parent (either evas or another canvas
> > object) do the final unref/unparent and destroying everything that's
> left.
>
> I like this direction. It might even allow a way to not have the double
> step destruction we have today.


Do you mean evas object manual free?
evas_object_del -> efl_invalidate (hides and calls existing destructor?)
manual_free -> unref and final cleanup?


> Also it allow to solve the problem we have of referencing parent during
> destruction and weird refcounting for parenting.
>

Referencing the parent? You mean using pd->parent or something like that?
Parent is NULL inside efl_destructor...

>
> If we enforce that path, then during destructor it must be expected that
> the parent is NULL. When setting the parent to NULL, it will trigger an
> invalidate of the object (If the object is not invalidated already). This
> means that efl_del get simplified to just parent set to NULL followed by
> unref. Making it a direct symetric operation to efl_add_ref.
>

Parent is already NULL inside destructor. Which I think can in fact be
problematic sometimes (since efl_provider_find fails).
From your sentence it would seem that the object has two refs? (parent ref
+ user ref)
I'm not thinking of adding a ref to the object. IMO efl_add_ref is only for
bindings, the ref dies after the scope ends (in C++ anyway).

This isn't a fully formed idea yet (in my mind at least)

> Anyway I think experiments only can tell us what's best. I see 3 items:
> >
> > - @noparent tag

> - efl_new (= efl_add without a parent -- requires @noparent if we want
> > strong NULL check)

> - efl_invalidate / efl_terminate (I prefer efl_close :P)
>
> I am now prefering efl_invalidate as efl_terminate is actually used by our
> lifecycle function and efl_close remind me of file.


Sure.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] efl_add causing confusion

[Jean-Philippe André]

> > > > > guess it would be best to just make it symetric to efl_add_ref.
> This
> > > will
> > > > > give a predictable outcome I think, but I am not sure it is enough.
> > > What do
> > > > > you think ?
> > > > >
> > > > > >   IMO, the whole problem with efl_add/efl_add_ref is that
> > > > > > "parents" are treated specially, which they should not.
> parent_set
> > > > > > should increment efl_ref and parent_unset should decrement it.
> > > > >
> > > > > Agreed and surprised it is not the case.
> > > > >
> > > > > > For C, OTH, where we do expect some "automatism" on resource
> > > > > > handling, efl_unref'ing may be too much of a hassle when a
> > > > > > parent is already going to handle the lifetime of the object. So,
> > > > > > it would make sense, IMO, for efl_add_scope. It could even be
> > > > > > that efl_add_scope is named efl_add, no problem, as long as
> > > > > > there's a efl_add that keeps this semantics for binding
> > > > > > development. Which also means that parent_set/unset must
> > > > > > be fixed.
> > > > >
> > > > > I think that once efl_del behavior is clearly defined, the
> existence
> > > of an
> > > > > efl_add_scope/efl_add will also be clearer to everyone.
> > > > >
> > > > > >   Also, @own tags must not relate to parent_set, because that
> > > > > > has no useful information for tags or users, if needed we can
> > > > > > add a @reparent tag, but that's not really special information
> > > > > > such as real owernship information.
> > > > >
> > > > > I am still wondering what the @own really mean. Does that mean
> that the
> > > > > object own at least one reference of it ? But in that case, doesn't
> > > that
> > > > > mean that the user need to always ref it, if it plans to keep it
> > > around.
> > > > >
> > > > > As for @reparent, I am not sure we have case yet where we return an
> > > object
> > > > > that can not be reparented, do we have such a case ?
> > > > >
> > > > > Cedric
> > > > >
> > > > >
> > > 
> --
> > > > > Check out the vibrant tech community on one of the world's most
> > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > > ___
> > > > > enlightenment-devel mailing list
> > > > > enlightenment-devel@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > > >
> > > >
> > > >
> > > > --
> > > > http://andywilliams.me
> > > > http://ajwillia.ms
> > > >
> > > 
> --
> > > > Check out the vibrant tech community on one of the world's most
> > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > ___
> > > > 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"
> --
> > > Carsten Haitzler - ras...@rasterman.com
> > >
> > >
> >
> > --
> > http://andywilliams.me
> > http://ajwillia.ms
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>

PS: The command lines are as follows (remove the grep -v for the first
stats):

git grep --color=never -E "efl_add\(.*CLASS," |grep -v EFL_UI_WIN_CLASS
|grep -v ECORE |sed -e 's/.*efl_add(\([^,]\+\),.*/\1/' |sort -u|wc
git grep --color=never -E "efl_add\(.*CLASS," |grep -v EFL_UI_WIN_CLASS
|grep -v ECORE |sed -e 's/.*efl_add(\([^,]\+\),.*/\1/' |wc

git grep --color=never -E "efl_add\(.*CLASS, NULL" |grep -v
EFL_UI_WIN_CLASS |grep -v ECORE |sed -e 's/.*efl_add(\([^,]\+\),.*/\1/'
|sort -u|wc
git grep --color=never -E "efl_add\(.*CLASS, NULL" |grep -v
EFL_UI_WIN_CLASS |grep -v ECORE |sed -e 's/.*efl_add(\([^,]\+\),.*/\1/' |wc


-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] API namespacing

[Jean-Philippe André]

More renaming ahead? :)

I'll assume we might keep an "eo_prefix" for some APIs like "efl_part" or
"efl_file" to not become too long in C (important: this affects only C!).

On Sat, Dec 23, 2017 at 3:16 AM, Andrew Williams <a...@andywilliams.me>
wrote:

> Hi all,
>
> I recently updated the API landing page to group by namespace:
> https://www.enlightenment.org/develop/api/start
>
> What this has indicated is that there are a few things out of place. The
> list as far as I can see it is:
>
> Efl.Access.* -> Efl.Ui.Access
>

Nope! That was also my reaction at first, though :)
Access can be used in a non-UI environment, conceptually. Ask @stanluk for
more details, but he managed to convince me.


> Efl.Animator -> Efl.Animation.Animator
>

@cedric?


> Efl.File -> Efl.Io.File
>

This name makes sense
But I already see an Efl.Io.File class? Gustavo, any input here?
Efl.Io refers to actual I/O (open, read, write, close...) while Efl.File is
just for the (image/edje) file set/get.


> Efl.Flipable -> Efl.Image.Flipable
>

Yes.


> Efl.Observer -> Efl.Observable.Observer
>

Makes sense (though it mixes class name and namespace which some people
dislike).


> Efl.Pack -> Efl.Ui.Pack
>

Makes sense.


> Efl.Part -> Efl.Layout.Part
>

It's not only for layout. Widget also implements the part API, so more like
Efl.Ui.Part.
The concept isn't necessarily limited to UI, even though all use cases are
UI-related for now.


> Efl.Vg -> Efl.Gfx.Vector
>

Sounds good.


> Also I am unsure about how we can tidy these one to a better group, do they
> belong in new namespaces or at the top level (i.e. along with Efl.Object):
>
> Efl.Container

Efl.Content
>

Container and Content can be in Efl.Ui.


> Efl.Control
>

raster? Do we even need this?


> Efl.Duplicate
>

It's a very generic thing, but only implemented in a few classes. A bit
like Cloneable in Java (found in java.lang).


> Efl.Orientation
>

Could be in Gfx if needed.


> Efl.Player
> Efl.Screen
>

No idea either :)


> I'd like to be able to tidy the API so we have at least 50% fewer child
> namespaces to Efl. Somewhere between the number of legacy modules and the
> number of namespaces currently.


Yes, this makes sense to me.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] vtorri commit access

[Jean-Philippe André]

On Sat, Jan 6, 2018 at 9:06 PM, <marcel-hollerb...@t-online.de> wrote:

> Hello,
>
> I would like to propose vtorri for getting commit access again!
> He does a lot of work for windows and that should have access to
> efl.git.
>
> Objections, Comments ?
>

Yes, please!
But it's still up to Vincent as well, I know he likes getting reviews
sometimes. :)

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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: promise: Add even simpler helper for main loop promise creation

[Jean-Philippe André]

On Fri, Jan 5, 2018 at 3:18 AM, Gustavo Sverzut Barbieri <barbi...@gmail.com
> wrote:

> On Thu, Jan 4, 2018 at 2:59 PM, Andrew Williams <a...@andywilliams.me>
> wrote:
> > Hi,
> >
> > Apologies for the future/promise gaff - I was working from the
> > documentation of the previous efl_loop_promise_new which also referred to
> > Future.
> > I will correct both.
> >
> > I am confused by the loop semantics. Many times I have been told that our
> > UI work must happen on the main thread, which indicates that such a
> helper
> > would be handy. Is this requirement changing?
>
> in concept, no. In practice it's recommended to propagate the
> resource... as you did in some examples that use the main loop given
> to efl_main(), not assume some "global"...
>
> not happening anytime soon, but in future we could (more like theory)
> move each unrelated/unlinked window to its own thread, each with its
> own "main loop"... then your approach would fail, while the "pass
> along" would work.
>
> anyway, the promises are not specific to main loop... and as I said
> before, it's not common to create *PROMISES* yourself... often you
> chain to some future, such as timer, idler, job... when more is moved
> to promise/future, this could also be some "file read", "directory
> listing" (eio)... thread feedback (ecore_thread still pending
> "eo-ifyication")...
>
> example:
>
> 1) creating a new promise:
>
> I base my promise on something that is not a promise, like when some
> eo event happens. Then I create my promise based on my assigned loop
> (usually you should be a loop user, or have one as parent), then
> return its future.
>
> I proposed to automatically wrap events -> future, with some people
> supporting that... things like "return me a future when the
> efl.io.copier event 'done' happens". It would register the event
> callback, wait for the event to happen, resolve the promise,
> unregister the event callback. This will be a common pattern.
>
> Usually core EFL is the ones expected to do this kind of work.
>

This sounds useful. Not insanely helpful in C (it only removes a call to
callback_del) but likely useful in bindings.


> 2)  chaining an existing future from a promise:
>
> I base my promise on another promise, like "after 10 seconds"
> (efl_loop_timeout).
>
> If there is a wrapper for "events -> future" as said above, then
> common stuff as "call me when efl.io.copier is done" will also be
> automatic and fall in this category.
>
> This is what most applications would ever use.
>
>
> --
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (16) 99354-9890
>
> 
> ------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>


-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] ecore / efl loop work

[Jean-Philippe André]

On Wed, Dec 20, 2017 at 12:41 PM, Carsten Haitzler <ras...@rasterman.com>
wrote:

> On Wed, 20 Dec 2017 11:58:21 +0900 Jean-Philippe André <j...@videolan.org>
> said:
>
> > On Wed, Dec 20, 2017 at 11:01 AM, Carsten Haitzler <ras...@rasterman.com
> >
> > wrote:
> >
> > > On Mon, 18 Dec 2017 20:16:49 +0900 Jean-Philippe André <
> j...@videolan.org>
> > > said:
> > >
> > > > On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler <
> ras...@rasterman.com
> > > >
> > > > wrote:
> > > >
> > > > > On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail <ced...@ddlm.me>
> said:
> > > > >
> > > > > > >  Original Message 
> > > > > > > Subject: [E-devel] ecore / efl loop work
> > > > > > > Local Time: December 14, 2017 9:30 PM
> > > > > > > UTC Time: December 15, 2017 5:30 AM
> > > > > > > From: ras...@rasterman.com
> > > > > > > To: e <enlightenment-devel@lists.sourceforge.net>
> > > > > >
> > > > > > 
> > > > > >
> > > > > > > there are internals that need some cleaning up like internal
> use of
> > > > > > > ecore_timer, ecore_idler. need to decide what to do with
> ecore_app
> > > and
> > > > > > > argv/argc stuff. the ecore signal code needs some cleaning up
> > > > > internally
> > > > > > > too. ecore_thread and ecore_pipe need re-implementation for
> > > > > > > inter-thread/loop messaging/calling etc.
> > > > > >
> > > > > > ecore_app and argv/argc are already passed to the
> > > > > EFL_LOOP_EVENT_ARGUMENTS as
> > > > > > parameter to the main loop. There is no real need I think to have
> > > that
> > > > > more
> > > > > > exposed.
> > > > >
> > > > > oh i know. i'm more thinking about spawning new threads+loops ...
> and
> > > > > should
> > > > > they be spawned by passing argv/c to them like processes get. it'd
> > > make all
> > > > > threads/loops consistent in this way. yes. being able to attach a
> void
> > > *
> > > > > might
> > > > > also be useful as this is what pthread will do anyway.
> > > > >
> > > > > > As for Ecore_Thread, the only binding that could make use of it
> is
> > > C++
> > > > > and it
> > > > > > requires to definitively have a way to mark a function in .eo for
> > > other
> > > > > > binding to ignore. At this point, there is no rush into
> implementing
> > > it.
> > > > >
> > > > > well ecore_thread also does a thread pool, work queue etc. and it's
> > > > > asymmetric.
> > > > > you can create work thread items and then send back results, but
> once
> > > > > created
> > > > > you cant "send more work to the thread". you create more threads.
> > > > >
> > > > > i was thinking more along the lines of:
> > > > >
> > > > > we create a thread+loop via eo (you get back a LOCAL object handle
> > > > > representing
> > > > > the remote thread that you use to communicate with it), and now
> you can
> > > > > send
> > > > > stuff to it, and get back events from it (sending likely just
> returns
> > > you a
> > > > > future if you are expecting a reply so you can turn it into a
> > > > > "conversation"
> > > > > via promises/futures). this is what i mean by "ecore thread" needs
> > > doing.
> > > > > we
> > > > > need a way of creating threads and talking to them nicely.
> > > > >
> > > > > > > i also don't delete the loop object on ecore shutdown. it's ...
> > > > > problematic.
> > > > > > > tbh the whole "shutdown" stuff we have in efl is just not
> worth the
> > > > > corner
> > > > > > > case work. init and leave up and running for the life of the
> > > process.
> > > > > it's
> > > > > > > simpler and it also actually makes it faster to exit an app...
> > > shutting
> > > > > > > down actually takes a

Re: [E-devel] ecore / efl loop work

[Jean-Philippe André]

On Wed, Dec 20, 2017 at 12:36 PM, Carsten Haitzler <ras...@rasterman.com>
wrote:

> On Wed, 20 Dec 2017 11:19:30 +0900 Jean-Philippe André <j...@videolan.org>
> said:
>
> > On Wed, Dec 20, 2017 at 11:10 AM, Carsten Haitzler <ras...@rasterman.com
> >
> > wrote:
> >
> > > On Tue, 19 Dec 2017 11:53:13 +0900 Jean-Philippe André <
> j...@videolan.org>
> > > said:
> > >
> > > > Hey raster,
> > > >
> > > > I'm confused by something, see ecore_test_ecore_main_loop_
> timer_inner,
> > > > and ecore_test_ecore_main_loop_event_recursive.
> > > > This test runs the main loop inside the main loop, which the
> > > documentation
> > > > says you shouldn't do. The test case passes because it's badly
> written
> > >
> > > indeed you shouldn't. we did at one point make the "ecore main loop
> > > iterate"
> > > func work... due to demand/requests for it... but it still is a bad
> idea
> > > to do
> > > this. it's quite possible my changes broke this... but the tests
> passed so
> > > i
> > > didn't look further. :)
> > >
> >
> > Well I disabled the tests. Your changes (or maybe another change prior to
> > that?) effectively prevent inner loops from existing. There's even a very
> > clear ERR message in that case :)
>
> hmm the tests didn't fail though... did they?
>

No because they were badly written :)
But you would see an ERR in the logs.


>
> > >
> > > > (marks the success variable before really running the test). It's not
> > > > testing that either of the inner timers even run.
> > > >
> > > > What's up with this? Did those inner loops use to work and then this
> > > became
> > > > forbidden?
> > >
> > > it was always forbidden... but due to requests by certain people who
> > > wanted to
> > > write recursive loops etc. we kind of made it work... but it's a pain
> to
> > > make
> > > this work and work right when someone could iterate or run a loop from
> any
> > > point in the call tree (inside a clicked callback/event from a button
> or
> > > the
> > > pixel get callback or glview paint callback etc. etc.)... imagine the
> hell
> > > that
> > > is trying to nest loops like this anywhere and everywhere? the advice
> > > stands:
> > >
> > > "don't do this". :) making it work universally is insanely hard without
> > > something failing somewhere.
> > >
> >
> >
> > > > On Mon, Dec 18, 2017 at 8:16 PM, Jean-Philippe André <
> j...@videolan.org>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler <
> > > ras...@rasterman.com>
> > > > > wrote:
> > > > >
> > > > >> On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail <ced...@ddlm.me>
> said:
> > > > >>
> > > > >> > >  Original Message 
> > > > >> > > Subject: [E-devel] ecore / efl loop work
> > > > >> > > Local Time: December 14, 2017 9:30 PM
> > > > >> > > UTC Time: December 15, 2017 5:30 AM
> > > > >> > > From: ras...@rasterman.com
> > > > >> > > To: e <enlightenment-devel@lists.sourceforge.net>
> > > > >> >
> > > > >> > 
> > > > >> >
> > > > >> > > there are internals that need some cleaning up like internal
> use
> > > of
> > > > >> > > ecore_timer, ecore_idler. need to decide what to do with
> > > ecore_app and
> > > > >> > > argv/argc stuff. the ecore signal code needs some cleaning up
> > > > >> internally
> > > > >> > > too. ecore_thread and ecore_pipe need re-implementation for
> > > > >> > > inter-thread/loop messaging/calling etc.
> > > > >> >
> > > > >> > ecore_app and argv/argc are already passed to the
> > > > >> EFL_LOOP_EVENT_ARGUMENTS as
> > > > >> > parameter to the main loop. There is no real need I think to
> have
> > > that
> > > > >> more
> > > > >> > exposed.
> > > > >>
> > > > >> oh i know. i'm more thinking about spawning new thr

Re: [E-devel] ecore / efl loop work

[Jean-Philippe André]

On Wed, Dec 20, 2017 at 11:01 AM, Carsten Haitzler <ras...@rasterman.com>
wrote:

> On Mon, 18 Dec 2017 20:16:49 +0900 Jean-Philippe André <j...@videolan.org>
> said:
>
> > On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler <ras...@rasterman.com
> >
> > wrote:
> >
> > > On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail <ced...@ddlm.me> said:
> > >
> > > > >  Original Message 
> > > > > Subject: [E-devel] ecore / efl loop work
> > > > > Local Time: December 14, 2017 9:30 PM
> > > > > UTC Time: December 15, 2017 5:30 AM
> > > > > From: ras...@rasterman.com
> > > > > To: e <enlightenment-devel@lists.sourceforge.net>
> > > >
> > > > 
> > > >
> > > > > there are internals that need some cleaning up like internal use of
> > > > > ecore_timer, ecore_idler. need to decide what to do with ecore_app
> and
> > > > > argv/argc stuff. the ecore signal code needs some cleaning up
> > > internally
> > > > > too. ecore_thread and ecore_pipe need re-implementation for
> > > > > inter-thread/loop messaging/calling etc.
> > > >
> > > > ecore_app and argv/argc are already passed to the
> > > EFL_LOOP_EVENT_ARGUMENTS as
> > > > parameter to the main loop. There is no real need I think to have
> that
> > > more
> > > > exposed.
> > >
> > > oh i know. i'm more thinking about spawning new threads+loops ... and
> > > should
> > > they be spawned by passing argv/c to them like processes get. it'd
> make all
> > > threads/loops consistent in this way. yes. being able to attach a void
> *
> > > might
> > > also be useful as this is what pthread will do anyway.
> > >
> > > > As for Ecore_Thread, the only binding that could make use of it is
> C++
> > > and it
> > > > requires to definitively have a way to mark a function in .eo for
> other
> > > > binding to ignore. At this point, there is no rush into implementing
> it.
> > >
> > > well ecore_thread also does a thread pool, work queue etc. and it's
> > > asymmetric.
> > > you can create work thread items and then send back results, but once
> > > created
> > > you cant "send more work to the thread". you create more threads.
> > >
> > > i was thinking more along the lines of:
> > >
> > > we create a thread+loop via eo (you get back a LOCAL object handle
> > > representing
> > > the remote thread that you use to communicate with it), and now you can
> > > send
> > > stuff to it, and get back events from it (sending likely just returns
> you a
> > > future if you are expecting a reply so you can turn it into a
> > > "conversation"
> > > via promises/futures). this is what i mean by "ecore thread" needs
> doing.
> > > we
> > > need a way of creating threads and talking to them nicely.
> > >
> > > > > i also don't delete the loop object on ecore shutdown. it's ...
> > > problematic.
> > > > > tbh the whole "shutdown" stuff we have in efl is just not worth the
> > > corner
> > > > > case work. init and leave up and running for the life of the
> process.
> > > it's
> > > > > simpler and it also actually makes it faster to exit an app...
> shutting
> > > > > down actually takes a lot of work. i've seen it delay an app
> closing a
> > > lot.
> > > >
> > > > This is going to likely create problem. If you have for example added
> > > data to
> > > > the loop object and you expect the destruction callback to be called
> at
> > > some
> > > > point, well, that will be out of luck. I can't remember why, but the
> two
> > > > tests you disable where from a real life case that required that
> > > behavior. So
> > > > it would be best if I could remember, but right now, I feel like not
> > > > destroying this object is ging to create trouble in the future as it
> > > will be
> > > > one object that doesn't have the same behavior as every other one.
> > >
> > > that doesn't change the fact that destruction is expensive and
> generally
> > > pointless. there may b e some cases where it's nice. like "detecting
> leaks
> > > by
> > > looking at what is still a

Re: [E-devel] ecore / efl loop work

[Jean-Philippe André]

On Wed, Dec 20, 2017 at 11:10 AM, Carsten Haitzler <ras...@rasterman.com>
wrote:

> On Tue, 19 Dec 2017 11:53:13 +0900 Jean-Philippe André <j...@videolan.org>
> said:
>
> > Hey raster,
> >
> > I'm confused by something, see ecore_test_ecore_main_loop_timer_inner,
> > and ecore_test_ecore_main_loop_event_recursive.
> > This test runs the main loop inside the main loop, which the
> documentation
> > says you shouldn't do. The test case passes because it's badly written
>
> indeed you shouldn't. we did at one point make the "ecore main loop
> iterate"
> func work... due to demand/requests for it... but it still is a bad idea
> to do
> this. it's quite possible my changes broke this... but the tests passed so
> i
> didn't look further. :)
>

Well I disabled the tests. Your changes (or maybe another change prior to
that?) effectively prevent inner loops from existing. There's even a very
clear ERR message in that case :)

>
> > (marks the success variable before really running the test). It's not
> > testing that either of the inner timers even run.
> >
> > What's up with this? Did those inner loops use to work and then this
> became
> > forbidden?
>
> it was always forbidden... but due to requests by certain people who
> wanted to
> write recursive loops etc. we kind of made it work... but it's a pain to
> make
> this work and work right when someone could iterate or run a loop from any
> point in the call tree (inside a clicked callback/event from a button or
> the
> pixel get callback or glview paint callback etc. etc.)... imagine the hell
> that
> is trying to nest loops like this anywhere and everywhere? the advice
> stands:
>
> "don't do this". :) making it work universally is insanely hard without
> something failing somewhere.
>


> > On Mon, Dec 18, 2017 at 8:16 PM, Jean-Philippe André <j...@videolan.org>
> > wrote:
> >
> > >
> > >
> > > On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler <
> ras...@rasterman.com>
> > > wrote:
> > >
> > >> On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail <ced...@ddlm.me> said:
> > >>
> > >> > >  Original Message 
> > >> > > Subject: [E-devel] ecore / efl loop work
> > >> > > Local Time: December 14, 2017 9:30 PM
> > >> > > UTC Time: December 15, 2017 5:30 AM
> > >> > > From: ras...@rasterman.com
> > >> > > To: e <enlightenment-devel@lists.sourceforge.net>
> > >> >
> > >> > 
> > >> >
> > >> > > there are internals that need some cleaning up like internal use
> of
> > >> > > ecore_timer, ecore_idler. need to decide what to do with
> ecore_app and
> > >> > > argv/argc stuff. the ecore signal code needs some cleaning up
> > >> internally
> > >> > > too. ecore_thread and ecore_pipe need re-implementation for
> > >> > > inter-thread/loop messaging/calling etc.
> > >> >
> > >> > ecore_app and argv/argc are already passed to the
> > >> EFL_LOOP_EVENT_ARGUMENTS as
> > >> > parameter to the main loop. There is no real need I think to have
> that
> > >> more
> > >> > exposed.
> > >>
> > >> oh i know. i'm more thinking about spawning new threads+loops ... and
> > >> should
> > >> they be spawned by passing argv/c to them like processes get. it'd
> make
> > >> all
> > >> threads/loops consistent in this way. yes. being able to attach a
> void *
> > >> might
> > >> also be useful as this is what pthread will do anyway.
> > >>
> > >> > As for Ecore_Thread, the only binding that could make use of it is
> C++
> > >> and it
> > >> > requires to definitively have a way to mark a function in .eo for
> other
> > >> > binding to ignore. At this point, there is no rush into
> implementing it.
> > >>
> > >> well ecore_thread also does a thread pool, work queue etc. and it's
> > >> asymmetric.
> > >> you can create work thread items and then send back results, but once
> > >> created
> > >> you cant "send more work to the thread". you create more threads.
> > >>
> > >> i was thinking more along the lines of:
> > >>
> > >> we create a thread+loop via eo (you get back a LOCAL object handle
> > >> representing
> &g

Re: [E-devel] [EGIT] [core/efl] master 06/12: loop: Try harder to find the main loop

[Jean-Philippe André]

On Wed, Dec 20, 2017 at 2:56 AM, Gustavo Sverzut Barbieri <
barbi...@gmail.com> wrote:

> On Mon, Dec 18, 2017 at 9:04 AM, Jean-Philippe ANDRÉ <j...@videolan.org>
> wrote:
> > jpeg pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=
> 784a5b56a3c798e5a8081e2ce30c79cd8ef7b326
> >
> > commit 784a5b56a3c798e5a8081e2ce30c79cd8ef7b326
> > Author: Jean-Philippe Andre <jp.an...@samsung.com>
> > Date:   Mon Dec 18 11:58:43 2017 +0900
> >
> > loop: Try harder to find the main loop
> >
> > If the object has no parent or anything else goes a bit wrong,
> > efl_loop_get() may fail to return the loop object. It's a bit
> ridiculous
> > when we're in the main loop as we know which loop object was
> requested.
> >
> > This avoids returning NULL.
> > ---
> >  src/lib/ecore/efl_loop_consumer.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/src/lib/ecore/efl_loop_consumer.c b/src/lib/ecore/efl_loop_
> consumer.c
> > index d436da82ff..389e0c5f96 100644
> > --- a/src/lib/ecore/efl_loop_consumer.c
> > +++ b/src/lib/ecore/efl_loop_consumer.c
> > @@ -14,6 +14,8 @@ struct _Efl_Loop_Consumer_Data
> >  static Efl_Loop *
> >  _efl_loop_consumer_loop_get(Eo *obj, Efl_Loop_Consumer_Data *pd
> EINA_UNUSED)
> >  {
> > +   if (eina_main_loop_is())
> > + return ecore_main_loop_get();
> > return efl_provider_find(obj, EFL_LOOP_CLASS);
>
> looks like that should be the fallback, not the first thing to check:
> only check if the main loop if there is no provider for
> EFL_LOOP_CLASS.
>

Ah, yes, my mistake.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] What are we going to release?

[Jean-Philippe André]

Hi,

On Tue, Dec 19, 2017 at 2:43 AM, Stephen Houston <smhousto...@gmail.com>
wrote:

> I really think a consensus needs to be reached here.  The uncertainty has
> too many ill effects in other areas of the project, not the least of which
> is documentation as Andy has said, as well as a difficulty prioritizing
> development efforts and attracting new developers.  Count me in as on the
> side of Cedric and Andy that stabilizing and releasing in parts is the most
> ideal method.
>

Here's what I think were we're at, for the "unified API":

Elementary's is clearly not ready for prime time. But a LOT of progress is
being made right now. Before a release this will need even more work, and
especially a lot of testing. I think it is not acceptable anymore to
functionally break those new widgets (like what happened to panes
recently), but they may still undergo some naming changes, as things start
settling down.
The new theme API is still far from being implemented (only the short group
names has been done).
So, this is not going to be finalized in the upcoming release.

Evas is mostly ready, except for text and animation APIs. Dunno how much
work is left.
Some unstable APIs could easily be marked as @beta.

Edje is almost there but I think Efl.Canvas.Layout will see a few changes
soon (basically the class should be empty and only "implement" interfaces).
New features might be added (but nothing that should break it).

Ecore has recently undergone some major changes, so I have no idea whether
its EO API now be ready for a release as part of the Unified API.

Eo and Eina are mostly fine as is.
Eolian needs to stop changing the syntax. libeolian doesn't need to be
stable yet.

"Efl" (as in efl/interfaces) is a mix of many things, which should then be
carefully divided between "stable" and "non-stable" parts of the unified
API.


I would love to stabilize the API in parts.

Best regards,



>
> On Mon, Dec 11, 2017 at 8:13 PM Carsten Haitzler <ras...@rasterman.com>
> wrote:
>
> > On Mon, 11 Dec 2017 13:11:53 +0900 Jean-Philippe André <
> j...@videolan.org>
> > said:
> >
> > > Hi,
> > >
> > >
> > > Just a word about panes and other new widgets: yes they got broken at
> > some
> > > point but should be fixed now that the "EO" theme API has been merged.
> > > I think most of the existing Efl.Ui.Xxx widgets should soon become
> > usable.
> > > But I am not ready to commit yet for all of elementary (note: the model
> > API
> > > is still in flux and the [gen]list widget isn't here yet).
> > >
> > >
> > > @netstar proposed branching off to EFL 2 and no one responded to that
> (as
> > > far as I can tell).
> >
> > I just dopn't think that'd be good for the project as a while, no matter
> > that
> > pain of having to keep legacy and eo/interfaces going at once.
> >
> > > I very very much wish we had taken that route as the most painful part
> in
> > > this interfaces rework is to keep legacy working.
> >
> > we are trying to do:
> >
> > https://www.youtube.com/watch?v=B_1bAnLqlMo
> >
> > yup. it's hard. :) it would have been easier to start fresh from the code
> > we
> > have and just nuke what we are not keeping. but as you say below, there
> are
> > reasons.
> >
> > > Unfortunately we have reasons for not branching off, as follows:
> > > - We need the existing ecosystem for testing (E, apps, Tizen, etc...).
> > > Breaking compilation or runtime or existing apps would be a huge PITA.
> > > Having a separate .so file (libefl.so.2) would mean a lot less
> > > out-of-the-box testing.
> > > Yes, we break stuff in legacy, but this is by accident, not by design.
> I
> > > hope it is clear that we are still trying hard to keep things in order.
> > > - We expect the existing ecosystem to progressively adapt to the EO
> API,
> > by
> > > modifying a UI component here and there, adding a new view or whatnot
> in
> > > the application, etc... We don't expect an immediate port of existing
> > > legacy apps to EO-only API.
> >
> > it likely will be a multi-year port for apps. certainly for enlightenment
> > it
> > will be a long long long path.
> >
> > > OTOH when it comes to bindings (Lua, C++, C# for now), everything is
> new,
> > > so legacy doesn't really matter.
> > > Cedric mentioned to me a couple of times how long it took large
> projects
> > > using Qt4 to finally move on to Qt5. So we're trying to avoid that
> > > bottleneck.
> > >
> > >
> >

Re: [E-devel] ecore / efl loop work

[Jean-Philippe André]

Hey raster,

I'm confused by something, see ecore_test_ecore_main_loop_timer_inner,
and ecore_test_ecore_main_loop_event_recursive.
This test runs the main loop inside the main loop, which the documentation
says you shouldn't do. The test case passes because it's badly written
(marks the success variable before really running the test). It's not
testing that either of the inner timers even run.

What's up with this? Did those inner loops use to work and then this became
forbidden?



On Mon, Dec 18, 2017 at 8:16 PM, Jean-Philippe André <j...@videolan.org>
wrote:

>
>
> On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
>
>> On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail <ced...@ddlm.me> said:
>>
>> > >  Original Message 
>> > > Subject: [E-devel] ecore / efl loop work
>> > > Local Time: December 14, 2017 9:30 PM
>> > > UTC Time: December 15, 2017 5:30 AM
>> > > From: ras...@rasterman.com
>> > > To: e <enlightenment-devel@lists.sourceforge.net>
>> >
>> > 
>> >
>> > > there are internals that need some cleaning up like internal use of
>> > > ecore_timer, ecore_idler. need to decide what to do with ecore_app and
>> > > argv/argc stuff. the ecore signal code needs some cleaning up
>> internally
>> > > too. ecore_thread and ecore_pipe need re-implementation for
>> > > inter-thread/loop messaging/calling etc.
>> >
>> > ecore_app and argv/argc are already passed to the
>> EFL_LOOP_EVENT_ARGUMENTS as
>> > parameter to the main loop. There is no real need I think to have that
>> more
>> > exposed.
>>
>> oh i know. i'm more thinking about spawning new threads+loops ... and
>> should
>> they be spawned by passing argv/c to them like processes get. it'd make
>> all
>> threads/loops consistent in this way. yes. being able to attach a void *
>> might
>> also be useful as this is what pthread will do anyway.
>>
>> > As for Ecore_Thread, the only binding that could make use of it is C++
>> and it
>> > requires to definitively have a way to mark a function in .eo for other
>> > binding to ignore. At this point, there is no rush into implementing it.
>>
>> well ecore_thread also does a thread pool, work queue etc. and it's
>> asymmetric.
>> you can create work thread items and then send back results, but once
>> created
>> you cant "send more work to the thread". you create more threads.
>>
>> i was thinking more along the lines of:
>>
>> we create a thread+loop via eo (you get back a LOCAL object handle
>> representing
>> the remote thread that you use to communicate with it), and now you can
>> send
>> stuff to it, and get back events from it (sending likely just returns you
>> a
>> future if you are expecting a reply so you can turn it into a
>> "conversation"
>> via promises/futures). this is what i mean by "ecore thread" needs doing.
>> we
>> need a way of creating threads and talking to them nicely.
>>
>> > > i also don't delete the loop object on ecore shutdown. it's ...
>> problematic.
>> > > tbh the whole "shutdown" stuff we have in efl is just not worth the
>> corner
>> > > case work. init and leave up and running for the life of the process.
>> it's
>> > > simpler and it also actually makes it faster to exit an app...
>> shutting
>> > > down actually takes a lot of work. i've seen it delay an app closing
>> a lot.
>> >
>> > This is going to likely create problem. If you have for example added
>> data to
>> > the loop object and you expect the destruction callback to be called at
>> some
>> > point, well, that will be out of luck. I can't remember why, but the two
>> > tests you disable where from a real life case that required that
>> behavior. So
>> > it would be best if I could remember, but right now, I feel like not
>> > destroying this object is ging to create trouble in the future as it
>> will be
>> > one object that doesn't have the same behavior as every other one.
>>
>> that doesn't change the fact that destruction is expensive and generally
>> pointless. there may b e some cases where it's nice. like "detecting
>> leaks by
>> looking at what is still allocated on exit" which frankly doesn't work
>> too well
>> anyway. but i found problems in eldbus for example when finally
>> everything was
>> really

Re: [E-devel] Type info in futures

[Jean-Philippe André]

Hi,

On Tue, Dec 19, 2017 at 12:25 AM, Andrew Williams <a...@andywilliams.me>
wrote:

> Hi,
>
> Is there a way that we can preserve type information when using
> Eina_Future?
>
> For example on the Efl.Io.Manager "open" method I have to read the full
> description to find it's return type:
>  https://www.enlightenment.org/develop/api/efl/io/manager/method/open


I believe in this specific case it should be declared as
  return: future;

But I think this still generates Efl.Future stuff, rather than Eina.Future.
Cedrc! :)

That being said, without documentation it remains near impossible to guess
the type.
It would be nice to have some introspection, I think?

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] ecore / efl loop work

[Jean-Philippe André]

for legacy ecore event.




> > 
> >
> > > this api is NOT FINAL. it's a good first stab at doing all of this
> work. it
> > > could probably improve. i need to clear up some of the internal bits
> that
> > > still use single mainloop dependent calls as per the commit and above,
> and
> > > some other things need a design and implementation... and then actually
> > > create multiple threads with loops and even decide HOW threads and
> loops
> > > are created and spawned and hooked up etc. ... but this is a huge step
> > > there.
> >
> > I am not to sure of the various API around message. It is missing a lot
> of
> > documentation to understand it, but in efl_loop, shouldn't
> message_process
> > and message_exists only be internal function ? Or do you see any use for
> them
> > in an application ? Why is message_handler_get an class function ?
>
> well they generally shouldn't be called, but they are really methods on the
> object, so i put them there. other than totally hiding them from eo ... i
> don't
> think we have a good solution yet. nothing like "@dangerous" or
> "@privileged"
> or something... just @protected which is not what i want really... i think.
>

Basically should be @beta at least. Or indeed not exposed in EO.


> message_handler_get was a class func due to a long talk i had with jpeg
> about
> making something that comes out nicely in bindings with typesafety and no
> casting. right now i forgot the detail... @jpeg - help me out - what was
> the
> detail again? ummm... I think it was that you can
>

The idea was that the event info would be a subclass of the main event info
class, i.e. Efl.Loop.Message.
There are no subclasses yet, as none of the existing events can be
transformed to EO objects without extra wrapping for legacy.

So let's say our event info class is My_Message, subclass of
Efl.Loop.Message.
The idea I think was that you'd also subclass Efl.Loop.Message.Handler and
create a new event type there, which could then be strongly typed with
My_Message as event info type. message_call would be a trivial
implementation that figures out the eo event type (let's say with a
@protected method message_type returning Efl.Event.Description) and fires
it.

Honestly I'm not sure I remember right, and I'm not sure it's necessary
either :) This was just a lunch discussion after all :)



>
> > How is Efl.Loop.Handler suppose to be used ? How does it fit with Efl.Io
> > interfaces ?
>
> loop handler doesn't DO io. it also isn't limited to fd's. its the old fd
> handler AND win32 handler combined in one object. it calls event callbacks
> when
> the fd or win32 handle is ready for read/write etc. - then you do it. yes.
> fd's
> are low level as are win32 handles. this is probably generally useless for
> js/lua/c# etc. etc. .. but it's necessary for c/c++ and other native
> languages
> where these types exist and need to be integrated. this backs the legacy
> fd and
> win32 handlers now (they sit on top of it). the efl io stuff didn't
> integrate
> into the loop. they didn't register for wakeup with select and friends. the
> handlers are the glue to do this with and they handle the lower level
> objects
> (fd's, win32 handles).
>
> > Cedric
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > 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" --
> Carsten Haitzler - ras...@rasterman.com
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>


-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Interfaces API not in EFL namespace

[Jean-Philippe André]

On Tue, Dec 12, 2017 at 2:31 AM, Andrew Williams <a...@andywilliams.me>
wrote:

> Hi,
>
> Perfect, that's the site updated to only include Efl.* (and eina.* as I
> realised there are some objects aliased).
>
> However this highlights an issue - the Efl.Ui widgets (or at least most of
> them) inherit from Elm.Widget and so their parent is no longer in the docs.
> The contents of Elm.Widget is almost all efl_ui_* - is there some reason
> why it still uses the legacy namespace for the class?
>

Yeah, there's a reason.
As some people are still working in major widgets I've postponed the rename
of Widget (from Elm. to Efl.Ui.) until those are also merged.
I think we will be able to do that renaming soon.

Hope that clarifies it :)



>
> Thanks,
> Andy
>
> On Sun, 10 Dec 2017 at 21:23 Cedric Bail <ced...@ddlm.me> wrote:
>
> > >  Original Message 
> > > Subject: Re: [E-devel] Interfaces API not in EFL namespace
> > > Local Time: December 9, 2017 1:01 AM
> > > UTC Time: December 9, 2017 9:01 AM
> > > From: a...@andywilliams.me
> > > To: Enlightenment developer list <
> > enlightenment-devel@lists.sourceforge.net>
> > >
> > > Hi,
> > >
> > > That makes sense, thanks.
> > > I’d like the API docs to reflect what we intend to release and an api
> > level
> > >
> > > - would it be ok then for me to filter for just “Efl.” prefix as the
> > others
> > > will be legacy?
> >
> > Yes, indeed it makes sense to not have the Eo documentation available for
> > those.
> >
> > Cedric
> >
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> --
> http://andywilliams.me
> http://ajwillia.ms
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] What are we going to release?

[Jean-Philippe André]

On Mon, Dec 11, 2017 at 3:36 PM, Simon Lees <sfl...@suse.de> wrote:

> On 11/12/17 14:41, Jean-Philippe André wrote:
> > Cedric mentioned to me a couple of times how long it took large projects
> > using Qt4 to finally move on to Qt5. So we're trying to avoid that
> > bottleneck.
>
> I don't think for most large projects it wasn't that long for Qt4-Qt5,
> the API changes were minimal for almost everything (except there first
> experimental mobile api, I ported a really large project in 2 days.
>
> The exception was apps that were still using "legacy" Qt3 compatibility
> API's that were dropped. The Qt3->Qt4 on the other hand was a much
> larger API break which did take a long time they learned from that for
> Qt4->Qt5 and didn't make nearly as many API changes.


Good to know. Anyway compatibility is important :)

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] API cleaning eina_str etc

[Jean-Philippe André]

On Wed, Dec 6, 2017 at 3:39 AM, Andrew Williams <a...@andywilliams.me>
wrote:

> Hi,
>
> Looking at the API we have aggregated over the year and thinking about our
> chance to clean things up right now I can't help but feel uncomfortable
> about the following:
>
> eina_str_*
> eina_stringshare_*
> eina_slstr_*
>
+ eina_tmpstr_*
+ eina_str*


>
> These are all related but have different namespaces.
> Would it be possible to tidy them up through aliases and deprecation
> perhaps?
>
> eina_string_[share|short] or even eina_str_[shr|tmp] would help a lot with
> APIs and also IDE auto-completion.


I agree those API's are confusing. Some may be compatible with each other
but some others not.
I just worry that adding more aliases to existing API's would end up being
more confusing?
Honestly I don't really know what's best :)


PS:  unless maybe you use #ifndef EINA_UNIFIED_API_ONLY to
hide the legacy forms when working exclusively in EO land 
-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] What are we going to release?

[Jean-Philippe André]

 as time goes. Bits by bits.
> > > > > > >
> > > > > > > they absolutely do. e.g. c#. without the full stack it's
> > > pointless. and
> > > > > > > they're
> > > > > > > not going to migrate... except rewrite in a new language. you
> know
> > > > > that as
> > > > > > > well
> > > > > > > as i do.
> > > > > > >
> > > > > > > > [snip]
> > > > > > > >
> > > > > > > > >> Should we instead figure when we might start releasing and
> > > set an
> > > > > > > > >> expectation to the public? Something like "come back in
> 2019"?
> > > > > > > > >>
> > > > > > > > >> well we hoped to finish in 2016, then by end of 2017 ...
> we
> > > have a
> > > > > > > better
> > > > > > > > >> chance now as people are really focusing on it, but i
> actually
> > > > > suspect
> > > > > > > > >> 2019 is a safe bet. mid 2018 might be "optimistic" and
> end of
> > > Q1
> > > > > 2018
> > > > > > > is
> > > > > > > > >> "totally crazy optimistic if the world all aligns right".
> > > > > > > >
> > > > > > > > If we keep trying to release everything at once without
> > > commitment
> > > > > and
> > > > > > > not by
> > > > > > > > slice of useful bits, then sure we will still be at it in
> 2019 or
> > > > > maybe
> > > > > > > even
> > > > > > > > later. But we don't need to do so. Existing apps and existing
> > > > > bindings
> > > > > > > won't
> > > > > > > > stop working. The new API is designed to allow for a smooth
> > > > > transition.
> > > > > > > It is
> > > > > > > > designed to allow you to mix old and new together. This way,
> you
> > > can
> > > > > > > already
> > > > > > > > build a useful application by building with Efl_Core,
> Efl_Net and
> > > > > > > Elementary.
> > > > > > > > This is fine.
> > > > > > >
> > > > > > > it's not about "trying to release all at once". it's about not
> > > painting
> > > > > > > ourselves into a corner. not limiting ourselves before we
> really
> > > need
> > > > > to.
> > > > > > >
> > > > > > > every release we do means we stop doing eo work and instead
> > > stabilize a
> > > > > > > release. the more we do the more we push a final result into
> 2019.
> > > > > without
> > > > > > > a
> > > > > > > significant amount of the interfaces api available you won't
> > > really get
> > > > > > > much, if
> > > > > > > any, valuable feedback, and instead simply lose at least a few
> > > months
> > > > > of
> > > > > > > work
> > > > > > > time into release work. (1 month per release at least).
> > > > > > >
> > > > > > > i don't see how this gets us to our goal better or sooner than
> > > what we
> > > > > are
> > > > > > > doing now. what i do see is:
> > > > > > >
> > > > > > > 1. getting there later
> > > > > > > 2. not gaining anything really valuable in return for that
> delay
> > > > > > >
> > > > > > > but here's my take... the above is my advice, but delay-wise...
> > > i'm not
> > > > > > > responsible. but mark my words that the goal that MATTERS -
> > > interfaces
> > > > > > > that can
> > > > > > > be used in BINDINGS like C#, C++, JS, LUA etc. will only get
> > > delayed
> > > > > ...
> > > > > > > and
> > > > > > > you know well enough how much a release delays. we have a whole
> > > > > mountain of
> > > > > > > new coverity complaints. any eo api to be "stabilized for
> release"
> > > > > needs a
> > > > > > > lot
> > > > > > > of attention in review and actual use before that release goes
> out
> > > if
> > > > > you
> > > > > > > want
> > > > > > > any kind of stability guarantee to it. and you know full well
> that
> > > just
> > > > > > > these
> > > > > > > few api's are of nil use to the consumers of bindings like
> above
> > > until
> > > > > > > there
> > > > > > > is a LOT more there.
> > > > > > >
> > > > > > > but if you wish to take the risk and the blame when things get
> > > > > delayed...
> > > > > > > you
> > > > > > > go ahead. all i want is proof of actual use in the wild like
> you
> > > claim,
> > > > > > > because unless there is such proof, no lessons will ever be
> learned
> > > > > from
> > > > > > > this.
> > > > > > > think of it as a "KPI". proof that the "stable beta api" is
> used
> > > > > without
> > > > > > > the
> > > > > > > current unstable beta #define and so on... in more than a few
> > > trivial
> > > > > > > places.
> > > > > > >
> > > > > > > > Cedric
> > > > > > > >
> > > > > > >
> > > > >
> > > 
> --
> > > > > > > > Check out the vibrant tech community on one of the world's
> most
> > > > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > > > > > ___
> > > > > > > > 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"
> > > > > --
> > > > > > > Carsten Haitzler - ras...@rasterman.com
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > 
> --
> > > > > > > Check out the vibrant tech community on one of the world's most
> > > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > > > > ___
> > > > > > > enlightenment-devel mailing list
> > > > > > > enlightenment-devel@lists.sourceforge.net
> > > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-
> devel
> > > > > > >
> > > > > > --
> > > > > > http://andywilliams.me
> > > > > > http://ajwillia.ms
> > > > > >
> > > > >
> > > 
> --
> > > > > > Check out the vibrant tech community on one of the world's most
> > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > > > ___
> > > > > > 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"
> > > --
> > > > > Carsten Haitzler - ras...@rasterman.com
> > > > >
> > > > > --
> > > > http://andywilliams.me
> > > > http://ajwillia.ms
> > >
> > >
> > > --
> > > - Codito, ergo sum - "I code, therefore I am"
> --
> > > Carsten Haitzler - ras...@rasterman.com
> > >
> > > --
> > http://andywilliams.me
> > http://ajwillia.ms
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Theme for EO widgets

[Jean-Philippe André]

Hi,

This series of patches has been merged.
Thanks again to everyone who worked on this so far.

Community, please report any new issue you can spot (related to theme).


On Tue, Nov 28, 2017 at 1:34 PM, Simon Lees <sfl...@suse.de> wrote:

>
>
> On 28/11/17 14:54, Jean-Philippe André wrote:
> > On Tue, Nov 28, 2017 at 1:04 PM, Simon Lees <sfl...@suse.de> wrote:
> >
> >>
> >>
> >> On 28/11/17 13:45, Jean-Philippe André wrote:
> >>> Hello all,
> >>>
> >>>
> >>> I have some terrible news to announce here.
> >>>
> >>>
> >>> In order to alter the behavior and fix oddities in the theme (eg.
> "left"
> >>> part for the upper side of a panes widget), add the necessary new
> >> features
> >>> (eg. "background" swallows and color classes), and remove unwanted
> things
> >>> (ActionSlider, anyone? ^^), we need to branch off the theme for EO
> >> widgets
> >>> into a separate category. Eventually this should become the only
> default
> >>> theme for EFL 2.0 and could be a separate EDJ file soon.
> >>>
> >>> Here are some of the points we're trying to address with this new
> theme:
> >>>
> >>> - simpler naming for groups (eg. "efl/button" for the base group for
> the
> >>> default style of a button). This should have benefits both for
> >> performance
> >>> (shorter strings, less memory stress) and readability
> >>>
> >>> - use color classes / text classes / size classes everywhere possible
> >> (also
> >>> with simple names and inheritance, if we manage to find a proper
> solution
> >>> in edje)
> >>>
> >>> - add "background" swallow in most widgets that could have a nice
> custom
> >>> background (eg. a button, frame, etc...). See also 3c47a4f9f9ef77 (can
> >> and
> >>> should be improved further).
> >>>
> >>> - more consistent part names, they should match 1:1 with the part names
> >> in
> >>> EO files. There are exceptions were "virtual" parts are used in EO
> (i.e.
> >>> the part is not a real object) or if those parts are sub objects
> manually
> >>> managed by the widget. Real parts should be marked as "required: 1" in
> >> EDC.
> >>>
> >>> - more consistent signal names, including a clear definition of
> "action"
> >>> and "state" changes.
> >>>
> >>>
> >>> The downsides to this tough decision are quite obvious:
> >>>
> >>> - More theme work to do for custom themes (unless you only care about
> EO
> >> or
> >>> only about legacy)
> >>>
> >>> - Less testing of the new theme (same as when introducing new classes)
> >>>
> >>> - It's a crazy amount of work to make sure everything is consistent and
> >>> complete.
> >>>
> >>>
> >>> I'll be merging a patch introducing this new theme very shortly. See
> >> D5473.
> >>>
> >>>
> >>> I really wish there was a better solution but we couldn't find another
> >> way
> >>> that doesn't break the existing theme API (which would be totally
> >>> unacceptable).
> >>>
> >>>
> >>> Best regards,
> >>>
> >>
> >> Before you merge this patch can you make sure elementary_test is capable
> >> of testing all the parts of "Legacy" and "EO" themes, otherwise as theme
> >> authors we are not able to test and create these theme parts properly.
> >>
> >> I know that if the theme gets pushed first elm test will get forgotten
> :-)
> >
> >
> > Yes indeed.
> > The legacy theme won't be touched, that's the whole idea. So in theory
> > there shouldn't be new bugs. In theory ;-)
> >
> > As for the EO theme, it does indeed require extensive testing in
> > elementary_test. New widgets should get a new theme (copy & paste from
> the
> > legacy one, then adapt to make a clean API).
> > This is also why I've added the distinction in elm_test between legacy
> and
> > EO.
> >
> > I'll try and make sure proper test cases are added.
> >
>
> The problem is less breaking themes that already exist but testing new
> themes i'm creating with the legacy api
>

Unfortunately this is out of scope for our current work.
More or better test cases for legacy widgets would definitely be nice to
have... I'm sorry I can't really help more :(

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 06/06: eolian: pass state where necessary

[Jean-Philippe André]

I believe this broke elm_check when clouseau is enabled.
See the bt at the end of the file.


On Wed, Dec 6, 2017 at 7:30 PM, Daniel Kolesa <dan...@octaforge.org> wrote:

> On Wed, Dec 6, 2017, at 10:22, Jean-Philippe André wrote:
> > This breaks the C# bindings as some Eolian APIs are changed :(
>
> Then the C# binding people should fix that themselves. Eolian is
> unstable API right now and if you add in new code relying on it then
> you're responsible for it. I'm not going to deal with any new bindings
> code introduced into our repository at this point, not JS, not C#,
> sorry.
>
> D5
>
> >
> > On Wed, Dec 6, 2017 at 12:42 AM, Daniel Kolesa <dan...@octaforge.org>
> > wrote:
> >
> > > q66 pushed a commit to branch master.
> > >
> > > http://git.enlightenment.org/core/efl.git/commit/?id=
> > > 8a1f93f698315b43de28b755bce5fc9a4d85d59a
> > >
> > > commit 8a1f93f698315b43de28b755bce5fc9a4d85d59a
> > > Author: Daniel Kolesa <d.kol...@osg.samsung.com>
> > > Date:   Tue Dec 5 16:40:04 2017 +0100
> > >
> > > eolian: pass state where necessary
> > >
> > > This modifies the API so that global state removal is made
> > > possible. It's still used internally for now but externally
> > > the state is contained.
> > > ---
> > >  src/bin/eolian/main.c|   9 ++-
> > >  src/bin/eolian_cxx/eolian_cxx.cc |  23 +--
> > >  src/bindings/luajit/eolian.lua   |  96
> 
> > >  src/lib/eolian/Eolian.h  | 116
> +++---
> > > 
> > >  src/lib/eolian/eolian_database.c |  20 +++---
> > >  src/scripts/elua/modules/lualian.lua |  16 +++--
> > >  src/tests/eolian/eolian_parsing.c| 119
> ++
> > > -
> > >  7 files changed, 258 insertions(+), 141 deletions(-)
> > >
> > > diff --git a/src/bin/eolian/main.c b/src/bin/eolian/main.c
> > > index fdb5ca2568..92643c6f7e 100644
> > > --- a/src/bin/eolian/main.c
> > > +++ b/src/bin/eolian/main.c
> > > @@ -430,6 +430,8 @@ main(int argc, char **argv)
> > > eina_init();
> > > eolian_init();
> > >
> > > +   Eolian *eos = eolian_new();
> > > +
> > > const char *dom = "eolian_gen";
> > > _eolian_gen_log_dom = eina_log_domain_register(dom,
> EINA_COLOR_GREEN);
> > > if (_eolian_gen_log_dom < 0)
> > > @@ -530,7 +532,7 @@ main(int argc, char **argv)
> > >
> > > if (scan_system)
> > >   {
> > > -if (!eolian_system_directory_scan())
> > > +if (!eolian_system_directory_scan(eos))
> > >{
> > >   fprintf(stderr, "eolian: could not scan system
> directory\n");
> > >   goto end;
> > > @@ -540,14 +542,14 @@ main(int argc, char **argv)
> > > const char *inc;
> > > EINA_LIST_FREE(includes, inc)
> > >   {
> > > -if (!eolian_directory_scan(inc))
> > > +if (!eolian_directory_scan(eos, inc))
> > >{
> > >   fprintf(stderr, "eolian: could not scan '%s'\n", inc);
> > >   goto end;
> > >}
> > >   }
> > >
> > > -   const Eolian_Unit *src = eolian_file_parse(input);
> > > +   const Eolian_Unit *src = eolian_file_parse(eos, input);
> > > if (!src)
> > >   {
> > >  fprintf(stderr, "eolian: could not parse file '%s'\n", input);
> > > @@ -589,6 +591,7 @@ end:
> > >   free(outs[i]);
> > > free(basen);
> > >
> > > +   eolian_free(eos);
> > > eolian_shutdown();
> > > eina_shutdown();
> > >
> > > diff --git a/src/bin/eolian_cxx/eolian_cxx.cc
> b/src/bin/eolian_cxx/eolian_
> > > cxx.cc
> > > index 134700ae6c..fac96da5e2 100644
> > > --- a/src/bin/eolian_cxx/eolian_cxx.cc
> > > +++ b/src/bin/eolian_cxx/eolian_cxx.cc
> > > @@ -34,6 +34,7 @@ struct options_type
> > >  {
> > > std::vector include_dirs;
> > > std::vector in_files;
> > > +   mutable Eolian* state;
> > > mutable Eolian_Unit const* unit;
> > > std::string out_file;
> > > bool main_header;
> > > @@ -298,7 +299,7 @@ run(options_type const& opts)
> > >
> > > for(auto&& name :

Re: [E-devel] (eolian) @since doc tags on property getters/setters

[Jean-Philippe André]

On Fri, Dec 8, 2017 at 11:54 AM, Jean-Philippe André <j...@videolan.org>
wrote:

> Hi,
>
> On Fri, Dec 8, 2017 at 5:56 AM, Lauro Moura <lauromoura@
> expertisesolutions.com.br> wrote:
>
>> Hi all.
>>
>> Currently eolian makes the class members inherit the @since value from the
>> class if it is not explicitly defined[1]. This works nicely for most
>> things
>> but may cause some inconsistencies for getters/setters.
>>
>> For example, if I have a class @since 1.17 and a property @since 1.18, if
>> I
>> don't explicitly specify the getter/setter @since tags they would end up
>> with @since 1.17, inherited from the class.
>>
>> Should getters/setters inherit their @since from their common property doc
>> or should we explicitly fill getters/setters with the correct @since tags
>> (actually making them inherit manually)?
>>
>
> Yes, the @since should be inherited:
> class @since -> property @since -> get/set @since
>

Sorry, maybe it's not clear. But I meant that you inherit like the above,
and if you want to override you do it. It shouldn't have to be necessary to
write @since if the parent has it.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] (eolian) @since doc tags on property getters/setters

[Jean-Philippe André]

Hi,

On Fri, Dec 8, 2017 at 5:56 AM, Lauro Moura <
lauromo...@expertisesolutions.com.br> wrote:

> Hi all.
>
> Currently eolian makes the class members inherit the @since value from the
> class if it is not explicitly defined[1]. This works nicely for most things
> but may cause some inconsistencies for getters/setters.
>
> For example, if I have a class @since 1.17 and a property @since 1.18, if I
> don't explicitly specify the getter/setter @since tags they would end up
> with @since 1.17, inherited from the class.
>
> Should getters/setters inherit their @since from their common property doc
> or should we explicitly fill getters/setters with the correct @since tags
> (actually making them inherit manually)?
>

Yes, the @since should be inherited:
class @since -> property @since -> get/set @since



>
> [1] eo_lexer.c:~505 // End of read_doc(...)
> --
> Lauro Moura
> Expertise Solutions
> "lauromoura" on FreeNode
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>


-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 06/06: eolian: pass state where necessary

[Jean-Philippe André]

s_get_by_name(unit, "Class_Funcs")));
>
> /* Class properties */
> @@ -950,6 +988,7 @@ START_TEST(eolian_class_funcs)
> fail_if(eolian_function_is_class(fid));
> fail_if(eolian_function_scope_get(fid, EOLIAN_METHOD) !=
> EOLIAN_SCOPE_PROTECTED);
>
> +   eolian_free(eos);
> eolian_shutdown();
>  }
>  END_TEST
> @@ -962,9 +1001,11 @@ START_TEST(eolian_free_func)
> const Eolian_Unit *unit;
>
> eolian_init();
> +   Eolian *eos = eolian_new();
>
> /* Parsing */
> -   fail_if(!(unit = eolian_file_parse(PACKAGE_
> DATA_DIR"/data/free_func.eo")));
> +   fail_if(!eolian_directory_scan(eos, PACKAGE_DATA_DIR"/data"));
> +   fail_if(!(unit = eolian_file_parse(eos, PACKAGE_DATA_DIR"/data/free_
> func.eo")));
>
> /* Check that the class Dummy is still readable */
> fail_if(!(class = eolian_class_get_by_name(unit, "Free_Func")));
> @@ -996,6 +1037,7 @@ START_TEST(eolian_free_func)
> fail_if(!(type = eolian_typedecl_base_type_get(tdl)));
> fail_if(strcmp(eolian_type_free_func_get(type), "ptr_free"));
>
> +   eolian_free(eos);
> eolian_shutdown();
>  }
>  END_TEST
> @@ -1009,9 +1051,11 @@ START_TEST(eolian_null)
> Eina_Iterator *iter;
>
> eolian_init();
> +   Eolian *eos = eolian_new();
>
> /* Parsing */
> -   fail_if(!(unit = eolian_file_parse(PACKAGE_DATA_DIR"/data/null.eo")));
> +   fail_if(!eolian_directory_scan(eos, PACKAGE_DATA_DIR"/data"));
> +   fail_if(!(unit = eolian_file_parse(eos, PACKAGE_DATA_DIR"/data/null.
> eo")));
>
> fail_if(!(class = eolian_class_get_by_name(unit, "Null")));
> fail_if(!(func = eolian_class_function_get_by_name(class, "foo",
> EOLIAN_METHOD)));
> @@ -1045,6 +1089,7 @@ START_TEST(eolian_null)
> fail_if(eina_iterator_next(iter, (void**)));
> eina_iterator_free(iter);
>
> +   eolian_free(eos);
> eolian_shutdown();
>  }
>  END_TEST
> @@ -1056,10 +1101,11 @@ START_TEST(eolian_import)
> const Eolian_Unit *unit;
>
> eolian_init();
> +   Eolian *eos = eolian_new();
>
> -   fail_if(!eolian_directory_scan(PACKAGE_DATA_DIR"/data"));
> +   fail_if(!eolian_directory_scan(eos, PACKAGE_DATA_DIR"/data"));
>
> -   fail_if(!(unit = eolian_file_parse(PACKAGE_
> DATA_DIR"/data/import.eo")));
> +   fail_if(!(unit = eolian_file_parse(eos, PACKAGE_DATA_DIR"/data/import.
> eo")));
> fail_if(!(class = eolian_class_get_by_name(unit, "Import")));
>
> fail_if(!(tdl = eolian_typedecl_alias_get_by_name(unit, "Imported")));
> @@ -1068,6 +1114,7 @@ START_TEST(eolian_import)
> fail_if(!(tdl = eolian_typedecl_struct_get_by_name(unit,
> "Imported_Struct")));
> fail_if(strcmp(eolian_typedecl_file_get(tdl), "import_types.eot"));
>
> +   eolian_free(eos);
> eolian_shutdown();
>  }
>  END_TEST
> @@ -1082,10 +1129,11 @@ START_TEST(eolian_decl)
> Eina_Iterator *itr;
>
> eolian_init();
> +   Eolian *eos = eolian_new();
>
> -   fail_if(!eolian_directory_scan(PACKAGE_DATA_DIR"/data"));
> +   fail_if(!eolian_directory_scan(eos, PACKAGE_DATA_DIR"/data"));
>
> -   fail_if(!(unit = eolian_file_parse(PACKAGE_DATA_DIR"/data/decl.eo")));
> +   fail_if(!(unit = eolian_file_parse(eos, PACKAGE_DATA_DIR"/data/decl.
> eo")));
> fail_if(!(class = eolian_class_get_by_name(unit, "Decl")));
>
> fail_if(!(itr = eolian_declarations_get_by_file("decl.eo")));
> @@ -1130,6 +1178,7 @@ START_TEST(eolian_decl)
> fail_if(!(decl = eolian_declaration_get_by_name("A")));
> fail_if(eolian_declaration_type_get(decl) != EOLIAN_DECL_STRUCT);
>
> +   eolian_free(eos);
> eolian_shutdown();
>  }
>  END_TEST
> @@ -1149,10 +1198,11 @@ START_TEST(eolian_docs)
> Eina_Iterator *itr;
>
> eolian_init();
> +   Eolian *eos = eolian_new();
>
> -   fail_if(!eolian_directory_scan(PACKAGE_DATA_DIR"/data"));
> +   fail_if(!eolian_directory_scan(eos, PACKAGE_DATA_DIR"/data"));
>
> -   fail_if(!(unit = eolian_file_parse(PACKAGE_DATA_DIR"/data/docs.eo")));
> +   fail_if(!(unit = eolian_file_parse(eos, PACKAGE_DATA_DIR"/data/docs.
> eo")));
>
> fail_if(!(tdl = eolian_typedecl_struct_get_by_name(unit, "Foo")));
> fail_if(!(doc = eolian_typedecl_documentation_get(tdl)));
> @@ -1374,6 +1424,7 @@ START_TEST(eolian_docs)
>"Event docs."));
> fail_if(eolian_documentation_description_get(doc));
>
> +   eolian_free(eos);
> eolian_shutdown();
>  }
>  END_TEST
> @@ -1391,11 +1442,12 @@ START_TEST(eolian_function_types)
> void *dummy;
>
> eolian_init();
> +   Eolian *eos = eolian_new();
>
> -   fail_if(!eolian_directory_scan(PACKAGE_DATA_DIR"/data"));
> +   fail_if(!eolian_directory_scan(eos, PACKAGE_DATA_DIR"/data"));
>
> /* Parsing */
> -   fail_if(!(unit = eolian_file_parse(PACKAGE_
> DATA_DIR"/data/function_types.eot")));
> +   fail_if(!(unit = eolian_file_parse(eos, PACKAGE_DATA_DIR"/data/
> function_types.eot")));
>
> /* void func(void); */
> fail_if(!(decl = eolian_typedecl_alias_get_by_name(unit,
> "VoidFunc")));
> @@ -1500,6 +1552,7 @@ START_TEST(eolian_function_types)
>
> fail_if(eina_iterator_next(iter, ));
>
> +   eolian_free(eos);
> eolian_shutdown();
>  }
>  END_TEST
> @@ -1517,10 +1570,11 @@ START_TEST(eolian_function_as_arguments)
> void *dummy;
>
> eolian_init();
> +   Eolian *eos = eolian_new();
>
> -   fail_if(!eolian_directory_scan(PACKAGE_DATA_DIR"/data"));
> +   fail_if(!eolian_directory_scan(eos, PACKAGE_DATA_DIR"/data"));
>
> -   fail_if(!(unit = eolian_file_parse(PACKAGE_DATA_DIR"/data/function_as_
> argument.eo")));
> +   fail_if(!(unit = eolian_file_parse(eos, PACKAGE_DATA_DIR"/data/
> function_as_argument.eo")));
>
> fail_if(!(cls = eolian_class_get_by_name(unit,
> "Function_As_Argument")));
>
> @@ -1540,6 +1594,7 @@ START_TEST(eolian_function_as_arguments)
>
> fail_if(eina_iterator_next(iter, ));
>
> +   eolian_free(eos);
> eolian_shutdown();
>  }
>  END_TEST
> @@ -1557,10 +1612,11 @@ START_TEST(eolian_parts)
> };
>
> eolian_init();
> +   Eolian *eos = eolian_new();
>
> -   fail_if(!eolian_directory_scan(PACKAGE_DATA_DIR"/data"));
> +   fail_if(!eolian_directory_scan(eos, PACKAGE_DATA_DIR"/data"));
>
> -   fail_if(!(unit = eolian_file_parse(PACKAGE_
> DATA_DIR"/data/parts.eo")));
> +   fail_if(!(unit = eolian_file_parse(eos, PACKAGE_DATA_DIR"/data/parts.
> eo")));
>
> fail_if(!(cls = eolian_class_get_by_name(unit, "Parts")));
>
> @@ -1585,6 +1641,7 @@ START_TEST(eolian_parts)
>   }
> eina_iterator_free(iter);
>
> +   eolian_free(eos);
> eolian_shutdown();
>  }
>  END_TEST
>
> --
>
> --
> Jean-Philippe André
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 16/16: eolian: Add inarray and inlist to source generation

[Jean-Philippe André]

Hi C# guys ;)

Thanks so much for finally merging those patches!

As for this one in particular, I don't think we want to use inarray or
inlist in the EO API.
Those types are quite weird in C, I'm not convinced we should try and
expose them outside of EFL (in EO API). We are currently not using them, I
think.

I will myself merge a large series of patches for C++ generation, including
parts and function pointer support.
I understand perfectly that the code may not be that great, but I want to
merge to master so that we have a common base for work. Please feel free to
modify or let me know what's wrong :)

Best regards,



On Tue, Dec 5, 2017 at 7:37 AM, Felipe Magno de Almeida <
fel...@expertisesolutions.com.br> wrote:

> felipealmeida pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=
> 66eb8ddfebf65f944a44f8b8871a8628757fe74e
>
> commit 66eb8ddfebf65f944a44f8b8871a8628757fe74e
> Author: Felipe Magno de Almeida <fel...@expertisesolutions.com.br>
> Date:   Mon Dec 4 20:32:06 2017 -0200
>
> eolian: Add inarray and inlist to source generation
> ---
>  src/bin/eolian/sources.c   | 28 ++--
>  src/tests/efl_mono/test_testing.eo |  4 ++--
>  2 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/src/bin/eolian/sources.c b/src/bin/eolian/sources.c
> index 2ba900c9bd..a8a349fa86 100644
> --- a/src/bin/eolian/sources.c
> +++ b/src/bin/eolian/sources.c
> @@ -189,14 +189,20 @@ _generate_iterative_free(Eina_Strbuf **buf, const
> Eolian_Type *type, const Eolia
> iterator_header = eina_strbuf_new();
> iter_param = eina_strbuf_new();
>
> +   Eolian_Type_Builtin_Type t = eolian_type_builtin_type_get(type);
> +
> eina_strbuf_append_printf(iter_param, "%s_iter",
> eolian_parameter_name_get(parameter));
>
> //generate the field definition
> eina_strbuf_append_printf(*buf, "   %s", 
> eolian_type_c_type_get(inner_type,
> EOLIAN_C_TYPE_DEFAULT));
> +   if(t == EOLIAN_TYPE_BUILTIN_INARRAY
> +  || t == EOLIAN_TYPE_BUILTIN_INLIST)
> + {
> +   eina_strbuf_append(*buf, "*");
> + }
> eina_strbuf_append_buffer(*buf, iter_param);
> eina_strbuf_append(*buf, ";\n");
>
> -   Eolian_Type_Builtin_Type t = eolian_type_builtin_type_get(type);
>
> if (t == EOLIAN_TYPE_BUILTIN_LIST)
>   {
> @@ -207,6 +213,24 @@ _generate_iterative_free(Eina_Strbuf **buf, const
> Eolian_Type *type, const Eolia
>  eina_strbuf_append(*buf, ")\n");
>  _generate_loop_content(buf, inner_type, iter_param);
>   }
> +   else if (t == EOLIAN_TYPE_BUILTIN_INARRAY)
> + {
> +eina_strbuf_append_printf(*buf, "   EINA_INARRAY_FOREACH(");
> +eina_strbuf_append_buffer(*buf, param);
> +eina_strbuf_append_char(*buf, ',');
> +eina_strbuf_append_buffer(*buf, iter_param);
> +eina_strbuf_append(*buf, ")\n");
> +_generate_loop_content(buf, inner_type, iter_param);
> + }
> +   else if (t == EOLIAN_TYPE_BUILTIN_INLIST)
> + {
> +eina_strbuf_append_printf(*buf, "   EINA_INLIST_FREE(");
> +eina_strbuf_append_buffer(*buf, param);
> +eina_strbuf_append_char(*buf, ',');
> +eina_strbuf_append_buffer(*buf, iter_param);
> +eina_strbuf_append(*buf, ")\n");
> +_generate_loop_content(buf, inner_type, iter_param);
> + }
> else if (t == EOLIAN_TYPE_BUILTIN_ITERATOR)
>   {
>  eina_strbuf_append_printf(*buf, "   EINA_ITERATOR_FOREACH(");
> @@ -237,7 +261,7 @@ _generate_iterative_free(Eina_Strbuf **buf, const
> Eolian_Type *type, const Eolia
>   }
> else
>   {
> -printf("Error, container unknown?!\n");
> +printf("Error, container unknown?! %d\n", (int)t);
>   }
>
> eina_strbuf_free(iterator_header);
> diff --git a/src/tests/efl_mono/test_testing.eo b/src/tests/efl_mono/test_
> testing.eo
> index db6f13bcf2..bf13a57283 100644
> --- a/src/tests/efl_mono/test_testing.eo
> +++ b/src/tests/efl_mono/test_testing.eo
> @@ -370,7 +370,7 @@ class Test.Testing (Efl.Object) {
>/* Integer */
>eina_inarray_int_in {
>   params {
> -@in arr: inarray;
> +@in arr: inarray<ptr(int)>;
>   }
>   return: bool;
>}
> @@ -387,7 +387,7 @@ class Test.Testing (Efl.Object) {
>
>eina_inarray_int_out {
>   params {
> -@out arr: inarray;
> +@out arr: inarray<ptr(int)>;
>   }
>   return: bool;
>}
>
> --
>
> --
> Jean-Philippe André
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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: efl_ui_spin: Add new spin and spin_button widgets

[Jean-Philippe André]

I guess you still have a file "efl_ui_spin.eo.h" in efl/interfaces. Please
remove it and compile again. It should be located in elementary, not efl.

On Mon, Dec 4, 2017 at 8:03 PM, Jean-Philippe André <j...@videolan.org>
wrote:

> Does this still happen? I can't reproduce this problem. Unless someone
> fixed it?
>
> On Fri, Dec 1, 2017 at 7:41 PM, Stefan Schmidt <ste...@osg.samsung.com>
> wrote:
>
>> Hello.
>>
>>
>> On 11/27/2017 11:55 AM, Woochan Lee wrote:
>> > jaehyun pushed a commit to branch master.
>> >
>> > http://git.enlightenment.org/core/efl.git/commit/?id=eefcb49
>> 419af9d0057ba4c03e6c9009a1265e31e
>> >
>> > commit eefcb49419af9d0057ba4c03e6c9009a1265e31e
>> > Author: Woochan Lee <wc0917@samsung.com>
>> > Date:   Mon Nov 20 19:12:49 2017 +0900
>> >
>> > efl_ui_spin: Add new spin and spin_button widgets
>> >
>> > Summary:
>> > https://phab.enlightenment.org/T5900
>> >
>> > Creating base class(efl_ui_spin) to support various shape of
>> spinner.
>> >
>> > Added button interaction widget efl_ui_spin_button inherited from
>> efl_ui_spin.
>> >
>> > Test Plan: Add tests in elementary_test.
>> >
>> > Reviewers: Jaehyun_Cho, woohyun, jpeg, singh.amitesh
>> >
>> > Subscribers: jenkins, id213sin, cedric, jpeg
>> >
>> > Differential Revision: https://phab.enlightenment.org/D5424
>> >
>>
>> Since this new widget I get compile error when building the examples.
>> My guess is that you either did not try to compile the examples or
>> disabled the C++ bindings. Please have a look to get this fixed.
>>
>>  CXX  bg_cxx_example_01.o
>>   CXX  bg_cxx_example_02.o
>>   CXX  button_cxx_example_00.o
>>   CXX  box_cxx_example_02.o
>> In file included from ../../../src/lib/elementary/Elementary.eo.hh:69:0,
>>  from ../../../src/lib/elementary/Elementary.hh:24,
>>  from box_cxx_example_02.cc:3:
>> ../../../src/lib/elementary/efl_ui_spin.eo.hh: In static member function
>> ‘static const Efl_Class* eo_cxx::efl::ui::Spin::_eo_class()’:
>> ../../../src/lib/elementary/efl_ui_spin.eo.hh:576:14: error:
>> ‘EFL_UI_SPIN_CLASS’ was not declared in this scope
>>return EFL_UI_SPIN_CLASS;
>>   ^
>> ../../../src/lib/elementary/efl_ui_spin.eo.hh:576:14: note: suggested
>> alternative: ‘EFL_UI_WIN_CLASS’
>>return EFL_UI_SPIN_CLASS;
>>   ^
>>   EFL_UI_WIN_CLASS
>> In file included from ../../../src/lib/elementary/Elementary.eo.hh:69:0,
>>  from ../../../src/lib/elementary/Elementary.hh:24,
>>  from box_cxx_example_02.cc:3:
>> ../../../src/lib/elementary/efl_ui_spin.eo.hh: In static member function
>> ‘static const Efl_Class* efl::ui::Spin::_eo_class()’:
>> ../../../src/lib/elementary/efl_ui_spin.eo.hh:660:14: error:
>> ‘EFL_UI_SPIN_CLASS’ was not declared in this scope
>>return EFL_UI_SPIN_CLASS;
>>   ^
>> ../../../src/lib/elementary/efl_ui_spin.eo.hh:660:14: note: suggested
>> alternative: ‘EFL_UI_WIN_CLASS’
>>return EFL_UI_SPIN_CLASS;
>>   ^
>>   EFL_UI_WIN_CLASS
>> ../../../src/lib/elementary/efl_ui_spin.eo.hh: In static member function
>> ‘static const Efl_Event_Description*
>> efl::ui::Spin::changed_event::description()’:
>> ../../../src/lib/elementary/efl_ui_spin.eo.hh:666:16: error:
>> ‘EFL_UI_SPIN_EVENT_CHANGED’ was not declared in this scope
>>{ return EFL_UI_SPIN_EVENT_CHANGED; }
>> ^
>> ../../../src/lib/elementary/efl_ui_spin.eo.hh:666:16: note: suggested
>> alternative: ‘EFL_UI_RADIO_EVENT_CHANGED’
>>{ return EFL_UI_SPIN_EVENT_CHANGED; }
>> ^
>> EFL_UI_RADIO_EVENT_CHANGED
>> ../../../src/lib/elementary/efl_ui_spin.eo.hh: In static member function
>> ‘static const Efl_Event_Description*
>> efl::ui::Spin::min_reached_event::description()’:
>> ../../../src/lib/elementary/efl_ui_spin.eo.hh:672:16: error:
>> ‘EFL_UI_SPIN_EVENT_MIN_REACHED’ was not declared in this scope
>>{ return EFL_UI_SPIN_EVENT_MIN_REACHED; }
>> ^
>> ../../../src/lib/elementary/efl_ui_spin.eo.hh:672:16: note: suggested
>> alternative: ‘ELM_SPI

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl_ui_spin: Add new spin and spin_button widgets

[Jean-Philippe André]

./../src/lib/elementary/efl_ui_spin.eo.hh:672:16: error:
> ‘EFL_UI_SPIN_EVENT_MIN_REACHED’ was not declared in this scope
>{ return EFL_UI_SPIN_EVENT_MIN_REACHED; }
> ^
> ../../../src/lib/elementary/efl_ui_spin.eo.hh:672:16: note: suggested
> alternative: ‘ELM_SPINNER_EVENT_MIN_REACHED’
>{ return EFL_UI_SPIN_EVENT_MIN_REACHED; }
> ^
> ELM_SPINNER_EVENT_MIN_REACHED
> ../../../src/lib/elementary/efl_ui_spin.eo.hh: In static member function
> ‘static const Efl_Event_Description*
> efl::ui::Spin::max_reached_event::description()’:
> ../../../src/lib/elementary/efl_ui_spin.eo.hh:678:16: error:
> ‘EFL_UI_SPIN_EVENT_MAX_REACHED’ was not declared in this scope
>    { return EFL_UI_SPIN_EVENT_MAX_REACHED; }
> ^
> ../../../src/lib/elementary/efl_ui_spin.eo.hh:678:16: note: suggested
> alternative: ‘ELM_SPINNER_EVENT_MAX_REACHED’
>{ return EFL_UI_SPIN_EVENT_MAX_REACHED; }
> ^
> ELM_SPINNER_EVENT_MAX_REACHED
> make[2]: *** [Makefile:5442: button_cxx_example_00.o] Error 1
> make[1]: *** [Makefile:55691: examples] Error 1
> make: *** [Makefile:3488: examples] Error 2
>
> regards
> Stefan Schmidt
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 03/05: efl: Introduce interface Efl.Dup

[Jean-Philippe André]

On Sun, Dec 3, 2017 at 3:45 AM, Andrew Williams <a...@andywilliams.me>
wrote:

> Is there anyway we could use a more descriptive name? It just seems
> unnecessarily short.
>

Absolutely. It didn't "think", and only changed the name from the method
"dup".
Cedric mentioned that to me and I think we'll rename to duplicate or
cloneable.


> Maybe that’s just me.
> Andy
> On Fri, 1 Dec 2017 at 18:50, Davide Andreoli <d...@gurumeditation.it>
> wrote:
>
> > 2017-12-01 3:12 GMT+01:00 Jean-Philippe André <j...@videolan.org>:
> >
> > > On Fri, Dec 1, 2017 at 3:49 AM, Davide Andreoli <
> d...@gurumeditation.it>
> > > wrote:
> > >
> > > > 2017-11-30 3:36 GMT+01:00 Jean-Philippe ANDRÉ <j...@videolan.org>:
> > > >
> > > > > jpeg pushed a commit to branch master.
> > > > >
> > > > > http://git.enlightenment.org/core/efl.git/commit/?id=
> > > > > bd5b76508b0b3bdc5d92f5f7db9741c100d47d3c
> > > > >
> > > > > commit bd5b76508b0b3bdc5d92f5f7db9741c100d47d3c
> > > > > Author: Jean-Philippe Andre <jp.an...@samsung.com>
> > > > > Date:   Wed Nov 29 20:03:16 2017 +0900
> > > > >
> > > > > efl: Introduce interface Efl.Dup
> > > > >
> > > > > A few classes allow their objects to be duplicated, so they
> > should
> > > > all
> > > > > use the same interface.
> > > > >
> > > > > Also, rename VG's dup to copy_from as it's not conforming to
> the
> > > > > definition of dup.
> > > > >
> > > >
> > > > Is'nt the last rename (vg_dup) an abi break ?
> > > >
> > > > python-efl apps now crash like this:
> > > > Traceback (most recent call last):
> > > >   File "/usr/bin/epymc", line 5, in 
> > > > from epymc.main import start_epymc
> > > >   File "/usr/lib/python3.6/site-packages/epymc/main.py", line 32, in
> > > > 
> > > > from efl import edje
> > > > ImportError: /usr/local/lib/libedje.so.1: undefined symbol:
> > > > evas_vg_node_dup
> > > >
> > > > A python-efl rebuild fixed the issue, this is why I think it's an abi
> > > > break.
> > > >
> > > > note that the bindings do not use/expose evas_vg in any way
> > > >
> > >
> > > I was under the impression that Evas VG was still "beta".
> > > In fact I can see EFL_BETA_API_SUPPORT.
> > >
> > > Could you double-check on your side what's happening?
> > > Where is this symbol used?
> > >
> >
> > Probably the symbol is used inside edje. PythonEFL is built with
> > EFL_BETA_API_SUPPORT on, and I think this is the source of
> > the issue
> >
> >
> > >
> > > TIA,
> > >
> > >
> > > >
> > > >
> > > >
> > > > > ---
> > > > >  src/Makefile_Efl.am   |  1 +
> > > > >  src/bin/elementary/test_events.c  | 10 +-
> > > > >  src/lib/edje/edje_calc.c  |  2 +-
> > > > >  src/lib/efl/Efl.h |  1 +
> > > > >  src/lib/efl/interfaces/efl_dup.eo | 17
> +
> > > > >  src/lib/efl/interfaces/efl_gfx_path.c |  4 ++--
> > > > >  src/lib/efl/interfaces/efl_gfx_path.eo|  3 ++-
> > > > >  src/lib/efl/interfaces/efl_gfx_shape.c| 12 +++-
> > > > >  src/lib/efl/interfaces/efl_gfx_shape.eo   | 12 +++-
> > > > >  src/lib/efl/interfaces/efl_interfaces_main.c  |  1 +
> > > > >  src/lib/evas/canvas/efl_canvas_vg.c   |  2 +-
> > > > >  src/lib/evas/canvas/efl_input_event.eo| 13 +
> > > > >  src/lib/evas/canvas/efl_input_focus.c |  2 +-
> > > > >  src/lib/evas/canvas/efl_input_focus.eo| 10 +-
> > > > >  src/lib/evas/canvas/efl_input_hold.c  |  2 +-
> > > > >  src/lib/evas/canvas/efl_input_hold.eo | 10 +-
> > > > >  src/lib/evas/canvas/efl_input_key.c   |  2 +-
> > > > >  src/lib/evas/canvas/efl_input_key.eo  | 10 +-
> > > > >  src/lib/evas/canvas/efl_input_pointer.c   |  2 +-
> > > > >  s

Re: [E-devel] [EGIT] [core/efl] master 03/05: efl: Introduce interface Efl.Dup

[Jean-Philippe André]

On Fri, Dec 1, 2017 at 3:49 AM, Davide Andreoli <d...@gurumeditation.it>
wrote:

> 2017-11-30 3:36 GMT+01:00 Jean-Philippe ANDRÉ <j...@videolan.org>:
>
> > jpeg pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=
> > bd5b76508b0b3bdc5d92f5f7db9741c100d47d3c
> >
> > commit bd5b76508b0b3bdc5d92f5f7db9741c100d47d3c
> > Author: Jean-Philippe Andre <jp.an...@samsung.com>
> > Date:   Wed Nov 29 20:03:16 2017 +0900
> >
> > efl: Introduce interface Efl.Dup
> >
> > A few classes allow their objects to be duplicated, so they should
> all
> > use the same interface.
> >
> > Also, rename VG's dup to copy_from as it's not conforming to the
> > definition of dup.
> >
>
> Is'nt the last rename (vg_dup) an abi break ?
>
> python-efl apps now crash like this:
> Traceback (most recent call last):
>   File "/usr/bin/epymc", line 5, in 
> from epymc.main import start_epymc
>   File "/usr/lib/python3.6/site-packages/epymc/main.py", line 32, in
> 
> from efl import edje
> ImportError: /usr/local/lib/libedje.so.1: undefined symbol:
> evas_vg_node_dup
>
> A python-efl rebuild fixed the issue, this is why I think it's an abi
> break.
>
> note that the bindings do not use/expose evas_vg in any way
>

I was under the impression that Evas VG was still "beta".
In fact I can see EFL_BETA_API_SUPPORT.

Could you double-check on your side what's happening?
Where is this symbol used?

TIA,


>
>
>
> > ---
> >  src/Makefile_Efl.am   |  1 +
> >  src/bin/elementary/test_events.c  | 10 +-
> >  src/lib/edje/edje_calc.c  |  2 +-
> >  src/lib/efl/Efl.h |  1 +
> >  src/lib/efl/interfaces/efl_dup.eo | 17 +
> >  src/lib/efl/interfaces/efl_gfx_path.c |  4 ++--
> >  src/lib/efl/interfaces/efl_gfx_path.eo|  3 ++-
> >  src/lib/efl/interfaces/efl_gfx_shape.c| 12 +++-
> >  src/lib/efl/interfaces/efl_gfx_shape.eo   | 12 +++-
> >  src/lib/efl/interfaces/efl_interfaces_main.c  |  1 +
> >  src/lib/evas/canvas/efl_canvas_vg.c   |  2 +-
> >  src/lib/evas/canvas/efl_input_event.eo| 13 +
> >  src/lib/evas/canvas/efl_input_focus.c |  2 +-
> >  src/lib/evas/canvas/efl_input_focus.eo| 10 +-
> >  src/lib/evas/canvas/efl_input_hold.c  |  2 +-
> >  src/lib/evas/canvas/efl_input_hold.eo | 10 +-
> >  src/lib/evas/canvas/efl_input_key.c   |  2 +-
> >  src/lib/evas/canvas/efl_input_key.eo  | 10 +-
> >  src/lib/evas/canvas/efl_input_pointer.c   |  2 +-
> >  src/lib/evas/canvas/efl_input_pointer.eo  | 10 +-
> >  src/lib/evas/canvas/efl_vg.eo |  7 ++-
> >  src/lib/evas/canvas/efl_vg_container.eo   |  2 +-
> >  src/lib/evas/canvas/efl_vg_gradient.eo|  2 +-
> >  src/lib/evas/canvas/efl_vg_gradient_linear.eo |  2 +-
> >  src/lib/evas/canvas/efl_vg_gradient_radial.eo |  2 +-
> >  src/lib/evas/canvas/efl_vg_shape.eo   |  2 +-
> >  src/lib/evas/canvas/evas_device.c |  2 +-
> >  src/lib/evas/canvas/evas_events.c | 22
> +++---
> >  src/lib/evas/canvas/evas_vg_container.c   |  6 +++---
> >  src/lib/evas/canvas/evas_vg_gradient.c|  4 ++--
> >  src/lib/evas/canvas/evas_vg_gradient_linear.c |  4 ++--
> >  src/lib/evas/canvas/evas_vg_gradient_radial.c |  4 ++--
> >  src/lib/evas/canvas/evas_vg_node.c|  4 ++--
> >  src/lib/evas/canvas/evas_vg_shape.c   | 16 
> >  src/lib/evas/vg/evas_vg_cache.c   |  2 +-
> >  35 files changed, 121 insertions(+), 86 deletions(-)
> >
> > diff --git a/src/Makefile_Efl.am b/src/Makefile_Efl.am
> > index 769abd6298..0584602894 100644
> > --- a/src/Makefile_Efl.am
> > +++ b/src/Makefile_Efl.am
> > @@ -16,6 +16,7 @@ efl_eolian_files = \
> >lib/efl/interfaces/efl_canvas.eo \
> >lib/efl/interfaces/efl_config.eo \
> >lib/efl/interfaces/efl_control.eo \
> > +  lib/efl/interfaces/efl_dup.eo \
> >lib/efl/interfaces/efl_file.eo \
> >lib/efl/interfaces/efl_image_load.eo \
> >lib/efl/interfaces/efl_part.eo \
> > diff --git a/src/bin/elementary/test_events.c b/src/bin/elementary/test_
> > events.c
> > index c6a3ca5a0e..30831e8329 100644
> > --- a/src/bin/elementary/test_events.c
> >

Re: [E-devel] Git Feature/ Proposal

[Jean-Philippe André]

Hi,

Patches pushed to a feature branch should not close the opened revisions or
tickets on phab, only mention the commit ids.

Not sure who can make sure of this?

Thanks,


On Thu, Nov 23, 2017 at 7:52 AM, Simon Lees <sfl...@suse.de> wrote:

>
>
> On 22/11/17 18:42, Andrew Williams wrote:
> > Can we instead ask people to pull master into their branch before asking
> > for review / merging it up to master? That’s pretty common practice - in
> > fact for a long lived branch I would expect that to happen on a regular
> > basis.
> >
> > Andy
>
> Yeah I presumed this would be a minimal expectation of any review, I
> guess it should be explicitly documented somewhere.
>
> > On Wed, 22 Nov 2017 at 02:56, Jean-Philippe André <j...@videolan.org>
> wrote:
> >
> >> My problem is that those branches won't be in sync with master.
> >> This will lead to merge conflicts. I am these days reviewing a lot of
> work
> >> done in dev branches or phab patches and it almost never applies nicely
> on
> >> master, because the interfaces change.
> >> A lot of work is done in branches (model, c#, eo widgets, ...) and those
> >> tasks are both long term and involve more than a single dev. They
> require
> >> constant rebasing on master or the final rebase will be a nightmare.
> Right
> >> now this is done by people pulling other devs branches, and then
> rebasing
> >> onto master in their own dev branch.
> >>
> >> Rewriting history on a shared branch has major downsides too. No problem
> >> for dev branches as there's only one committer, but anyone pulling a
> >> rewritten history will endure pain.
> >>
> >> Honestly I don't have a solution.
> >>
> >> It's a move in the right direction, but I'm not sure it's solving the
> >> problems I'm facing :(
> >>
> >>
> >>
> >> 2017-11-22 3:43 GMT+09:00 Tom Hacohen <t...@stosb.com>:
> >>
> >>> Only problem would be the commit emails being resent (because
> >>> technically they are new commits). One can mitigate that by first
> >>> pushing them to a dev branch. Commits there have first been there
> >>> don't trigger emails.
> >>>
> >>> On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
> >>> <michael.blumenkra...@gmail.com> wrote:
> >>>> In the issue where a significant rebase against master is necessary
> >> then
> >>>> it's trivial enough to either push to a new feature branch or delete
> >> and
> >>>> re-create the existing branch.
> >>>>
> >>>> On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen <t...@stosb.com> wrote:
> >>>>
> >>>>> As Mike said, the rebase/sync to master is being done locally before
> >>>>> the merge. If you are talking about keeping this branch in sync with
> >>>>> master constantly while developing, yes it's a problem. But I guess
> >>>>> it's not intended for long term features.
> >>>>>
> >>>>> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
> >>>>> <michael.blumenkra...@gmail.com> wrote:
> >>>>>> I don't see a difference in the merge process? A feature branch
> >>> should be
> >>>>>> treated exactly the same as master; the only difference is that
> >> it's a
> >>>>>> branch which people must specifically pull in order to use instead
> >> of
> >>>>> being
> >>>>>> master.
> >>>>>>
> >>>>>> When merging, you can either do a regular rebase/merge as in the git
> >>>>>> practices documentation or you can choose to rebase/squash on the
> >>>>> branched
> >>>>>> commits prior to pushing the merge. There is no rewriting within the
> >>>>>> branch, but you can still rewrite anything which has not been pushed
> >>> to
> >>>>>> master just prior to pushing it to master.
> >>>>>>
> >>>>>> On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
> >>> j...@videolan.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hey,
> >>>>>>>
> >>>>>>> If we can't rewrite history on those branches (rebase and push -f),
> >>> how
> >>>>>>> should we proceed w

Re: [E-devel] [EGIT] [core/efl] master 01/01: elm_code: Reload grid colours on theme change

[Jean-Philippe André]

Hi Andy,

On Tue, Nov 28, 2017 at 6:23 AM, Andy Williams  wrote:

> ajwillia-ms pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=
> d43fe6c16fd763215e2741b37baa8df913f151c0
>
> commit d43fe6c16fd763215e2741b37baa8df913f151c0
> Author: Andy Williams 
> Date:   Mon Nov 27 21:23:11 2017 +
>
> elm_code: Reload grid colours on theme change
> ---
>  src/lib/elementary/elm_code_widget.c  | 34 +++---
> 
>  src/lib/elementary/elm_code_widget.eo |  1 +
>  2 files changed, 28 insertions(+), 7 deletions(-)
>
> diff --git a/src/lib/elementary/elm_code_widget.c
> b/src/lib/elementary/elm_code_widget.c
> index e61aa6afea..774e763c78 100644
> --- a/src/lib/elementary/elm_code_widget.c
> +++ b/src/lib/elementary/elm_code_widget.c
> @@ -1874,7 +1874,7 @@ _elm_code_widget_ensure_n_grid_rows(Elm_Code_Widget
> *widget, int rows)
>  evas_object_size_hint_weight_set(grid, EVAS_HINT_EXPAND, 0.0);
>  evas_object_size_hint_align_set(grid, EVAS_HINT_FILL, 0.0);
>  evas_object_show(grid);
> -_elm_code_widget_setup_palette(grid,
> efl_parent_get(pd->scroller));
> +_elm_code_widget_setup_palette(grid, widget);
>
>  elm_box_pack_end(pd->gridbox, grid);
>  pd->grids = eina_list_append(pd->grids, grid);
> @@ -2192,13 +2192,35 @@ _elm_code_widget_cursor_position_get(Eo *obj
> EINA_UNUSED, Elm_Code_Widget_Data *
> *col = pd->cursor_col;
>  }
>
> +EOLIAN static Efl_Ui_Theme_Apply
> +_elm_code_widget_elm_widget_theme_apply(Eo *obj, Elm_Code_Widget_Data
> *pd)
> +{
> +   Eo *edje;
> +   int r, g, b, a;
> +   unsigned int i;
> +   Evas_Object *grid, *background;
> +
> +   edje = elm_layout_edje_get(obj);
> +   edje_object_color_class_get(edje, "elm/code/status/default", , ,
> , ,
> +   NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL);
> +
> +   background = elm_object_part_content_get(pd->scroller,
> "elm.swallow.background");
> +   evas_object_color_set(background, r, g, b, a);
> +
> +   for (i = 0; i < eina_list_count(pd->grids); i++)
> + {
> +grid = eina_list_nth(pd->grids, i);
> +_elm_code_widget_setup_palette(grid, obj);
> + }
> +
> +   return EFL_UI_THEME_APPLY_SUCCESS;
> +}
>

I don't see any call to efl_super() so I wonder how the new edje is
supposed to be loaded?
You may want to refer to _efl_ui_button_elm_widget_theme_apply() for
instance.

Best regards,
--
JP
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Theme for EO widgets

[Jean-Philippe André]

On Tue, Nov 28, 2017 at 1:04 PM, Simon Lees <sfl...@suse.de> wrote:

>
>
> On 28/11/17 13:45, Jean-Philippe André wrote:
> > Hello all,
> >
> >
> > I have some terrible news to announce here.
> >
> >
> > In order to alter the behavior and fix oddities in the theme (eg. "left"
> > part for the upper side of a panes widget), add the necessary new
> features
> > (eg. "background" swallows and color classes), and remove unwanted things
> > (ActionSlider, anyone? ^^), we need to branch off the theme for EO
> widgets
> > into a separate category. Eventually this should become the only default
> > theme for EFL 2.0 and could be a separate EDJ file soon.
> >
> > Here are some of the points we're trying to address with this new theme:
> >
> > - simpler naming for groups (eg. "efl/button" for the base group for the
> > default style of a button). This should have benefits both for
> performance
> > (shorter strings, less memory stress) and readability
> >
> > - use color classes / text classes / size classes everywhere possible
> (also
> > with simple names and inheritance, if we manage to find a proper solution
> > in edje)
> >
> > - add "background" swallow in most widgets that could have a nice custom
> > background (eg. a button, frame, etc...). See also 3c47a4f9f9ef77 (can
> and
> > should be improved further).
> >
> > - more consistent part names, they should match 1:1 with the part names
> in
> > EO files. There are exceptions were "virtual" parts are used in EO (i.e.
> > the part is not a real object) or if those parts are sub objects manually
> > managed by the widget. Real parts should be marked as "required: 1" in
> EDC.
> >
> > - more consistent signal names, including a clear definition of "action"
> > and "state" changes.
> >
> >
> > The downsides to this tough decision are quite obvious:
> >
> > - More theme work to do for custom themes (unless you only care about EO
> or
> > only about legacy)
> >
> > - Less testing of the new theme (same as when introducing new classes)
> >
> > - It's a crazy amount of work to make sure everything is consistent and
> > complete.
> >
> >
> > I'll be merging a patch introducing this new theme very shortly. See
> D5473.
> >
> >
> > I really wish there was a better solution but we couldn't find another
> way
> > that doesn't break the existing theme API (which would be totally
> > unacceptable).
> >
> >
> > Best regards,
> >
>
> Before you merge this patch can you make sure elementary_test is capable
> of testing all the parts of "Legacy" and "EO" themes, otherwise as theme
> authors we are not able to test and create these theme parts properly.
>
> I know that if the theme gets pushed first elm test will get forgotten :-)


Yes indeed.
The legacy theme won't be touched, that's the whole idea. So in theory
there shouldn't be new bugs. In theory ;-)

As for the EO theme, it does indeed require extensive testing in
elementary_test. New widgets should get a new theme (copy & paste from the
legacy one, then adapt to make a clean API).
This is also why I've added the distinction in elm_test between legacy and
EO.

I'll try and make sure proper test cases are added.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Theme for EO widgets

[Jean-Philippe André]

Hello all,


I have some terrible news to announce here.


In order to alter the behavior and fix oddities in the theme (eg. "left"
part for the upper side of a panes widget), add the necessary new features
(eg. "background" swallows and color classes), and remove unwanted things
(ActionSlider, anyone? ^^), we need to branch off the theme for EO widgets
into a separate category. Eventually this should become the only default
theme for EFL 2.0 and could be a separate EDJ file soon.

Here are some of the points we're trying to address with this new theme:

- simpler naming for groups (eg. "efl/button" for the base group for the
default style of a button). This should have benefits both for performance
(shorter strings, less memory stress) and readability

- use color classes / text classes / size classes everywhere possible (also
with simple names and inheritance, if we manage to find a proper solution
in edje)

- add "background" swallow in most widgets that could have a nice custom
background (eg. a button, frame, etc...). See also 3c47a4f9f9ef77 (can and
should be improved further).

- more consistent part names, they should match 1:1 with the part names in
EO files. There are exceptions were "virtual" parts are used in EO (i.e.
the part is not a real object) or if those parts are sub objects manually
managed by the widget. Real parts should be marked as "required: 1" in EDC.

- more consistent signal names, including a clear definition of "action"
and "state" changes.


The downsides to this tough decision are quite obvious:

- More theme work to do for custom themes (unless you only care about EO or
only about legacy)

- Less testing of the new theme (same as when introducing new classes)

- It's a crazy amount of work to make sure everything is consistent and
complete.


I'll be merging a patch introducing this new theme very shortly. See D5473.


I really wish there was a better solution but we couldn't find another way
that doesn't break the existing theme API (which would be totally
unacceptable).


Best regards,

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Efl.Ui.Panes

[Jean-Philippe André]

Amitesh, please fix it!

On Mon, Nov 27, 2017 at 8:49 PM, Andrew Williams <a...@andywilliams.me>
wrote:

> Hi,
>
> I have looked further and cannot find any evidence of efl.ui.panes in our
> theme.
> Can someone help me here? Am I missing something or is the elm_panes
> interface replacement completely nonfunctional?
>

Not sure what went wrong, but this shall be fixed shortly.
Unless we manage to break it more :)


> Thanks,
> Andy
>
> On Fri, 24 Nov 2017 at 21:11 Andrew Williams <a...@andywilliams.me> wrote:
>
> > Hi Amitesh,
> >
> > Thanks for that. Any idea why it does not pack correctly? Is that part of
> > the theme missing? (I searched for “first” but could not find anything).
> >
> > Thanks,
> > Andy
> > On Fri, 24 Nov 2017 at 18:32, Amitesh Singh <singh.amit...@gmail.com>
> > wrote:
> >
> >> Hello Andy,
> >>
> >> On Fri, Nov 24, 2017 at 3:58 PM, Andrew Williams <a...@andywilliams.me>
> >> wrote:
> >>
> >> > The example code uses "first" and "second" as the names of the panes
> but
> >> > the theme seems to use "left" and "right". Changing to those, however,
> >> does
> >> > not seem to fix the issue so I must still be missing something.
> >> >
> >> >
> >> Indeed, The new theme for Efl.Ui.Panes will have first and second  part
> >> names.
> >> alias naming is now applicable to legacy widgets only.
> >>
> >> Thanks,
> >> > Andy
> >> >
> >> > On Fri, 24 Nov 2017 at 13:46 Andrew Williams <a...@andywilliams.me>
> >> wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > Does anyone know what might be wrong with Efl.Ui.Panes example (from
> >> > > elementary_test) on my system?... All I see is this:
> >> > >
> >> > > [image: e-5a1821040c3483.94547659.png]
> >> > > --
> >> > > http://andywilliams.me
> >> > > http://ajwillia.ms
> >> > >
> >> > --
> >> > http://andywilliams.me
> >> > http://ajwillia.ms
> >> >
> >> > 
> >> > --
> >> > Check out the vibrant tech community on one of the world's most
> >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> > ___
> >> > enlightenment-devel mailing list
> >> > enlightenment-devel@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >
> >> >
> >>
> >> 
> --
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> > --
> > http://andywilliams.me
> > http://ajwillia.ms
> >
> --
> http://andywilliams.me
> http://ajwillia.ms
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 07/12: ecore_con: quiet 2 "clobbered" warnings in ecore_con

[Jean-Philippe André]

On Sun, Nov 26, 2017 at 9:25 PM, Gustavo Sverzut Barbieri <
barbi...@gmail.com> wrote:

> On Thu, Nov 23, 2017 at 9:58 PM, Pawel Aksiutowicz
> <p.aksiuto...@partner.samsung.com> wrote:
> > ecore_con: quiet 2 "clobbered" warnings in ecore_con
> ...
> > -   uint8_t user_len = user ? strlen(user) : 0;
> > -   uint8_t pass_len = pass ? strlen(pass) : 0;
> > +   volatile uint8_t user_len = user ? strlen(user) : 0;
> > +   volatile uint8_t pass_len = pass ? strlen(pass) : 0;
>
> what? someone care to explain why adding "volatile" here quites
> clobbered... what was clobbered? it makes no sense to me to add these
> volatile :-S
>
>
When compiling with GCC -Ofast with we get this kind of errors:

/home/jpeg/e/core/optimized-efl/src/lib/ecore_con/ecore_con.c: In function
‘_efl_net_ip_connect_async_run_socks4a’:
/home/jpeg/e/core/optimized-efl/src/lib/ecore_con/ecore_con.c:1247:16:
warning: variable ‘proxy_user’ might be clobbered by ‘longjmp’ or ‘vfork’
[-Wclobbered]
const char *proxy_user, *proxy_pass, *proxy_host, *proxy_port;
^~

I know that volatile prevents this kind of warning. That's all I know
though, I don't quite understand the exact meaning of the warning nor do I
find longjmp or vfork in that code.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] ecore main loop -> efl_loop full convert

[Jean-Philippe André]

ve.
> >promise = eina_promise_new(...);
> >future = efl_future_then(loop, eina_future_new(promise)); // use
> > efl variant to auto-delete future if loop dies!
> >loop->receivers[event_class].append(promise);
> >return future;
>
> i dislike this for reasons above. the promises are really the domain of the
> "action" to create and handle. the event queue is just s pub/sub bus.
> one-off's
> are what jobs are for. we already have efl_loop_job's for just this and
> they
> are promises/futures. they need some deferring/event queue mechanism to
> live on
> top of. they currently depend on the legacy ecore jobs which depend on
> the legacy event queue. that is the thing i need to replace. i consider
> jobs
> (one-off events) a solved problem other than replacing the use of of the
> legacy
> ecore event and job api's inside the code. :)
>
> >// efl_loop_broadcast()
> >event_class = efl_class_get(event);
> >foreach promise of loop->receivers[event_class] {
> >   eina_promise_resolve(promise, eina_value_object_init(event)); //
> > auto-refs!
> >}
> >loop->receivers[event_class].clear(); // empty array. recurring
> > will re_schedule
> >
> >
> >
> >// efl_loop_receiver_add()
> >future = efl_loop_receive_once(...); // use same core
> >
> >// keep info to re-schedule and "del" (unregister)
> >ctx = alloc({ .event_class = event_class, .cb = cb, .data = data });
> >loop->receivers.append(ctx); // or loop->receivers[event_class].
> append
> > (ctx);
> >
> >future2 = eina_future_then(future, re_schedule, ctx); // future
> > chain that auto re-schedules and calls user
> >ctx->future = future2;
> >
> >
> >   // efl_loop_receiver_del()
> >   foreach ctx of loop->receivers {  // or loop->receivers[event_class]
> >  if (ctx->event_class == event_class && ctx->cb == cb && ctx->data
> > == data) {
> > efl_future_cancel(ctx->future);
> > loop->receivers.remove(ctx);
> > free(ctx);
> > return true;
> >  }
> >   }
> >   return false; // not found
> >
> >
> > Advantages:
> >
> >   - very simple to implement, basically invert Promise/Future <->
> > Ecore_Event handling in existing main loop;
> >
> >  - Job is natively handled (since it's a promise/future in the new api);
> >
> >  - single shot events are the core, very easy to manage
> >
> >  - recurring events are done on top of single shot, adds one more cb,
> > but no big deal in performance (if it's, just reverse the structures)
> >
> >  - events as proper Eo objects: give us many possibilities without
> > need to implement extras, like references, methods (getters, protected
> > setters)...
> >
> > I'd not go with Eina_Value as events. It could be done, would work
> > exactly the same but offers less flexibility (needs copy intead of ref
> > count, no way to protect members). But if Eo is considered too heavy
> > or cumbersome, it could be used. (cumbersome: remember eolian should
> > help!)
> >
> > For Eina_Value_Type, special care would be needed for structures...
> > I'm not expecting users to create new Eina_Value_Type for each event,
> > rather just use EINA_VALUE_TYPE_STRUCT or similar. In these cases,
> > "subtype" is needed, that describes the structure itself (it can be
> > used as event_class). Or impose it's always a structure and in this
> > case pass the Eina_Value_Struct_Desc instead of Eina_Value_Type as
> > "event_class".
>
> eina value might be another option for the event object to be posted, but i
> kind of leaned to the heavier eo objects... because i know it's what we do
> for
> input events already and it can be optimized as above to be less costly.
>
> > On Wed, Nov 22, 2017 at 5:38 AM, Jean-Philippe André <j...@videolan.org>
> > wrote:
> > > Hi,
> > >
> > > I talked to raster for clarification.
> > >
> > > 2017-11-22 14:57 GMT+09:00 Carsten Haitzler <ras...@rasterman.com>:
> > >
> > >> So we had a partly done move to efl_loop. it still was all built on
> top of
> > >> the
> > >> main loop globals. If this is all done right then we can have multiple
> > >> loops
> > >> (e.g. one per thread) and that is a good thing.
> > >>
> > >> So I've been fixing that. I've done just about all the globals in
> ecore
>

[E-devel] C++ bindings

[Jean-Philippe André]

Hey guys,

I've recently been playing with our C++ bindings, trying to make them
easier to use and more complete. I managed to implement function pointer
support and a few other things.

But I'd like to know if we have people here who are well knowledgeable
about modern C++ (basically C++11 and later) who'd be able to review my
code or guide me? Or even work with me? :) Felipe is quite busy at the
moment, I reckon.

Since we're a C and python community mostly, I wonder who else is
interested in C++.

I'm doing this work in a great part to exert our EO interfaces and try to
spot the missing bits (the bindings are in tree and I know roughly how much
they cover).

TIA,
JP
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] ecore main loop -> efl_loop full convert

[Jean-Philippe André]

Hi,

I talked to raster for clarification.

2017-11-22 14:57 GMT+09:00 Carsten Haitzler <ras...@rasterman.com>:

> So we had a partly done move to efl_loop. it still was all built on top of
> the
> main loop globals. If this is all done right then we can have multiple
> loops
> (e.g. one per thread) and that is a good thing.
>
> So I've been fixing that. I've done just about all the globals in ecore
> EXCEPT
> ecore events. I now have to think about how to do this in eo/interfaces
> with
> efl loop objects and so on. I'm mulling how to do it.
>
> We still have some need for a deferred event bus/queue. A lot of things
> that
> are ecore events should be callbacks on objects directly and that's being
> fixed, but an event queue + types is still needed.
>
> So there are a few aspects to this.
>
> 1. Creating of new event types at runtime (and allocating a unique
> identifier
> for them).
> 2. Being able to submit them to a queue to be "processed later"
> 3. Being able to call callbacks that are listening for that type of event
> and
> hand them the deferred event data.
>
> This is used as the backing for ecore_jobs and pretty much every i/o thing
> (input events, i/o and more) as well as in-process custom event bus+events.
>
> My current thought is this.
>
> 1. event types are still ints with a single global shared backing table of
> all
> event types (allocated once ever much like atoms in x).
> 2. event event is an eo object on the queue (of some type).
> 3. some event object "factory" on the loop that creates and "deletes"
> (caches
> then) these event objects for recycling.
>
> Does anyone have better ideas? I considered the event type being an object
> itself and also doubling as a factory per event type but due to multiple
> threads you'd probably be creating an object then per thread per event
> type and
> I do not like that.



Basically we have two base EO types:

 - "ecore event type" EO class:
singleton per loop, it's a handle
you can request the loop for the handle  given the UUID
contains the read-only UUID, maybe a string description, and an EO event
"received" or whatever
created and managed by the Efl.Loop (each Loop would need to create their
own handles)
listeners add an EO callback for "received" to that handle, this keeps the
listeners list per loop
the loop has a special function to send an event

 - "ecore event info" EO class:
an ecore event that carries no info could even use null
event info is a base class with a link to its type
the loop creates and manages these temporary objects as events are being
processed


This is consistent with input events (info type are EO objects with a
common base class).
I see no major issue with this design, besides extra memory requirements.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo API docs: Large inheritance content

[Jean-Philippe André]

Hi,

2017-11-22 9:14 GMT+09:00 Carsten Haitzler <ras...@rasterman.com>:

> On Tue, 21 Nov 2017 16:57:18 + Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi team,
> >
> > Looking at some of our larger inheritance trees, such as
> > https://www.enlightenment.org/develop/api/class/efl/ui/clock , may
> provide
> > only 8 members but the page runs to hundreds of items - a complete bed
> time
> > read in itself. I think for the sanity of our readers it would be good to
> > list the members it inherits in short hand. Like the somewhat
> standardised
> > JavaDoc output -
> > https://docs.oracle.com/javase/7/docs/api/java/io/
> OutputStreamWriter.html
> >
> > Additionally the complete heirarchy tree at the top of each page takes a
> > lot of space and repeats a lot - it would make sense to flatten this to a
> > list.
>
> I like the tree at the top... It does contain very useful information of
> where the class comes from in the scheme of things. Why not use a foldable
> section? Expand it if you want the tree, otherwise stay collapsed?
>
> Same for all of the inherited methods/properties etc. - put them all in
> foldable sections you expand?
>

The tree view in our doc pages has some issues indeed. It repeats the same
classes multiple times (multiple inheritance leading to that), like
Efl.Object on the page Andy mentioned.
I think it would be acceptable to separate between direct inheritance and
interfaces, like in JavaDoc? Not sure where mixins would go, maybe in a
special category as well.

In JavaDoc, QtDoc and all, we also find usually a summary of the methods,
and the inherited methods, with links to the full description.
We already have this separation (full doc for edit_mode is under its own
page:
https://www.enlightenment.org/develop/api/class/efl/ui/clock/property/edit_mode)
but the view is probably not condensed enough. Basically the table view in
"Method Summary" is good but could be better if left side as the method
name (+get/set), right side the brief description and maybe a
pseudo-language signature, if that's possible.

PS: The inheritance graph picture should not be generated with a max size,
as it becomes unreadable.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Git Feature/ Proposal

[Jean-Philippe André]

My problem is that those branches won't be in sync with master.
This will lead to merge conflicts. I am these days reviewing a lot of work
done in dev branches or phab patches and it almost never applies nicely on
master, because the interfaces change.
A lot of work is done in branches (model, c#, eo widgets, ...) and those
tasks are both long term and involve more than a single dev. They require
constant rebasing on master or the final rebase will be a nightmare. Right
now this is done by people pulling other devs branches, and then rebasing
onto master in their own dev branch.

Rewriting history on a shared branch has major downsides too. No problem
for dev branches as there's only one committer, but anyone pulling a
rewritten history will endure pain.

Honestly I don't have a solution.

It's a move in the right direction, but I'm not sure it's solving the
problems I'm facing :(



2017-11-22 3:43 GMT+09:00 Tom Hacohen <t...@stosb.com>:

> Only problem would be the commit emails being resent (because
> technically they are new commits). One can mitigate that by first
> pushing them to a dev branch. Commits there have first been there
> don't trigger emails.
>
> On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
> <michael.blumenkra...@gmail.com> wrote:
> > In the issue where a significant rebase against master is necessary then
> > it's trivial enough to either push to a new feature branch or delete and
> > re-create the existing branch.
> >
> > On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen <t...@stosb.com> wrote:
> >
> >> As Mike said, the rebase/sync to master is being done locally before
> >> the merge. If you are talking about keeping this branch in sync with
> >> master constantly while developing, yes it's a problem. But I guess
> >> it's not intended for long term features.
> >>
> >> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
> >> <michael.blumenkra...@gmail.com> wrote:
> >> > I don't see a difference in the merge process? A feature branch
> should be
> >> > treated exactly the same as master; the only difference is that it's a
> >> > branch which people must specifically pull in order to use instead of
> >> being
> >> > master.
> >> >
> >> > When merging, you can either do a regular rebase/merge as in the git
> >> > practices documentation or you can choose to rebase/squash on the
> >> branched
> >> > commits prior to pushing the merge. There is no rewriting within the
> >> > branch, but you can still rewrite anything which has not been pushed
> to
> >> > master just prior to pushing it to master.
> >> >
> >> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
> j...@videolan.org>
> >> > wrote:
> >> >
> >> >> Hey,
> >> >>
> >> >> If we can't rewrite history on those branches (rebase and push -f),
> how
> >> >> should we proceed with the merge to/from master?
> >> >> Usually when we merge a branch to master, we rebase it on top of
> master
> >> >> first and then rebase. That's how our history remains linear and
> simple.
> >> >>
> >> >> What's the idea here? I wonder.
> >> >>
> >> >> Thanks for implementing this btw,
> >> >>
> >> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen <t...@stosb.com>:
> >> >>
> >> >> > I'm not sure about jenkins, that's Stefan's role.
> >> >> >
> >> >> > Anyhow, pushed the changes according to the wiki. Please consider
> >> >> > especially mentioning probies when you say "everyone can push to".
> >> >> >
> >> >> > --
> >> >> > Tom.
> >> >> >
> >> >> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
> >> >> > <michael.blumenkra...@gmail.com> wrote:
> >> >> > > I've added all the necessary info to the documentation at
> >> >> > >
> >> >>
> >> https://www.enlightenment.org/contrib/devs/git-guide.md#
> Feature_Branches
> >> >> > >
> >> >> > > If the jenkins concept is not possible then feel free to remove,
> but
> >> >> the
> >> >> > > rest should be in line with what we want.
> >> >> > >
> >> >> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen <t...@stosb.com>
> wrote:
> >> >> > >
> >> >> > 

Re: [E-devel] Git Feature/ Proposal

[Jean-Philippe André]

t; which scrapes the archive of
> this
> >> >> > mailing
> >> >> > >> list and then crashes the session of anyone who replies to this
> >> thread,
> >> >> > we
> >> >> > >> might jointly create a branch named "feature/discussion_helper"
> >> and push
> >> >> > >> commits to it.
> >> >> > >>
> >> >> > >> A key point of this proposal would be that the feature/ branches
> >> must
> >> >> > >> trigger mails to the mailing list just like stable branches.
> This
> >> would
> >> >> > >> increase visibility for feature branches as well as promote
> further
> >> >> > >> collaboration even from those who are not directly involved in
> >> creating
> >> >> > the
> >> >> > >> feature. The initial feature development could be done in a dev/
> >> branch,
> >> >> > >> and then it could later move to a feature/ branch once it has
> >> >> > progressed to
> >> >> > >> the point where it is ready for public visibility and increased
> >> >> > >> collaboration.
> >> >> > >>
> >> >> > >> Lastly, feature branches would not be required use, just
> >> encouraged.
> >> >> > This
> >> >> > >> allows people to continue the current EFL standard of always
> >> committing
> >> >> > >> only to master without any prior testing or branching, the need
> for
> >> >> > which
> >> >> > >> has defeated other proposals which would prevent such action.
> >> >> > >>
> >> >> > >> I think this could yield significant improvements to the
> >> community's
> >> >> > >> overall workflow without massively changing the structure under
> >> which
> >> >> > the
> >> >> > >> everyone has been functioning.
> >> >> > >>
> >> >> > >>
> >> >> >
> >> 
> --
> >> >> > >> Check out the vibrant tech community on one of the world's most
> >> >> > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> >> > >> ___
> >> >> > >> enlightenment-devel mailing list
> >> >> > >> enlightenment-devel@lists.sourceforge.net
> >> >> > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-
> devel
> >> >> > >>
> >> >> > > --
> >> >> > > http://andywilliams.me
> >> >> > > http://ajwillia.ms
> >> >> > >
> >> >> >
> >> 
> --
> >> >> > > Check out the vibrant tech community on one of the world's most
> >> >> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> >> > > ___
> >> >> > > enlightenment-devel mailing list
> >> >> > > enlightenment-devel@lists.sourceforge.net
> >> >> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >> >
> >> >> >
> >> >> >
> >> 
> --
> >> >> > Check out the vibrant tech community on one of the world's most
> >> >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> >> > ___
> >> >> > enlightenment-devel mailing list
> >> >> > enlightenment-devel@lists.sourceforge.net
> >> >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >> >
> >> >>
> >> 
> --
> >> >> Check out the vibrant tech community on one of the world's most
> >> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> >> ___
> >> >> 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"
> --
> >> > Carsten Haitzler - ras...@rasterman.com
> >> >
> >> >
> >> >
> >> 
> --
> >> > Check out the vibrant tech community on one of the world's most
> >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> > ___
> >> > enlightenment-devel mailing list
> >> > enlightenment-devel@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> >>
> >> 
> --
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>


-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Probie proposal: Taxi2se

[Jean-Philippe André]

2017-11-10 18:59 GMT+09:00 Stefan Schmidt <ste...@osg.samsung.com>:

> Hello.
>
>
> On 11/10/2017 10:52 AM, Daniel Zaoui wrote:
> > Hey fellows
> >
> > Sorry to bring it back on the table but why do people need to request
> approbation from others regarding probie access? It is not commit access.
> We (except cedric) check the code anyway before pushing so there is no
> danger, no?
> >
> You are right. If a developer wants to give some person probie access
> there is no need to ask others before.
>
> JP simply wrote this mail to be nice and inform others I think. Maybe my
> go ahead set you on the track that it needed acknowledgments from
> others. For probies that is indeed not needed.
>

Got it. I've now added him.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo installed files issue

[Jean-Philippe André]

Hi,

2017-11-13 3:12 GMT+09:00 Daniel Zaoui <jackdani...@eyomi.org>:

> Hi guys,
>
> I have some issue concerning the parsing of the installed Eo files. It is
> now impossible to parse some of them because of the dependency on internal
> Eo files/types.
>
> A simple case is efl_ui_calendar.eo that fails during Eolian parsing
> because it references Elm.Calendar.Weekday in the comments. We have another
> case where efl_ui_text.eo imports elm_entry that is internal, leading to a
> parsing error. I am sure there are/will be other cases.
>

Calendar is a small issue, entry is a larger problem, as I see Efl.Ui.Text
still has quite a few APIs that aren't really "eo-ready" yet (item
providers, cnp, context menu in particular).


> So now, I try to understand which solution we have:
> - Don't install Eo files at all: shitty.
> - Fix the failing Eo files so they dont depend on internals.
>

Solution 2 is the only correct way here.
As far as I'm concerned, if make distcheck passes and I can build external
apps (E, terminology) there isn't much more I can do to verify install is
fine.

Maybe we should check the Eo files validity during installation, by running
> eolian_gen on the files to install. Is it do-able?
>

It would be fine for me if there was a tool to run on the installed files.
After installation is fine.
Maybe run the documentation generator?

Anyhow I'm sorry that I broke everything for you with that change. As we
discussed earlier, this had to be done, and I think now is a good time to
try and fix everything. Having errors is a good way to know what to fix :)
If you have any specific issue or a tool I can run, let me know so I can
help!

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Probie proposal: Taxi2se

[Jean-Philippe André]

Hello,

I would like to propose Sungtaek Hong aka taxi2se for probie access.

He's been working mostly on elementary features, has just a few commits in
master but recently he's been involved in some core stuff for elementary.

I would like to offer him a probie access in part because this would make
*my* life easier reviewing and merging his patches. For instance D5364 (elm
theme for eo) or D5151 (bg part for all widgets in eo) are large patches
made of multiple commits.

I also believe he is fully able to contribute well to EFL and hope that
this access would encourage him to do even more ^^

Unless there is a strong opposition, I'll add him on Monday.

Best regards,

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] It's That Time Again (tm)

[Jean-Philippe André]

Enjoy your vacation Mike, you deserve it!

2017-11-09 1:37 GMT+09:00 Mike Blumenkrantz <michael.blumenkra...@gmail.com>
:

> Occasionally I will get a mail or a message which reads something like
> this:
>
> "Don't you ever take a day off?"
>
> or:
>
> "Do you ever sleep?"
>
> The answer to both questions is yes, albeit infrequently. Some may recall
> the last time that I took a day off back in August of 2015 when I traveled
> overseas to attend an Extremely Important and Official EFL developer
> conference/wakeboarding event. Others may recall the time prior, in 2013,
> when I accidentally my whole job.
>
> Regardless, it is again an odd-numbered year and so it is again time for me
> to enter my Samsung-provided hibernation pod to re-energize myself.
>
> Effective 9 November 2017, I will be on vacation. Here is what to expect
> during this time:
>
> * No IRC availability
> * Greatly reduced phabricator monitoring
>  - Only the most important of tickets (I expect there to be few that cannot
> be resolved by reverting commits pushed after this mail has been sent) will
> be examined
> * Greatly reduced mailing list monitoring
>  - This is a joke, I do not plan to read the mailing list while on vacation
>
> I will return briefly from my recovery chamber on 20 November 2017,
> primarily to ensure that nothing of significance has occurred during the
> initial phase of this process, after which time I will resume the Vacation
> Program until approximately year-end.
>
> If anyone needs to reach me during this time for a matter which cannot be
> solved without my intervention, please send a mail to me and my handlers
> will determine whether it is urgent enough to temporarily suspend safety
> procedures so that I may respond.
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>


-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] OS X build error

[Jean-Philippe André]

The difference between my build (Linux) and OSX seems to be the presence or
not of cserve2 which lead to the inclusion of all of evas private headers,
thus LKI() was well defined (and LKD, etc... were defined multiple times).

2017-11-07 20:22 GMT+09:00 Jean-Philippe André <j...@videolan.org>:

>
>
> 2017-11-07 20:20 GMT+09:00 Carsten Haitzler <ras...@rasterman.com>:
>
>> On Tue, 07 Nov 2017 09:08:04 + Andrew Williams <a...@andywilliams.me>
>> said:
>>
>> > Hi,
>> >
>> > It got us much closer - it now fails with the following:
>> >
>> > CXXLDlib/evas/libevas.la
>> >
>> > Undefined symbols for architecture x86_64:
>> >
>> >   "_LKI", referenced from:
>> >
>> >   __evas_common_font_int_cache_init in
>> > lib_evas_libevas_la-evas_font_load.o
>> >
>> >   _evas_common_font_memory_load in lib_evas_libevas_la-evas_font_
>> load.o
>> >
>> >   _evas_common_font_load in lib_evas_libevas_la-evas_font_load.o
>> >
>> >   _evas_common_font_init in lib_evas_libevas_la-evas_font_main.o
>> >
>> > ld: symbol(s) not found for architecture x86_64
>> >
>> > clang: error: linker command failed with exit code 1 (use -v to see
>> > invocation)
>> >
>> > make[4]: *** [lib/evas/libevas.la] Error 1
>>
>> that is very odd. they are specced with
>>
>> src/lib/evas/common/evas_font.h:EAPI RGBA_Font
>> *evas_common_font_memory_load  (const char *source, const char
>> *name,
>> int size, const void *data, int data_size, Font_Rend_Flags wanted_rend,
>> Efl_Text_Font_Bitmap_Scalable bitmap_scalable);
>>
>> for example. EAPI ... should still be defined to make these visible
>> functions.
>> could EAPI be mis-defined there causing this?
>>
>>
> Nah. LKI is undefined. The evas functions reference it.
> LKI is a macro. Somehow didn't get defined, thus became a symbol.,
> I wonder why it works for us.
>
> I pushed a patch, please test.
>
>
>> >
>> > Thanks,
>> >
>> > Andy
>> >
>> > On Tue, 7 Nov 2017 at 01:48 Jean-Philippe André <j...@videolan.org>
>> wrote:
>> >
>> > > EAPI is redefined to (nothing/dllimport) after Elementary.h, so I had
>> > > introduced elm_module_helper.h to re-define EAPI for those modules.
>> > > I think that keeping EAPI defined after Elementary.h caused problems
>> on
>> > > Windows where application's EAPI were marked as dllimport instead of
>> > > dllexport (or something like that, I can't remember very well).
>> > >
>> > > Anyway I pushed a patch, let us know if this fixes the build for OSX.
>> > > Thanks!
>> > >
>> > >
>> > > 2017-11-07 5:37 GMT+09:00 Jean Guyomarc'h <jean.guyoma...@gmail.com>:
>> > >
>> > > > Hi,
>> > > >
>> > > > Eo events are generated as:
>> > > >   EWAPI const Efl_Event_Description __BLAH =
>> > > EFL_EVENT_DESCRIPTION("blah");
>> > > >
>> > > > this yields private symbols that are not exported outside of
>> > > libelementary.
>> > > > Hence link failure with elm modules...
>> > > > But I don't understand why.
>> > > >
>> > > >
>> > > > Jean
>> > > >
>> > > > On Sat, Nov 4, 2017 at 5:39 PM, Jean Guyomarc'h <
>> > > jean.guyoma...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > hi,
>> > > > >
>> > > > > i'm not at home, and cannot really help. if there is a ticket
>> open, i
>> > > may
>> > > > > have a look on  monday. is that on git master ?
>> > > > >
>> > > > > thanks
>> > > > > Jean
>> > > > >
>> > > > >
>> > > > > On Nov 4, 2017 15:03, "Carsten Haitzler" <ras...@rasterman.com>
>> wrote:
>> > > > >
>> > > > > On Sat, 04 Nov 2017 11:21:09 + Andrew Williams <
>> > > a...@andywilliams.me
>> > > > >
>> > > > > said:
>> > > > >
>> > > > > > Can anyone help with this one please?
>> > > > > >
>> > > > > >
>> > > > > > Thanks,
>> > > > > &

Re: [E-devel] OS X build error

[Jean-Philippe André]

2017-11-07 20:20 GMT+09:00 Carsten Haitzler <ras...@rasterman.com>:

> On Tue, 07 Nov 2017 09:08:04 + Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi,
> >
> > It got us much closer - it now fails with the following:
> >
> > CXXLDlib/evas/libevas.la
> >
> > Undefined symbols for architecture x86_64:
> >
> >   "_LKI", referenced from:
> >
> >   __evas_common_font_int_cache_init in
> > lib_evas_libevas_la-evas_font_load.o
> >
> >   _evas_common_font_memory_load in lib_evas_libevas_la-evas_font_
> load.o
> >
> >   _evas_common_font_load in lib_evas_libevas_la-evas_font_load.o
> >
> >   _evas_common_font_init in lib_evas_libevas_la-evas_font_main.o
> >
> > ld: symbol(s) not found for architecture x86_64
> >
> > clang: error: linker command failed with exit code 1 (use -v to see
> > invocation)
> >
> > make[4]: *** [lib/evas/libevas.la] Error 1
>
> that is very odd. they are specced with
>
> src/lib/evas/common/evas_font.h:EAPI RGBA_Font
> *evas_common_font_memory_load  (const char *source, const char
> *name,
> int size, const void *data, int data_size, Font_Rend_Flags wanted_rend,
> Efl_Text_Font_Bitmap_Scalable bitmap_scalable);
>
> for example. EAPI ... should still be defined to make these visible
> functions.
> could EAPI be mis-defined there causing this?
>
>
Nah. LKI is undefined. The evas functions reference it.
LKI is a macro. Somehow didn't get defined, thus became a symbol.,
I wonder why it works for us.

I pushed a patch, please test.


> >
> > Thanks,
> >
> > Andy
> >
> > On Tue, 7 Nov 2017 at 01:48 Jean-Philippe André <j...@videolan.org>
> wrote:
> >
> > > EAPI is redefined to (nothing/dllimport) after Elementary.h, so I had
> > > introduced elm_module_helper.h to re-define EAPI for those modules.
> > > I think that keeping EAPI defined after Elementary.h caused problems on
> > > Windows where application's EAPI were marked as dllimport instead of
> > > dllexport (or something like that, I can't remember very well).
> > >
> > > Anyway I pushed a patch, let us know if this fixes the build for OSX.
> > > Thanks!
> > >
> > >
> > > 2017-11-07 5:37 GMT+09:00 Jean Guyomarc'h <jean.guyoma...@gmail.com>:
> > >
> > > > Hi,
> > > >
> > > > Eo events are generated as:
> > > >   EWAPI const Efl_Event_Description __BLAH =
> > > EFL_EVENT_DESCRIPTION("blah");
> > > >
> > > > this yields private symbols that are not exported outside of
> > > libelementary.
> > > > Hence link failure with elm modules...
> > > > But I don't understand why.
> > > >
> > > >
> > > > Jean
> > > >
> > > > On Sat, Nov 4, 2017 at 5:39 PM, Jean Guyomarc'h <
> > > jean.guyoma...@gmail.com>
> > > > wrote:
> > > >
> > > > > hi,
> > > > >
> > > > > i'm not at home, and cannot really help. if there is a ticket
> open, i
> > > may
> > > > > have a look on  monday. is that on git master ?
> > > > >
> > > > > thanks
> > > > > Jean
> > > > >
> > > > >
> > > > > On Nov 4, 2017 15:03, "Carsten Haitzler" <ras...@rasterman.com>
> wrote:
> > > > >
> > > > > On Sat, 04 Nov 2017 11:21:09 + Andrew Williams <
> > > a...@andywilliams.me
> > > > >
> > > > > said:
> > > > >
> > > > > > Can anyone help with this one please?
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Andy
> > > > > >
> > > > > >
> > > > > >   CC
> > > > > > modules/elementary/clock_input_ctxpopup/modules_elementary_
> > > > > clock_input_ctxpopup_module_la-clock_input_ctxpopup.lo
> > > > > >
> > > > > >   CCLD modules/elementary/clock_input_ctxpopup/module.la
> > > > > >
> > > > > > Undefined symbols for architecture x86_64:
> > > > > >
> > > > > >   "__ELM_CTXPOPUP_EVENT_DISMISSED", referenced from:
> > > > > >
> > > > > >   __field_clicked_cb in
> > > > > > modules_element

Re: [E-devel] OS X build error

[Jean-Philippe André]

EAPI is redefined to (nothing/dllimport) after Elementary.h, so I had
introduced elm_module_helper.h to re-define EAPI for those modules.
I think that keeping EAPI defined after Elementary.h caused problems on
Windows where application's EAPI were marked as dllimport instead of
dllexport (or something like that, I can't remember very well).

Anyway I pushed a patch, let us know if this fixes the build for OSX.
Thanks!


2017-11-07 5:37 GMT+09:00 Jean Guyomarc'h <jean.guyoma...@gmail.com>:

> Hi,
>
> Eo events are generated as:
>   EWAPI const Efl_Event_Description __BLAH = EFL_EVENT_DESCRIPTION("blah");
>
> this yields private symbols that are not exported outside of libelementary.
> Hence link failure with elm modules...
> But I don't understand why.
>
>
> Jean
>
> On Sat, Nov 4, 2017 at 5:39 PM, Jean Guyomarc'h <jean.guyoma...@gmail.com>
> wrote:
>
> > hi,
> >
> > i'm not at home, and cannot really help. if there is a ticket open, i may
> > have a look on  monday. is that on git master ?
> >
> > thanks
> > Jean
> >
> >
> > On Nov 4, 2017 15:03, "Carsten Haitzler" <ras...@rasterman.com> wrote:
> >
> > On Sat, 04 Nov 2017 11:21:09 + Andrew Williams <a...@andywilliams.me
> >
> > said:
> >
> > > Can anyone help with this one please?
> > >
> > >
> > > Thanks,
> > >
> > > Andy
> > >
> > >
> > >   CC
> > > modules/elementary/clock_input_ctxpopup/modules_elementary_
> > clock_input_ctxpopup_module_la-clock_input_ctxpopup.lo
> > >
> > >   CCLD modules/elementary/clock_input_ctxpopup/module.la
> > >
> > > Undefined symbols for architecture x86_64:
> > >
> > >   "__ELM_CTXPOPUP_EVENT_DISMISSED", referenced from:
> > >
> > >   __field_clicked_cb in
> > > modules_elementary_clock_input_ctxpopup_module_la-
> clock_input_ctxpopup.o
> >
> > that sounds totally bizarre because the function is _field_clicked_cb:
> >
> > static void
> > _field_clicked_cb(void *data, const Efl_Event *event)
> > {
> >
> > > ld: symbol(s) not found for architecture x86_64
> > >
> > > clang: error: linker command failed with exit code 1 (use -v to see
> > > invocation)
> > >
> > > make[4]: *** [modules/elementary/clock_input_ctxpopup/module.la]
> Error 1
> > >
> > > make[3]: *** [all-recursive] Error 1
> > >
> > > make[2]: *** [all] Error 2
> > >
> > > make[1]: *** [all-recursive] Error 1
> > >
> > > make: *** [all] Error 2
> > > --
> > > http://andywilliams.me
> > > http://ajwillia.ms
> > > 
> > --
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > ___
> > > 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" --
> > Carsten Haitzler - ras...@rasterman.com
> >
> >
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> >
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>


-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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/04: elm_multibuttonentry: do not eat all the events

[Jean-Philippe André]

2017-10-27 16:15 GMT+09:00 Amitesh Singh <singh.amit...@gmail.com>:

> On Fri, Oct 27, 2017 at 3:55 PM, Amitesh Singh <singh.amit...@gmail.com>
> wrote:
>
> >
> >
> > On Wed, Oct 25, 2017 at 9:36 PM, Marcel Hollerbach <
> mar...@osg.samsung.com
> > > wrote:
> >
> >> bu5hm4n pushed a commit to branch master.
> >>
> >> http://git.enlightenment.org/core/efl.git/commit/?id=f440cc4
> >> eb6edbda0a0093df785ab1bc02ee21835
> >>
> >> commit f440cc4eb6edbda0a0093df785ab1bc02ee21835
> >> Author: Marcel Hollerbach <mar...@osg.samsung.com>
> >> Date:   Wed Oct 25 13:57:32 2017 +0200
> >>
> >> elm_multibuttonentry: do not eat all the events
> >>
> >> I have no idea why it was doing that, but that ends up eating all
> the
> >> events, not propagating them up to the parent ... If someone has a
> >> idea
> >> why it was like that, feel free to notify.
> >> ---
> >>  src/lib/elementary/efl_ui_multibuttonentry.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/lib/elementary/efl_ui_multibuttonentry.c
> >> b/src/lib/elementary/efl_ui_multibuttonentry.c
> >> index 0456532b63..b1abc2d00d 100644
> >> --- a/src/lib/elementary/efl_ui_multibuttonentry.c
> >> +++ b/src/lib/elementary/efl_ui_multibuttonentry.c
> >> @@ -984,7 +984,8 @@ _efl_ui_multibuttonentry_elm_widget_widget_event(Eo
> >> *obj EINA_UNUSED, Efl_Ui_Mul
> >> // ACCESS
> >> if (_elm_config->access_mode == ELM_ACCESS_MODE_ON) return
> EINA_FALSE;
> >>
> >> -   return EINA_TRUE;
> >> +   //lets stop eating all events
> >> +   return EINA_FALSE;
> >>  }
> >>
> >>  EOLIAN static void
> >>
> >> --
> >>
> >
> > f440cc4eb6edbda0a0093df785ab1bc02ee21835 and
> > 53fcc4bb7de3bfc9c69f6e138bc25a1f52a49744 breaks the shrink feature in
> MBE.
> > Please verify it with elm test -> multibuttonentry shrink example.
> >
> >
> Okay, so 53fcc4bb7de3bfc9c69f6e138bc25a made mbe a not focusable widget by
> default and the elm test case rely on focus property of mbe.
> so fixed it by making mbe focusable.
>

Surely there was a very good reason for Marcel to make it unfocusable.
You patch b6567ab1f6fa377f4047106bae8aa808ff033180 changes the test case.
Please revert it.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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/03: Efl.Ui.Format: implement generic format_string function

[Jean-Philippe André]

2017-10-27 11:12 GMT+09:00 Amitesh Singh <singh.amit...@gmail.com>:

> Hello,
>
>
> On Thu, Oct 26, 2017 at 9:30 PM, Gustavo Sverzut Barbieri <
> barbi...@gmail.com> wrote:
>
> > On Thu, Oct 26, 2017 at 10:12 AM, Amitesh Singh <amitesh...@samsung.com>
> > wrote:
> >
> > thanks for the improvement, but one hint I said before went unnoticed
> > and would save great deal of this implementation:
> >
> >
> > > +typedef struct
> > > +{
> > > +   const char *template;
> > > +} Efl_Ui_Format_Data;
> >
> > this is already stored in the object, due format_string_set... that's
> > why I'm saying that you should pass it to the callback, so there is no
> > need to store it again, providing a free_cb to release that.
> >
> >
> >
> > > +_default_format_cb(void *data, Eina_Strbuf *str, const Eina_Value
> value)
> >
> > here you should pass: str, value AND template :-)
> >
> >
> I don't think there is a need to pass tempate here since its least useful
> to user and its a burden for anyone to have both strbuf and template
> string.
> We got another API for passing string template.
>

Hmm I agree with Amitesh here.
If the template is given as well then the user cb is mostly useless, as the
default implementation would take care of doing the sprintf.
All that can then be done is prepend or append strings, at best.

I wonder if that wouldn't lead to more mistakes as we would then assume
what the format string is (eg. print  a double eina_value with "%i units"
for instance).


>
>
> > > +_default_format_free_cb(void *data)
> >
> > then this is not needed.
> >
> >
> >
> > > +EOLIAN static void
> > > +_efl_ui_format_format_string_set(Eo *obj, Efl_Ui_Format_Data *sd,
> > const char *template)
> > > +{
> > > +   if (!template) return;
> > > +   eina_stringshare_replace(>template, template);
> > > +   efl_ui_format_cb_set(obj, sd, _default_format_cb,
> > _default_format_free_cb);
> >
> > because here you'd not call "efl_ui_format_cb_set()"... you'd do that
> > once at the constructor/init, then the callback gets the template
> > stored by efl_ui_format_string_set().
> >
> >
> > > -elm_layout_text_set(obj, "elm.units", buf);
> > > +sd->format_cb(sd->format_cb_data, sd->format_strbuf, val);
> >
> > this is not that good. You should wrap this into a protected method
> > that implementers call, like:
> >
> > efl_ui_format(obj, strbuf, val);
> >
> > Think of bindings (ie: python/javascript/c#), they may want to call
> > the implementation of efl.ui.slider how to? you need to provide a
> > method to allow that.
>

Hmm good point. I'll think about it.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] GitFlow

[Jean-Philippe André]

t;
> > >> On Sat, Oct 21, 2017 at 4:18 PM, Andrew Williams <
> a...@andywilliams.me>
> > >> wrote:
> > >> > Hi git admins,
> > >> >
> > >> > I'm setting up gitflow on Edi but I can't push to origin because of
> the
> > >> > branch naming rules. Can you please open up the ability to have
> remote
> > >> > branches matching the patterns "develop", "feature/*", "bugfix/*",
> > >> > "release/*", "hotfix/*" and "support/*"?
> > >> >
> > >> > I'd really appreciate it thanks.
> > >> > Oh and to those who worried about "changing to develop branch is an
> > >> extra
> > >> > step" don't fear as HEAD can be pointed to develop instead of
> master if
> > >> > that's what folk are looking to have set up :)
> > >> >
> > >> > Cheers,
> > >> > Andrew
> > >> >
> > >> > --
> > >> > http://andywilliams.me
> > >> > http://ajwillia.ms
> > >> >
> > >> 
> --
> > >> > Check out the vibrant tech community on one of the world's most
> > >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > >> > ___
> > >> > enlightenment-devel mailing list
> > >> > enlightenment-devel@lists.sourceforge.net
> > >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >>
> > >>
> > >> 
> --
> > >> Check out the vibrant tech community on one of the world's most
> > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > >> ___
> > >> enlightenment-devel mailing list
> > >> enlightenment-devel@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >>
> > > --
> > > http://andywilliams.me
> > > http://ajwillia.ms
> > >
> > --
> > http://andywilliams.me
> > http://ajwillia.ms
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > 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" --
> Carsten Haitzler - ras...@rasterman.com
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>


-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 03/03: config: Simplify EO API

[Jean-Philippe André]

2017-10-20 8:15 GMT+09:00 Carsten Haitzler <ras...@rasterman.com>:

> On Thu, 19 Oct 2017 14:28:27 -0200 Gustavo Sverzut Barbieri
> <barbi...@gmail.com> said:
>
> > > + get {
> > > +keys {
> > > +   name: string; [[Configuration option name.]]
> >
> > shall we document and handle this as a path, so nested Eets can be
> > used, such as in E (wm).
>

It could be. Why not.
Then use '.' or '/' for path separator? :)

I am in fact not very happy about the value type returned, as it's @owned
(terrible in C... it WILL leak).
But returning const(any_value) is hard (lifetime of the value? lifetime of
the strings stored?).

I'm not so sure this config API is "good enough". It is indeed very very
> simple (string key to single value pair). But history tells me that this is
> very limiting. I've been here before (edb) and i hit the limits of this
> pretty
> fast. I needed SETS of things (a list of strings. a list of keybindings, a
> list
> of whatever) very quickly. I think that this should be an API which allows
> nesting and "sets" (ordered lists/array of items with the ability to
> append,
> prepend, insert and remove) and probably also "hashmaps" as well (key ->
> item
> lookup). yes. it's more complex, but at least it won't hit a wall really
> really
> fast and then we need to extend this api so it begins to look a bit ugly
> after
> extending.
>

Meh. Sets, lists, structs, etc... can all be stored in the Eina_Value.

also i'm not sure if it should also allow for fallbacks (look for val in
> config
> store X - if not there, look in Y, if not there look in Z. this is common
> for
> looking in user config first then falling back to system config ... but we
> don't
> do it value by value atm... but needing to be able to defined where those
> config stores are would be important big-picture, with probably a default
> of
> system + user).
>

This has probably very little to do with this specific interface, but would
have to do with the config backend, i.e. elm_config or any preference
module we come up with (if we ever do). Unless we want to expose options
for such feedback policy... but that can be added later.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Phab EFL ticket management

[Jean-Philippe André]

ayout
> > > > > > > >   * efl-ui
> > > > > > > > (etc etc)
> > > > > > > >
> > > > > > > > Notice the use of the new namespaces for everything in the
> > > > > interfaces -
> > > > > > > > this is surely how we should be thinking going forward :)
> > > > > > > > If we are able to split things out a bit more then we can
> have
> > > more
> > > > > > > people
> > > > > > > > assigned to projects with fewer issues per project.
> > > > > > > > Then the milestone for release can be the main point of
> concern
> > > for a
> > > > > > > > release manager :)
> > > > > > > >
> > > > > > > > I wanted to throw the concept out to the list before doing
> > > anything
> > > > > in
> > > > > > > case
> > > > > > > > there are any concerns with this approach that I may have
> missed?
> > > > > > > >
> > > > > > > > Thanks :)
> > > > > > > > Andy
> > > > > > > > --
> > > > > > > > http://andywilliams.me
> > > > > > > > http://ajwillia.ms
> > > > > > > >
> > > > > > >
> > > > >
> > > 
> --
> > > > > > > > Check out the vibrant tech community on one of the world's
> most
> > > > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > > > > > ___
> > > > > > > > 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
> > > > > > >
> > > > > > > --
> > > > > > http://andywilliams.me
> > > > > > http://ajwillia.ms
> > > > >
> > > > >
> > > > > --
> > > > > - Codito, ergo sum - "I code, therefore I am"
> > > --
> > > > > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> > > > >
> > > > > --
> > > > http://andywilliams.me
> > > > http://ajwillia.ms
> > >
> > >
> > > --
> > > - Codito, ergo sum - "I code, therefore I am"
> --
> > > Carsten Haitzler - ras...@rasterman.com
> > >
> > > --
> > http://andywilliams.me
> > http://ajwillia.ms
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>


-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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: efl intf: Add format interface

[Jean-Philippe André]

2017-10-16 21:45 GMT+09:00 Gustavo Sverzut Barbieri <barbi...@gmail.com>:

> > +function Efl.Ui.Format_Func_Cb {
> > +   [[Function pointer for format function hook]]
> > +   params {
> > +  @in str: ptr(Eina.Strbuf);
> > +  @in value: Eina.Value;
>
> I'd use const(generic_value), there is no need to use `Eina.Value`
> since it's a "native" eolian type... and you don't want to modify it,
> then saying "const" would make it clear.
>

I think it's called "any_value" now :)
Although I still see "generic_value" in some places. @q66 care to explain
why we have both of those?

Another comment: this needs doc. What is $str and why is it an @in value,
etc... (I know, but it's far from obvious here)

> +interface Efl.Ui.Format
> > +{
> > +   [[interface class for format_func]]
> > +   methods {
> > +  @property func_cb @protected {
>
> not so good name, particularly for a "Format" interface, just
> replicate the name and let eolian de-duplicate the format:
>
> Efl.Ui.Format.format_func or format_cb... should generate:
> efl_ui_format_func_set/get.
>
> also, I don't see why is this "ui" only, it's good to go into a
> broader namespace (if we do have, not sure).
>
>
>
> > +  @property unit @protected {
> > + [[Control the format string for a given units label
> > +
> > +   If $NULL is passed on $format, it will make $obj's units
> > +   area to be hidden completely. If not, it'll set the format
> > +   string for the units label's text. The units label is
> > +   provided a floating point value, so the units text is up
> display
> > +   at most one floating point value. Note that the units label
> is
> > +   optional. Use a format string such as "%1.2f meters" for
> example.
> > +
> > +   Note: The default format string is an integer percentage,
> > +   as in $"%.0f %%".
> > + ]]
>
> also dislike the name "unit", since it's "format" -- in the general
> term and gets a value... I'd not limit it to "units", meaning that's
> only to format units of a value. You may use it to format some date,
> etc.
>
> my suggestion is to change it to "format_template" or
> "format_string"... and pass that to format_cb/func as above, so you
> could change the template string and get it passed to the format
> template:
>
>   format_func(result_strbuf, format_template, value)
>

Agree with all the above comments.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Evas_Engine_Software_X11.h missing on purpose?

[Jean-Philippe André]

Hi Ross,

2017-10-15 4:26 GMT+09:00 Ross Vandegrift <r...@kallisti.us>:

> Hi all,
>
> I'm testing Debian packages that use EFL against 1.20.4, and exactimages
> fails to build because Evas_Engine_Software_X11.h is no longer installed
> by make install. [1]
>
> Probably this is a change from a long time ago - but I'm having trouble
> confirming.  Was this intentional?
>
> Thanks,
> Ross
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878572


Yes indeed this was intentional.
Those engine-specific headers exposed structures containing data that
should have been kept internal, and bind the applications to a specific
display system, which we've been trying to abstract.

Now I have to admit that I hadn't heard of exactimage before and thus
wonder why this header is required?

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL 1.20.5

[Jean-Philippe André]

2017-10-14 11:21 GMT+09:00 Christophe Sadoine <ch...@indefini.org>:

> 2017/10/14 午前3:00 "Cedric Bail" <ced...@ddlm.me>:
>
> Hello everyone,
>
> I will be making another minor release of EFL 1.20 branch sometime after
> Wednesday next week (It is likely be the only one I will do, as we should
> see Stefan back on duty next month). If you have patch or bug you would
> like to see addressed in it, please let me know in the coming days.
>
>
> hello,
> it would be nice if this could be fixed, as you cannot select text in
> entries... (is no one using them?)
>
> https://phab.enlightenment.org/T6079
> If can try to take a look if no one is.
>

That's a problem with the elementary config. I just don't know how the
value got changed to the default instead of the standard one.

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 02/02: widget: Rename focus_region (EO)

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=72f1fbf4f1eddbc1cde4455081be4f3a9b8a1a44

commit 72f1fbf4f1eddbc1cde4455081be4f3a9b8a1a44
Author: Jean-Philippe Andre 
Date:   Thu Oct 12 18:16:42 2017 +0900

widget: Rename focus_region (EO)

This region has little to do with focus, as it's more of a region of
interest within the widget, and not directly related to the highlight
geometry, for instance. It's related to focus in the sense that only
widgets with focus would really care about this region.

I decided to change this name after talking with @bu5hm4n.
Note that gengrid uses this but is also completely broken (the focus
highlight floats around and you don't even see the focused item).

Note: This is very close to show_region but I'm not sure those can be
merged safely (since the default "focus_region" is NULL while the
default "show_region" is the widget's geometry).

Ref T5363
---
 src/lib/elementary/efl_ui_text.c   |  2 +-
 src/lib/elementary/efl_ui_text.eo  |  2 +-
 src/lib/elementary/elm_entry.c |  2 +-
 src/lib/elementary/elm_entry.eo|  2 +-
 src/lib/elementary/elm_general.eot |  3 +--
 src/lib/elementary/elm_general.h   |  5 +
 src/lib/elementary/elm_gengrid.c   |  4 ++--
 src/lib/elementary/elm_gengrid.eo  |  2 +-
 src/lib/elementary/elm_panel.c |  2 +-
 src/lib/elementary/elm_panel.eo|  2 +-
 src/lib/elementary/elm_widget.c| 10 +-
 src/lib/elementary/elm_widget.eo   | 39 ++
 12 files changed, 43 insertions(+), 32 deletions(-)

diff --git a/src/lib/elementary/efl_ui_text.c b/src/lib/elementary/efl_ui_text.c
index eca513b945..a95ef7e885 100644
--- a/src/lib/elementary/efl_ui_text.c
+++ b/src/lib/elementary/efl_ui_text.c
@@ -1250,7 +1250,7 @@ _efl_ui_text_elm_widget_on_focus_update(Eo *obj, 
Efl_Ui_Text_Data *sd, Elm_Objec
 }
 
 EOLIAN static Eina_Rect
-_efl_ui_text_elm_widget_focus_region_get(Eo *obj EINA_UNUSED, Efl_Ui_Text_Data 
*sd)
+_efl_ui_text_elm_widget_interest_region_get(Eo *obj EINA_UNUSED, 
Efl_Ui_Text_Data *sd)
 {
Evas_Coord edje_x, edje_y, elm_x, elm_y;
Eina_Rect r = {};
diff --git a/src/lib/elementary/efl_ui_text.eo 
b/src/lib/elementary/efl_ui_text.eo
index fccc3598b7..354dc9c95b 100644
--- a/src/lib/elementary/efl_ui_text.eo
+++ b/src/lib/elementary/efl_ui_text.eo
@@ -361,7 +361,7 @@ class Efl.Ui.Text (Efl.Ui.Layout, Elm.Interface_Scrollable, 
Efl.Ui.Clickable,
   Elm.Widget.on_access_activate;
   Elm.Widget.theme_apply;
   Elm.Widget.on_focus_update;
-  Elm.Widget.focus_region { get; }
+  Elm.Widget.interest_region { get; }
   Elm.Widget.on_disabled_update;
   Elm.Widget.widget_sub_object_del;
   Elm.Interface_Scrollable.policy { set; }
diff --git a/src/lib/elementary/elm_entry.c b/src/lib/elementary/elm_entry.c
index 0b9c7acd1a..3808817db5 100644
--- a/src/lib/elementary/elm_entry.c
+++ b/src/lib/elementary/elm_entry.c
@@ -1308,7 +1308,7 @@ _elm_entry_elm_widget_on_focus_update(Eo *obj, 
Elm_Entry_Data *sd, Elm_Object_It
 }
 
 EOLIAN static Eina_Rect
-_elm_entry_elm_widget_focus_region_get(Eo *obj, Elm_Entry_Data *sd)
+_elm_entry_elm_widget_interest_region_get(Eo *obj, Elm_Entry_Data *sd)
 {
Evas_Coord cx, cy, cw, ch;
Evas_Coord edx, edy;
diff --git a/src/lib/elementary/elm_entry.eo b/src/lib/elementary/elm_entry.eo
index 6ca81e7381..72cca8d721 100644
--- a/src/lib/elementary/elm_entry.eo
+++ b/src/lib/elementary/elm_entry.eo
@@ -960,7 +960,7 @@ class Elm.Entry (Efl.Ui.Layout, Elm.Interface_Scrollable, 
Efl.Ui.Clickable,
   Elm.Widget.on_access_activate;
   Elm.Widget.theme_apply;
   Elm.Widget.on_focus_update;
-  Elm.Widget.focus_region { get; }
+  Elm.Widget.interest_region { get; }
   Elm.Widget.on_disabled_update;
   Elm.Widget.widget_sub_object_del;
   Elm.Interface_Scrollable.policy { set; }
diff --git a/src/lib/elementary/elm_general.eot 
b/src/lib/elementary/elm_general.eot
index 43f1dece60..f41c9fa6f9 100644
--- a/src/lib/elementary/elm_general.eot
+++ b/src/lib/elementary/elm_general.eot
@@ -141,10 +141,9 @@ enum Efl.Ui.Focus.Direction
last = 6
 }
 
-enum Elm.Focus.Region.Show_Mode
+enum Efl.Ui.Interest_Region_Mode
 {
[[Focus region show mode.]]
-   legacy: elm_focus_region_show;
widget, [[As a widget.]]
item, [[As an item.]]
 }
diff --git a/src/lib/elementary/elm_general.h b/src/lib/elementary/elm_general.h
index 8376c9fa60..d506a75e79 100644
--- a/src/lib/elementary/elm_general.h
+++ b/src/lib/elementary/elm_general.h
@@ -45,6 +45,11 @@ typedef enum
ELM_OBJECT_LAYER_LAST /**< last layer known by Elementary */
 } Elm_Object_Layer;
 
+/** How the focus region should be calculated (not related to input focus). */
+typedef Efl_Ui_Interest_Region_Mode Elm_Focus_Region_Show_Mode;
+#define ELM_FOCUS_REGION_SHOW_WIDGET EFL_UI_INTEREST_REGION_MODE_WIDGET
+#define 

[EGIT] [core/efl] master 01/02: edje_object: Mark access_part_iterate as @beta

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=19dff855194f2c4b411fc5d27b33d212ff26bcb0

commit 19dff855194f2c4b411fc5d27b33d212ff26bcb0
Author: Jean-Philippe Andre 
Date:   Thu Oct 12 16:00:42 2017 +0900

edje_object: Mark access_part_iterate as @beta

This may be internal... Not sure we need this exposed outside of the
ATSPI layer, really. Marking as beta for now.

Ref T5315
---
 src/lib/edje/edje_object.eo | 2 +-
 src/lib/edje/edje_private.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/lib/edje/edje_object.eo b/src/lib/edje/edje_object.eo
index 104928ce85..a2124200f5 100644
--- a/src/lib/edje/edje_object.eo
+++ b/src/lib/edje/edje_object.eo
@@ -316,7 +316,7 @@ class Edje.Object (Efl.Canvas.Group, Efl.File, 
Efl.Container, Efl.Part,
   }
   /* CLASS APIS END  */
 
-  access_part_iterate {
+  access_part_iterate @beta {
  [[Iterates over all accessibility-enabled part names.]]
  legacy: null;
  return: iterator @owned; [[Part name iterator]]
diff --git a/src/lib/edje/edje_private.h b/src/lib/edje/edje_private.h
index b2610ee7aa..90e248922d 100644
--- a/src/lib/edje/edje_private.h
+++ b/src/lib/edje/edje_private.h
@@ -39,6 +39,7 @@
 # include 
 #endif
 
+#define EDJE_OBJECT_BETA
 #define EFL_CANVAS_OBJECT_PROTECTED
 #define EFL_CANVAS_LAYOUT_CALC_PROTECTED
 

-- 

[EGIT] [core/efl] master 02/03: evas: Implement support for different H/V font DPI

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=ca581e00baea8d8f714fdc4850dd77898db5a80b

commit ca581e00baea8d8f714fdc4850dd77898db5a80b
Author: Jean-Philippe Andre 
Date:   Thu Oct 12 15:15:34 2017 +0900

evas: Implement support for different H/V font DPI

This is modifying how a rarely used environment variable that sets the
DPI used for font sizing is parsed. The previous form remains valid, of
course. Note that EFL tends to use "scaling" instead of this DPI. The
font DPI is useful for me to open up a terminology window with almost
the same size as my IDE's code viewer.

Use case:

  export EVAS_FONT_DPI=95x94 terminology

Note:
I still don't get a 1:1 match with Qt's rendering, and in fact
94x95 works better than what 95x94 (which is reported by xdpyinfo).
Interesting though :)

@feature
---
 src/lib/evas/common/evas_font.h  |  2 +-
 src/lib/evas/common/evas_font_load.c | 19 +++
 src/lib/evas/common/evas_font_main.c |  7 +--
 3 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/src/lib/evas/common/evas_font.h b/src/lib/evas/common/evas_font.h
index b50b68d530..132b474e2f 100644
--- a/src/lib/evas/common/evas_font.h
+++ b/src/lib/evas/common/evas_font.h
@@ -39,7 +39,7 @@ EAPI void  evas_common_font_draw_do(const 
Cutout_Rects *reuse, const
 EAPI Eina_Bool evas_common_font_draw_prepare_cutout(Cutout_Rects 
**reuse, RGBA_Image *dst, RGBA_Draw_Context *dc, RGBA_Gfx_Func *func);
 
 /* load */
-EAPI void  evas_common_font_dpi_set  (int dpi);
+EAPI void  evas_common_font_dpi_set  (int dpi_h, int 
dpi_v);
 EAPI RGBA_Font_Source *evas_common_font_source_memory_load   (const char 
*name, const void *data, int data_size);
 EAPI RGBA_Font_Source *evas_common_font_source_load  (const char 
*name);
 EAPI int   evas_common_font_source_load_complete (RGBA_Font_Source 
*fs);
diff --git a/src/lib/evas/common/evas_font_load.c 
b/src/lib/evas/common/evas_font_load.c
index f568fa718a..dfe94e9fb1 100644
--- a/src/lib/evas/common/evas_font_load.c
+++ b/src/lib/evas/common/evas_font_load.c
@@ -24,7 +24,8 @@ extern FT_Library evas_ft_lib;
 
 static intfont_cache_usage = 0;
 static intfont_cache = 0;
-static intfont_dpi = 75;
+static intfont_dpi_h = 75;
+static intfont_dpi_v = 75;
 
 static Eina_Hash   *fonts_src = NULL;
 static Eina_Hash   *fonts = NULL;
@@ -131,9 +132,11 @@ evas_common_font_load_shutdown(void)
 }
 
 EAPI void
-evas_common_font_dpi_set(int dpi)
+evas_common_font_dpi_set(int dpi_h, int dpi_v)
 {
-   font_dpi = dpi;
+   if (dpi_v <= 0) dpi_v = dpi_h;
+   font_dpi_h = dpi_h;
+   font_dpi_v = dpi_v;
 }
 
 EAPI RGBA_Font_Source *
@@ -365,7 +368,7 @@ evas_common_font_int_memory_load(const char *source, const 
char *name, int size,
 #ifdef EVAS_CSERVE2
if (evas_cserve2_use_get())
  {
-fi->cs2_handler = evas_cserve2_font_load(source, name, size, font_dpi,
+fi->cs2_handler = evas_cserve2_font_load(source, name, size, 
font_dpi_h,
  wanted_rend);
 if (fi->cs2_handler)
   {
@@ -409,7 +412,7 @@ evas_common_font_int_load(const char *name, int size,
 #ifdef EVAS_CSERVE2
if (evas_cserve2_use_get())
  {
-fi->cs2_handler = evas_cserve2_font_load(NULL, name, size, font_dpi,
+fi->cs2_handler = evas_cserve2_font_load(NULL, name, size, font_dpi_h,
  wanted_rend);
 if (fi->cs2_handler)
   {
@@ -449,7 +452,7 @@ evas_common_font_int_load_complete(RGBA_Font_Int *fi)
  }
fi->real_size = fi->size * 64;
fi->scale_factor = 1.0;
-   error = FT_Set_Char_Size(fi->src->ft.face, 0, fi->real_size, font_dpi, 
font_dpi);
+   error = FT_Set_Char_Size(fi->src->ft.face, 0, fi->real_size, font_dpi_h, 
font_dpi_v);
if (error)
  error = FT_Set_Pixel_Sizes(fi->src->ft.face, 0, fi->real_size);
FTUNLOCK();
@@ -503,12 +506,12 @@ evas_common_font_int_load_complete(RGBA_Font_Int *fi)
 FTUNLOCK();
if (error)
  {
- error = FT_Set_Char_Size(fi->src->ft.face, 0, fi->real_size, 
font_dpi, font_dpi);
+ error = FT_Set_Char_Size(fi->src->ft.face, 0, fi->real_size, 
font_dpi_h, font_dpi_v);
  if (error)
{
   /* hack around broken fonts */
   fi->real_size = (chosen_size2 / 64) * 60;
-  error = FT_Set_Char_Size(fi->src->ft.face, 0, fi->real_size, 
font_dpi, font_dpi);
+  error = FT_Set_Char_Size(fi->src->ft.face, 0, fi->real_size, 
font_dpi_h, font_dpi_v);
   if (error)
 {
/* couldn't choose the size anyway... what now? */
diff 

[EGIT] [core/efl] master 01/03: widget: Some EO docs formatting

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=47a46323981925f715153e921fe10aec9283fb35

commit 47a46323981925f715153e921fe10aec9283fb35
Author: Jean-Philippe Andre 
Date:   Thu Oct 12 12:28:23 2017 +0900

widget: Some EO docs formatting

Cosmetic surgery.
---
 src/lib/elementary/elm_widget.eo | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/src/lib/elementary/elm_widget.eo b/src/lib/elementary/elm_widget.eo
index 36157ce255..a50b40af05 100644
--- a/src/lib/elementary/elm_widget.eo
+++ b/src/lib/elementary/elm_widget.eo
@@ -562,7 +562,8 @@ abstract Elm.Widget (Efl.Canvas.Group, 
Elm.Interface.Atspi_Accessible,
  
@since 1.18]]
  values {
-automatic: bool; [[$true to follow system focus move policy 
change, $false otherwise]]
+automatic: bool; [[$true to follow system focus move policy change,
+   $false otherwise]]
  }
   }
 
@@ -576,18 +577,26 @@ abstract Elm.Widget (Efl.Canvas.Group, 
Elm.Interface.Atspi_Accessible,
   focus_state_apply @protected {
  [[Register focus with the given configuration.
 
-   The implementation can feel free to change the logical flag as it 
wants, but other than that it should strictly keep the configuration.
+   The implementation can feel free to change the logical flag as it
+   wants, but other than that it should strictly keep the 
configuration.
 
-   The implementation in elm.widget updates the current state into 
what is passed as configured state, respecting manager changes, registeration 
and unregistration based on if it should be registered or unregistered.
+   The implementation in elm.widget updates the current state into what
+   is passed as configured state, respecting manager changes,
+   registeration and unregistration based on if it should be registered
+   or unregistered.
 
-   A manager field that is $null means that the widget should not or 
was not registered.
+   A manager field that is $null means that the widget should not or 
was
+   not registered.
  ]]
  params {
-@in current_state : Elm.Widget.Focus_State; [[The focus manager to 
register with.]]
-@inout configured_state : Elm.Widget.Focus_State; [[The evalulated 
Focus state that should be used]]
-@in redirect : Elm.Widget; [[A redirect that will be set by the 
elm.widget implementation]]
+@in current_state : Elm.Widget.Focus_State;
+   [[The focus manager to register with.]]
+@inout configured_state : Elm.Widget.Focus_State;
+   [[The evalulated Focus state that should be used.]]
+@in redirect : Elm.Widget;
+   [[A redirect that will be set by the elm.widget 
implementation.]]
  }
- return: bool; [[return $true or $false if the widget is registered or 
false if it is not]]
+ return: bool; [[Returns whether the widget is registered or not.]]
   }
   focus_manager_create @protected {
  [[If the widget needs a focus manager, this function will be called.
@@ -598,7 +607,7 @@ abstract Elm.Widget (Efl.Canvas.Group, 
Elm.Interface.Atspi_Accessible,
  params {
 @in root: Efl.Ui.Focus.Object; [[The logical root object for 
focus.]]
  }
- return: Efl.Ui.Focus.Manager; [[Focus manager]]
+ return: Efl.Ui.Focus.Manager; [[The focus manager.]]
   }
}
implements {

-- 

Re: [E-devel] [EGIT] [core/efl] master 01/04: evas: Override del() for evas objects

[Jean-Philippe André]

I thought you'd be interested since you previously had issues with
evas_object_del(), and raster added the hide() in there. I can't remember
the details exactly, though.

2017-10-10 23:57 GMT+09:00 Mike Blumenkrantz <michael.blumenkra...@gmail.com
>:

> Hi?
>
> On Tue, Oct 10, 2017, 6:32 AM Jean-Philippe ANDRÉ <j...@videolan.org>
> wrote:
>
> > jpeg pushed a commit to branch master.
> >
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=
> e021e25c852313463925195b1367938057734c5f
> >
> > commit e021e25c852313463925195b1367938057734c5f
> > Author: Jean-Philippe Andre <jp.an...@samsung.com>
> > Date:   Thu Sep 28 18:03:33 2017 +0900
> >
> > evas: Override del() for evas objects
> >
> > This makes EAPI evas_object_del() and EO API efl_del() work the same
> on
> > evas objects, i.e. a del() implies an immediate call to hide() and
> mark
> > the object as "delete_me".
> >
> > If the refcount remains > 0 the object won't be actually deleted,
> thus
> > EFL_EVENT_DEL won't be triggered. I think it would probably be a good
> > idea to have a new event "del,request", to signal reference owners
> that
> > this object "wants" to die.
> >
> > Ping @raster @zmike
> > ---
> >  src/lib/evas/canvas/efl_canvas_object.eo |  1 +
> >  src/lib/evas/canvas/evas_object_main.c   | 26
> +++---
> >  2 files changed, 16 insertions(+), 11 deletions(-)
> >
> > diff --git a/src/lib/evas/canvas/efl_canvas_object.eo
> > b/src/lib/evas/canvas/efl_canvas_object.eo
> > index 61c59497dd..ac3ecd4bdc 100644
> > --- a/src/lib/evas/canvas/efl_canvas_object.eo
> > +++ b/src/lib/evas/canvas/efl_canvas_object.eo
> > @@ -662,6 +662,7 @@ abstract Efl.Canvas.Object (Efl.Object, Efl.Gfx,
> > Efl.Gfx.Stack, Efl.Animator,
> >Efl.Object.destructor;
> >Efl.Object.finalize;
> >Efl.Object.provider_find;
> > +  Efl.Object.del;
> >Efl.Object.debug_name_override;
> >Efl.Gfx.visible { get; set; }
> >Efl.Gfx.color { get; set; }
> > diff --git a/src/lib/evas/canvas/evas_object_main.c
> > b/src/lib/evas/canvas/evas_object_main.c
> > index d298efb478..e6f36ec280 100644
> > --- a/src/lib/evas/canvas/evas_object_main.c
> > +++ b/src/lib/evas/canvas/evas_object_main.c
> > @@ -902,17 +902,9 @@ evas_object_ref_get(const Evas_Object *eo_obj)
> > return obj->ref;
> >  }
> >
> > -EAPI void
> > -evas_object_del(Evas_Object *eo_obj)
> > +EOLIAN static void
> > +_efl_canvas_object_efl_object_del(const Eo *eo_obj,
> > Evas_Object_Protected_Data *obj)
> >  {
> > -   if (!eo_obj) return;
> > -   MAGIC_CHECK(eo_obj, Evas_Object, MAGIC_OBJ);
> > -   return;
> > -   MAGIC_CHECK_END();
> > -
> > -   Evas_Object_Protected_Data *obj = efl_data_scope_get(eo_obj,
> MY_CLASS);
> > -
> > -   if (!obj) return;
> > evas_object_async_block(obj);
> > if (obj->delete_me || obj->efl_del_called) return;
> > if (obj->ref > 0)
> > @@ -920,9 +912,21 @@ evas_object_del(Evas_Object *eo_obj)
> >  obj->del_ref = EINA_TRUE;
> >  return;
> >   }
> > -   evas_object_hide(eo_obj);
> > +   efl_gfx_visible_set((Eo *) eo_obj, EINA_FALSE);
> > obj->efl_del_called = EINA_TRUE;
> > +   efl_del(efl_super(eo_obj, MY_CLASS));
> > +}
> >
> > +EAPI void
> > +evas_object_del(Evas_Object *eo_obj)
> > +{
> > +   if (!eo_obj) return;
> > +   if (!efl_isa(eo_obj, MY_CLASS))
> > + {
> > +ERR("Called %s on a non-evas object: %s@%p",
> > +__FUNCTION__, efl_class_name_get(eo_obj), eo_obj);
> > +return;
> > + }
> > efl_del(eo_obj);
> >  }
> >
> >
> > --
> >
> >
> >
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 01/04: evas: Override del() for evas objects

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=e021e25c852313463925195b1367938057734c5f

commit e021e25c852313463925195b1367938057734c5f
Author: Jean-Philippe Andre 
Date:   Thu Sep 28 18:03:33 2017 +0900

evas: Override del() for evas objects

This makes EAPI evas_object_del() and EO API efl_del() work the same on
evas objects, i.e. a del() implies an immediate call to hide() and mark
the object as "delete_me".

If the refcount remains > 0 the object won't be actually deleted, thus
EFL_EVENT_DEL won't be triggered. I think it would probably be a good
idea to have a new event "del,request", to signal reference owners that
this object "wants" to die.

Ping @raster @zmike
---
 src/lib/evas/canvas/efl_canvas_object.eo |  1 +
 src/lib/evas/canvas/evas_object_main.c   | 26 +++---
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/src/lib/evas/canvas/efl_canvas_object.eo 
b/src/lib/evas/canvas/efl_canvas_object.eo
index 61c59497dd..ac3ecd4bdc 100644
--- a/src/lib/evas/canvas/efl_canvas_object.eo
+++ b/src/lib/evas/canvas/efl_canvas_object.eo
@@ -662,6 +662,7 @@ abstract Efl.Canvas.Object (Efl.Object, Efl.Gfx, 
Efl.Gfx.Stack, Efl.Animator,
   Efl.Object.destructor;
   Efl.Object.finalize;
   Efl.Object.provider_find;
+  Efl.Object.del;
   Efl.Object.debug_name_override;
   Efl.Gfx.visible { get; set; }
   Efl.Gfx.color { get; set; }
diff --git a/src/lib/evas/canvas/evas_object_main.c 
b/src/lib/evas/canvas/evas_object_main.c
index d298efb478..e6f36ec280 100644
--- a/src/lib/evas/canvas/evas_object_main.c
+++ b/src/lib/evas/canvas/evas_object_main.c
@@ -902,17 +902,9 @@ evas_object_ref_get(const Evas_Object *eo_obj)
return obj->ref;
 }
 
-EAPI void
-evas_object_del(Evas_Object *eo_obj)
+EOLIAN static void
+_efl_canvas_object_efl_object_del(const Eo *eo_obj, Evas_Object_Protected_Data 
*obj)
 {
-   if (!eo_obj) return;
-   MAGIC_CHECK(eo_obj, Evas_Object, MAGIC_OBJ);
-   return;
-   MAGIC_CHECK_END();
-
-   Evas_Object_Protected_Data *obj = efl_data_scope_get(eo_obj, MY_CLASS);
-
-   if (!obj) return;
evas_object_async_block(obj);
if (obj->delete_me || obj->efl_del_called) return;
if (obj->ref > 0)
@@ -920,9 +912,21 @@ evas_object_del(Evas_Object *eo_obj)
 obj->del_ref = EINA_TRUE;
 return;
  }
-   evas_object_hide(eo_obj);
+   efl_gfx_visible_set((Eo *) eo_obj, EINA_FALSE);
obj->efl_del_called = EINA_TRUE;
+   efl_del(efl_super(eo_obj, MY_CLASS));
+}
 
+EAPI void
+evas_object_del(Evas_Object *eo_obj)
+{
+   if (!eo_obj) return;
+   if (!efl_isa(eo_obj, MY_CLASS))
+ {
+ERR("Called %s on a non-evas object: %s@%p",
+__FUNCTION__, efl_class_name_get(eo_obj), eo_obj);
+return;
+ }
efl_del(eo_obj);
 }
 

-- 

[EGIT] [core/efl] master 02/04: combobox: Mark as legacy only if legacy API is used

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=15f95c374e32e37871411ecd5ebe9ef8fa48df5e

commit 15f95c374e32e37871411ecd5ebe9ef8fa48df5e
Author: Jean-Philippe Andre 
Date:   Tue Oct 10 14:15:21 2017 +0900

combobox: Mark as legacy only if legacy API is used

See bc2fe6bb778b559e6c88f836d8cbdfb631b193b4
---
 src/lib/elementary/elc_combobox.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/lib/elementary/elc_combobox.c 
b/src/lib/elementary/elc_combobox.c
index 9372ffe34f..fde189aa52 100644
--- a/src/lib/elementary/elc_combobox.c
+++ b/src/lib/elementary/elc_combobox.c
@@ -336,6 +336,15 @@ elm_combobox_add(Evas_Object *parent)
return efl_add(MY_CLASS, parent, efl_canvas_object_legacy_ctor(efl_added));
 }
 
+static inline void
+_hover_ctor(Eo *parent, Eo *hover)
+{
+   ELM_WIDGET_DATA_GET_OR_RETURN(parent, wd);
+   if (wd->legacy)
+ efl_canvas_object_legacy_ctor(hover);
+   efl_gfx_visible_set(hover, EINA_FALSE);
+}
+
 EOLIAN static Eo *
 _elm_combobox_efl_object_constructor(Eo *obj, Elm_Combobox_Data *sd)
 {
@@ -358,8 +367,8 @@ _elm_combobox_efl_object_constructor(Eo *obj, 
Elm_Combobox_Data *sd)
 
//hover
sd->hover = efl_add(ELM_HOVER_CLASS, sd->hover_parent,
-   elm_obj_widget_style_set(efl_added, buf),
-   efl_canvas_object_legacy_ctor(efl_added));
+   _hover_ctor(obj, efl_added),
+   elm_obj_widget_style_set(efl_added, buf));
evas_object_layer_set(sd->hover, EVAS_LAYER_MAX);
efl_ui_mirrored_automatic_set(sd->hover, EINA_FALSE);
elm_hover_target_set(sd->hover, obj);

-- 

[EGIT] [core/efl] master 03/04: widget: Make focus_mouse_up_handle internal

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=f75d2e6be22187fd7428290469ec5a93bbc88200

commit f75d2e6be22187fd7428290469ec5a93bbc88200
Author: Jean-Philippe Andre 
Date:   Tue Oct 10 18:53:43 2017 +0900

widget: Make focus_mouse_up_handle internal

I don't think this belongs to the public EO API.

Ref T5363
---
 src/lib/elementary/elm_widget.c  | 7 +--
 src/lib/elementary/elm_widget.eo | 4 
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/lib/elementary/elm_widget.c b/src/lib/elementary/elm_widget.c
index f7e2aca30b..2c32e6631b 100644
--- a/src/lib/elementary/elm_widget.c
+++ b/src/lib/elementary/elm_widget.c
@@ -4332,9 +4332,12 @@ _elm_widget_focus_hide_handle(Eo *obj, 
Elm_Widget_Smart_Data *_pd EINA_UNUSED)
_if_focused_revert(obj, EINA_TRUE);
 }
 
-EOLIAN static void
-_elm_widget_focus_mouse_up_handle(Eo *obj, Elm_Widget_Smart_Data *pd)
+/* internal */
+EAPI void
+elm_widget_focus_mouse_up_handle(Eo *obj)
 {
+   Elm_Widget_Smart_Data *pd = efl_data_scope_get(obj, MY_CLASS);
+
if (!_is_focusable(obj)) return;
 
elm_obj_widget_focus_steal(obj, NULL);
diff --git a/src/lib/elementary/elm_widget.eo b/src/lib/elementary/elm_widget.eo
index 2479139f50..59ab4ea447 100644
--- a/src/lib/elementary/elm_widget.eo
+++ b/src/lib/elementary/elm_widget.eo
@@ -369,10 +369,6 @@ abstract Elm.Widget (Efl.Canvas.Group, 
Elm.Interface.Atspi_Accessible,
  }
  return: bool; [[$true if this widget can handle focus, $false 
otherwise]]
   }
-  /* FIXME: Needs better doc... maybe merge with widget_event? */
-  focus_mouse_up_handle {
- [[Handle focus mouse up]]
-  }
 
   /* Scroll API. */
   @property on_show_region_hook @protected {

-- 

[EGIT] [core/efl] master 04/04: focus: Avoid infinite loop in window

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=4c0167916bd472569a71f2888f32b49231dedb5e

commit 4c0167916bd472569a71f2888f32b49231dedb5e
Author: Jean-Philippe Andre 
Date:   Tue Oct 10 19:30:38 2017 +0900

focus: Avoid infinite loop in window

I kept the safety error message for easier debugging.
Test scenario:
  elementary_test -to "Window Inline"
  Click on an entry. Press Shift+Tab.

Ping @bu5hm4n
---
 src/lib/elementary/efl_ui_focus_manager_root_focus.c | 1 +
 src/lib/elementary/efl_ui_win.c  | 2 ++
 src/lib/elementary/elm_interface_scrollable.c| 3 +--
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/lib/elementary/efl_ui_focus_manager_root_focus.c 
b/src/lib/elementary/efl_ui_focus_manager_root_focus.c
index 4736f4ac08..700271bb69 100644
--- a/src/lib/elementary/efl_ui_focus_manager_root_focus.c
+++ b/src/lib/elementary/efl_ui_focus_manager_root_focus.c
@@ -67,6 +67,7 @@ 
_efl_ui_focus_manager_root_focus_efl_ui_focus_manager_calc_unregister(Eo *obj, E
 EOLIAN static void
 _efl_ui_focus_manager_root_focus_efl_ui_focus_manager_focus_set(Eo *obj, 
Efl_Ui_Focus_Manager_Root_Focus_Data *pd, Efl_Ui_Focus_Object *focus)
 {
+   EINA_SAFETY_ON_NULL_RETURN(focus);
efl_ui_focus_manager_focus_set(efl_super(obj, MY_CLASS), _trap(pd, focus));
 }
 
diff --git a/src/lib/elementary/efl_ui_win.c b/src/lib/elementary/efl_ui_win.c
index 4a112e5b00..9f39bc4e42 100644
--- a/src/lib/elementary/efl_ui_win.c
+++ b/src/lib/elementary/efl_ui_win.c
@@ -1757,12 +1757,14 @@ _key_action_move(Evas_Object *obj, const char *params)
 
 do {
   last = efl_ui_focus_manager_logical_end(rec_manager);
+  EINA_SAFETY_ON_NULL_GOTO(last.element, end);
   efl_ui_focus_manager_focus_set(rec_manager, last.element);
 
   rec_manager = efl_ui_focus_manager_redirect_get(rec_manager);
 } while (!last.is_regular_end);
  }
 
+end:
return EINA_TRUE;
 }
 
diff --git a/src/lib/elementary/elm_interface_scrollable.c 
b/src/lib/elementary/elm_interface_scrollable.c
index 6346453d4b..1f8d67a747 100644
--- a/src/lib/elementary/elm_interface_scrollable.c
+++ b/src/lib/elementary/elm_interface_scrollable.c
@@ -4731,10 +4731,9 @@ 
_elm_interface_scrollable_efl_ui_focus_manager_focus_set(Eo *obj, Elm_Scrollable
Eina_Rectangle geom;
int pan_x, pan_y;
 
+   EINA_SAFETY_ON_NULL_RETURN(focus);
efl_ui_focus_manager_focus_set(efl_super(obj, MY_SCROLLABLE_INTERFACE), 
focus);
 
-   if (!focus) return;
-
evas_object_geometry_get(focus, , , , );
elm_obj_pan_pos_get(pd->pan_obj, _x, _y);
geom.x = geom.x + pan_x;

-- 

[EGIT] [core/efl] efl-1.20 04/16: evas: Fix shutdown of async cmd cache

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch efl-1.20.

http://git.enlightenment.org/core/efl.git/commit/?id=757c5f83d8eb37e5509bdff1f4b53b8cb4d99c82

commit 757c5f83d8eb37e5509bdff1f4b53b8cb4d99c82
Author: Jean-Philippe Andre 
Date:   Tue Sep 26 14:26:56 2017 +0900

evas: Fix shutdown of async cmd cache

The incomplete reset (array to NULL but max not reset) triggers errors
in evas_thread_queue_append() where eina_inarray_grow() returns NULL.

This shows up in:
   CK_FORK=no elm_suite

@fix
---
 src/lib/evas/canvas/evas_async_events.c  | 1 +
 src/lib/evas/common/evas_thread_render.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/lib/evas/canvas/evas_async_events.c 
b/src/lib/evas/canvas/evas_async_events.c
index a903644772..58f26fb52e 100644
--- a/src/lib/evas/canvas/evas_async_events.c
+++ b/src/lib/evas/canvas/evas_async_events.c
@@ -158,6 +158,7 @@ evas_async_events_shutdown(void)
 
free(async_queue_cache);
async_queue_cache = NULL;
+   async_queue_cache_max = 0;
 
eina_spinlock_free(_lock);
eina_inarray_flush(_queue);
diff --git a/src/lib/evas/common/evas_thread_render.c 
b/src/lib/evas/common/evas_thread_render.c
index bbde81a657..84ea7b4234 100644
--- a/src/lib/evas/common/evas_thread_render.c
+++ b/src/lib/evas/common/evas_thread_render.c
@@ -270,6 +270,7 @@ timeout_shutdown:
 
free(evas_thread_queue_cache);
evas_thread_queue_cache = NULL;
+   evas_thread_queue_cache_max = 0;
eina_inarray_flush(_thread_queue);
 
eina_threads_shutdown();

-- 

[EGIT] [core/efl] efl-1.20 05/16: win: Avoid calling same function twice on shutdown

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch efl-1.20.

http://git.enlightenment.org/core/efl.git/commit/?id=b9ad278737c0988cab76db4914e246a17783cbbf

commit b9ad278737c0988cab76db4914e246a17783cbbf
Author: Jean-Philippe Andre 
Date:   Tue Sep 26 15:00:53 2017 +0900

win: Avoid calling same function twice on shutdown

This avoids calling:
  ecore_evas_callback_delete_request_set
  ecore_evas_callback_resize_set
twice when deleting a window. Also adds safety over sd->ee.
---
 src/lib/elementary/efl_ui_win.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/src/lib/elementary/efl_ui_win.c b/src/lib/elementary/efl_ui_win.c
index dd9f1114ca..e608e4ee6c 100644
--- a/src/lib/elementary/efl_ui_win.c
+++ b/src/lib/elementary/efl_ui_win.c
@@ -2894,14 +2894,15 @@ _efl_ui_win_efl_canvas_group_group_del(Eo *obj, 
Efl_Ui_Win_Data *sd)
sd->wm_rot.rots = NULL;
 
/* Don't let callback in the air that point to sd */
-   ecore_evas_callback_delete_request_set(sd->ee, NULL);
-   ecore_evas_callback_resize_set(sd->ee, NULL);
-   ecore_evas_callback_mouse_in_set(sd->ee, NULL);
-   ecore_evas_callback_focus_in_set(sd->ee, NULL);
-   ecore_evas_callback_focus_out_set(sd->ee, NULL);
-   ecore_evas_callback_move_set(sd->ee, NULL);
-   ecore_evas_callback_state_change_set(sd->ee, NULL);
-   ecore_evas_callback_pre_render_set(sd->ee, NULL);
+   if (sd->ee)
+ {
+ecore_evas_callback_mouse_in_set(sd->ee, NULL);
+ecore_evas_callback_focus_in_set(sd->ee, NULL);
+ecore_evas_callback_focus_out_set(sd->ee, NULL);
+ecore_evas_callback_move_set(sd->ee, NULL);
+ecore_evas_callback_state_change_set(sd->ee, NULL);
+ecore_evas_callback_pre_render_set(sd->ee, NULL);
+ }
 
efl_canvas_group_del(efl_super(obj, MY_CLASS));
 

-- 

[EGIT] [core/efl] efl-1.20 02/16: win: Avoid safety ERR in efreet

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch efl-1.20.

http://git.enlightenment.org/core/efl.git/commit/?id=2b4f0bee7f74d6eede4dbd905aaf6deff11b7d96

commit 2b4f0bee7f74d6eede4dbd905aaf6deff11b7d96
Author: Jean-Philippe Andre 
Date:   Tue Sep 26 12:20:43 2017 +0900

win: Avoid safety ERR in efreet

This is an error happening in make check. Annoying but mostly harmless.
---
 src/lib/elementary/efl_ui_win.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/elementary/efl_ui_win.c b/src/lib/elementary/efl_ui_win.c
index 306da95497..dd9f1114ca 100644
--- a/src/lib/elementary/efl_ui_win.c
+++ b/src/lib/elementary/efl_ui_win.c
@@ -4333,7 +4333,7 @@ _elm_win_frame_add(Efl_Ui_Win_Data *sd, const char 
*element, const char *style)
 
 if (sd->icon_name)
   set = elm_icon_standard_set(sd->icon, sd->icon_name);
-if ((!sd->icon_name) || (!set))
+if (((!sd->icon_name) || (!set)) && _elm_appname)
   {
  Efreet_Desktop *d;
  d = efreet_util_desktop_exec_find(_elm_appname);

-- 

[EGIT] [core/efl] efl-1.20 03/16: elm: Properly unregister providers on shutdown

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch efl-1.20.

http://git.enlightenment.org/core/efl.git/commit/?id=f24a9903f8ef7f598979c4d1696c62d021fedada

commit f24a9903f8ef7f598979c4d1696c62d021fedada
Author: Jean-Philippe Andre 
Date:   Tue Sep 26 14:09:14 2017 +0900

elm: Properly unregister providers on shutdown

This should fix some errors in make check with CK_FORK=no

Test:
  /src$ CK_FORK=no ./tests/elementary/elm_suite elm_config

@fix
---
 src/lib/eio/eio_main.c  | 1 +
 src/lib/elementary/elm_config.c | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/lib/eio/eio_main.c b/src/lib/eio/eio_main.c
index 4716ea63f4..e2a2b03925 100644
--- a/src/lib/eio/eio_main.c
+++ b/src/lib/eio/eio_main.c
@@ -358,6 +358,7 @@ eio_shutdown(void)
EINA_LOG_STATE_START,
EINA_LOG_STATE_SHUTDOWN);
 
+   efl_loop_unregister(ecore_main_loop_get(), EFL_IO_MANAGER_CLASS, 
io_manager);
efl_del(io_manager);
io_manager = NULL;
 
diff --git a/src/lib/elementary/elm_config.c b/src/lib/elementary/elm_config.c
index f6bc5a8ee6..83715c563d 100644
--- a/src/lib/elementary/elm_config.c
+++ b/src/lib/elementary/elm_config.c
@@ -4304,8 +4304,8 @@ void
 _elm_config_shutdown(void)
 {
efl_del_intercept_set(_efl_config_obj, NULL);
-   efl_loop_register(ecore_main_loop_get(), EFL_CONFIG_INTERFACE, NULL);
-   efl_loop_register(ecore_main_loop_get(), EFL_CONFIG_GLOBAL_CLASS, NULL);
+   efl_loop_unregister(ecore_main_loop_get(), EFL_CONFIG_INTERFACE, 
_efl_config_obj);
+   efl_loop_unregister(ecore_main_loop_get(), EFL_CONFIG_GLOBAL_CLASS, 
_efl_config_obj);
ELM_SAFE_FREE(_efl_config_obj, efl_del);
ELM_SAFE_FREE(_elm_config, _config_free);
ELM_SAFE_FREE(_elm_preferred_engine, eina_stringshare_del);

-- 

[EGIT] [core/efl] efl-1.20 13/16: evas: Fix dangling references with input devices

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch efl-1.20.

http://git.enlightenment.org/core/efl.git/commit/?id=7890d93c2e101e3c8892f81d36e62f064299a254

commit 7890d93c2e101e3c8892f81d36e62f064299a254
Author: Jean-Philippe Andre 
Date:   Thu Sep 28 11:27:56 2017 +0900

evas: Fix dangling references with input devices

This solves issues with efl_input_dup() which didn't properly give a
reference to the caller, resulting in dangling eo ids.

Note: This may trigger leaks (instead of invalid refs), but this now
actually reflects the meaning of @owned. This should work with bindings
and C API users should know to call efl_unref().

This patch is the reason for the previous improvements on eo_debug.

@fix
---
 src/lib/efl/interfaces/efl_common_internal.h |  2 +-
 src/lib/evas/canvas/efl_input_event.eo   | 11 +--
 src/lib/evas/canvas/efl_input_focus.c| 17 ++---
 src/lib/evas/canvas/efl_input_hold.c | 12 +++-
 src/lib/evas/canvas/efl_input_key.c  |  7 ---
 src/lib/evas/canvas/efl_input_pointer.c  | 10 +-
 src/lib/evas/canvas/evas_device.c| 23 ++-
 src/lib/evas/canvas/evas_focus.c |  2 +-
 8 files changed, 51 insertions(+), 33 deletions(-)

diff --git a/src/lib/efl/interfaces/efl_common_internal.h 
b/src/lib/efl/interfaces/efl_common_internal.h
index cacb21a252..be6cd25957 100644
--- a/src/lib/efl/interfaces/efl_common_internal.h
+++ b/src/lib/efl/interfaces/efl_common_internal.h
@@ -114,7 +114,7 @@ struct _Efl_Input_Focus_Data
 {
Eo *eo;
Efl_Input_Device *device; //The seat
-   Eo *object; //The focused object - Efl.Canvas.Object or Efl.Canvas.
+   Eo *object_wref; // wref on the focused object - Efl.Canvas.Object or 
Efl.Canvas.
double timestamp;
 };
 
diff --git a/src/lib/evas/canvas/efl_input_event.eo 
b/src/lib/evas/canvas/efl_input_event.eo
index 43f0753d75..56becac6cd 100644
--- a/src/lib/evas/canvas/efl_input_event.eo
+++ b/src/lib/evas/canvas/efl_input_event.eo
@@ -31,8 +31,15 @@ mixin Efl.Input.Event (Efl.Interface, Efl.Object)
  [[Resets the internal data to 0 or default values.]]
   }
   dup @pure_virtual {
- [[Creates a copy of this event.]]
- return: own(Efl.Input.Event); [[Event copy]]
+ [[Creates a copy of this event.
+
+   The returned event object is similar to the given object in most
+   ways except that @.fake will be $true.
+
+   Note: A reference is given to the caller. In order to avoid leaks
+   the C API users should call $efl_unref() after use.
+ ]]
+ return: own(Efl.Input.Event); [[Event copy, marked as @.fake.]]
   }
   @property device @pure_virtual {
  [[Input device that originated this event.]]
diff --git a/src/lib/evas/canvas/efl_input_focus.c 
b/src/lib/evas/canvas/efl_input_focus.c
index 5e3065b489..cc8e64aa0a 100644
--- a/src/lib/evas/canvas/efl_input_focus.c
+++ b/src/lib/evas/canvas/efl_input_focus.c
@@ -39,6 +39,7 @@ _del_hook(Eo *evt)
 static void
 _efl_input_focus_free(Efl_Input_Focus_Data *pd)
 {
+   efl_wref_del_safe(>object_wref);
efl_unref(pd->device);
 }
 
@@ -71,13 +72,13 @@ EOLIAN static void
 _efl_input_focus_object_set(Eo *obj EINA_UNUSED, Efl_Input_Focus_Data *pd,
 Efl_Object *object)
 {
-   pd->object = object;
+   pd->object_wref = object;
 }
 
 EOLIAN static Efl_Object *
 _efl_input_focus_object_get(Eo *obj EINA_UNUSED, Efl_Input_Focus_Data *pd)
 {
-   return pd->object;
+   return pd->object_wref;
 }
 
 EOLIAN static void
@@ -111,18 +112,20 @@ _efl_input_focus_efl_input_event_timestamp_get(Eo *obj 
EINA_UNUSED,
 }
 
 EOLIAN static Efl_Input_Focus *
-_efl_input_focus_efl_input_event_dup(Eo *obj, Efl_Input_Focus_Data *pd)
+_efl_input_focus_efl_input_event_dup(Eo *obj EINA_UNUSED, Efl_Input_Focus_Data 
*pd)
 {
Efl_Input_Focus_Data *ev;
Efl_Input_Focus *evt;
 
-   evt = efl_input_instance_get(MY_CLASS, efl_parent_get(obj), (void **) );
-   if (!evt || !ev) return NULL;
+   evt = efl_add(MY_CLASS, NULL);
+   ev = efl_data_scope_get(evt, MY_CLASS);
+   if (!ev) return NULL;
 
+   memcpy(ev, pd, sizeof(*ev));
ev->eo= evt;
-   ev->object= pd->object;
ev->device= efl_ref(pd->device);
-   ev->timestamp = pd->timestamp;
+   efl_wref_add(ev->object_wref, >object_wref);
+
return evt;
 }
 
diff --git a/src/lib/evas/canvas/efl_input_hold.c 
b/src/lib/evas/canvas/efl_input_hold.c
index 1d991e78f0..beca304098 100644
--- a/src/lib/evas/canvas/efl_input_hold.c
+++ b/src/lib/evas/canvas/efl_input_hold.c
@@ -101,17 +101,19 @@ _efl_input_hold_efl_input_event_reset(Eo *obj, 
Efl_Input_Hold_Data *pd)
 }
 
 EOLIAN static Efl_Input_Event *
-_efl_input_hold_efl_input_event_dup(Eo *obj, Efl_Input_Hold_Data *pd)
+_efl_input_hold_efl_input_event_dup(Eo *obj EINA_UNUSED, Efl_Input_Hold_Data 
*pd)
 {
Efl_Input_Hold_Data *ev;
-   

[EGIT] [core/efl] efl-1.20 10/16: ecore: Reset do_quit when ecore shuts down

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch efl-1.20.

http://git.enlightenment.org/core/efl.git/commit/?id=ed29bbe56f1badfc45c2931b992115d938113fd0

commit ed29bbe56f1badfc45c2931b992115d938113fd0
Author: Jean-Philippe Andre 
Date:   Tue Sep 26 17:18:02 2017 +0900

ecore: Reset do_quit when ecore shuts down

After ecore_shutdown the main loop is dead, so the flag do_quit can be
safely reset to 0. This will fix issues with cycles of
elm_init/shutdown. This fixes:
  CK_FORK=no tests/elementary/elm_suite elm_win

This patch relies on a few of the previous patches which ensure that
ecore is well shut down.

@fix
---
 src/lib/ecore/ecore_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/lib/ecore/ecore_main.c b/src/lib/ecore/ecore_main.c
index 8ca2c96293..88419cee32 100644
--- a/src/lib/ecore/ecore_main.c
+++ b/src/lib/ecore/ecore_main.c
@@ -1650,6 +1650,7 @@ _ecore_main_shutdown(void)
fd_handlers_to_call_current = NULL;
fd_handlers_to_delete = NULL;
fd_handler_current = NULL;
+   do_quit = 0;
 
 #ifdef _WIN32
while (win32_handlers)

-- 

[EGIT] [core/efl] efl-1.20 06/16: elm: Fix elm_shutdown

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch efl-1.20.

http://git.enlightenment.org/core/efl.git/commit/?id=9b6a6098dc9ea3a35ba6f2b2cf80670df2931f06

commit 9b6a6098dc9ea3a35ba6f2b2cf80670df2931f06
Author: Jean-Philippe Andre 
Date:   Tue Sep 26 16:21:27 2017 +0900

elm: Fix elm_shutdown

ecore could not shut down properly in an elm_init()/elm_shutdown()
cycle, with 7 remaining references, all because of a typo.

This should help @cedric as well
---
 src/lib/elementary/elm_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/elementary/elm_main.c b/src/lib/elementary/elm_main.c
index cc38bfe3b1..d7efe136b5 100644
--- a/src/lib/elementary/elm_main.c
+++ b/src/lib/elementary/elm_main.c
@@ -883,7 +883,7 @@ elm_quicklaunch_shutdown(void)
_elm_emotion_shutdown();
 
ecore_file_shutdown();
-   eio_init();
+   eio_shutdown();
ecore_shutdown();
eet_shutdown();
 

-- 

[EGIT] [core/efl] efl-1.20 16/16: eo: Allow efl_reuse to be called with a parent

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch efl-1.20.

http://git.enlightenment.org/core/efl.git/commit/?id=85e97c7c293f6cf1c670ef71909c8fc796b31358

commit 85e97c7c293f6cf1c670ef71909c8fc796b31358
Author: Jean-Philippe Andre 
Date:   Thu Sep 28 15:43:28 2017 +0900

eo: Allow efl_reuse to be called with a parent

If an object still has a parent inside the del intercept, we shouldn't
reset the "parent_sunk" flag. This would indeed break logic as
parent_sunk == false implies that a parent was never set, which means
the parent must be null. Right now this case isn't used but it can be
imagined with caches of evas objects (they should remain parented to
their evas).

@fix
---
 src/lib/eo/eo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/lib/eo/eo.c b/src/lib/eo/eo.c
index 26b6b6f899..16c932c89d 100644
--- a/src/lib/eo/eo.c
+++ b/src/lib/eo/eo.c
@@ -983,7 +983,8 @@ efl_reuse(const Eo *_obj)
 {
Eo *obj = (Eo *) _obj;
efl_object_override(obj, NULL);
-   _efl_object_parent_sink_set(obj, EINA_FALSE);
+   if (!efl_parent_get(obj))
+ _efl_object_parent_sink_set(obj, EINA_FALSE);
 }
 
 void

-- 

[EGIT] [core/efl] efl-1.20 01/16: elm: Fix module load with ELM_RUN_IN_TREE

[Jean-Philippe ANDRÉ]

jpeg pushed a commit to branch efl-1.20.

http://git.enlightenment.org/core/efl.git/commit/?id=d199516dbffb4ae45da4a6dbb6f5f17efc25745d

commit d199516dbffb4ae45da4a6dbb6f5f17efc25745d
Author: Jean-Philippe Andre 
Date:   Tue Sep 26 12:13:24 2017 +0900

elm: Fix module load with ELM_RUN_IN_TREE

Somehow I was seeing a ton of errors with "prefs_iface" not found in
make check. This code could not have worked since the merge of
elementary in EFL tree...

@fix
---
 src/lib/elementary/elm_module.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/elementary/elm_module.c b/src/lib/elementary/elm_module.c
index 03f70dc032..745930cb29 100644
--- a/src/lib/elementary/elm_module.c
+++ b/src/lib/elementary/elm_module.c
@@ -135,7 +135,7 @@ _elm_module_load(Elm_Module *m)
if (getenv("ELM_RUN_IN_TREE"))
  {
 snprintf(buf, sizeof(buf),
- ELM_TOP_BUILD_DIR 
"/src/modules/%s/.libs/module"EFL_SHARED_EXTENSION, m->name);
+ ELM_TOP_BUILD_DIR 
"/src/modules/elementary/%s/.libs/module"EFL_SHARED_EXTENSION, m->name);
  }
else
 #endif

--