Re: [E-devel] Licenses & Linking

[Andrew Williams]

Hi,

Thanks. I think it's best not to consider the derivitive works angle as it
could also be argued that the EFL were derived from Enlightenment work in
part, and that is BSD too.

Either way it sounds like my understanding was correct - the LGPL is there
intentionally and will override the BSD license if you want to link
statically?

One assumes this also means that all Tizen native apps are limited to
dynamic linking to avoid the need for developers to provide alternative
object code downloads?

Thanks,
Andrew

On Mon, 30 Jul 2018 at 02:35 Simon Lees  wrote:

> Hi all,
>
> I also remember the eina lgpl being intentional, one of the reasons is
> that it might be possible to argue that to the rest of the efl
> libraries, eina / efl (also lgpl) are more then just libraries that the
> rest of efl uses and therefore the rest of the efl libraries should be
> treated as derivative works. This will likely get slightly more complex
> when we as upstream start merging libraries.
>
> Probably the safest way legally would be to treat all of the efl as lgpl
> and provide objects in such a way that you can relink any part of the
> efl. But I am not a lawyer and its probably one of those ambiguities
> where without it going to court we will never actually know so most
> companies legal teams will advise them to take the safest possible
> interpretation atleast in my experience.
>
> On 30/07/18 05:56, Andrew Williams wrote:
> > Hi Stephen,
> >
> > I was probably over-simplifying but in the context where static-linking
> is
> > required then the LGPL forces certain behaviours which the BSD does not.
> > My understanding is that this applies to anyone linking statically to any
> > part of EFL as they (mostly) all depend on Eina?
> >
> > Reading from
> https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic If
> > I write a framework which is statically linked which includes the Eina
> > static link then the application developer must ship alternative object
> for
> > for re-linking. Additionally the app publishers would need to provide the
> > source code of Eina that was linked to to comply with LGPL.
> >
> > Do others have a different understanding of the situation?
> > Thanks,
> > Andrew
> >
> > On Thu, 26 Jul 2018 at 13:56 Stephen Houston 
> wrote:
> >
> >> This was a huge argument when Eina came into EFL. IIRC the profusion
> guys
> >> that wrote Eina were adamant on it being LGPL and even looked into the
> >> possibility of trying to make the rest of EFL LGPL. Of course getting
> all
> >> the author permissions to do so would be impossible so that was nixed.
> So
> >> the state of things license wise is what it is today. As far as the
> >> implications of that, I haven't studied it much.  Can you provide the
> exact
> >> language that makes you believe this to be true?
> >>
> >> On Thu, Jul 26, 2018, 6:58 AM Andrew Williams 
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> I was checking out the situation regarding licensing and read the
> current
> >>> state in https://github.com/Enlightenment/efl/blob/master/README. As
> far
> >>> as
> >>> I can tell the library at the bottom of our dependency tree, Eina, is
> >> LGPL
> >>> whereas most others are BSD - which includes the main Efl library.
> >>>
> >>> As far as I can see this means that the BSD Efl lib will restrict to
> LGPL
> >>> automatically if statically linked.
> >>> Is that the intention?
> >>>
> >>> I was hoping to use static linking for a project but I don't want to
> pass
> >>> this restriction up stream. Is there anything I can do and/or have I
> >>> misunderstood the situation at all?
> >>>
> >>> Thanks,
> >>> 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 o

Re: [E-devel] Licenses & Linking

[Andrew Williams]

Hi Stephen,

I was probably over-simplifying but in the context where static-linking is
required then the LGPL forces certain behaviours which the BSD does not.
My understanding is that this applies to anyone linking statically to any
part of EFL as they (mostly) all depend on Eina?

Reading from https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic If
I write a framework which is statically linked which includes the Eina
static link then the application developer must ship alternative object for
for re-linking. Additionally the app publishers would need to provide the
source code of Eina that was linked to to comply with LGPL.

Do others have a different understanding of the situation?
Thanks,
Andrew

On Thu, 26 Jul 2018 at 13:56 Stephen Houston  wrote:

> This was a huge argument when Eina came into EFL. IIRC the profusion guys
> that wrote Eina were adamant on it being LGPL and even looked into the
> possibility of trying to make the rest of EFL LGPL. Of course getting all
> the author permissions to do so would be impossible so that was nixed. So
> the state of things license wise is what it is today. As far as the
> implications of that, I haven't studied it much.  Can you provide the exact
> language that makes you believe this to be true?
>
> On Thu, Jul 26, 2018, 6:58 AM Andrew Williams 
> wrote:
>
> > Hi,
> >
> > I was checking out the situation regarding licensing and read the current
> > state in https://github.com/Enlightenment/efl/blob/master/README. As far
> > as
> > I can tell the library at the bottom of our dependency tree, Eina, is
> LGPL
> > whereas most others are BSD - which includes the main Efl library.
> >
> > As far as I can see this means that the BSD Efl lib will restrict to LGPL
> > automatically if statically linked.
> > Is that the intention?
> >
> > I was hoping to use static linking for a project but I don't want to pass
> > this restriction up stream. Is there anything I can do and/or have I
> > misunderstood the situation at all?
> >
> > Thanks,
> > 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
--
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] Licenses & Linking

[Andrew Williams]

Hi,

I was checking out the situation regarding licensing and read the current
state in https://github.com/Enlightenment/efl/blob/master/README. As far as
I can tell the library at the bottom of our dependency tree, Eina, is LGPL
whereas most others are BSD - which includes the main Efl library.

As far as I can see this means that the BSD Efl lib will restrict to LGPL
automatically if statically linked.
Is that the intention?

I was hoping to use static linking for a project but I don't want to pass
this restriction up stream. Is there anything I can do and/or have I
misunderstood the situation at all?

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

Re: [E-devel] latest efl lifecycle commits (from cedric)

[Andrew Williams]

Hi,

It makes me very sad to see how fast EFL work slips to the blame game when
there is a problem. If the process is not working then focus on that not
the person please. This was the result of a large amount of work that was
required for the next release - if folk worked together to deliver these
larger improvements then perhaps it would seem less personal when something
does not go smoothly.

I hope that people are familiar with the concept "Judge Ourselves by Our
Ideals and Other People by Their Acts" - that seems to be visible in this
thread. If it looks like tests would have failed then it must be not tested
- whereas if it were ourselves then it must have been a config or
environment issue... When reviewing code it is possible that we may miss
something but when someone else does then they are not doing a good job?
Can't we assume that people are working hard and trying to do a good job?
Just like believe of ourselves...

This reflects, I think, directly the experience with the ecore loop rewrite
- it broke a lot of stuff when it was merged in, but through discussion and
patching we resolved it. That was deemed to be necessary because the
underlying assumptions were wrong or the old code hacky - does this not
seem similar?

Why can't everyone just get along? :(
Andrew

On Sun, 27 May 2018 at 09:56 Carsten Haitzler  wrote:

> i've been dreading updating e1fl for the past few days. the dread proved
> founded. the short version:
>
> the batch below is pretty horrible. it leaves enlightenment glitching with
> garbage windows after a desktop switch or a second or 2. it makes
> enlightenment's restarts significantly slower (like from 1 second on this
> machine to like 2-3) with more visual bi-products (screen with just
> wallpaper
> visible for 0.5-1sec). the batch is also essentially unbisectable.
>
> this batch leaves efl in a far worse state than before.
>
> the batch itself is horrible because of the unbisectability. i have tried
> now
> about 15 commits (i lost count as i ended up in text console unable to
> write
> notes where i was writing them) and out of them only 1 compiled and ran at
> all
> without major issues. the largest amount of these just left e crashing on
> startup along with another group having edje_cc crash during compilation.
> while
> the crashes were gone by the end of the batch the above issues (short
> version
> above) remain.
>
> finding out the causes of these issues is nigh impossible. i've already
> spent
> over 4hrs on the above trying to find them.
>
> so... i've gone back to 0090384ef5ac9f9e939874a1bbf233298c9db930 which is
> good/works. i'm sitting on this (and i suggest anyone else do the same for
> now).
>
> i'm going to wait until my wednesday morning here in seoul. if the above
> issues
> are not fixed by then i have no choice but to revert every patch from
> 36f8a70041a8a16249a07d5b7131d57a8a6ea95b to
> 75bb7c049f05176aef635bddcfb320c306b196bf from cedric because tbh - this is
> the
> problem batch as described. it's not personal. it's the reality of the
> situation. i have to do this because there is no way an efl release can go
> out
> with these in place in their current condition. this is 115 commits btw...
> so
> going over every single one to figure out what may or may not be involved
> is
> going to be a major time sink that i don't think can be done well other
> than
> maybe trim the start of this series and keep some of those. i might do so
> in
> the meantime.
>
> i'm a bit disappointed on the lack of testing of these. :( also this is a
> perfect example of drive-by commit batches causing major issues which is
> why i
> keep pushing against branches or hoarding of commits because they lead to
> this
> again and again. it also reinforces my take that work needs to be done in
> small
> units and shared frequently and i am certain the more and more common
> issues
> efl etc. are having is a result of the change to branches and hoarding of
> patches and dumping them in large numbers. review doesn't work because i
> already reverted one patch earlier today that was reviewed that totally
> broke
> e. review obviously doesn't involve any testing and that is the most basic
> thing to do. :(
>
> --
> - 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

Re: [E-devel] Off

[Andrew Williams]

Hi Cedric,

I really hope you enjoy your well earned break and that we see you again
when you are rested. Your contribution has been enormous and I have very
much enjoyed working with you.

All the best for the next adventure!
Andrew

On Wed, 30 May 2018 at 04:32, Cedric Bail  wrote:

> Hello,
>
> It has been quite exhausting over the past months to deal with the major
> change and
> discussion necessary to be done for enabling a stable interfaces for
> bindings. I will thanks
> everyone that helped get things done. Still, I am clearly burnout by the
> effort put in and
> need to take some time off. So for June to August, I will be on a
> sabbatical.
>
> 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

Re: [E-devel] Off

[Andrew Williams]

This is absolutely unacceptable William. We have community guidelines.
https://www.enlightenment.org/contact
Note “Please treat everyone with kindness and respect.”
Your behaviour is clearly in violation of the community that the team are
trying to defend and I hope that someone who can do so will take action.

Regards,
Andrew

On Thu, 31 May 2018 at 15:16, William L. Thomson Jr. <
wlt...@obsidian-studios.com> wrote:

> I will deviate with all others and to me this is good news!!! I have had
> few if any interactions with Cedric. One of my first and maybe only was
> nothing but insults from him... Which he jumped in out of no where...
>
> https://phab.enlightenment.org/T6221#102021
>
> His comments were uncalled for, insulting, and hardly the actions of an
> respected leadership Or even a respectful person!!!
>
> He went on to insult more...
> https://phab.enlightenment.org/T6221#102027
>
> Then saying I am rude and insulting... Pot calling the kettle black...
> I did not hijack his bug report as he did mine... RUDE
> He had no business commenting on that at all!!!
>
> Cedrics participation only ended up in my loss of my phabricator
> account. Contributed nothing of technical value to that technical
> issue. Which I do not believe that issue is resolved, as many others
> with elm_code which still remain... Preventing progress with Ecrire.
> https://github.com/Obsidian-StudiosInc/ecrire/issues
>
> None of which Cedric is working on, so why he got involved?
>
> Note the other in that task has also mostly moved on or something per
>
> https://sourceforge.net/p/enlightenment/mailman/enlightenment-devel/thread/CADrerf4-HvLbrB4_oS7-Am9e9-DJW8sM_iiLbhGXaoSk%3DE7Ztg%40mail.gmail.com/#msg36216138
>
> No clue where that leaves elm_code, or ecrire...
>
> IMHO these people who have been around for a long time are likely more
> of the reason for the lack of new people, and direction things have
> gone. They surely have not made my things any better for me as someone
> new to EFL development and the community.
>
> Hard for me to see things the way others do. You all are bias from
> years of working with each other. I am new, and treated like garbage...
> I am happy to see some go!!!
>
> --
> William L. Thomson Jr.
>
> --
> 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

Re: [E-devel] Edi 0.6.1 release

[Andrew Williams]

It’s this one in Arch
https://aur.archlinux.org/packages/bear/

Andrew
On Thu, 17 May 2018 at 18:47, William L. Thomson Jr. <
wlt...@obsidian-studios.com> wrote:

> On Thu, 17 May 2018 13:21:50 -0400
> "William L. Thomson Jr."  wrote:
> >
> > Do you have a URL or something for bear? I cannot find any information
> > on that, my search fu is weak. Not sure if an ebuild for Gentoo
> > exists. Not seeing anything within Gentoo's portage at the moment.
> > Thanks!
>
> Seems like this is project
>  https://github.com/rizsotto/Bear
>
> I do not believe its packaged in Gentoo. I will likely to have to make
> an ebuild. Then I can add optional bear support for edi via USE flag.
>
> --
> William L. Thomson Jr.
>
> --
> 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

Re: [E-devel] Edi 0.6.1 release

[Andrew Williams]

Hi,

There are no new dependencies as far as I’m aware - bear has been used for
a while to generate compile_commands.json in c builds.

Andrew

On Thu, 17 May 2018 at 15:43, William L. Thomson Jr. <
wlt...@obsidian-studios.com> wrote:

> On Thu, 17 May 2018 09:24:55 +0100
> Andrew Williams <a...@andywilliams.me> wrote:
>
> > Hi,
> >
> > Since Edi is no longer hosted on e.org it seemed inappropriate to
> > push it to old download locations. It has been posted on GitHub for
> > years so it's not the immediate transition that it seemed to you.
>
> Ok no problem, I can switch URLs to github for edi.
>
> > The .gz -> .xz was an artifact of moving to Meson which was done in
> > parallel with E - neither had a major version bump, and why would it
> > as that was not delivering any significant improvement to the users
> > of the app.
>
> Actually the others are still there, I just need to change which is
> used in the ebuild. Not sure if there is a benefit to having an
> additional release tarball.
>
> I will use
> https://github.com/Enlightenment/edi/archive/v0.6.1.tar.gz
>
> Instead of
>
> https://github.com/Enlightenment/edi/releases/download/v0.6.1/edi-0.6.1.tar.xz
>
> My fault there, I should have caught that sooner.
>
> > If there is any build problem let me know, but moving from one to
> > another will happen. I have updated the blog post for any packagers
> > following - thanks for the reminder.
>
> I got it covered now, accept for the bear program. Not sure where that
> comes from, maybe something go related. The clang stuff may have been
> there with make, and I never noticed it, or new with meson. Either way
> i addressed that and fixed a few issues with my first ebuild. So the
> clang USE flag works and can be built with and without clang.
>
>
> --
> William L. Thomson Jr.
>
> --
> 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

Re: [E-devel] Edi 0.6.1 release

[Andrew Williams]

Hi,

Since Edi is no longer hosted on e.org it seemed inappropriate to push it
to old download locations. It has been posted on GitHub for years so it's
not the immediate transition that it seemed to you.

The .gz -> .xz was an artifact of moving to Meson which was done in
parallel with E - neither had a major version bump, and why would it as
that was not delivering any significant improvement to the users of the app.

If there is any build problem let me know, but moving from one to another
will happen. I have updated the blog post for any packagers following -
thanks for the reminder.

Andrew

On Wed, 16 May 2018 at 22:32 William L. Thomson Jr. <
wlt...@obsidian-studios.com> wrote:

> On Wed, 16 May 2018 20:34:35 +0100
> Andrew Williams <a...@andywilliams.me> wrote:
> >
> > 1:
> >
> https://github.com/Enlightenment/edi/releases/download/v0.6.1/edi-0.6.1.tar.xz
>
> Question, any plans to add the tarball here?
> https://download.enlightenment.org/rel/apps/edi/
>
> Or is github the new place for edi releases?
>
> Also switching from gz to xz.
>
> I personally like aspects of github releases. Maybe do that there and
> mirror/copy over to older spot.
>
> Either way may also want to update
> https://www.enlightenment.org/download
>
> Being consistent with releases is VERY important to downstream
> packagers. I had this setup with an e.eclass for re-use of
> enlightenment URLs etc. Which I can switch over to github no problem
> there. But then it also causes issue with the 0.6.0 being tar.gz and
> 0.6.1 tar.xz. Making it so I have to add conditionals for versions.
>
> Really not friendly to packagers. Changing URL, changing available
> formats, etc. Consistency is key there, please!!! Thank you!!!
>
> --
> William L. Thomson Jr.
>
> --
> 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

[E-devel] Edi 0.6.1 release

[Andrew Williams]

Hi,

Yesterday we rolled the latest release of Edi, 0.6.1 which is available to
download[1].

This update, which remains only reliant on efl 1.20.x releases, includes
the new EFL Examples as project templates, notifications and split view
editors as well as improved debugging and git integration.

As always please give it a shot and let me know if you have any feedback :)
Full details in the blog post [2].

Thanks,
Andrew

1:
https://github.com/Enlightenment/edi/releases/download/v0.6.1/edi-0.6.1.tar.xz
2: http://edi-ide.com/2018/05/15/0.6.1-released.html
-- 
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

Re: [E-devel] [EGIT] [core/efl] efl-1.20 01/02: elm_code: Support indentation styles that are purely tab based

[Andrew Williams]

Yes,

The feature of tab based interaction was already included - but when
auto-indenting it broke until this was applied.

Thanks,
Andrew
On Mon, 26 Mar 2018 at 07:32, Stefan Schmidt  wrote:

> Hello.
>
>
> On 03/24/2018 07:40 PM, Andy Williams wrote:
> > ajwillia-ms pushed a commit to branch efl-1.20.
> >
> >
> http://git.enlightenment.org/core/efl.git/commit/?id=228ddd733ce58af7db54c518f969509eb22434fd
> >
> > commit 228ddd733ce58af7db54c518f969509eb22434fd
> > Author: Andy Williams 
> > Date:   Sat Mar 24 10:39:32 2018 +
> >
> > elm_code: Support indentation styles that are purely tab based
> >
> > read: Allow non-EFL style indentation.
> > This is off by default but is switched on if you turn 'tabs insert
> spaces' off
> > ---
> >  src/bin/elementary/test.c   |  2 +
> >  src/bin/elementary/test_code.c  | 50 +++
> >  src/lib/elementary/elm_code.c   |  1 +
> >  src/lib/elementary/elm_code_common.h|  1 +
> >  src/lib/elementary/elm_code_indent.c| 25 +++-
> >  src/lib/elementary/elm_code_widget.c|  2 +
> >  src/tests/elementary/elm_code_test_indent.c | 61
> -
> >  7 files changed, 131 insertions(+), 11 deletions(-)
> >
>
> This really sounds like a new feature and not a bug fix that should be
> backported to the 1.20 branch.
> Can you explain to me why this is a bug fix valid for a backport?
>
> regards
> Stefan Schmidt
>
-- 
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

Re: [E-devel] Current State and Future Direction of E/EFL

[Andrew Williams]

Hi,

I know I’m not really active here but I just wanted to agree with the
sentiment here. It’s a little blunt but overall Stephen has a point.

I still think that would could have helped is a shared understanding of
what is being done (& why) and who the project is aimed at. Armed with such
a “vision” or “roadmap” it would be clearer if contributions will be
welcomed or not. And if commercial sponsorship is taking the project in the
right direction...

Andrew
On Sat, 10 Mar 2018 at 09:28, Stephen Houston  wrote:

> There is so much I whole heartedly disagree with in your attitude and point
> of view in this thread that will take me too much energy and time and
> arguing to cover.  I think other developers are coming to this same
> realization and are leaving rather than trying to change your mind.  This
> project has become far more than just you and your opinion and what you
> think is right but every word you say is coming out with an arrogance to it
> that you can't possibly be wrong, and it seems this is why you don't want
> to add any structure because then there would be rules that you too would
> have to follow and decisions made that you would not like.  While having a
> free to work on and push whatever you like unless raster vetos it community
> works out really well for you, you are not the entire dev or users
> community and they are the ones being hurt.  Our community is clearly down
> and grasping for air.  I don't think arguing for the status quo is a good
> idea.
>
> On Sat, Mar 10, 2018, 3:43 AM Carsten Haitzler 
> wrote:
>
> > On Fri, 9 Mar 2018 11:28:01 -0500 "William L. Thomson Jr."
> >  said:
> >
> > > On Fri, 9 Mar 2018 13:38:36 +0900
> > > Carsten Haitzler (The Rasterman)  wrote:
> > >
> > > > a volunteer is not going to do something they dislike. certainly not
> > > > readily. users have to convince the volunteer to do it. not the other
> > > > way around (that volunteers need to be slaves to users and do work
> > > > for them even if the volunteer disagrees and dislikes it). volunteers
> > > > don't get paid... they do things because they desire and want to.
> > > > it's the user's job to convince them... or for the user to stand up
> > > > and do it themselves. :)
> > >
> > > Yes and no. Being a volunteer does not mean you just show up and do
> > > what ever you want to do. I do not think anyone who thinks along those
> > > lines has ever volunteered in person. In my area we do things like
> > > beach cleanup, hurricane and disaster recovery. You do no get to just
> > > show up and do what ever. You do get assigned things to do as a
> > > volunteer.
> >
> > that's not how open source works. there is nothing keeping you around
> > unlike
> > thew moral obligation you put on yourself to volunteer to clean up after
> a
> > disaster for example.
> >
> > they are very very very different things. also physically volunteering
> > means
> > that walking away is something everyone sees you do. there is a face to
> it.
> > walking away from an oss project is simply stopping work. invariably
> there
> > are
> > not even real names let alone faces associated. there e never many
> > repercussions that you'd get from the example above like your neighbours
> > and
> > community giving you a hard time after walking off.
> >
> > also cleanup after a disaster is doing what has to be done, not what
> > someone
> > WANTS to be done. how would you like it if you volunteered to clean up
> and
> > the
> > home owner comes by to the house you're cleaning stuff out of and says
> "oh
> > by
> > the way. paint the walls lime green... no not that green. this green. and
> > can
> > you rebuild my garage to be a double instead of single, also use concrete
> > instead of gravel on the driveway..." any volunteer and organization will
> > tell
> > them to jump in the lake. they get the cleanup they get. not just the
> > exact way
> > they want it to be. the volunteers and organization decide what needs
> > doing.
> > not the "users". they don't get a say.
> >
> > > When it comes to FOSS this gets lost. People think its my time, my
> > > volunteering, I am going to do what ever I want with my time. That is
> > > true within reason. But that also says they only care about themselves,
> > > not the project, or what ever they are volunteering for.
> >
> > that is absolutely correct. that's what it is. it's not a humanitarian
> > effort to
> > clean up after a disaster. it's utterly superfluous really to the daily
> > trials
> > and tribulations of life. it's a luxury to get your software for free.
> >
> > it is absolutely the job of users to convince the devs to do what they
> > want.
> > not to expect devs to line up and take orders.
> >
> > > Which if they do not care about users, that also shows they do not
> > > care about the entity, organization, or project over all. If users must
> > > always convince others, that 

Re: [E-devel] UnifiedAPI Namespace definition proposal

[Andrew Williams]

Just to follow up on this by way of “documentation on the website
handover”. Whether there is “consensus” or not there is still an underlying
issue. I exposed the namespaces that Daniel mentioned to make the website
API index more readable: https://www.enlightenment.org/develop/api/start

As you can see the “main class” of a namespace is often not in the
associated namespaces. This is because the way eolian namespaces work is
basically implicit and the class name (or last part of the fully qualified
name) is not part of the namespace - so Efl.Canvas is not within efl.canvas
namespace.

This, in my unbiased-because-I’m-not-contributing-anymore needs to be
addressed and I think it would make life better for those who are binding
to other languages too.

Andy

On Sat, 24 Feb 2018 at 11:09, Davide Andreoli 
wrote:

> 2018-02-24 10:16 GMT+01:00 Vincent Torri :
>
> > On Fri, Feb 23, 2018 at 7:53 PM, Davide Andreoli  >
> > wrote:
> > > 2018-02-23 12:03 GMT+01:00 Daniel Kolesa :
> > >
> > >> On Thu, Feb 22, 2018, at 14:05, Davide Andreoli wrote:
> > >> > Hi all,
> > >> >
> > >> > I'm working again on autogenerated python bindings for efl
> UnifiedAPI
> > but
> > >> > I'm quite blocked by the lack of namespace definitions in eo/eolian.
> > >> >
> > >> > This is a noproblem in C and any other language without proper
> > >> namespacing,
> > >> > but for the langs that provide namespaces (like python and many
> > others)
> > >> > this need to be defined in some way.
> > >> >
> > >> > First of all we need to define what a namespace is, and define some
> > rules
> > >> > for them. Then we should implement something in Eolian so that every
> > >> > different bindings can be generated with the same namespace
> hierarchy.
> > >> >
> > >> > Currently I'm assuming that the namespace of an object (class or
> > >> typedecl)
> > >> > is its full name without the last part, fe the Efl.Canvas.Object
> live
> > in
> > >> > the Efl.Canvas namespace. Is this correct? is this what we want?
> > >>
> > >> This is exactly correct. If you look at the Eolian API, you can even
> > >> retrieve the namespaces using the namespaces_get functions.
> > >>
> > >> >
> > >> > As for the rules we should define some, I have two on my mind atm:
> > >> > 1. (definition) The namespace of an object is it's full name without
> > the
> > >> > last part (mybe lowercased?)
> > >> > 2. A namespace cannot have the same name of another eo object
> > (classes,
> > >> > enums, typedefs, aliases, etc)
> > >> >
> > >> > The #2 is mandatory in python. I can workaround this in my generator
> > by
> > >> > lowercasing the namespaces (fe: efl.canvas.Object), but seems to me
> > that
> > >> > having 2 different things (a class and a namespace) with the same
> > name is
> > >> > confusing for everyone and probably will not work for
> > languages/systems
> > >> > without a case-sensitive filesystem (thinking about windoz here)
> > >>
> > >> I don't see what filesystems have to do with this, but I'm not exactly
> > >> opposed to introducing the rule.
> > >>
> > >
> > > In python a tree of namespaces is created on the filesystem using a
> > folder
> > > for each namespace, and
> > > in that folder there is a file for each class (more or less). To
> > implement
> > > the Efl namespace I must
> > > create a folder called Efl, and the Efl.Canvas namespace is a folder
> > inside
> > > the Efl Folder:
> > >
> > > Efl (the namespace, a folder)
> > > -> Canvas (the namespace, a folder inside the Efl folder)
> > > -> Canvas (the class, a file inside the Efl folder)
> > >
> > > This is just not going to work in python.
> > >
> > > I can workaround lowering the namespaces as:
> > >
> > > efl (the namespace, a folder)
> > > -> canvas (the namespace, a folder inside the efl folder)
> > > -> Canvas (the class, a file inside the efl folder)
> > >
> > > This will work on linux, no idea if it will work on windoz...
> >
> > It will not. The names must be different (noncase sensitive)
> >
> > maybe canvas_ns for the namespace on Python ? Or a subfolder named
> > Namespaces where are the namespaces (just ideas, i don't know if it is
> > feasible)
> >
>
> the first suggestion will look very ugly while the second is not feasible.
>
> But note that I'm not searching for python-related solutions, I'm trying
> to help the guys that are working on the UnifiedAPI to create something
> that will works for namespace-aware languages.
>
>
> >
> > Vincent
> >
> > >
> > >
> > >>
> > >> >
> > >> >
> > >> > To better understand what I'm speaking about please give a look at:
> > >> > http://www.gurumeditation.it/dokuwiki/doku.php?id=develop:api:start
> > >> > http://www.gurumeditation.it/dokuwiki/doku.php?id=develop:
> > api:namespaces
> > >> >
> > >> > Those pages are automatically generated, are NOT python related, and
> > >> should
> > >> > serve as a reference for the UnifiedAPI work in progess, they
> 

Re: [E-devel] Upcoming efl 1.20.7 release

[Andrew Williams]

Hi Stefan,

I have backported a few things from elm_code onto this branch (as who knows
when that major release is coming).
I omitted anything in the realm of interfaces and themes so it should be ok.
Working fine here :)

Thanks,
Andy
On Thu, 8 Feb 2018 at 14:20, Stefan Schmidt  wrote:

> Hello.
>
> We got some requests for a new stable release and Raster started to
> backport more fixes to the stable branch already.
>
> If you have anything else pending for a backport please do so until Sunday
> evening in your timezone. I will prepare pre-release tarballs on
> Monday and if nothing comes up do the final release on Tuesday.
>
> 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
>
-- 
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

[E-devel] A different direction for a brighter future

[Andrew Williams]

Hi everyone,

I’ve been following the Enlightenment project for 15 years having got
involved originally due to the catchy graphics, innovative approach and
friendly community. We’ve had up times and down times as some may remember
but right now I have serious concerns about the future of this project.

When I joined the Enlightenment team it felt like we were building
something shiny and new for those that wanted a slick, beautiful
alternative desktop. After many years of development we got E17 and the
EFL, but who was EFL for? It enables E but why are we building it (for
whom)? Over time this question has become harder to answer and with
commercial support came additional confusion as to its purpose. Take
Elementary for example. It is documented as being light and minimal, but it
isn’t. We encourage developers to build desktop apps despite it not being
built for purpose and we allow widget contributions from people who don’t
even test with the standard theme.

In addition are the technical issues with our (EFL) codebase. It has
evolved organically since the beginning and we have had various namespace
changes, splitting and re-combining that brings with it a significant
legacy. The Eo/Interfaces project was a chance to leave that behind and
build things “the right way” but unfortunately it’s implementation is being
heavily shaped by legacy choices or restrictions that are bleeding out
through the new API as complexity or confusion. The type of change that we
are attempting cannot be completed effectively without up front planning,
guiding vision and regular releases to our target audience.

And finally I have observed over the last few years our community becoming
less friendly - at times even hostile - towards developers both new and
established. When I started Edi to help get new developers on board our
mailing list and IRC channel welcomed inquisitive, questioning minds but
now I often see contrary thought being beaten back. I don’t know the cause
of this change but I do see it damaging our chances of success.

*Unfortunately I don’t think these problems can be fixed within the current
project and community. Therefore I have decided to work on something new
and separate so that I can avoid these shortcomings.*

This new project aims to provide a great API for application developers to
quickly create beautiful, usable, lightweight applications for desktop and
mobile. Driven by design and usability principles it is a chance to break
from current desktop app drudgery to create something joyous akin to
material design and iOS’s interface simplicity.

Ideally it will be built on top of EFL, leveraging the great work that
exists here but abstracting it away from the user so that internal changes
and object lifecycle never bother API users. The development environment
will be polished such that new developers can easily get up and running
using the same tools as the development team. It will be built using modern
tooling and platforms that reduce the barrier to entry and allow any
potential developers or collaborators to see what we are working towards,
how we are doing and how they can get involved.

Apologies for the length of this email, I wanted to provide my reasoning so
it is clear why this is happening. I’ve put some of this info on a website
to help explain the goals - see http://fyne.io/ . If you are interested in
learning more or getting involved please contact me off list or on
IRC/Slack direct message.

All the best,
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

Re: [E-devel] FOSDEM 2017

[Andrew Williams]

Hi,

Unfortunately I’m not going to make it. I’m ill and going to stay at home
instead. Fun times.

Have a drink for me!
Andy
On Thu, 1 Feb 2018 at 09:24, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Wed, 31 Jan 2018 11:54:22 +0100 Philippe Caseiro <pcase...@cadoles.com>
> said:
>
> > Hi !!
> >
> > What about a meet-up on Saturday morning 9am @ the central "bar" neer
> > building K ?
> > Then we plan for the Diner ?
>
> 9am planning for dinner? That's keen! :) But meeting at a bar... any time.
> :)
>
> > Or we chose a restaurant and a meet time here ?
> >
> > See you !
> >
> > Le lundi 22 janvier 2018 00:48:17 CET, Andrew Williams a écrit :
> > > Hi,
> > >
> > > I expect to be there too, though staying near the event rather than
> city
> > > centre this time.
> > >
> > > Andy
> > >
> > > On Sat, 20 Jan 2018 at 16:21, Vincent Torri <vincent.to...@gmail.com>
> wrote:
> > >
> > >> i'll be at fosdem but i go back home around 6PM
> > >>
> > >> Vincent
> > >>
> > >> On Sat, Jan 20, 2018 at 3:19 PM, Carsten Haitzler <
> ras...@rasterman.com>
> > >> wrote: ...
> >
> > --
> > Philippe Caseiro
> >
> > Responsable Cadoles Services & Solutions
> > Ingénieur logiciels libres
> >
> > https://www.cadoles.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
>
>
> --
> - 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

[E-devel] Eo/Unified API decisions

[Andrew Williams]

Hi,

I have been trying to capture the choices being made that could have impact
or confusion or future discussions.
Hopefully this will avoid people like me coming back and going through old
conversations again.

https://phab.enlightenment.org/w/unified-efl-tradeoff/
Please add anything I have missed and also let me know if something there
does not seem right.

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

Re: [E-devel] FOSDEM 2017

[Andrew Williams]

Hi,

I expect to be there too, though staying near the event rather than city
centre this time.

Andy

On Sat, 20 Jan 2018 at 16:21, Vincent Torri  wrote:

> i'll be at fosdem but i go back home around 6PM
>
> Vincent
>
> On Sat, Jan 20, 2018 at 3:19 PM, Carsten Haitzler 
> wrote:
> > On Sat, 20 Jan 2018 10:33:37 +0100 Philippe Caseiro
> >  said:
> >
> >> Better late than never !
> >>
> >> Great, I'm happy to see you in Bruxelles !
> >>
> >> I don't have any news about the Stand so I think ... the answer is no
> for us.
> >>
> >> Do we organise a little Dinner on saturday night ?
> >
> > oui. allons nous manger! :)
> >
> >> Who is present ?
> >>
> >> 2017-12-18 11:50 GMT+01:00 Carsten Haitzler :
> >> > On Sun, 17 Dec 2017 19:50:16 + Tom Hacohen  said:
> >> >
> >> >> This one is from last year. ;)
> >> >
> >> > Dang. It is... I'm a bit late. :)
> >> >
> >> >> On 17 Dec 2017 15:01, "Carsten Haitzler" 
> wrote:
> >> >>
> >> >> > On Mon, 5 Dec 2016 14:09:00 +0100 Philippe Caseiro <
> >> >> > caseiro.phili...@gmail.com>
> >> >> > said:
> >> >> >
> >> >> > didn't submit... but i'm coming. :)
> >> >> >
> >> >> > > Hi, falks
> >> >> > >
> >> >> > >Sorry for the late notice I had some personal troubles this
> year so
> >> >> > > I'm a little bit late.
> >> >> > >
> >> >> > >Please take some time to submit talks this week.
> >> >> > >
> >> >> > >One more time I'm very sorry about that delay and the short
> notice.
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > FOSDEM is one of the largest (5,000+ hackers!) gatherings of Free
> >> >> > > Software contributors in the world and happens each February in
> >> >> > > Brussels (Belgium, Europe). Once again, one of the tracks will
> be the
> >> >> > > Desktops DevRoom (formerly known as “CrossDesktop DevRoom”),
> which
> >> >> > > will host Desktop-related talks.
> >> >> > >
> >> >> > > We are now inviting proposals for talks about
> Free/Libre/Open-source
> >> >> > > Software on the topics of Desktop development, Desktop
> applications
> >> >> > > and interoperability amongst Desktop Environments. This is a
> unique
> >> >> > > opportunity to show novel ideas and developments to a wide
> technical
> >> >> > > audience.
> >> >> > >
> >> >> > > Topics accepted include, but are not limited to:
> >> >> > >
> >> >> > > Open Desktops: Gnome, KDE, Unity, Enlightenment, XFCE, Razor,
> MATE,
> >> >> > > Cinnamon, ReactOS, CDE etc
> >> >> > > Closed desktops: Windows, Mac OS X, MorphOS, etc (when talking
> about a
> >> >> > > FLOSS topic)
> >> >> > > Software development for the desktop
> >> >> > > Development tools
> >> >> > > Applications that enhance desktops
> >> >> > > General desktop matters
> >> >> > > Cross-platform software development
> >> >> > > Web
> >> >> > > Thin clients, desktop virtualiation, etc
> >> >> > >
> >> >> > > Talks can be very specific, such as the advantages/disadvantages
> of
> >> >> > > distributing a desktop application with snap vs flatpak, or as
> general
> >> >> > > as using HTML5 technologies to develop native applications.
> >> >> > >
> >> >> > > Topics that are of interest to the users and developers of all
> desktop
> >> >> > > environments are especially welcome. The FOSDEM 2016 schedule
> might
> >> >> > > give you some inspiration.
> >> >> > >
> >> >> > >
> >> >> > > Submissions
> >> >> > >
> >> >> > > Please include the following information when submitting a
> proposal:
> >> >> > >
> >> >> > > Your name
> >> >> > > The title of your talk (please be descriptive, as titles will be
> >> >> > > listed with around 400 from other projects)
> >> >> > > Short abstract of one or two paragraphs
> >> >> > > Short bio (with photo)
> >> >> > > Requested time: from 15 to 45 minutes. Normal duration is 30
> minutes.
> >> >> > > Longer duration requests must be properly justified. You may be
> >> >> > > assigned LESS time than you request.
> >> >> > >
> >> >> > > How to submit
> >> >> > >
> >> >> > > All submissions are made in the Pentabarf event planning tool:
> >> >> > > https://penta.fosdem.org/submission/FOSDEM17
> >> >> > >
> >> >> > > To submit your talk, click on "Create Event", then make sure to
> select
> >> >> > > the “Desktops” devroom as the “Track”. Otherwise your talk will
> not be
> >> >> > > even considered for any devroom at all.
> >> >> > >
> >> >> > > If you already have a Pentabarf account from a previous year,
> even if
> >> >> > > your talk was not accepted, please reuse it. Create an account
> if, and
> >> >> > > only if, you don’t have one from a previous year. If you have any
> >> >> > > issues with Pentabarf, please contact desktops-devroom AT lists
> DOT
> >> >> > > fosdem DOT org.
> >> >> > >
> >> >> > >
> >> >> > > Deadline
> >> >> > >
> >> >> > > The deadline for submissions is December 5th 2016.
> >> >> > >
> >> >> > > FOSDEM will be held on the weekend of 4 & 5 February 

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: shot - add a padded screenshot so it can also grab shadows/surrounds

[Andrew Williams]

Hi,

No I don’t have an alternative proposal. It’s really have the cognitive
load on the menu or move the choice to a config. I’m really surprised this
is something you choose between very often - I’m curious, what is the
reason for one vs the other when you take your shot?

I’d genuinely be very surprised if > 10% of our users use both of these
option regularly - I had imagined that most people prefer either one or the
other.

Andy
On Fri, 19 Jan 2018 at 13:23, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Fri, 19 Jan 2018 09:36:44 + Andrew Williams <a...@andywilliams.me>
> said:
>
> > Every time I go to take a screenshot I pause at this menu and have to
> think
> > - “which am I doing”?
> > Can we move “include shadows in window shots” to a configuration
> somewhere
> > and return to a single menu item?
>
> that would force me to very regularly keep switching this config back and
> forth
> then take a shot. maybe you only ever use one, but i use both very often.
>
> so to save you ... maybe 0.5s of thought each time, you'd cause others
> like me
> 10-20 seconds of work to switch a setting back and forth very possibly each
> time. i don't see this as an even trade at all.
>
> do you have a better solution? if your other option is "make a config
> option to
> enable or disable this menu item" then i think from a user-interface
> usability
> standpoint things become really bad as you have a feature that is
> essentially
> undiscoverable as you have to switch a checkbox somewhere else to enable
> another option here. that should only be done in drastic cases such as
> security
> or safety cases where selecting the wrong item can have drastic
> consequences
> and so you must hide things to avoid these even despite the extra effort.
>
> it could be one item and then a dialog to select amount of padding, but
> it'd
> then be an extra 2 or 3 clicks (a slider, or drag a box around, then hit
> ok)
> which would address something like "it's a fixed amount - please make it
> variable so i can avoid the effort of cropping again in gimp" which would
> make
> sense to me, so this would in fact do the opposite of addressing your
> issue and
> make you spend even more time.
>
> do you have a solution that removes this 0.5 seconds of thought (which is
> probably what it takes, at least i'm in the ballpark i think), and doesn't
> cost
> others as much ore more time, or doesn't just remove cost in the menu but
> add
> it elsewhere later (in a dialog)?
>
> > Just a thought,
> > Andy
> > On Sat, 4 Nov 2017 at 00:45, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> >
> > > On Fri, 03 Nov 2017 14:10:28 + Mike Blumenkrantz
> > > <michael.blumenkra...@gmail.com> said:
> > >
> > > > On Fri, Nov 3, 2017 at 9:50 AM Carsten Haitzler <
> ras...@rasterman.com>
> > > > wrote:
> > > >
> > > > > On Fri, 03 Nov 2017 11:28:28 + Mike Blumenkrantz
> > > > > <michael.blumenkra...@gmail.com> said:
> > > > >
> > > > > > I see what you are going for here based on the theme that you
> have
> > > been
> > > > > > working on, and I think it would be a nice improvement overall to
> > > have
> > > > > this
> > > > >
> > > > > actually it applies to default too.. :)
> > > > >
> > > >
> > > > Nobody cares about the shadows in a theme which has been the default
> for
> > > > over 5 years :) :) :) :) :)
> > > >
> > > >
> > > > >
> > > > > > sort of feature, but I think that this is not the best way to go
> > > about
> > > > > > it--specifically adding it to the window menu since there are
> now two
> > > > > > screenshot items, though the general implementation also seems
> to be
> > > > > > something that would only be used by you since it either adds a
> large
> > > > > > amount of padding by default or requires the user to trial+error
> in
> > > order
> > > > > > to achieve the desired results.
> > > > >
> > > > > i just kind of thought i chose a pretty good default that would
> "do the
> > > > > job 99%
> > > > > of the time anyway"... if that's what you wanted. it does make for
> much
> > > > > nicer
> > > > > screenshots of specific windows. :)
> > > > >
> > > > > the problem here is we don't actually know

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: shot - add a padded screenshot so it can also grab shadows/surrounds

[Andrew Williams]

Every time I go to take a screenshot I pause at this menu and have to think
- “which am I doing”?
Can we move “include shadows in window shots” to a configuration somewhere
and return to a single menu item?

Just a thought,
Andy
On Sat, 4 Nov 2017 at 00:45, Carsten Haitzler  wrote:

> On Fri, 03 Nov 2017 14:10:28 + Mike Blumenkrantz
>  said:
>
> > On Fri, Nov 3, 2017 at 9:50 AM Carsten Haitzler 
> > wrote:
> >
> > > On Fri, 03 Nov 2017 11:28:28 + Mike Blumenkrantz
> > >  said:
> > >
> > > > I see what you are going for here based on the theme that you have
> been
> > > > working on, and I think it would be a nice improvement overall to
> have
> > > this
> > >
> > > actually it applies to default too.. :)
> > >
> >
> > Nobody cares about the shadows in a theme which has been the default for
> > over 5 years :) :) :) :) :)
> >
> >
> > >
> > > > sort of feature, but I think that this is not the best way to go
> about
> > > > it--specifically adding it to the window menu since there are now two
> > > > screenshot items, though the general implementation also seems to be
> > > > something that would only be used by you since it either adds a large
> > > > amount of padding by default or requires the user to trial+error in
> order
> > > > to achieve the desired results.
> > >
> > > i just kind of thought i chose a pretty good default that would "do the
> > > job 99%
> > > of the time anyway"... if that's what you wanted. it does make for much
> > > nicer
> > > screenshots of specific windows. :)
> > >
> > > the problem here is we don't actually know the dimensions of the
> shadow.
> > > it's
> > > done outside the object bounds, thus just taking some value is about as
> > > good as
> > > it gets at this point. well in x11. in wayland we do. but if we
> calculated
> > > it
> > > given current shadows the top padding would be less, bottom more etc.
> so
> > > you'd
> > > want to take the max anyway.
> > >
> >
> > Using edje_object_parts_extends_calc() would yield correct dimensions for
> > server-side shadows, and there are themes which have used this to have
> > resize trigger based on pointer interaction with the shadow region in
> x11.
>
> i didn't know that had been added.
>
> > > > I think the better solution for reliably capturing shadows on windows
> > > would
> > > > be to do something like add a feature for snapshot objects where
> setting
> > > > the clip to an object under it will restrict it to only being a
> snapshot
> > > > from image data resulting from that object. Then all window-based
> > > > screenshots could automatically be made to capture shadows and do it
> > > > accurately.
> > >
> > > i did indeed try proxies... they ended up blank with no content...
> > > (creates an
> > > image set src to ec->frame etc. etc.) and that still has the above
> "shadow
> > > is
> > > done outside of object bounds" thing where you can't grab it via a
> proxy
> > > this
> > > way anyway... :(
> >
> > Snapshot object, not proxy. I've created a task for it.
> > https://phab.enlightenment.org/T6312
>
> sure. but proxies would be the only way to capture a specific object and
> not
> everything below it too at this point. :)
>
> > > > Alternatively, dynamic cropping from e.g., emprint or ephoto could be
> > > added
> > > > to the base screenshot gui which would be a useful feature for many
> > > cases.
> > >
> > > that was on a list of things to "add later" as it would take more work.
> > > also
> > > if it were just simply "draw a rect to crop" it's lead to inconsistent
> > > padding
> > > around windows. to do it well it'd be a bit like the screen select but
> you
> > > can
> > > click on windows, then click and drag handles outside of the window,
> maybe
> > > with
> > > a "add std padding" button with some field with the padding amount to
> add
> > > around the bounds etc. - definitely more work by a good chunk.
> > >
> > > what i have done is a very quick and simple solution to having window
> shots
> > > actually look "nice" with their surrounding decorations and shadow ...
> if
> > > you
> > > want. i kept the non-padded entry because sometimes you don't want
> other
> > > windows
> > > around your to leak into the shot... not the nicest of solutions, but
> it's
> > > a
> > > pretty quick and simple one for now.
> > >
> >
> > I understand why you did it as well as why you did it the way you did,
> but
> > I disagree with the latter. Having more parameters to an action that only
> > extreme power users will ever notice is whatever, but adding extra menu
> > items which duplicate the functionality of existing menu items is not
> > ideal. The toplevel menu should contain exactly one item for taking
> > screenshots of windows, not one for taking screenshots and a second for
> > taking slightly larger screenshots.
>
> wile it doesnt look brilliant my choices are:
>
> 1. always take a padded 

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

[Andrew Williams]

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.

Andy

On Thu, 18 Jan 2018 at 07:54 Jean-Philippe André  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  wrote:
> > > thiep pushed a commit to branch master.
> > >
> > > http://git.enlightenment.org/core/efl.git/commit/?id=f191d68
> > 21f0fd94389dc92c8353b769eaacad28a
> > >
> > > commit f191d6821f0fd94389dc92c8353b769eaacad28a
> > > Author: Thiep Ha 
> > > 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 +1,62 @@
> > > +#ifdef HAVE_CONFIG_H
> > > +# include "elementary_config.h"
> > > +#endif
> > > +
> > > +#define EFL_SELECTION_MANAGER_BETA
> > > +
> > > +#include 
> > > +#include "elm_priv.h"
> > > +
> > > +#define MY_CLASS EFL_SELECTION_MIXIN
> > > +#define MY_CLASS_NAME "Efl.Selection"
> > > +
> > > +static inline Eo*
> > > +_selection_manager_get(Eo *obj)
> > > +{
> > > +   Eo *top = elm_widget_top_get(obj);
> > > +   if (!top)
> > > + {
> > > +top = obj;
> > > + }
> > > +   Eo *sel_man = efl_key_data_get(top, "__selection_manager");
> > > +   if (!sel_man)
> > > + {
> > > +sel_man = efl_add(EFL_SELECTION_MANAGER_CLASS, top);
> > > +efl_key_data_set(top, "__selection_manager", sel_man);
> > > + }
> > > +   return sel_man;
> > > +}
> > > +
> > > +EOLIAN static void
> > > +_efl_selection_selection_get(Eo *obj, void *pd EINA_UNUSED,
> > Efl_Selection_Type type, Efl_Selection_Format format,
> > > + void *data_func_data,
> > Efl_Selection_Data_Ready data_func, Eina_Free_Cb data_func_free_cb,
> > unsigned int seat)
> > > +{
> > > +   Eo *sel_man = _selection_manager_get(obj);
> > > +   efl_selection_manager_selection_get(sel_man, obj, type, format,
> > > +   data_func_data, data_func,
> > > +   data_func_free_cb, seat);
> > > +}
> > > +
> > > +EOLIAN static Eina_Future *
> > > +_efl_selection_selection_set(Eo *obj, void *pd EINA_UNUSED,
> > Efl_Selection_Type type, Efl_Selection_Format format, Eina_Slice data,
> > unsigned int seat)
> > > +{
> 

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

[Andrew Williams]

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.

Thanks,
Andy

On Sat, 13 Jan 2018 at 10:45 Davide Andreoli  wrote:

> 2018-01-11 6:18 GMT+01:00 Jean-Philippe André :
>
> > Hi Dave,
> >
> > On Thu, Jan 11, 2018 at 7:43 AM, Davide Andreoli  >
> > wrote:
> >
> > > 2018-01-08 19:52 GMT+01:00 Cedric Bail :
> > >
> > > > 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 
> > > > >
> > > > > 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 in the obect itself.
>
> So there is no need to import the Text interface to just use an object that
> implement it,
> but you need to import the iface if you want (fe) to create a new class
> that implement
> that interface (not sure if this will make sense in practice) or you need
> to use that name
> for other means, maybe you want to check if a given object implement a
> specific interface:
>
> from efl.text import Text
> ...
> if isinstance(obj, Text):
>   blah, blah
>
> In this case you need to import the interface as you are using it's name.
>
>
>
>
> >
> > 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).
> >
>
> 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 

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

[Andrew Williams]

Sorry to be pessimistic but this sounds like a month or two of refactoring
on the end of whatever timeline we could have imagined before.

It also hammers the last nail into the coffin of any early releases.

Andy

On Thu, 11 Jan 2018 at 00:41, Carsten Haitzler  wrote:

> On Wed, 10 Jan 2018 23:43:15 +0100 Davide Andreoli  >
> said:
>
> > 2018-01-08 19:52 GMT+01:00 Cedric Bail :
> >
> > > 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 
> > > >
> > > > 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
> > > >
> > > > 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.
> >
> > 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.
> >
> > 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 !
>
> i think this is one of those things that will come together near the end
> when
> the big picture is clear and we're going to just argue about names. :) as
> things get added they're looked at and evaluated and argued about and
> changed.
>
> > > 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
> > >
> >
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > Mail
> > priva di virus. www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> --
> > 

Re: [E-devel] Is there a book?

[Andrew Williams]

Hi,

We are working on updating all of our documentation but we don’t have a
book at this time.
You can read most of our documentation for developers at
https://enlightenment.org/develop/

Happy coding,
Andy
On Wed, 10 Jan 2018 at 08:54, Vanangamudi  wrote:

> Hi,
>
>
> First of all, I must appreciate the work you guys are doing. Keep up the
> good work.
>
>
> I want to get started with application development with EFL. Is there a
> book I can read to get started?
>
>
> Thanks,
>
> Vanangamudi
>
>
>
> --
> 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

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl loop - provide efl namespace versions of begin/end locks on mainloop

[Andrew Williams]

Oh my this loop/thread thing is a mess.

I practically got ripped a new one on a different thread because I assumed
that the main loop would be a useful thing to access. And now we have
explicit access to the main loop. Which main? Which thread?

Can we please step back for a minute and actually agree what the loop model
is intended to be so we can all be working in the same direction?

Thanks,
Andy
On Mon, 8 Jan 2018 at 10:49, Cedric Bail  wrote:

> >  Original Message 
> > Subject: Re: [E-devel] [EGIT] [core/efl] master 01/01: efl loop -
> provide efl namespace versions of begin/end locks on mainloop
> > Local Time: January 5, 2018 5:04 AM
> > UTC Time: January 5, 2018 1:04 PM
> > From: ras...@rasterman.com
> > To: Enlightenment developer list <
> enlightenment-devel@lists.sourceforge.net>
> > g...@lists.enlightenment.org
> >
> > On Fri, 5 Jan 2018 10:53:46 -0200 Gustavo Sverzut Barbieri
> barbi...@gmail.com
> > said:
> >
> >> On Fri, Jan 5, 2018 at 4:04 AM, Carsten Haitzler ras...@rasterman.com
> wrote:
> >>
> >>> raster pushed a commit to branch master.
> >>>
> http://git.enlightenment.org/core/efl.git/commit/?id=76b837002eaea56b5ecb174bffe284012084dc74
> >>> commit 76b837002eaea56b5ecb174bffe284012084dc74
> >>> Author: Carsten Haitzler (Rasterman) ras...@rasterman.com
> >>> Date: Fri Jan 5 15:01:02 2018 +0900
>
> 
>
> > we can't do this multi-loop because this is also tied specifically to
> switching
> > eo domain id's from "thread" to "main" and back. main has one and only
> one
> > instance - the mainloop eo id. thread is a thread-local per thread
> domain so
> > you can't actually switch to another thread's domain ... except the main
> loop.
>
> I still do strongly believe that this is a problem that needs solving, but
> anyway, there is no point into moving function like that in the new unified
> namespace at the moment as we can always use legacy along with the new API.
> Also as there is a lot of problems with bindings regarding threads to be
> solved and have eolian properly aware of that. So it is a C only API at the
> moment. Which reinforce my point of just use legacy API for this purpose.
> Also it is clearly not a priority and not something we should start pushing
> for a release. For this reasons and Gustavo arguments, I think we should
> remove this added function and only rely on legacy for the time being.
>
> --
> 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

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

[Andrew Williams]

I think one of the issues we have is that namespace is not declared as it
would be in other languages. I have inferred, as have others, that the
namespace is everything except the last component of the class name. This
seems to work to an extent but if we were to clarify this as the desired
behaviour we could specify which namespaces we wish to use rather than have
them be determined through (side effects of) class naming...

Andy
On Mon, 8 Jan 2018 at 10:53, Cedric Bail  wrote:

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

Re: [E-devel] [EGIT] [core/efl] master 01/01: elm: disable interface theme loading

[Andrew Williams]

Hi,

This breaks Efl.Ui.Text and Efl.Ui.Panes unfortunately. I looked at the
ticket but could not figure which of the widgets was causing you trouble.
Any more info so we an get this back in but properly?

Thanks,
Andy

On Fri, 5 Jan 2018 at 16:48 Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:

> discomfitor pushed a commit to branch master.
>
>
> http://git.enlightenment.org/core/efl.git/commit/?id=3d07b90461818804ed51b6dcaed9f05c0d0155bb
>
> commit 3d07b90461818804ed51b6dcaed9f05c0d0155bb
> Author: Mike Blumenkrantz 
> Date:   Fri Jan 5 11:43:47 2018 -0500
>
> elm: disable interface theme loading
>
> this is broken. do not reenable until testing has been done.
>
> partially reverts dd4467505ea29d6120e5e7d467d76836a6630ff4
>
> ref T6579
> ---
>  src/lib/elementary/elm_theme.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/src/lib/elementary/elm_theme.c
> b/src/lib/elementary/elm_theme.c
> index 69028c6770..0780265859 100644
> --- a/src/lib/elementary/elm_theme.c
> +++ b/src/lib/elementary/elm_theme.c
> @@ -305,12 +305,12 @@ _elm_theme_set(Elm_Theme *th, Evas_Object *o, const
> char *clas, const char *grou
>
> if ((!clas) || !o) return EFL_UI_THEME_APPLY_FAILED;
> if (!th) th = &(theme_default);
> -   if (is_legacy)
> +   //if (is_legacy)
>   snprintf(buf2, sizeof(buf2), "elm/%s/%s/%s", clas, (group) ? group :
> "base", (style) ? style : "default");
> -   else
> - snprintf(buf2, sizeof(buf2), "efl/%s%s%s%s%s", clas,
> -((group) ? group_sep : "\0"), ((group) ? group : "\0"),
> -((style) ? style_sep : "\0"), ((style) ? style : "\0"));
> +   //else
> + //snprintf(buf2, sizeof(buf2), "efl/%s%s%s%s%s", clas,
> +//((group) ? group_sep : "\0"), ((group) ? group : "\0"),
> +//((style) ? style_sep : "\0"), ((style) ? style : "\0"));
> if (!eina_hash_find(th->cache_style_load_failed, buf2))
>   {
>  file = _elm_theme_group_file_find(th, buf2);
> @@ -333,11 +333,11 @@ _elm_theme_set(Elm_Theme *th, Evas_Object *o, const
> char *clas, const char *grou
>   return EFL_UI_THEME_APPLY_FAILED;
>
> // Use the elementary default style.
> -   if (is_legacy)
> +   //if (is_legacy)
>   snprintf(buf2, sizeof(buf2), "elm/%s/%s/%s", clas, (group) ? group :
> "base", "default");
> -   else
> - snprintf(buf2, sizeof(buf2), "efl/%s%s%s", clas,
> -((group) ? group_sep : "\0"), ((group) ? group : "\0"));
> +   //else
> + //snprintf(buf2, sizeof(buf2), "efl/%s%s%s", clas,
> +//((group) ? group_sep : "\0"), ((group) ? group : "\0"));
> if (!eina_hash_find(th->cache_style_load_failed, buf2))
>   {
>  file = _elm_theme_group_file_find(th, buf2);
>
> --
>
>
>

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

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

Hi,

I don't think I can do this any longer. Any comment I make about usability
is met with

"it's easy to understand if you know the internal state/functioning of the
object".

My premise is still

"with efl_add sometimes returning ownership and other times not this is
confusing for the developer"

I wanted for us to present something that is clear and simple without
needing to know internal state or reading the EFL source code.
It seems I will not succeed.

Andy

On Thu, 4 Jan 2018 at 06:32 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Wed, 03 Jan 2018 09:43:16 + Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi Cedric,
> >
> > I think I agree, if we can tidy the definitions then everything should
> get
> > clearer.
> >
> > efl_add_ref being needed for bindings implies that our definition of
> > efl_add was not clean enough in the first place.
>
> we were very clear on that. for bindings it's needed (or if you want to
> write
> code in that style) but it's highly inconvenient and we've been over that.
>
> > If efl_del is "hide and unparent" then maybe what we really need is
> > efl_gfx_hide and efl_parent_unset - but I don't see why we need to
> unparent
> > anyhow...
>
> well if it's the last ref... the unparenting cleanly removes from the
> parent
> AND removes the last ref as a result.
>
> BUT i kind of agree with you here. the unparenting is proving to be a major
> pain in the rear. by that i mean the unparenting happens and then parent is
> NULL and THEN as a result of this reference goes to 0 and destructors get
> called. when the destructors are called, the parent is already NULL and
> this
> has proven an "odd" case i've been dealing with the efl loop work...
> because on
> destruction the object doesn't know what loop it belonged to anymore...
> yes -
> you have to handle parent_set to NULL then but it means this has to do some
> kind of destruction of loop bound resources... :(
>
> IMHO when the destructors are called the object should still have a parent
> and
> be removed from the child list as a very last "after last destructor is
> called"
> step, not "before destructors are called".
>
> also we need to do better parent policing.
>
> 1. objects that can never have a NULL parent need to be marked as such
> 1.2 objects that MUST have a loop parent at the top of their parent tree or
> somewhere in it (provider_find for a loop class must fund a non-null loop
> object).
> 1.3 objects MUST have a loop object and it MUST be the main loop object and
> only that one.
> 2. some objects are intended to be toplevels (with NULL as the parent) and
> should be marked as such (e.g. loop objects).
>
> > If we are delegating to a parent to manage the lifecycle of the object
> then
> > we should step away from the reference and forget it - that is the most
> > "convenient" behaviour I guess.
> >
> > if:
> > efl_add *always* returned an owned reference and took no parent
> > efl_add_child *never* returned an owned reference and required a parent
> >
> > then:
> > efl_add_ref* would no longer be required right? (if the binding requires
> a
> > ref after efl_add_child we have efl_ref that it could wrap up)
> > efl_del would take a reference and dec (probably not needed as we have
> > efl_unref?)
> > efl_del_child seems unlikely to be needed as all that is left is hiding
> > which is a graphics call, not an eo lifecycle one.
> >
> > The more I look at it the more I think we have too much UI related
> thinking
> > in our object lifecycle.
>
> that's because 90% of our objects have been UI related in the past sand
> pretty
> much still are. for us, i think this is the right thing.
>
> > Andy
> >
> > On Wed, 3 Jan 2018 at 05:41 Cedric Bail <ced...@ddlm.me> wrote:
> >
> > > > The whole efl_del argument just exist because it is kinda poorly
> > > > named. IMO, del means: get this object to an "empty" state.
> > > > Just like close to files and hide and unparent to UI objects. efl_del
> > > > should not steal references under people who owns it, the object
> > > > would get deleted at a later time when everybody using the object
> > > > stops doing so, we could even return errors from efl_del'eted
> > > > objects for methods that do not make sense anymore, causing
> > > > most actions to, possibly, halt earlier rather than later.
> > >
> > > So, if efl_del does not still a references under people who owns it,
> how
> > > do we fix it ? Shou

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

Hi,

I would avoid the name efl_release if it is not to do with object lifecycle
as that is the word ObjectiveC uses in their retain/release pair for memory
management.

Just a thought if we are trying to attract devs from elsewhere.

Andy

On Thu, 4 Jan 2018 at 00:04 Cedric Bail  wrote:

> >  Original Message 
> > Subject: Re: [E-devel] efl_add causing confusion
> > Local Time: January 3, 2018 1:43 AM
> > UTC Time: January 3, 2018 9:43 AM
> > From: a...@andywilliams.me
> > To: Enlightenment developer list <
> enlightenment-devel@lists.sourceforge.net>
> >
> > Hi Cedric,
> >
> > I think I agree, if we can tidy the definitions then everything should
> get
> > clearer.
> >
> > efl_add_ref being needed for bindings implies that our definition of
> > efl_add was not clean enough in the first place.
> > If efl_del is "hide and unparent" then maybe what we really need is
> > efl_gfx_hide and efl_parent_unset - but I don't see why we need to
> unparent
> > anyhow...
>
> After some discussion with Felipe we came to the conclusion that efl_del
> is not properly design and the core problem is indeed that it does to many
> things. Our idea is to split it in two part. efl_release that will have
> different meaning on object, could close a socket if it an network object
> for example or hide and remove from scenegraph if it is a canvas object.
> This will not affect the object lifecycle. It will make it emit a new event
> once it is released (This would be a first step, but later on we would
> likely want to block some function from working when an object is released
> and the ability to unrelease an object).
>
> The second function would be what efl_del kind of does, but moved to an
> inline function that call efl_release. This way binding can use release (it
> doesn't randomly mess with the object life cycle) and provide their own
> logic for del. Now in C, it is still not obvious what efl_del should do in
> term of unparenting and unref. Right now, it does a wonderful if there is a
> parent, then unset the parent, if there is no parent, then just unref. But
> in the following example :
>
> obj = efl_add(CLASS, NULL);
> efl_parent_set(obj, some_parent);
> efl_del(obj);
>
> obj will still have one reference, but no parent left, while in the
> example below :
>
> obj = efl_add(CLASS, some_parent);
> efl_del(obj);
>
> The object will have been properly destroyed. This kind of problem happen
> easily in our API when we actually return a new Eo object. Depending on how
> we create it, its reference count might change. My personal take is that
> efl_del should not do anything on the parent. If we give an object to be
> managed by the parent, del should not be the one touching it. The parent
> should. So I would argue that efl_del should just be efl_release +
> efl_unref.
>
> > If we are delegating to a parent to manage the lifecycle of the object
> then
> > we should step away from the reference and forget it - that is the most
> > "convenient" behaviour I guess.
> >
> > if:
> > efl_add always returned an owned reference and took no parent
> > efl_add_child never returned an owned reference and required a parent
>
> This seems to match the change we think are necessary to efl_del.
>
> > then:
> > efl_add_ref* would no longer be required right? (if the binding requires
> a
> > ref after efl_add_child we have efl_ref that it could wrap up)
>
> We could still provide an efl_add_ref helper in C too, but otherwise yes
> to your point.
>
> > efl_del would take a reference and dec (probably not needed as we have
> > efl_unref?)
> > efl_del_child seems unlikely to be needed as all that is left is hiding
> > which is a graphics call, not an eo lifecycle one.
>
> I am not a fan of the idea of an efl_del_child, but as it would be an
> inline helper, it can be done later if we feel it is useful.
>
> This proposal would work for binding. Right now, they rely on efl_unref
> and can't call efl_del due to the unpredictable lifecycle that result of
> it, cleaning that, clean also the other side of the confusion by making
> efl_add more rigorous in its behavior.
>
> 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

Re: [E-devel] [EGIT] [core/efl] master 01/01: promise: Add even simpler helper for main loop promise creation

[Andrew Williams]

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?

Thanks,
Andrew

On Thu, 4 Jan 2018 at 13:10 Gustavo Sverzut Barbieri 
wrote:

> On Thu, Jan 4, 2018 at 9:56 AM, Andy Williams 
> wrote:
> > ajwillia-ms pushed a commit to branch master.
> >
> >
> http://git.enlightenment.org/core/efl.git/commit/?id=e931fd698d26b8bec0e34239d2f79c059b339a51
> >
> > commit e931fd698d26b8bec0e34239d2f79c059b339a51
> > Author: Andy Williams 
> > Date:   Thu Jan 4 11:56:01 2018 +
> >
> > promise: Add even simpler helper for main loop promise creation
> > ---
> >  src/lib/ecore/Ecore_Eo.h | 12 
> >  src/lib/ecore/efl_loop.c | 10 ++
> >  2 files changed, 22 insertions(+)
> >
> > diff --git a/src/lib/ecore/Ecore_Eo.h b/src/lib/ecore/Ecore_Eo.h
> > index fa5d08d798..4c6783cd5f 100644
> > --- a/src/lib/ecore/Ecore_Eo.h
> > +++ b/src/lib/ecore/Ecore_Eo.h
> > @@ -83,6 +83,18 @@ EAPI Eina_Future_Scheduler
> *efl_loop_future_scheduler_get(const Eo *obj);
> >   */
> >  EAPI Eina_Promise *efl_loop_promise_new(const Eo *obj,
> Eina_Promise_Cancel_Cb cancel_cb, const void *data);
> >
> > +/**
> > + * @brief Create a future attached to the main loop
>
> watch out the terms... they are confusing, I always mix them up... and
> so you did ;-)
>
> s/future/promise/
>
> promise is the "write side" of the pipe... you send the value to it
> (resolve/reject) and then it will propagate to the read side in a
> chain of futures.
>
>
> > + * @param cancel_cb A callback used to inform that the promise was
> canceled. Use
> > + * this callback to @c free @p data. @p cancel_cb must not be @c NULL !
> > + * @param data Data to @p cancel_cb.
> > + * @return A promise or @c NULL on error.
> > + *
> > + * @see eina_promise_new()
> > + */
> > +EAPI Eina_Promise *efl_loop_main_promise_new(Eina_Promise_Cancel_Cb
> cancel_cb, const void *data);
> ...
> > +EAPI Eina_Promise *
> > +efl_loop_main_promise_new(Eina_Promise_Cancel_Cb cancel_cb, const void
> *data)
> > +{
> > +   Efl_Loop *main;
> > +
> > +   main = efl_loop_main_get(EFL_LOOP_CLASS);
>
> however this shouldn't exist, really.
>
> as I wrote in my previous long-long-email, creating PROMISES is not
> common. Basically internal EFL code is doing that, like
> timeout/job/idle promises that are returned as FUTURE... then the user
> will chain on those futures... no need to create and return a new
> promise. There is no need for helping it that much.
>
> that said, providing a helper to do it for the "main" loop is wrong,
> because people should be careful to stick with the existing main loop
> they are bound to and never-EVER assume there is a single main loop
> and they are running from it.
>
> for the time being, things will work, after all we have a single
> loop... but once we make it really possible to have multiple loops,
> then things start to misbehave and it will be super-hard to fix...
> since things won't crash, they won't fail to compile... they will just
> be dispatched "elsewhere" and eventually this is freaking hard to
> identify.
>
> a good quality check for EFL would be to identify code as
> "efl_loop_main_get()" or others that assume a main loop instead of
> propagating using loop/loop-user... and mark as a bug.
>
>
> --
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (16) 99354-9890 <+55%2016%2099354-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
>


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

Re: [E-devel] is there a roadmap for future significative improvements/changes

[Andrew Williams]

Hi,

Our release page (https://phab.enlightenment.org/w/release_roadmap/) still
says that we are doing time based releases

"We aim for a 3 months release cycle (with a release on the first Monday in
February, May, August and November)"
and "Release 1.21 is planned for late 2017".

If we are now looking at a feature based release then
*) Why does our release summary document not reflect this
*) Does this mean there will be no 1.21 until that
https://phab.enlightenment.org/T5301 is completed?

If we are waiting for T5301 then here are some statistics:

* The parent ticket was created 9 months ago and has 92 child tickets
* 23 of the child tickets are closed (that's 25%)
* On average 2 new tickets are added every month
* 24 of the tickets are lower than "High" priority

Assuming that high and above is what is required then we've completed 1/3
of the tickets.
A very crude calculation would show an average 2 added and 2.5 closed per
month could extrapolate to many years of work remaining.
If instead we assume that most tickets are partly done and that the new
tickets are smaller it still points to 6 - 18 months work remaining

With this in mind I think that 1.21 probably needs to be either a subset of
the interface work or somehow revised.
I think whatever we do intend to do we should update the release page so
that the intentions are clear.
I pulled this together to help understand our current plan, not to complain
or point fingers - I hope these thoughts are taken in that spirit.

Let's figure what makes sense for all the expected recipients of our next
major release :)

Andrew

On Thu, 4 Jan 2018 at 06:32 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Wed, 3 Jan 2018 21:09:17 -0500 Michael Blumenkrantz
> <michael.blumenkra...@gmail.com> said:
>
> > On Sat, 23 Dec 2017 19:37:31 +0900
> > Carsten Haitzler <ras...@rasterman.com> wrote:
> >
> > > On Fri, 22 Dec 2017 19:54:02 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > Hi Vincent,
> > > >
> > > > I would really love this too - in fact I have been pushing for it. I
> > > > suggest regularly that it would be helpful to have a roadmap. On my
> most
> > > > recent request I was told bluntly “too much effort, you are the only
> > > > person that wants it”.
> > >
> > > https://phab.enlightenment.org/T5301. you keep telling me "that's not
> a
> > > roadmap".
> > >
> > > comparison table:
> > >
> > > || T5301 | GTK+  |
> > > | Has title  |   X   |   X   |
> > > | Has short description  |   X   |   X   |
> > > | Has longer (multi-parapgraph) descriptions | Some  | Some  |
> > > | Has assignment of who is doing it  |   X   |   X   |
> > > | Has status/priority|   X   |   X   |
> > > | Are a changing "document"  |   X   |   X   |
> > > | Has dependencies   |   X   |   |
> > > | Has discussion thread  |   X   |   |
> > >
> > > OH look there. it has everything your supposed roadmap has and even
> more!
> > > What were you telling me that this is not a roadmap? Please indicate
> > > clearly how it is not as I have clearly shown above that it has
> everything
> > > you claim a roadmap has (you would want that document linked to) and
> even
> > > then some more.
> > >
> > > > If we can get more support for such a document I would be far
> happier to
> > > > push forward again and see it is pulles together.
> > >
> > > The document exists. Stop saying it doesn't. You just want someone to
> write
> > > it up in a table on a wiki page (which is what the GTK+ one is)
> instead of
> > > as tickets. If you want that - then you do it. And maintain it.
> >
> > Unless I've misread the previous mail, Andy has just said that if people
> are
> > in favor of such a page that he is willing to do the work. I'm confused
> by
> > the apparently hostile demeanor of your reply considering that someone
> has
> > just offered to do the work which was requested?
>
> Andy spent several hours in a private IRC /msg session telling me a roadmap
> document doesn't exist, and I kept pointing him to this, sayning that
> maybe it
> can be fleshed out a little more, but all of the essentials are there, the
> him
> repeating it's not a roadmap, then I see these emails pointing to
> something as
> "oh that's a roadmap". and it is i

Re: [E-devel] Phab Task Spam

[Andrew Williams]

Hi,

If we are looking to grow the community don’t you think that “to report a
bug you must be approved by an admin” might be problematic?

Andy
On Thu, 4 Jan 2018 at 06:32, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Wed, 03 Jan 2018 09:51:54 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > Seems like this is something that a managed service would take care of
> for
> > us...
> >
> > https://github.com/blog/1426-spam-spam-spam-spam
>
> Having been burned by managed services before (sf.net)... This discussion
> has
> been rehashed multiple times, so I don't think that's even remotely an
> option.
>
> So either turn off problem registration methods, or move to "every new
> user must
> be approved by admins", which may or may not create more work than
> removing the
> spam.
>
> > On Wed, 3 Jan 2018 at 04:16 Carsten Haitzler <ras...@rasterman.com>
> wrote:
> >
> > > On Wed, 3 Jan 2018 12:37:56 +0900 Carsten Haitzler <
> ras...@rasterman.com>
> > > said:
> > >
> > > > On Tue, 02 Jan 2018 15:52:59 + Mike Blumenkrantz
> > > > <michael.blumenkra...@gmail.com> said:
> > > >
> > > > > Once a week now for the past couple weeks there have been users
> > > registering
> > > > > and creating numerous spam tickets on phab. Can anything be done to
> > > prevent
> > > > > this?
> > > >
> > > > where are they? we could maybe disable account creation via github,
> fb
> > > etc. if
> > > > that's where they come from. or is it via manually registered
> > > accounts+email?
> > > > without samples i don't know.
> > >
> > > never mind. found one: https://phab.enlightenment.org/T6556 .. and a
> > > bunch of
> > > others.  all the same user. at least it's easy to identify the problem
> > > source
> > > of a batch of spam.
> > >
> > > > but requiring a github or fb account to register with phab is, i
> think,
> > > going
> > > > to be a non-starter.
> > > >
> > > > >
> > >
> --
> > > > > 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
> > > >
> > >
> > >
> > > --
> > > - 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
--
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_loop: move scheduler_get to eo API

[Andrew Williams]

Then surely the we are missing something in eina to get the main loop
scheduler?
Moving this code into the efl namespace seems misleading if the intent is
that it would not be part of our bindings.
Eina is, if I understand it, there for the C implementation specifics...

Andy

On Wed, 3 Jan 2018 at 14:54 Gustavo Sverzut Barbieri <barbi...@gmail.com>
wrote:

> On Wed, Jan 3, 2018 at 11:55 AM, Andrew Williams <a...@andywilliams.me>
> wrote:
> > Hi,
> >
> > We need to expose some API for creating an Eina_Future_Scheduler if it is
> > to remain in eina_promise_new.
> > The alternative is that we pass a simple Eo *parent instead and we could
> > keep all the scheduler work internally.
>
>
> Sorry, I don't get what you mean.
>
> What I wrote in my email is that you need to manually write C code to
> get the Eina_Future_Scheduler, as you need to manually write C code to
> call eina_promise_new().
>
> And that this should be nicely integrated into the language-native
> Promise implementation, so it can be chained with other
> promise/future... like in Python. This requires some extra work, it's
> not trivial or auto-generated.
>
>
> --
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (16) 99354-9890 <+55%2016%2099354-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
>


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

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl_loop: move scheduler_get to eo API

[Andrew Williams]

Hi,

We need to expose some API for creating an Eina_Future_Scheduler if it is
to remain in eina_promise_new.
The alternative is that we pass a simple Eo *parent instead and we could
keep all the scheduler work internally.

Andy

On Wed, 3 Jan 2018 at 13:17 Gustavo Sverzut Barbieri <barbi...@gmail.com>
wrote:

> On Wed, Jan 3, 2018 at 11:07 AM, Andrew Williams <a...@andywilliams.me>
> wrote:
> > Hi,
> >
> > I was concerned that, as this had been added in a legacy header, it may
> > need to remain..?
>
> not a legacy header, rather a "eo-only" and "c-only" header... usually
> for things that shouldn't be exposed to bindings, at least on an
> automated way.
>
> eina_promise_new() is the one that uses that function, it's not
> auto-generated by bindings. The idea is that high-level languages
> (Python, C#, C++...) will expose this using their native promise, so
> it's transparent... this all needs manual work, so exposing this
> method in ".eo" to be parseable by eolian will not be useful.
>
> I recall that was the reason to not put it in ".eo", just in eo-only
> and c-only header.
>
>
>
> --
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (16) 99354-9890 <+55%2016%2099354-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
>


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

Re: [E-devel] [EGIT] [core/efl] master 01/01: efl_loop: move scheduler_get to eo API

[Andrew Williams]

Hi,

I was concerned that, as this had been added in a legacy header, it may
need to remain..?

Andrew

On Wed, 3 Jan 2018 at 13:05 Gustavo Sverzut Barbieri 
wrote:

> On Wed, Jan 3, 2018 at 10:46 AM, Andy Williams 
> wrote:
> > ajwillia-ms pushed a commit to branch master.
> >
> >
> http://git.enlightenment.org/core/efl.git/commit/?id=f910ba248e3f8f8390674e79cbbe49582eed861e
> >
> > commit f910ba248e3f8f8390674e79cbbe49582eed861e
> > Author: Andy Williams 
> > Date:   Wed Jan 3 12:46:06 2018 +
> >
> > efl_loop: move scheduler_get to eo API
> > ---
> >  src/lib/ecore/Ecore_Eo.h  |  2 +-
> >  src/lib/ecore/efl_loop.c  |  4 ++--
> >  src/lib/ecore/efl_loop.eo | 11 +++
> >  src/lib/eo/eina_types.eot |  1 +
> >  4 files changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/lib/ecore/Ecore_Eo.h b/src/lib/ecore/Ecore_Eo.h
> > index 77cc3d45e4..290a8be701 100644
> > --- a/src/lib/ecore/Ecore_Eo.h
> > +++ b/src/lib/ecore/Ecore_Eo.h
> > @@ -62,7 +62,7 @@ EAPI int efl_loop_exit_code_process(Eina_Value *value);
> >
> >  #include "efl_loop_consumer.eo.h"
> >
> > -EAPI Eina_Future_Scheduler *efl_loop_future_scheduler_get(Eo *obj);
> > +EAPI Eina_Future_Scheduler *efl_loop_future_scheduler_get(const Eo
> *obj);
>
> you can remove this one, it's generated by eolian.
>
>
>
> --
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (16) 99354-9890 <+55%2016%2099354-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
>


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

Re: [E-devel] Phab Task Spam

[Andrew Williams]

Seems like this is something that a managed service would take care of for
us...

https://github.com/blog/1426-spam-spam-spam-spam

On Wed, 3 Jan 2018 at 04:16 Carsten Haitzler  wrote:

> On Wed, 3 Jan 2018 12:37:56 +0900 Carsten Haitzler 
> said:
>
> > On Tue, 02 Jan 2018 15:52:59 + Mike Blumenkrantz
> >  said:
> >
> > > Once a week now for the past couple weeks there have been users
> registering
> > > and creating numerous spam tickets on phab. Can anything be done to
> prevent
> > > this?
> >
> > where are they? we could maybe disable account creation via github, fb
> etc. if
> > that's where they come from. or is it via manually registered
> accounts+email?
> > without samples i don't know.
>
> never mind. found one: https://phab.enlightenment.org/T6556 .. and a
> bunch of
> others.  all the same user. at least it's easy to identify the problem
> source
> of a batch of spam.
>
> > but requiring a github or fb account to register with phab is, i think,
> going
> > to be a non-starter.
> >
> > >
> --
> > > 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
> >
>
>
> --
> - 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

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

Hi Cedric,

I think I agree, if we can tidy the definitions then everything should get
clearer.

efl_add_ref being needed for bindings implies that our definition of
efl_add was not clean enough in the first place.
If efl_del is "hide and unparent" then maybe what we really need is
efl_gfx_hide and efl_parent_unset - but I don't see why we need to unparent
anyhow...

If we are delegating to a parent to manage the lifecycle of the object then
we should step away from the reference and forget it - that is the most
"convenient" behaviour I guess.

if:
efl_add *always* returned an owned reference and took no parent
efl_add_child *never* returned an owned reference and required a parent

then:
efl_add_ref* would no longer be required right? (if the binding requires a
ref after efl_add_child we have efl_ref that it could wrap up)
efl_del would take a reference and dec (probably not needed as we have
efl_unref?)
efl_del_child seems unlikely to be needed as all that is left is hiding
which is a graphics call, not an eo lifecycle one.

The more I look at it the more I think we have too much UI related thinking
in our object lifecycle.

Andy

On Wed, 3 Jan 2018 at 05:41 Cedric Bail  wrote:

> > The whole efl_del argument just exist because it is kinda poorly
> > named. IMO, del means: get this object to an "empty" state.
> > Just like close to files and hide and unparent to UI objects. efl_del
> > should not steal references under people who owns it, the object
> > would get deleted at a later time when everybody using the object
> > stops doing so, we could even return errors from efl_del'eted
> > objects for methods that do not make sense anymore, causing
> > most actions to, possibly, halt earlier rather than later.
>
> So, if efl_del does not still a references under people who owns it, how
> do we fix it ? Should it still magically reset its parent to NULL when
> there is one and just efl_unref in the other case ? Should it be symetric
> to efl_add_ref and always reset the parent to NULL along with unref ? Or
> should it do none of this at all and you have to manually do the parent set
> and the unref ?
>
> Trying to figure out what behavior would make it work for binding, I would
> 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

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

Wow, I guess I walked into that with my "... whatever ..." so let's go 1
step simpler still:

void some_api(Eo *parent) {
   Eo *var = efl_add(SOME_CLASS, parent);

   printf("I got an Eo %p, %s\n", var, efl_name_get(var));

   // TODO figure whether or not I should release var
   efl_unref(var); // ???
}

This is still not clear as we don't know what parent was used. Compare to:

void some_api(void) {
   char *ptr = malloc(10);

   printf("Got pointer %p\n", ptr);

   free(ptr);
}

Here it is clear. malloc always returns a memory handle that must be freed.

Are you seeing the confusion yet? I don't think I have it in me to explain
any further.
What I really want to avoid is having people confused by our new API and
having to review this again in retrospect a few years down the line.

Andy

On Wed, 3 Jan 2018 at 03:59 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Tue, 02 Jan 2018 19:19:37 + Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi,
> >
> > I am obviously struggling to explain this with words, so will try with
> code.
> > Take the following code fragment:
> >
> > void some_api(Eo *parent) {
> >Eo *var = efl_add(SOME_CLASS, parent);
> >
> >... do some stuff with var (possible, acknowledged, race condition)
> ...
> >
> >// TODO figure whether or not I should release var
> >efl_unref(var); // ???
> > }
> >
> > In that code how can I know the correct behaviour without inspecting the
> > content of parent?
>
> the same as:
>
> void some_api(...) {
>char *ptr = malloc(10);
>...
>free(ptr); // ???
> }
>
> you do NOT know if you are to free or not ... it depends what you do with
> ptr
> between malloc and end of scope. do you pass the ptr to another func to
> consume it or not?stick it in a list or array to store it? this is life in
> C. C
> is not java.
>
> parent here is an explicit store like a list or array. store this object in
> this parent (if not null). it's explicit.
>
> > If I am a user of this API I would expect to be able to read code and
> > understand if the correct objects have been released.
> > With the last line this may be released too soon, without it we may have
> a
> > memory leak...
>
> reading your sample code says to me "this object REQUIRES a parent"
> otherwise
> why would you pass in a parent var at all? you'd use NULL if it doesn't.
>
> > Does that help?
> > Andy
> >
> > On Wed, 27 Dec 2017 at 07:15 Carsten Haitzler <ras...@rasterman.com>
> wrote:
> >
> > > On Tue, 26 Dec 2017 17:46:50 -0200 Felipe Magno de Almeida
> > > <felipe.m.alme...@gmail.com> said:
> > >
> > > > JP, Cedric, me and TAsn have been having this argument for a while.
> > > >
> > > > IMO, the whole problem is that we're thinking of ownership in terms
> > > > of parentship, which is wrong with reference counting. Ownership
> > > > is shared between all reference owners and that's it. That's also
> > > > the only sane way for bindings to work without having references
> > > > being pull under their feet.
> > > >
> > > > The whole efl_del argument just exist because it is kinda poorly
> > > > named. IMO, del means: get this object to an "empty" state.
> > > > Just like close to files and hide and unparent to UI objects. efl_del
> > > > should not steal references under people who owns it, the object
> > > > would get deleted at a later time when everybody using the object
> > > > stops doing so, we could even return errors from efl_del'eted
> > > > objects for methods that do not make sense anymore, causing
> > > > most actions to, possibly, halt earlier rather than later.
> > > >
> > > > 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.
> > >
> > > that's actually what happens, why efl_add_ref ends up with a refcount
> of
> > > 2, and
> > > efl_add has a refcount of 1 (if parent is non-null). efl_add if parent
> is
> > > not
> > > null is doing a parent_set during add. it's taking the "convenience"
> that
> > > the
> > > parent is transferred from scope to parent just so you dont have to
> unref
> > > at
> > > end of scope manually - in c that is. we're really just talking c here.
> > >
> > > > Fo

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

Hi,

I am obviously struggling to explain this with words, so will try with code.
Take the following code fragment:

void some_api(Eo *parent) {
   Eo *var = efl_add(SOME_CLASS, parent);

   ... do some stuff with var (possible, acknowledged, race condition) ...

   // TODO figure whether or not I should release var
   efl_unref(var); // ???
}

In that code how can I know the correct behaviour without inspecting the
content of parent?

If I am a user of this API I would expect to be able to read code and
understand if the correct objects have been released.
With the last line this may be released too soon, without it we may have a
memory leak...

Does that help?
Andy

On Wed, 27 Dec 2017 at 07:15 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Tue, 26 Dec 2017 17:46:50 -0200 Felipe Magno de Almeida
> <felipe.m.alme...@gmail.com> said:
>
> > JP, Cedric, me and TAsn have been having this argument for a while.
> >
> > IMO, the whole problem is that we're thinking of ownership in terms
> > of parentship, which is wrong with reference counting. Ownership
> > is shared between all reference owners and that's it. That's also
> > the only sane way for bindings to work without having references
> > being pull under their feet.
> >
> > The whole efl_del argument just exist because it is kinda poorly
> > named. IMO, del means: get this object to an "empty" state.
> > Just like close to files and hide and unparent to UI objects. efl_del
> > should not steal references under people who owns it, the object
> > would get deleted at a later time when everybody using the object
> > stops doing so, we could even return errors from efl_del'eted
> > objects for methods that do not make sense anymore, causing
> > most actions to, possibly, halt earlier rather than later.
> >
> > 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.
>
> that's actually what happens, why efl_add_ref ends up with a refcount of
> 2, and
> efl_add has a refcount of 1 (if parent is non-null). efl_add if parent is
> not
> null is doing a parent_set during add. it's taking the "convenience" that
> the
> parent is transferred from scope to parent just so you dont have to unref
> at
> end of scope manually - in c that is. we're really just talking c here.
>
> > 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,
>
> that was precisely the vote and discussion back in 2014. so while what we
> have
> in c is not "strictly correct" (so to speak) it's far more convenient than
> forcing people to manually unref at end of scope.
>
> > 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.
>
> that'd be efl_add_ref() for bindings where scope is auto-managed by the
> language (as above), and efl_add for c. if you want to write c in the
> "strict
> scope references" way like these other languages, then efl_add_ref is
> there for
> that. it's going to be inconvenient and requires you to handle scope
> cleaning
> correctly. with some gcc extensions this can actually be automated, but the
> problem is we have to have our api work without such extensions.
>
> you can use __attribute__ ((__cleanup__(efl_unref))) on such vars in
> gcc... but
> it's non-standard. if this was standard across all major compilers then
> this
> whole argument would be moot. we're have efl_add behave like efl_add_ref
> all
> the time and require all objects handles to be unique in scope and have
> some
> macro to declare the object handle with the above attributes and you have
> to
> compile with -fexceptions to handle c++ exception unwinding if it goes
> through
> some c code along the way but as i said. it's non-standard. we can't
> rely
> on it.
>
> > 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.
> >
> > So, #4 on the original OP should be treated as a bug if we
> > consider efl_add as efl_add_scope, but we also need
> > to fix parent_set/parent_unset. And code must not unref
> > 

Re: [E-devel] Site statistics

[Andrew Williams]

Hi,

Oh dear I read the stats wrong - it's 3% not 15% - still, nice to see
relatively consistent usage outside the active documentation work.

Andy

On Tue, 2 Jan 2018 at 18:35 Andrew Williams <a...@andywilliams.me> wrote:

> Hi,
>
> With regards to the beta API perhaps being related to the active work on
> it here is an update:
> Over the Christmas week we were not working on those pages. In that period
> the overall access percentage went from 5% of our site hits to 15%.
>
> I think the pinch of salt got smaller,
> Andy
>
> On Wed, 20 Dec 2017 at 02:13 Carsten Haitzler <ras...@rasterman.com>
> wrote:
>
>> On Mon, 18 Dec 2017 12:23:08 + Andrew Williams <a...@andywilliams.me>
>> said:
>>
>> > Hi all.
>> >
>> > Since adding Google Analytics a while back I have some interesting
>> > statistics that I thought I would share:
>> >
>> > 1) Very few people read our Stable API documentation - around 0.5% of
>> our
>> > page hits
>> > 2) Over 5% of the page hits are already for the beta API documentation
>>
>> I'm willing to bet that this is mostly because of the work going on on
>> these
>> and "checking the work when done" etc. and not "real traffic". At least
>> until
>> this settles down I'd take these numbers with a grain of salt then look at
>> again.
>>
>> > 3) Most of the hits to /docs seem to result in a referral to /develop
>> > 4) Nearly 40% of people landing on our home page leave right away
>>
>> Not surprising. enlightenment is a common word.
>>
>> > 5) Terminology is the most popular app (by page hits) and Edi is second
>> > (1/4 times the hits) then ephoto (1/4 again)
>>
>> Also not surprising. :)
>>
>> > Not all of this requires any action but here is the action plan:
>> > 1) I am not intending to put any further effort into our legacy API
>> other
>> > than the extraction of eina and eo for the Beta API docs
>>
>> Like others said. I think this might be a mistake. The legacy API is
>> going to
>> be around and supported for years to come. Sure. eo/eina is important in
>> where
>> we're going, but the legacy docs maybe should at least just be made to be
>> "not
>> broken" as much as is sanely possible. Not saying we should go WRITE more
>> docs
>> there... That's all. Unless this is what you had in mind?
>>
>> > 2) We can expect more people to be trying to use our Beta API - do we
>> need
>> > to prepare for this or should we put up more obvious warnings about
>> > attempting?
>>
>> I thought the need for a #define to enable them was enough... perhaps
>> some more
>> #warnings IF that define is set AND it's not the efl build itself... ? I
>> still
>> think it's far too early to stabilize any of this. Even futures are still
>> "not
>> done" and in flux. As is ecore (efl loop and friends/related).
>>
>> > 3) I think it is time that the main "Develop" link goes to the /develop/
>> > dokuwiki. The link to phab exists on the /contrib page where it belongs
>>
>> I guess that depends on the interpretation of "Develop". Developing as in
>> a
>> USEE of EFL libraries and their APIs, or developing as in working on
>> E/EFL/etc.
>> and EFL API's. It's a fine distinction.
>>
>> > 4) We should find a way to make our home page more appealing - when
>> loaded
>> > on an average monitor you need to be full screen to see anything more
>> than
>> > the "Window manager" section.
>>
>> Indeed it could be nicer. Using a wiki limits our formatting abilities as
>> it's
>> simpler. I would have just had large screenshots of lots of stuff to
>> start with
>> instead of text as really "oooh aaah pretty images" really works. At least
>> "front and foremost". But I'm holding off on doing this until flat theme
>> is
>> done. At least then it'll be "oh finally they're flat" reactions.
>>
>> How to present those screenshots... that is in and of itself a good
>> question.
>> like a big horizontal banner then with a small bit of text (and links)
>> below,
>> one after the other? One of those lightbox things that keeps flipping
>> multiple
>> images with some js (would need a wiki plugin). for some things videos or
>> animated gifs might actually be the best as the wow factor is in watching
>> it
>> move and react. Yes - it's a bandwidth hog, but it should have a 

Re: [E-devel] Site statistics

[Andrew Williams]

Hi,

With regards to the beta API perhaps being related to the active work on it
here is an update:
Over the Christmas week we were not working on those pages. In that period
the overall access percentage went from 5% of our site hits to 15%.

I think the pinch of salt got smaller,
Andy

On Wed, 20 Dec 2017 at 02:13 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Mon, 18 Dec 2017 12:23:08 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi all.
> >
> > Since adding Google Analytics a while back I have some interesting
> > statistics that I thought I would share:
> >
> > 1) Very few people read our Stable API documentation - around 0.5% of our
> > page hits
> > 2) Over 5% of the page hits are already for the beta API documentation
>
> I'm willing to bet that this is mostly because of the work going on on
> these
> and "checking the work when done" etc. and not "real traffic". At least
> until
> this settles down I'd take these numbers with a grain of salt then look at
> again.
>
> > 3) Most of the hits to /docs seem to result in a referral to /develop
> > 4) Nearly 40% of people landing on our home page leave right away
>
> Not surprising. enlightenment is a common word.
>
> > 5) Terminology is the most popular app (by page hits) and Edi is second
> > (1/4 times the hits) then ephoto (1/4 again)
>
> Also not surprising. :)
>
> > Not all of this requires any action but here is the action plan:
> > 1) I am not intending to put any further effort into our legacy API other
> > than the extraction of eina and eo for the Beta API docs
>
> Like others said. I think this might be a mistake. The legacy API is going
> to
> be around and supported for years to come. Sure. eo/eina is important in
> where
> we're going, but the legacy docs maybe should at least just be made to be
> "not
> broken" as much as is sanely possible. Not saying we should go WRITE more
> docs
> there... That's all. Unless this is what you had in mind?
>
> > 2) We can expect more people to be trying to use our Beta API - do we
> need
> > to prepare for this or should we put up more obvious warnings about
> > attempting?
>
> I thought the need for a #define to enable them was enough... perhaps some
> more
> #warnings IF that define is set AND it's not the efl build itself... ? I
> still
> think it's far too early to stabilize any of this. Even futures are still
> "not
> done" and in flux. As is ecore (efl loop and friends/related).
>
> > 3) I think it is time that the main "Develop" link goes to the /develop/
> > dokuwiki. The link to phab exists on the /contrib page where it belongs
>
> I guess that depends on the interpretation of "Develop". Developing as in a
> USEE of EFL libraries and their APIs, or developing as in working on
> E/EFL/etc.
> and EFL API's. It's a fine distinction.
>
> > 4) We should find a way to make our home page more appealing - when
> loaded
> > on an average monitor you need to be full screen to see anything more
> than
> > the "Window manager" section.
>
> Indeed it could be nicer. Using a wiki limits our formatting abilities as
> it's
> simpler. I would have just had large screenshots of lots of stuff to start
> with
> instead of text as really "oooh aaah pretty images" really works. At least
> "front and foremost". But I'm holding off on doing this until flat theme is
> done. At least then it'll be "oh finally they're flat" reactions.
>
> How to present those screenshots... that is in and of itself a good
> question.
> like a big horizontal banner then with a small bit of text (and links)
> below,
> one after the other? One of those lightbox things that keeps flipping
> multiple
> images with some js (would need a wiki plugin). for some things videos or
> animated gifs might actually be the best as the wow factor is in watching
> it
> move and react. Yes - it's a bandwidth hog, but it should have a huge
> impact vs
> stills. Perhaps again - a wiki plugin with a "still image" until you
> mouseover
> or maybe click/tap then the video/animated gif is loaded and plays? I don't
> know. just trying a more concrete idea "float".
>
> > 5) For our about page we may need to tell a better story about how it all
> > fits together. Otherwise it's E & EFL and a list of apps - not the how or
> > why of what we are doing...
>
> Yes. Also the main pages like about need to just have less text and more
> pictures. Reality is few will want to go through a wall of text. The wall
> of
> text should be "f

Re: [E-devel] Site statistics

[Andrew Williams]

Hi,

As there was no blocker on #3 I have changed our "Devel" link from phab to
be our /develop/ documentation (and changed it to "Develop" for clarity).

If you have bookmarked the E site but not phab and used that a lot you  can
still get it at "Contrib" -> "Phabricator" so it's just one click further.

I hope this helps get more browsing developers find what they are looking
for.
Andy

On Mon, 18 Dec 2017 at 12:23 Andrew Williams <a...@andywilliams.me> wrote:

> Hi all.
>
> Since adding Google Analytics a while back I have some interesting
> statistics that I thought I would share:
>
> 1) Very few people read our Stable API documentation - around 0.5% of our
> page hits
> 2) Over 5% of the page hits are already for the beta API documentation
> 3) Most of the hits to /docs seem to result in a referral to /develop
> 4) Nearly 40% of people landing on our home page leave right away
> 5) Terminology is the most popular app (by page hits) and Edi is second
> (1/4 times the hits) then ephoto (1/4 again)
>
> Not all of this requires any action but here is the action plan:
> 1) I am not intending to put any further effort into our legacy API other
> than the extraction of eina and eo for the Beta API docs
> 2) We can expect more people to be trying to use our Beta API - do we need
> to prepare for this or should we put up more obvious warnings about
> attempting?
> 3) I think it is time that the main "Develop" link goes to the /develop/
> dokuwiki. The link to phab exists on the /contrib page where it belongs
> 4) We should find a way to make our home page more appealing - when loaded
> on an average monitor you need to be full screen to see anything more than
> the "Window manager" section.
> 5) For our about page we may need to tell a better story about how it all
> fits together. Otherwise it's E & EFL and a list of apps - not the how or
> why of what we are doing...
>
> Please shout if you disagree with any of these action points :)
>
> Andrew
> --
> 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

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

In the books I have read they consider null being a special case of
behaviour within a method just as confusing as passing a bool like in your
illustration.

Andy

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

> Hi,
>
> With the proposal of efl_add and efl_add_child we remove the need for
> efl_add_ref* as the result of the former becomes consistent in its return
> of owned or not owned references.
> Hopefully Cedric can confirm this as I don’t know the spec.
> Right now we have a second one because the first is not consistently
> returning pointers that either do or do not need to be unrefd.
>
> Andy
> On Tue, 26 Dec 2017 at 04:25, Carsten Haitzler <ras...@rasterman.com>
> wrote:
>
>> On Sun, 24 Dec 2017 09:16:08 + Andrew Williams <a...@andywilliams.me>
>> said:
>>
>> > Are you trolling me now?
>>
>> no. you said its inconsistent. it's consistent. it has a simple rule.
>>
>> http://www.dictionary.com/browse/consistent
>>
>> it consistently adheres to the same principles. i described them.
>>
>> > A method that does two different things depending on some magic value /
>>
>> it's not a MAGIC value. it's a parent object handle. it's far from magic.
>> it's
>> "put this object into THIS box here, or into NO box and give it to me"
>> based on
>> that option.
>>
>> > null flag is a code smell (see Clean Coders if this is not familiar).
>> > Consider this method:
>> >
>> > ptr get_mem(string poolname, long bytes) {
>> > If (poolname == NULL)
>> > return malloc(bytes); // MUST be freed
>> > else
>> > return get_pool(poolname).borrow(bytes); // must NOT be freed
>> > }
>> >
>> > Do you think that is consistent? The user is not sure without inspecting
>> > the parameter contents whether or not the should free(). This is
>> > conceptually what we are setting up.
>>
>> #define efl_add_noparent(klass, ...) efl_add(klass, NULL, ## __VA_ARGS__)
>>
>> happy? you can have a macro to hide the parent if NULL. but it'll be used
>> fairly rarely.
>>
>> > Back to our efl_add - what would be consistent is this:
>> >
>> > Eo* efl_add(klass, ... constructors ...); // must be unrefd (no parent)
>> >
>> > Eo* efl_add_child(klass, parent, ... constructors ... ); // parent must
>> not
>> > be null, should not be unrefd
>> >
>> > That is consistent. It is also compliant with the V7 vote. It still has
>> the
>> > race condition but is much easier to read. I know from the method names
>> > what is expected.
>>
>> your proposal was to have efl_add return void. the above is better for
>> sure. i
>> see we were walking down similar paths.
>>
>> i still dislike the above because it just makes the api more verbose for
>> the
>> sake of special-casing "parent == NULL". i dislike it. this isn't a magic
>> "bool" that turns on or off behaviour. that is actually not great. you
>> read code
>> like
>>
>> func_do_something(obj, EINA_TRUE, EINA_FALSE, EINA_TRUE);
>>
>> ... and what are the 3 bools? it's not clear or obvious. but with a
>> constructor
>> like efl_add firstly it's incredibly common so it's something that will be
>> learned very quickly, and the typing already tells you it's an object
>> handle.
>> and you should have learned already that it's the parent object (or no
>> parent
>> at all if NULL).
>>
>> why do i dislike it? we now go from 2 constructors (efl_add and
>> efl_add_ref) to
>> 4 (efl_add, efl_child_add, efl_add_ref, efl_child_add_ref). i dislike this
>> "explosion" just to hide the parent arg being NULL.
>>
>> > Thoughts?
>> > On Sun, 24 Dec 2017 at 03:33, Carsten Haitzler <ras...@rasterman.com>
>> wrote:
>> >
>> > > On Sat, 23 Dec 2017 11:30:58 + Andrew Williams <
>> a...@andywilliams.me>
>> > > said:
>> > >
>> > > > Hi,
>> > > >
>> > > > As this thread seems to be descending into word games and (insert
>> > > > appropriate word) contests I will reiterate my concern:
>> > > >
>> > > > efl_add is inconsistent and that should be addressed.
>> > >
>> > > do it's not. i explained already that it is not. i'll repeat again.
>> it's
>> > > consistent:
>> > >
>> > > if parent == valid object, then ref is owned by parent

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

Hi,

With the proposal of efl_add and efl_add_child we remove the need for
efl_add_ref* as the result of the former becomes consistent in its return
of owned or not owned references.
Hopefully Cedric can confirm this as I don’t know the spec.
Right now we have a second one because the first is not consistently
returning pointers that either do or do not need to be unrefd.

Andy
On Tue, 26 Dec 2017 at 04:25, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Sun, 24 Dec 2017 09:16:08 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > Are you trolling me now?
>
> no. you said its inconsistent. it's consistent. it has a simple rule.
>
> http://www.dictionary.com/browse/consistent
>
> it consistently adheres to the same principles. i described them.
>
> > A method that does two different things depending on some magic value /
>
> it's not a MAGIC value. it's a parent object handle. it's far from magic.
> it's
> "put this object into THIS box here, or into NO box and give it to me"
> based on
> that option.
>
> > null flag is a code smell (see Clean Coders if this is not familiar).
> > Consider this method:
> >
> > ptr get_mem(string poolname, long bytes) {
> > If (poolname == NULL)
> > return malloc(bytes); // MUST be freed
> > else
> > return get_pool(poolname).borrow(bytes); // must NOT be freed
> > }
> >
> > Do you think that is consistent? The user is not sure without inspecting
> > the parameter contents whether or not the should free(). This is
> > conceptually what we are setting up.
>
> #define efl_add_noparent(klass, ...) efl_add(klass, NULL, ## __VA_ARGS__)
>
> happy? you can have a macro to hide the parent if NULL. but it'll be used
> fairly rarely.
>
> > Back to our efl_add - what would be consistent is this:
> >
> > Eo* efl_add(klass, ... constructors ...); // must be unrefd (no parent)
> >
> > Eo* efl_add_child(klass, parent, ... constructors ... ); // parent must
> not
> > be null, should not be unrefd
> >
> > That is consistent. It is also compliant with the V7 vote. It still has
> the
> > race condition but is much easier to read. I know from the method names
> > what is expected.
>
> your proposal was to have efl_add return void. the above is better for
> sure. i
> see we were walking down similar paths.
>
> i still dislike the above because it just makes the api more verbose for
> the
> sake of special-casing "parent == NULL". i dislike it. this isn't a magic
> "bool" that turns on or off behaviour. that is actually not great. you
> read code
> like
>
> func_do_something(obj, EINA_TRUE, EINA_FALSE, EINA_TRUE);
>
> ... and what are the 3 bools? it's not clear or obvious. but with a
> constructor
> like efl_add firstly it's incredibly common so it's something that will be
> learned very quickly, and the typing already tells you it's an object
> handle.
> and you should have learned already that it's the parent object (or no
> parent
> at all if NULL).
>
> why do i dislike it? we now go from 2 constructors (efl_add and
> efl_add_ref) to
> 4 (efl_add, efl_child_add, efl_add_ref, efl_child_add_ref). i dislike this
> "explosion" just to hide the parent arg being NULL.
>
> > Thoughts?
> > On Sun, 24 Dec 2017 at 03:33, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> >
> > > On Sat, 23 Dec 2017 11:30:58 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > Hi,
> > > >
> > > > As this thread seems to be descending into word games and (insert
> > > > appropriate word) contests I will reiterate my concern:
> > > >
> > > > efl_add is inconsistent and that should be addressed.
> > >
> > > do it's not. i explained already that it is not. i'll repeat again.
> it's
> > > consistent:
> > >
> > > if parent == valid object, then ref is owned by parent
> > > else ref is owned by caller/scope.
> > >
> > > that is consistent.
> > >
> > > > I hope that is clear enough
> > > > Andy
> > > >
> > > >
> > > > On Thu, 21 Dec 2017 at 13:15, Andrew Williams <a...@andywilliams.me>
> > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > This is now well documented (
> > > > > https://www.enlightenment.org/develop/tutorials/c/eo-refcount.md)
> but
> > > the
> > > > > more I use efl_add the more I feel it is confusing especially to
> new
> &

Re: [E-devel] is there a roadmap for future significative improvements/changes

[Andrew Williams]

You're quit right that document is really more of a checklist. Which now I
look more closely is exactly what they called it too.
Their roadmap document is actually
https://wiki.gnome.org/Projects/GTK+/Roadmap .

Anyhow for clarity what I feel we are missing in our "roadmap" is:

* What are we aiming for
* What are the milestones along the way
* What is the scope of the project and milestones
* (Ideally) At what stage is it ready for external feedback etc

Whilst presentation matters to an extent I don't think it has to be a table
or wiki page - though they are typically much easier to read as a quick
summary.

As you can see from the list above it is, in my mind, a document that
covers far more than is currently documented in our tickets
Whilst I would be happy to write and maintain such a document I am
concerned about the significant risk of it not matching your desires or
expectations.
As the community leader it is something that I thought you could pull
together but I don't know who else can speak for the community effort.

Just my thoughts,
Andy

On Sat, 23 Dec 2017 at 10:57 Carsten Haitzler  wrote:

> On Fri, 22 Dec 2017 17:56:54 +0100 Vincent Torri 
> said:
>
> > hello
> >
> > i've recently seen this gtk roadmap :
> > https://wiki.gnome.org/Projects/GTK%2B/Roadmap/GTK4
> >
> > is there the same for EFL ?
>
> https://phab.enlightenment.org/T5301
>
> specifically for eo/interfaces.
>
> there's parallel work for wayland. that's about it for major work going on.
>
> > Vincent
> >
> >
> --
> > 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

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

Hi,

Yes invalid access is easier to debug than a memory lean, in general.
In this situation we are talking about the possible consistent memory leaks
vs the occasional (race condition) undefined access. The latter is not
easier to debug.

And if we did find the line at error it would look (using the designed
efl_add behaviour) completely reasonable - what would the fix even be?

Andy

On Sun, 24 Dec 2017 at 03:33, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Sat, 23 Dec 2017 11:19:59 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > As framework developers we should be doing everything in our power to
> avoid
> > undefined behaviour. I’ll take accidents memory leaks any day - there
> are a
> > plethora of tools to solve that but it’s far harder to debug the “app not
> > working correctly sometimes on my system” bug reports.
>
> actually no. we should be doing everything we can to make things EASY.
> avoiding
> undefined behaviour is one way of making things easier. having to write
> less
> code and it be HARDER to write things that have bad side-effects is also
> making
> things easier.
>
> if you don't leak large amounts of objects you will not have tools find it
> easy
> to find such leaks. if you leak LOTs (1000's or more objects in one place)
> then
> you can probably find it by spotting an excessive allocation point in
> something
> like massif, BUT nothing will detect a leaked pointer, because eoid
> maintains a
> pointer to the object in the eoid object table. the pointer is actually
> never
> lost. it's tracked by eo. so no. leak check tools won't work. maybe "still
> allocated on shutdown" might unless you have a LOT of that data which is a
> lot
> of work to ensure is done. there are lots of allocations on exit from efl,
> glibc and other places already (that are harmless).
>
> invalid access as i explained is directly ind immediately debuggable.
> leaks -
> not so much.
>
> but regardless of that the votes already were vastly for the thing we have
> today.
>
> > Andy
> >
> > On Sat, 23 Dec 2017 at 10:56, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> >
> > > On Fri, 22 Dec 2017 11:53:32 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > We do have a showstopper design bug.
> > >
> > > see my previous mail. https://phab.enlightenment.org/V7 to be
> explicit.
> > > discussed. voted on. known compromise. lots of code built on top of
> that
> > > design
> > > decision. not a showstopper by any stretch. it's exactly what gtk
> does. the
> > > only difference is we have the "parent set" be part of the add and gtk
> > > does it
> > > as a separate step with container_add()
> > >
> > > > We are managing to work with it because we know how it works
> internally.
> > > > The API must be straight forward and provide consistent, robust
> options.
> > > >
> > > > Any new user would be asking of efl_add:
> > > > *) Do I need to unref the result when I am done?
> > > > *) How long is my returned reference valid for?
> > >
> > > see the vote. see gtk samples. floating reference.
> > >
> > > > Both of those are answered with "it depends" and that is a design
> > > > showstopper.
> > >
> > > disagree. it's clear. if parent is NULL then calling scope gets a
> > > floating reference you have to unref. if not then parent owns that
> > > reference and the rules of that parent cover lifetime of that object.
> > > covered
> > > that in prior mails - the alternative is to force people to manually
> unref
> > > every time they want a handle to something at all to do useful things
> with
> > > ...
> > > like add a child to this parent (child packed into a box parent for
> > > example).
> > > see the gtk/gobject design doc with the idea of floating references.
> see
> > > the
> > > previous discussion thread. see the vote in favor of what is there now
> and
> > > with
> > > everyone fully aware of scoping etc. and that is why efl_add_ref
> exists if
> > > you
> > > choose to use that.
> > >
> > > note for this discussion i am assuming scope is a small local function
> > > scope
> > > not larger. technically it can be the global scope of the entire app.
> > >
> > > i'll put it simply:
> > >
> > > 1: do it your way and people will have to always unref at end of scope
>

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

The proposal has 0 occurrences of “NULL”.

Andy

On Sun, 24 Dec 2017 at 03:33, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Sat, 23 Dec 2017 11:26:42 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi,
> >
> > Thanks for posting that poll. Very useful.
> > If I may I wish to contradict your assertion that this has all been
> > discussed before - the poll had *0* consideration for what if parent is
> > NULL.
>
> i don't see why it needed to. NULL == no parent, thus floating ref.
> non-NULL
> and the ref is immediately handed to the parent object. (assuming non-null
> is
> also a valid object).
>
> > If you re-read the accepted proposal you will see that is not the current
> > behaviour at all. There is a (relatively) explicit handing of the
> reference
> > which can occur *after* I am finished with the reference.
> > In short the proposal that was voted for did not have this race condition
> > by design.
>
> the proposal of course considers NULL. how do you create the win? at the
> time
> we had no loop object or had yet discussed it, so windows would have been
> created with a NULL parent.
>
> the core is the same. you want efl_add to return nothing (void) which
> makes it
> useless for creating a container (win, box, button, etc. etc.) which is a
> huge
> use case of objects at construction etc. ... which means we'd need to use
> efl_add_ref() instead. or something that is the same (and you say this too
> saying you then need to unref). and the whole idea of having to unref at
> end of
> scope during creation was voted against. the same arguments i have been
> making
> - it's less error prone to not have to unref. it's commonly seen enough in
> c
> (gtk does it for example) etc. etc.
>
> > And so it follows that we are currently working with a third option that
> > was not part of the vote.
>
> i don't see it that way. it's the same. if you remove the return from
> efl_add()
> (returns void and deletes the object if parent is NULL) then the proposal
> you
> have is to use efl_add_Ref for all these cases where you do need the
> return and
> that is what was voted on already. even if today > 50% of devs voted for
> this
> i'd still say "don't change" due to the sheer cost of change as i've
> explained.
> my answer is "use efl_add_ref then if this bothers you and remember to
> unref,
> but now you are the one holding the bag. we advised against this by
> default".
> the thing you want is there d available for use. i and most developers
> would
> advise against it (see vote).
>
> > Same with gtk, apologies for misreading initially, they hand the
> reference
> > over when they are done.
>
> correct. and we hand it over "in one go" in efl_add. it amounts to the
> same.
>
> > One last thought - safety is broader than not crashing. If we have put in
> > place methods to catch corner cases in our design then perhaps our design
> > is not solid enough?
>
> eoid catches this case not because it was meant to catch the corner case
> you
> speak of (parent deletes child while you still have the object handle in
> scope) or other corner cases, but because of a more general problem of
> lots of
> problems with developers unable to understand magic checks with invalid
> object
> refs in general (mostly far far far later than scope usage), and simply
> handing
> off the bug as "an efl bug" because it crashed inside an efl function (even
> though the crash was in the magic check which de referenced a pointer
> pointing
> out of memory space). it happens to be a very safe mechanism to access our
> objects and it happens to deal with the case you speak of.
>
> > Andy
> >
> > On Sat, 23 Dec 2017 at 10:56, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> >
> > > On Fri, 22 Dec 2017 11:44:32 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > Hi,
> > > >
> > > > I think your summary about the Gtk is not what you think - read the
> docs
> > > > further
> > > >
> https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-new
> > > and
> > > > you see that actually the trivial example leaks the reference - just
> like
> > > > an efl_add_ref with no unref or del later.
> > > > They are *not* returning a pointer where you can expect to lose
> ownership
> > > > at some future time. Notice also they do not pass parents to the
> > > > constructors.
> > >
> > > ummm no. that's wron

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

Are you trolling me now?

A method that does two different things depending on some magic value /
null flag is a code smell (see Clean Coders if this is not familiar).
Consider this method:

ptr get_mem(string poolname, long bytes) {
If (poolname == NULL)
return malloc(bytes); // MUST be freed
else
return get_pool(poolname).borrow(bytes); // must NOT be freed
}

Do you think that is consistent? The user is not sure without inspecting
the parameter contents whether or not the should free(). This is
conceptually what we are setting up.

Back to our efl_add - what would be consistent is this:

Eo* efl_add(klass, ... constructors ...); // must be unrefd (no parent)

Eo* efl_add_child(klass, parent, ... constructors ... ); // parent must not
be null, should not be unrefd

That is consistent. It is also compliant with the V7 vote. It still has the
race condition but is much easier to read. I know from the method names
what is expected.

Thoughts?
On Sun, 24 Dec 2017 at 03:33, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Sat, 23 Dec 2017 11:30:58 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi,
> >
> > As this thread seems to be descending into word games and (insert
> > appropriate word) contests I will reiterate my concern:
> >
> > efl_add is inconsistent and that should be addressed.
>
> do it's not. i explained already that it is not. i'll repeat again. it's
> consistent:
>
> if parent == valid object, then ref is owned by parent
> else ref is owned by caller/scope.
>
> that is consistent.
>
> > I hope that is clear enough
> > Andy
> >
> >
> > On Thu, 21 Dec 2017 at 13:15, Andrew Williams <a...@andywilliams.me>
> wrote:
> >
> > > Hi,
> > >
> > > This is now well documented (
> > > https://www.enlightenment.org/develop/tutorials/c/eo-refcount.md) but
> the
> > > more I use efl_add the more I feel it is confusing especially to new
> > > developers.
> > >
> > > In the current model (if I understand it correctly)
> > > 1) child = efl_add(klass, parent) means the child must NOT be
> unfeferenced
> > > 2) child = efl_add(klass, NULL) means the child should be unreferenced
> > > 3) child = efl_add_ref(klass, parent) means the child must be
> unreferenced
> > > 4) child = efl_add_ref(klass, NULL) somehow means that the child
> should be
> > > unreferenced twice
> > >
> > > In my opinion 1) and 4) are peculiar and so I provide a proposal to fix
> > > this:
> > >
> > > We could change efl_add to return void. It never retains a reference.
> If
> > > the parent is NULL then it should be automatically unref before
> returning.
> > > Then efl_add_ref would be changed to mirror this and always retain
> exactly
> > > 1 reference - so if parent is NULL there is no double count returned.
> > >
> > > Using this model if an Eo * is returned then I know I have a reference
> and
> > > must later unref.
> > > Any need for using the pointer in an efl_add (which is no longer
> returned)
> > > would still be supported through efl_added within the constructor.
> > >
> > > What do people think about this? I put the suggestion forward to
> improve
> > > the symettry with add and unref which is currently confusing. If my
> > > assumptions above are incorrect please let me know!
> > >
> > > Thanks,
> > > Andy
> > > --
> > > 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
>
> --
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

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

Hi,

As this thread seems to be descending into word games and (insert
appropriate word) contests I will reiterate my concern:

efl_add is inconsistent and that should be addressed.

I hope that is clear enough
Andy


On Thu, 21 Dec 2017 at 13:15, Andrew Williams <a...@andywilliams.me> wrote:

> Hi,
>
> This is now well documented (
> https://www.enlightenment.org/develop/tutorials/c/eo-refcount.md) but the
> more I use efl_add the more I feel it is confusing especially to new
> developers.
>
> In the current model (if I understand it correctly)
> 1) child = efl_add(klass, parent) means the child must NOT be unfeferenced
> 2) child = efl_add(klass, NULL) means the child should be unreferenced
> 3) child = efl_add_ref(klass, parent) means the child must be unreferenced
> 4) child = efl_add_ref(klass, NULL) somehow means that the child should be
> unreferenced twice
>
> In my opinion 1) and 4) are peculiar and so I provide a proposal to fix
> this:
>
> We could change efl_add to return void. It never retains a reference. If
> the parent is NULL then it should be automatically unref before returning.
> Then efl_add_ref would be changed to mirror this and always retain exactly
> 1 reference - so if parent is NULL there is no double count returned.
>
> Using this model if an Eo * is returned then I know I have a reference and
> must later unref.
> Any need for using the pointer in an efl_add (which is no longer returned)
> would still be supported through efl_added within the constructor.
>
> What do people think about this? I put the suggestion forward to improve
> the symettry with add and unref which is currently confusing. If my
> assumptions above are incorrect please let me know!
>
> Thanks,
> Andy
> --
> 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

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

Hi,

Thanks for posting that poll. Very useful.
If I may I wish to contradict your assertion that this has all been
discussed before - the poll had *0* consideration for what if parent is
NULL.
If you re-read the accepted proposal you will see that is not the current
behaviour at all. There is a (relatively) explicit handing of the reference
which can occur *after* I am finished with the reference.
In short the proposal that was voted for did not have this race condition
by design.

And so it follows that we are currently working with a third option that
was not part of the vote.

Same with gtk, apologies for misreading initially, they hand the reference
over when they are done.

One last thought - safety is broader than not crashing. If we have put in
place methods to catch corner cases in our design then perhaps our design
is not solid enough?

Andy

On Sat, 23 Dec 2017 at 10:56, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Fri, 22 Dec 2017 11:44:32 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi,
> >
> > I think your summary about the Gtk is not what you think - read the docs
> > further
> > https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-new
> and
> > you see that actually the trivial example leaks the reference - just like
> > an efl_add_ref with no unref or del later.
> > They are *not* returning a pointer where you can expect to lose ownership
> > at some future time. Notice also they do not pass parents to the
> > constructors.
>
> ummm no. that's wrong. because if you destroy the gtk window that you
> added the
> button and box to... the button is deleted and it DOESNT LEAK. the button
> is
> destroyed and freed. ownership of the reference is TRANSFERRED to the
> parent
> (the window) by gtk_container_add. see there are no unrefs there. it's not
> the
> same.  if the window was deleted (implicitly or explicitly) within that
> scope
> the button object pointer would have become invalid as well.
>
> efl_add_ref will have the button LEAK and stay around forever until you do
> another unref on it as the parent being destroyed (the window or box) will
> not
> be enough to remove all references.
>
> i did gtk dev for quite a few years... :)
>
> > In ObjC the basic construct is
> >
> > obj = [klass alloc]
> > ...
> > do things with obj
> > ...
> > [obj release]
> >
> > and they made this less cumbersome with
> >
> > obj = [[klass alloc] autorelease]
> > ...
> > do things with obj
> >
> > This provides a guarantee that the obj reference is alive for the current
> > scope.
> > I can find no examples where an object reference may or may not stay live
> > and may or may not need released based on a variable passed to the
> > constructor call...
>
> because the LANGUAGE will unref when scope exits. C will not. you must do
> it
> manually. and that is a vector for bugs, leaks and complaints about how
> hard it
> is and how much simpler gtk is etc.
>
> what's worse? a 20% chance that someone will forget to unref when exiting
> scope (and there can be multiple scope exit points), or that "the object
> will
> be deleted from under you". the 2nd will result in a complaint that the
> eoid is
> invalid. the first will result in a memory leak. possibly until all memory
> is
> exhausted and oom killers kick in. one has a very tiny chance of happening
> the
> other has a much higher chance (forgetting to manually unref is going to
> be a
> far higher chance). the one with the higher chance will lead to memory
> being
> gobbled up until perhaps a system falls over (possibly many processes and
> daemons fall over), and the other results in a complaint of an invalid
> object.
>
> and i've already mentioned that magical deletion in these cases is
> probably a
> bug (probably, not certainly) in the lifecycle design of something.
>
> > Wanting safety in our applications is not pedantry - anything less than
> > scope guarantees is asking for trouble and we are just patching bad
> > decisions.
>
> didn't i just say it was safe? it's safe. eoid ensures that.
>
> > I have been told on so many occasions that none of this API is final -
> but
> > now there is a chance to make things better but I am too late?
> > Please make up your mind.
>
> these arguments were had already a long time ago before now and now we're
> going
> back after a lot of code has been built on top. you are asking for a change
> that will lead to a lot of instability for a long time and a huge delay in
> work. it'd better be a very very very very good reason. what is the value
> of
> that chang

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

As framework developers we should be doing everything in our power to avoid
undefined behaviour. I’ll take accidents memory leaks any day - there are a
plethora of tools to solve that but it’s far harder to debug the “app not
working correctly sometimes on my system” bug reports.

Andy

On Sat, 23 Dec 2017 at 10:56, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Fri, 22 Dec 2017 11:53:32 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > We do have a showstopper design bug.
>
> see my previous mail. https://phab.enlightenment.org/V7 to be explicit.
> discussed. voted on. known compromise. lots of code built on top of that
> design
> decision. not a showstopper by any stretch. it's exactly what gtk does. the
> only difference is we have the "parent set" be part of the add and gtk
> does it
> as a separate step with container_add()
>
> > We are managing to work with it because we know how it works internally.
> > The API must be straight forward and provide consistent, robust options.
> >
> > Any new user would be asking of efl_add:
> > *) Do I need to unref the result when I am done?
> > *) How long is my returned reference valid for?
>
> see the vote. see gtk samples. floating reference.
>
> > Both of those are answered with "it depends" and that is a design
> > showstopper.
>
> disagree. it's clear. if parent is NULL then calling scope gets a
> floating reference you have to unref. if not then parent owns that
> reference and the rules of that parent cover lifetime of that object.
> covered
> that in prior mails - the alternative is to force people to manually unref
> every time they want a handle to something at all to do useful things with
> ...
> like add a child to this parent (child packed into a box parent for
> example).
> see the gtk/gobject design doc with the idea of floating references. see
> the
> previous discussion thread. see the vote in favor of what is there now and
> with
> everyone fully aware of scoping etc. and that is why efl_add_ref exists if
> you
> choose to use that.
>
> note for this discussion i am assuming scope is a small local function
> scope
> not larger. technically it can be the global scope of the entire app.
>
> i'll put it simply:
>
> 1: do it your way and people will have to always unref at end of scope (if
> they
> want an object handle to do something with, like pack a button into a box
> parent which is exceedingly common). the will at times forget to unref
> causing
> leaks.
>
> 2: do it the current way and perhaps sometimes in some rare circumstances
> an
> object is deleted by a parent before your scope ends.
>
> chances of 1: i'll put it at maybe 10-20% that someone forgets a scope
> exit case
> and forgets to unref (a return in the middle for example).
>
> chances of 2: i'll put at at maybe 1% on a bad day. likely far far less.
>
> so let's say 15% to 1%. 15x more mistakes likely with your proposal. but
> let's
> cover the CONSEQUENCES of a mistake:
>
> consequences of 1: leak memory (possibly huge amounts, if for example this
> is
> inside a model where you create objects and return them to the model to
> display but now they return with an extra ref and never get deleted as a
> result). leaking enough memory will result in severe system degradation
> (hitting swap or OOM killer) not to mention be relatively hard to pin down
> where the extra ref came from. a lot of fun debugging this ans isolating
> it.
>
> consequences of 2: a complaint to stderr with the object id, a backtrace to
> where it's invalid (instantly identifying the point of invalid access and
> very
> quickly leading to finding the source). with the identification of the
> invalid
> source point, finding the deletion point is very easy by adding a del event
> callback and tracing that. We could find ways of making this easier with
> env
> vars or a convenience call like efl_debug_del_track(obj, EINA_TRUE) which
> might print a debug log with bt on deletion of this object. you already
> know
> the exact object that is creating this issue from the first bt... so this
> will
> be a 2nd step to isolate it exactly. much easier to fix than #1 AND the
> conseqeunces are far less as it's just a "error print".
>
> so how do we rate the conequences? well #2 - let's call it a 10, and let's
> say
> somethnig vey hard to debug and that could lead to oom killers and swap
> storms... i'll call that a 1000. so 15*1000 vs 1*10. 1500 TIMES worse. yes.
> numbers pulled out of thin air. i'm making a point. your proposal is worse.
>
> in addition moving from #2 to #1 would be a huge effort to do, lead to a
> lot of
> problems 

Re: [E-devel] is there a roadmap for future significative improvements/changes

[Andrew Williams]

Hi Vincent,

I would really love this too - in fact I have been pushing for it. I
suggest regularly that it would be helpful to have a roadmap. On my most
recent request I was told bluntly “too much effort, you are the only person
that wants it”.

If we can get more support for such a document I would be far happier to
push forward again and see it is pulles together.

Thanks,
Andy
On Fri, 22 Dec 2017 at 16:57, Vincent Torri  wrote:

> hello
>
> i've recently seen this gtk roadmap :
> https://wiki.gnome.org/Projects/GTK%2B/Roadmap/GTK4
>
> is there the same for EFL ?
>
> Vincent
>
>
> --
> 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

[E-devel] API namespacing

[Andrew Williams]

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
Efl.Animator -> Efl.Animation.Animator
Efl.File -> Efl.Io.File
Efl.Flipable -> Efl.Image.Flipable
Efl.Observer -> Efl.Observable.Observer
Efl.Pack -> Efl.Ui.Pack
Efl.Part -> Efl.Layout.Part
Efl.Vg -> Efl.Gfx.Vector

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
Efl.Control
Efl.Duplicate
Efl.Orientation
Efl.Player
Efl.Screen

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.

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

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

We do have a showstopper design bug.
We are managing to work with it because we know how it works internally.
The API must be straight forward and provide consistent, robust options.

Any new user would be asking of efl_add:
*) Do I need to unref the result when I am done?
*) How long is my returned reference valid for?

Both of those are answered with "it depends" and that is a design
showstopper.

Andrew

On Fri, 22 Dec 2017 at 10:56 Carsten Haitzler  wrote:

> [snip]
>
> this is the kind of change that would only really justify being done if we
> had
> a showstopper design bug. we do not. not IMHO. there is clear behaviour and
> it's logical and simple. if you don't LIKE it... efl_add_ref is there for
> you
> to use and then to remember to unref on all scope exits by hand. i
> certainly
> would not choose to use this.
>
> [snip]
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
>
> --
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

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

Hi,

I think your summary about the Gtk is not what you think - read the docs
further
https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-new and
you see that actually the trivial example leaks the reference - just like
an efl_add_ref with no unref or del later.
They are *not* returning a pointer where you can expect to lose ownership
at some future time. Notice also they do not pass parents to the
constructors.

In ObjC the basic construct is

obj = [klass alloc]
...
do things with obj
...
[obj release]

and they made this less cumbersome with

obj = [[klass alloc] autorelease]
...
do things with obj

This provides a guarantee that the obj reference is alive for the current
scope.
I can find no examples where an object reference may or may not stay live
and may or may not need released based on a variable passed to the
constructor call...

Wanting safety in our applications is not pedantry - anything less than
scope guarantees is asking for trouble and we are just patching bad
decisions.
I have been told on so many occasions that none of this API is final - but
now there is a chance to make things better but I am too late?
Please make up your mind.

Andrew

On Fri, 22 Dec 2017 at 10:56 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Fri, 22 Dec 2017 10:10:48 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > On Fri, 22 Dec 2017 at 09:59 Carsten Haitzler <ras...@rasterman.com>
> wrote:
> >
> > > On Fri, 22 Dec 2017 09:43:20 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > Hi,
> > > >
> > > > I think that maybe I could have explained this a little better, let
> me
> > > step
> > > > back from the implementation details for a minute.
> > > >
> > > > As a user of this API all I want to know is do I have to unref a
> > > reference
> > > > that I have been handed. From this point of view we should be
> consistent.
> > > > My proposal was (intended) to mean that efl_add should never require
> the
> > > > user to unreference whereas efl_add_ref should always require this
> (but
> > > > only once - that may have been a bug).
> > > >
> > > > Having to know the value of the second parameter to the method to
> > > ascertain
> > > > the correct behaviour is what I think is confusing and should be
> > > > eliminated. Therefore the main purpose was so that the docs could
> ready
> > > > simply "this is a borrowed reference which you should not unref" vs
> "this
> > > > is an owned reference and you must unref when done".
> > >
> > > yes. i got that. but your proposal is no better than what is there. in
> fact
> > > think it's worse. unless i didn't understand it?
> > >
> >
> > "is no better"? it ensures that you know to unref efl_add_ref and that
> you
> > cannot accidentally use a risky efl_add. Not ideal which is why I
> suggested
> > efl_add_scope in a follow up which is something you don't have to unref
> but
> > also guarantees liveness for the scope.
>
> forcing all this code that builds widgets (see below about leaks) to
> remember
> to unref is asking for disaster as people will juyst end up using
> efl_Add_ref
> all the time because not doing so it incredibly inconvenient. it's also
> going to
> be a major complaint in usage.
>
> reality is ... people seem fine with how we do it in c. why? this is how
> gtk
> works... same thing. it's also how efl has worked for a long time. hello
> world
> for gtk:
>
> https://developer.gnome.org/gtk-tutorial/2.90/c39.html
> https://developer.gnome.org/gtk3/stable/gtk-getting-started.html
>
> the construction return an object ptr, you do things with it, hand it to a
> parent. no unreffing. in gtk the parent could delete the children any time
> it
> liked like in efl. this is a common design pattern already in c for this
> kind
> of stuff.
>
> you can be pedantic, or you can just be practical. this is one of these
> "we're
> being practical" things rather than pedantic. if you want to write code
> pedantically then efl_add_ref() is there - remember to unref when going
> out of
> scope or you'll have leaks.
>
> > > i get your point... as i said. but your proposal doesn't sound as if
> it's
> > > better.
> > >
> > > what MIGHT be better is to class objects into "can have a null parent"
> and
> > > "must have a non-null parent". the 1st case doesn't change. from now.
> the
> > > 2nd
> > > case results in efl_add

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

On Fri, 22 Dec 2017 at 09:59 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Fri, 22 Dec 2017 09:43:20 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi,
> >
> > I think that maybe I could have explained this a little better, let me
> step
> > back from the implementation details for a minute.
> >
> > As a user of this API all I want to know is do I have to unref a
> reference
> > that I have been handed. From this point of view we should be consistent.
> > My proposal was (intended) to mean that efl_add should never require the
> > user to unreference whereas efl_add_ref should always require this (but
> > only once - that may have been a bug).
> >
> > Having to know the value of the second parameter to the method to
> ascertain
> > the correct behaviour is what I think is confusing and should be
> > eliminated. Therefore the main purpose was so that the docs could ready
> > simply "this is a borrowed reference which you should not unref" vs "this
> > is an owned reference and you must unref when done".
>
> yes. i got that. but your proposal is no better than what is there. in fact
> think it's worse. unless i didn't understand it?
>

"is no better"? it ensures that you know to unref efl_add_ref and that you
cannot accidentally use a risky efl_add. Not ideal which is why I suggested
efl_add_scope in a follow up which is something you don't have to unref but
also guarantees liveness for the scope.


> i get your point... as i said. but your proposal doesn't sound as if it's
> better.
>
> what MIGHT be better is to class objects into "can have a null parent" and
> "must have a non-null parent". the 1st case doesn't change. from now. the
> 2nd
> case results in efl_add returning NULL (construction fails) if the parent
> is
> null. that might be an improvement.
>

Why do I, as the user, have to care what the content of the parent variable
is? It was suggested to me that efl_add could require a parent and then
would safely return the reference, but you still have the race condition so
I'm not convinced.


> > The added complication is the race condition with the "parent" usage in
> > efl_add. When I pass a parent reference to efl_add then the returned
> handle
> > is something I can use. Yes this is very helpful. But this is dangerous.
> We
> > (as a framework) are providing 0 guarantee that the object will live as
> > long as the scope - that is entirely up to the parent, not the user and
> not
> > the framework. This is also something that I think we should address.
>
> we can't guarantee it if the parent decides some time within the scope to
> delete the object you added. well we can;'t unless you use efl_add_ref()
> then
> you create an object with 2 references (parent one and your scope/app one)
> and
> you will have to remember to unref at end of scope. this leads to verbose
> code,
> and having to remember to do this... which is more than likely going to
> lead to
> huge amounts of memory leaking.
>

Only if not coded correctly. We currently return references which are not
clear if they should be unref or not so there is not a huge difference.


> so which is worse? sometimes a parent decides to delete an object on you
> while
> you are still holding and using its handle, or that you always have to
> unref
> every obj you added when you exit scope? i'll take the first one any day
> of the
> week. :)
>

I'm going to say safety. 100% safety is more important than removing a line
of code. This is our opportunity to do things right. Introducing a race
condition at the root of our API seems an unfortunate choice.


> > So there you go - the background behind my proposal. Hopefully if I did
> not
> > explain the details well you can now see why I felt it is important.
>
> yup. i know the background. i'm speaking of the details of the proposal.
>
> > Thanks,
> > Andy
> >
> > On Fri, 22 Dec 2017 at 03:25 Carsten Haitzler <ras...@rasterman.com>
> wrote:
> >
> > > On Thu, 21 Dec 2017 13:15:26 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > Hi,
> > > >
> > > > This is now well documented (
> > > > https://www.enlightenment.org/develop/tutorials/c/eo-refcount.md)
> but
> > > the
> > > > more I use efl_add the more I feel it is confusing especially to new
> > > > developers.
> > > >
> > > > In the current model (if I understand it correctly)
> > > > 1) child = efl_add(klass, parent) means the child must NOT be
> > > un

Re: [E-devel] Focus,Changed

[Andrew Williams]

Hi,

A good point - we do need consistency at the core. Additionally as Eo was
designed to make binding easier then allowing a :bool event type is
probably not in the spirit of things.

Whilst it is convenient I'd also say that (event->info) is unclear - given
the noun nature it looks like a check for a non-null info entity. Even if I
do figure that it's a bool it is still not clear what it represents. A
"focussed" member in a struct is much clearer for the reader of the code.

Thanks,
Andy

On Fri, 22 Dec 2017 at 03:25 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Thu, 21 Dec 2017 18:17:58 + Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi,
> >
> > I'm sorry but seriously?
> > "Well, common or not is nothing that counts here IMO."
> >
> > In an exercise such as this consistency is one of the most important
> > concepts.
> > No?
> > Andy
>
> well in C bu5hm4n makes a point - you'd have to cast to a struct type then
> deref it to get to the bool... where if (event->info) ... will do just as
> well..
>
> BUT in other languages it's better this way because the type will be able
> to be
> immediately expressed (the bool) without having to jump through a container
> that contains a single bool element...
>
> so in general this kind of pattern is probably not bad as it's convenient
> in
> all languages. it does come with a downside: once you make the event info a
> bool its not able to extend in future with more data.
>
> the question is - is the convenience worth it to give up the ability to
> ever
> extend?
>
> this is also part of a larger design pattern question:
>
>   focus,changed
>
> vs.
>
>   focus,in + focus,out
>
> also if focus,changed doesn't HAVE to carry the focus bool in the event
> info.
> you can get the focus state from the object itself by getting its focused
> property, so the event info focus data is redundant.
>
> so is having 2 events better than 1 or vice-versa? and this is a design
> question everywhere. mouse,down + mouse,up vs just mouse,button + flag for
> down vs up?  mouse,in + mouse,out vs mouse,crossing + flag ? we should be
> consistent in design here.
>
> the important thing i think is design consistency. also we should not have
> redundancy unless there are VERY good reasons to have it. by that i mean
> "there
> are 2 or 3 or 4 ways to do this depending on which side of the bed you
> woke up
> on today". bigger-picture-wise this makes it harder to learn and work with
> efl
> because you read code and the code in one place may not be consistent with
> another. also developers will be given the need to choose the way and make
> a
> decision, and this will slow them down when there are 2 or 3 ways to do the
> same thing. i DO see a point to multiple ways if there is a significant
> difference (lots less code, faster execution by a good margin etc. etc.),
> otherwise this raises the bar to learn and maintain without IMHO a good
> pay-off.
>
> > On Thu, 21 Dec 2017 at 18:11 <marcel-hollerb...@t-online.de> wrote:
> >
> > > Hi,
> > >
> > > On Thu, Dec 21, 2017 at 12:19:41PM +, Andrew Williams wrote:
> > > > Hi,
> > > >
> > > > Stumbling upon the efl_ui_focus_object.eo defintion:
> > > >
> > > >  focus,changed : bool; [[Emitted if the focus state has
> changed]]
> > > >
> > >
> > > The now active property.
> > >
> > > > I am unsure what the purpose of the bool is. My guess is that it's
> what
> > > the
> > > > focussed value used to be or has become.
> > > > Following the docs it implies a relation to whether or not focus has
> > > > changed.
> > > > None of our code seems to use this - they all call
> > > > efl_ui_focus_object_focus_get within the callback.
> > >
> > > the old code always used elm_widget_focus_get and that was replaced
> with
> > > efl_ui_object_focus_get, instead of sometimes using the flag ...
> > >
> > > > For that matter is it common to pass a primitive value in the place
> of
> > > void
> > > > *? All the other callbacks I have used pass structs which are far
> easier
> > > to
> > > > understand.
> > >
> > > Well, common or not is nothing that counts here IMO.
> > >
> > > if (event->info) { ... } else { ... }
> > >
> > > Is handy and does not need any casting or something, a struct would

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

Hi,

Surely hide and unref are separate? Why are we trying to do both with a
single call to _del? If we wish to continue supporting "hide and unref" in
a single call then we can - but as a convenience. It could be documented as
such: "del will remove your reference to the object and, if the object is
visible, hide it. Any other references will remain valid but will no longer
visibly affect the object" nice and clear.

But I think cedric is still correct - unref is all that is "needed" - any
user could _hide && _unref if they wanted - it would then be exactly the
same as the _del semantic you describe.

If we have to put a big OR in a simple method documentation then we are
setting up confusion.

Andy

On Fri, 22 Dec 2017 at 03:26 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Thu, 21 Dec 2017 13:29:05 -0500 Cedric Bail <ced...@ddlm.me> said:
>
> > Hi,
> >
> > >  Original Message 
> > > Subject: Re: [E-devel] efl_add causing confusion
> > > Local Time: December 21, 2017 9:02 AM
> > > UTC Time: December 21, 2017 5:02 PM
> > > From: a...@andywilliams.me
> > > To: Enlightenment developer list <
> enlightenment-devel@lists.sourceforge.net>
> > >
> > > P.S. if the loss of temporary handles with efl_add is not met with
> > > efl_added it would be possible to add a new macro along the lines of:
> > >
> > > efl_add_scope(klass, parent) { ... statements ... } whereby the scope
> of
> > > the variable is valid only within that block.
> >
> > This is an interesting idea that give an explicit lifecycle to the newly
> > created reference and when you safely own it.
> >
> > > On Thu, 21 Dec 2017 at 13:15 Andrew Williams a...@andywilliams.me
> wrote:
> > >
> > >> Hi,
> > >> This is now well documented (
> > >> https://www.enlightenment.org/develop/tutorials/c/eo-refcount.md)
> but the
> > >> more I use efl_add the more I feel it is confusing especially to new
> > >> developers.
> > >> In the current model (if I understand it correctly)
> > >>
> > >> - child = efl_add(klass, parent) means the child must NOT be
> unfeferenced
> > >> - child = efl_add(klass, NULL) means the child should be unreferenced
> > >> - child = efl_add_ref(klass, parent) means the child must be
> unreferenced
> > >> - child = efl_add_ref(klass, NULL) somehow means that the child
> should be
> > >> unreferenced twice
> > >>
> > >> In my opinion 1) and 4) are peculiar and so I provide a proposal to
> fix
> > >> this:
> > >> We could change efl_add to return void. It never retains a reference.
> If
> > >> the parent is NULL then it should be automatically unref before
> returning.
> > >> Then efl_add_ref would be changed to mirror this and always retain
> exactly
> > >> 1 reference - so if parent is NULL there is no double count returned.
> > >> Using this model if an Eo * is returned then I know I have a
> reference and
> > >> must later unref.
> > >> Any need for using the pointer in an efl_add (which is no longer
> returned)
> > >> would still be supported through efl_added within the constructor.
> > >> What do people think about this? I put the suggestion forward to
> improve
> > >> the symettry with add and unref which is currently confusing. If my
> > >> assumptions above are incorrect please let me know!
> >
> > We have been trying to fix the semantic problem of efl_add since pretty
> much
> > it was created. This proposal seems to build on top of efl_add_ref that
> was
> > added to fix the problem created for binding. I do like this proposal at
> it
> > start fixing the problem of inconsistency when creating an object. An
> > additional fix is that we would not need any more an efl_del as efl_unref
> > will be the only thing needed (efl_del is a weird thing that does unset
> the
> > parent and unref somehow, but can't also be used safely by binding). This
> > would make for a cleaner semantic and less surprise in refcounting.
>
> i disagree that unref is all that is needed. here is a case we hit in
> legacy
> api:
>
> you have an object and you do evas_object_del(). you can keep the object
> alive
> with more refs, but del SHOULD hide the object. refs should not affect
> VISIBILITY of the object, thus a del is different to an unref.
>
> del == "remove a reference from this object and otherwise act as if this
> object
> should now be delet

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

Hi,

I think that maybe I could have explained this a little better, let me step
back from the implementation details for a minute.

As a user of this API all I want to know is do I have to unref a reference
that I have been handed. From this point of view we should be consistent.
My proposal was (intended) to mean that efl_add should never require the
user to unreference whereas efl_add_ref should always require this (but
only once - that may have been a bug).

Having to know the value of the second parameter to the method to ascertain
the correct behaviour is what I think is confusing and should be
eliminated. Therefore the main purpose was so that the docs could ready
simply "this is a borrowed reference which you should not unref" vs "this
is an owned reference and you must unref when done".

The added complication is the race condition with the "parent" usage in
efl_add. When I pass a parent reference to efl_add then the returned handle
is something I can use. Yes this is very helpful. But this is dangerous. We
(as a framework) are providing 0 guarantee that the object will live as
long as the scope - that is entirely up to the parent, not the user and not
the framework. This is also something that I think we should address.

So there you go - the background behind my proposal. Hopefully if I did not
explain the details well you can now see why I felt it is important.

Thanks,
Andy

On Fri, 22 Dec 2017 at 03:25 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Thu, 21 Dec 2017 13:15:26 + Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi,
> >
> > This is now well documented (
> > https://www.enlightenment.org/develop/tutorials/c/eo-refcount.md) but
> the
> > more I use efl_add the more I feel it is confusing especially to new
> > developers.
> >
> > In the current model (if I understand it correctly)
> > 1) child = efl_add(klass, parent) means the child must NOT be
> unfeferenced
> > 2) child = efl_add(klass, NULL) means the child should be unreferenced
> > 3) child = efl_add_ref(klass, parent) means the child must be
> unreferenced
> > 4) child = efl_add_ref(klass, NULL) somehow means that the child should
> be
> > unreferenced twice
>
> #4 smells like a bug... 1 is intended.
>
> > In my opinion 1) and 4) are peculiar and so I provide a proposal to fix
> > this:
> >
> > We could change efl_add to return void. It never retains a reference. If
> > the parent is NULL then it should be automatically unref before
> returning.
> > Then efl_add_ref would be changed to mirror this and always retain
> exactly
> > 1 reference - so if parent is NULL there is no double count returned.
>
> umm... then you are saying efl_add_ref() is exactly the same as efl_add()
> today. what does this help? and the shorter efl_add now returns nothing so
> i
> can't use the return to usefully access the things i created later on like
> add
> callbacks to it, change the label of a button, delete a window, or use it
> as a
> parent for further adds which is like THE most common use case around when
> building a ui for example (create box, then create a button and pack button
> into box. i need the box to be able to do that). unless i use efl_add_ref
> which
> si the same thing as efl_add now.
>
> > Using this model if an Eo * is returned then I know I have a reference
> and
> > must later unref.
> > Any need for using the pointer in an efl_add (which is no longer
> returned)
> > would still be supported through efl_added within the constructor.
>
> if efl_add_ref returns an obj with only 1 reference, then this is wrong
> above.
> if parent is NULL, yes you'd have to unref/del. if parent is not null then
> there is still only 1 ref and it belongs to the parent object. so
>
> > What do people think about this? I put the suggestion forward to improve
> > the symettry with add and unref which is currently confusing. If my
> > assumptions above are incorrect please let me know!
> >
> > 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" --
> Carsten Haitzler - ras...@rasterman.com
>
> --
ht

Re: [E-devel] Focus,Changed

[Andrew Williams]

Hi,

I'm sorry but seriously?
"Well, common or not is nothing that counts here IMO."

In an exercise such as this consistency is one of the most important
concepts.
No?
Andy

On Thu, 21 Dec 2017 at 18:11 <marcel-hollerb...@t-online.de> wrote:

> Hi,
>
> On Thu, Dec 21, 2017 at 12:19:41PM +, Andrew Williams wrote:
> > Hi,
> >
> > Stumbling upon the efl_ui_focus_object.eo defintion:
> >
> >  focus,changed : bool; [[Emitted if the focus state has changed]]
> >
>
> The now active property.
>
> > I am unsure what the purpose of the bool is. My guess is that it's what
> the
> > focussed value used to be or has become.
> > Following the docs it implies a relation to whether or not focus has
> > changed.
> > None of our code seems to use this - they all call
> > efl_ui_focus_object_focus_get within the callback.
>
> the old code always used elm_widget_focus_get and that was replaced with
> efl_ui_object_focus_get, instead of sometimes using the flag ...
>
> > For that matter is it common to pass a primitive value in the place of
> void
> > *? All the other callbacks I have used pass structs which are far easier
> to
> > understand.
>
> Well, common or not is nothing that counts here IMO.
>
> if (event->info) { ... } else { ... }
>
> Is handy and does not need any casting or something, a struct would
> require at least a cast to that struct, which is not that nice.
>
> >
> > Thanks for any help on this,
> > 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
>
>
> --
> 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

Re: [E-devel] efl_add causing confusion

[Andrew Williams]

P.S. if the loss of temporary handles with efl_add is not met with
efl_added it would be possible to add a new macro along the lines of:

efl_add_scope(klass, parent) { ... statements ... } whereby the scope of
the variable is valid only within that block.

On Thu, 21 Dec 2017 at 13:15 Andrew Williams <a...@andywilliams.me> wrote:

> Hi,
>
> This is now well documented (
> https://www.enlightenment.org/develop/tutorials/c/eo-refcount.md) but the
> more I use efl_add the more I feel it is confusing especially to new
> developers.
>
> In the current model (if I understand it correctly)
> 1) child = efl_add(klass, parent) means the child must NOT be unfeferenced
> 2) child = efl_add(klass, NULL) means the child should be unreferenced
> 3) child = efl_add_ref(klass, parent) means the child must be unreferenced
> 4) child = efl_add_ref(klass, NULL) somehow means that the child should be
> unreferenced twice
>
> In my opinion 1) and 4) are peculiar and so I provide a proposal to fix
> this:
>
> We could change efl_add to return void. It never retains a reference. If
> the parent is NULL then it should be automatically unref before returning.
> Then efl_add_ref would be changed to mirror this and always retain exactly
> 1 reference - so if parent is NULL there is no double count returned.
>
> Using this model if an Eo * is returned then I know I have a reference and
> must later unref.
> Any need for using the pointer in an efl_add (which is no longer returned)
> would still be supported through efl_added within the constructor.
>
> What do people think about this? I put the suggestion forward to improve
> the symettry with add and unref which is currently confusing. If my
> assumptions above are incorrect please let me know!
>
> Thanks,
> Andy
> --
> 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

[E-devel] efl_add causing confusion

[Andrew Williams]

Hi,

This is now well documented (
https://www.enlightenment.org/develop/tutorials/c/eo-refcount.md) but the
more I use efl_add the more I feel it is confusing especially to new
developers.

In the current model (if I understand it correctly)
1) child = efl_add(klass, parent) means the child must NOT be unfeferenced
2) child = efl_add(klass, NULL) means the child should be unreferenced
3) child = efl_add_ref(klass, parent) means the child must be unreferenced
4) child = efl_add_ref(klass, NULL) somehow means that the child should be
unreferenced twice

In my opinion 1) and 4) are peculiar and so I provide a proposal to fix
this:

We could change efl_add to return void. It never retains a reference. If
the parent is NULL then it should be automatically unref before returning.
Then efl_add_ref would be changed to mirror this and always retain exactly
1 reference - so if parent is NULL there is no double count returned.

Using this model if an Eo * is returned then I know I have a reference and
must later unref.
Any need for using the pointer in an efl_add (which is no longer returned)
would still be supported through efl_added within the constructor.

What do people think about this? I put the suggestion forward to improve
the symettry with add and unref which is currently confusing. If my
assumptions above are incorrect please let me know!

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

[E-devel] Focus,Changed

[Andrew Williams]

Hi,

Stumbling upon the efl_ui_focus_object.eo defintion:

 focus,changed : bool; [[Emitted if the focus state has changed]]

I am unsure what the purpose of the bool is. My guess is that it's what the
focussed value used to be or has become.
Following the docs it implies a relation to whether or not focus has
changed.
None of our code seems to use this - they all call
efl_ui_focus_object_focus_get within the callback.

For that matter is it common to pass a primitive value in the place of void
*? All the other callbacks I have used pass structs which are far easier to
understand.

Thanks for any help on this,
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

[E-devel] Magic fail in Unified shutdown

[Andrew Williams]

Hi,

In the last few days I have started seeing magic fails in the shutdown of
some examples. Such as the following:

ERR<18036>:ecore lib/ecore/ecore.c:790 _ecore_magic_fail()
*** ECORE ERROR: Ecore Magic Check Failed!!!
*** IN FUNCTION: ecore_main_fd_handler_del()
ERR<18036>:ecore lib/ecore/ecore.c:794 _ecore_magic_fail()   Input handle
has already been freed!
ERR<18036>:ecore lib/ecore/ecore.c:803 _ecore_magic_fail() *** NAUGHTY
PROGRAMMER!!!
*** SPANK SPANK SPANK!!!
*** Now go fix your code. Tut tut tut!

It is unfortunate that the errors are occurring but also a rather abrupt
output for a developer who has merely created an object and then exited the
program.
Please compile and run the following - tap some characters then ctrl-D and
see the error stream. :(

#define EFL_EO_API_SUPPORT 1
#define EFL_BETA_API_SUPPORT 1

#include 
#include 

#include 
#include 

static void
_copier_done(void *data EINA_UNUSED, const Efl_Event *event)
{
   efl_exit(EXIT_SUCCESS);
}

EAPI_MAIN void
efl_main(void *data EINA_UNUSED, const Efl_Event *ev)
{
   Efl_Loop *loop;
   Eo *input, *output;

   loop = ev->object;

   input = efl_add(EFL_IO_STDIN_CLASS, loop);
   output = efl_add(EFL_IO_STDOUT_CLASS, loop);

   efl_add(EFL_IO_COPIER_CLASS, loop,
   efl_io_copier_source_set(efl_added, input),
   efl_io_copier_destination_set(efl_added, output),
   efl_event_callback_add(efl_added, EFL_IO_COPIER_EVENT_DONE,
_copier_done, NULL));

   printf("  Type something here and press enter, it will be copied to
stdout...\n");
   printf("  (press Ctrl-D to exit)\n");
}
EFL_MAIN()

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

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

[Andrew Williams]

Since this came in the core_loop example is no longer working correctly.
https://git.enlightenment.org/tools/examples.git/tree/reference/c/core/src/core_event.c

There are a few ERR about timers being dead and objects having parents that
didn't happen before.
Additionally a EFL_LOOP child of mainloop is created and a timer attached.
The timer no longer gets the TIMER_EVENT_TICK callback.

Any hints as to where I should start looking to see what is broken?

Thanks,
Andy

On Wed, 20 Dec 2017 at 04:28 Jean-Philippe André  wrote:

> On Wed, Dec 20, 2017 at 12:41 PM, Carsten Haitzler 
> 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 
> > 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 
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > > 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
> > > > > > 

Re: [E-devel] FOSDEM

[Andrew Williams]

Phillipe,

This page does not list us https://fosdem.org/2018/stands/ - does that mean
we did not manage to get a stand?

I thought I would just check in case I need to pull together a demo.
Andy

On Mon, 18 Dec 2017 at 10:52 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Sun, 17 Dec 2017 19:51:13 + Tom Hacohen <t...@stosb.com> said:
>
> > I'm also coming. Want to book my travel. When is everyone getting
> > there/leaving?
> >
> > I'm thinking doing Friday - Sunday?
>
> I'll be there for those days. :)
>
> > --
> > Tom
> >
> > On 17 Dec 2017 15:01, "Carsten Haitzler" <ras...@rasterman.com> wrote:
> >
> > > On Wed, 22 Nov 2017 18:02:56 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > Hi,
> > > >
> > > > The supplier I work with does not do embroidery.
> > > > Does anyone who will be attending Fosdem have the ability to get a
> full
> > > > shirt with stitching organised?
> > >
> > > We did before get caps made that are embroidered. i have one. also
> towels.
> > > cedric i think knows who/where...
> > >
> > > fyi i've booked my travel to fosdem, so i'll be there. :)
> > >
> > > > If not should I go ahead with a t-shirt or do folk feel strongly
> that it
> > > is
> > > > not suitable for us?
> > > >
> > > > Thanks,
> > > > Andy
> > > >
> > > > p.s. still wondering if folk would pay for their own shirt or if I
> need
> > > to
> > > > get sponsorship for this?
> > > >
> > > > On Thu, 9 Nov 2017 at 00:24 Carsten Haitzler <ras...@rasterman.com>
> > > wrote:
> > > >
> > > > > On Wed, 08 Nov 2017 22:05:07 + Andrew Williams <
> > > a...@andywilliams.me>
> > > > > said:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I reckon stickers are a minimum :) not sure if we can afford more
> > > than
> > > > > that
> > > > > > to give away.
> > > > > >
> > > > > > I also wondered if we should get some new t-shirts - not to give
> > > away but
> > > > > > for a little branding and visibility. Would folk be willing to
> pay
> > > for
> > > > > > their own shirt?
> > > > > >
> > > > > > I was wondering about “Enlightenment” (with logo) on the front
> and
> > > maybe
> > > > > > “built on EFL” on the back :)
> > > > >
> > > > > Can we do more stylish than a t-shirt? Like... A proper collared
> shirt
> > > > > maybe
> > > > > with the logo embroidered? grey/black with white embroidery? :)
> > > > >
> > > > > > Looking forward to it,
> > > > > > Andy
> > > > > > On Mon, 23 Oct 2017 at 14:31, Philippe Caseiro <
> pcase...@cadoles.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > > > Hi !!
> > > > > > >
> > > > > > >Stand request posted !
> > > > > > >
> > > > > > >Now, I will work on some goodies !
> > > > > > >
> > > > > > >Some ideas or proposals ?
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > > Le mercredi 11 octobre 2017 14:51:03 CEST, Philippe Caseiro a
> > > écrit :
> > > > > > > > Le mercredi 11 octobre 2017 13:19:42 CEST, Andrew Williams a
> > > écrit :
> > > > > > > >> Hi,
> > > > > > > >>
> > > > > > > >> Good shout! I think I could make it this year and would be
> > > happy to
> > > > > help
> > > > > > > >> with the stand and/or put forward a talk (probably around
> edi
> > > > > > > >> ;) or getting
> > > > > > > >> into efl).
> > > > > > > >
> > > > > > > > Great !
> > > > > > > >
> > > > > > > >>
> > > > > > > >> One proviso: we would have to do it properly - some fixed
> > > > > > > >> demos, a story to
> > > > > 

Re: [E-devel] Site statistics

[Andrew Williams]

Hi,

On Wed, 20 Dec 2017 at 02:13 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Mon, 18 Dec 2017 12:23:08 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi all.
> >
> > Since adding Google Analytics a while back I have some interesting
> > statistics that I thought I would share:
> >
> > 1) Very few people read our Stable API documentation - around 0.5% of our
> > page hits
> > 2) Over 5% of the page hits are already for the beta API documentation
>
> I'm willing to bet that this is mostly because of the work going on on
> these
> and "checking the work when done" etc. and not "real traffic". At least
> until
> this settles down I'd take these numbers with a grain of salt then look at
> again.
>

Looking further it's roughly 50/50 returning vs new users - so your grain
of saly can only be 50% of our numbers at the most...


> > 3) Most of the hits to /docs seem to result in a referral to /develop
> > 4) Nearly 40% of people landing on our home page leave right away
>
> Not surprising. enlightenment is a common word.
>
> > 5) Terminology is the most popular app (by page hits) and Edi is second
> > (1/4 times the hits) then ephoto (1/4 again)
>
> Also not surprising. :)
>
> > Not all of this requires any action but here is the action plan:
> > 1) I am not intending to put any further effort into our legacy API other
> > than the extraction of eina and eo for the Beta API docs
>
> Like others said. I think this might be a mistake. The legacy API is going
> to
> be around and supported for years to come. Sure. eo/eina is important in
> where
> we're going, but the legacy docs maybe should at least just be made to be
> "not
> broken" as much as is sanely possible. Not saying we should go WRITE more
> docs
> there... That's all. Unless this is what you had in mind?
>

I was not aware they were broken or I would not have suggested it. What I
wanted to do was to focus on going forward.
But not at the cost of breaking or removing legacy!


> > 2) We can expect more people to be trying to use our Beta API - do we
> need
> > to prepare for this or should we put up more obvious warnings about
> > attempting?
>
> I thought the need for a #define to enable them was enough... perhaps some
> more
> #warnings IF that define is set AND it's not the efl build itself... ? I
> still
> think it's far too early to stabilize any of this. Even futures are still
> "not
> done" and in flux. As is ecore (efl loop and friends/related).
>

The flag is BETA - we called it beta a long time ago. That is the
expectation that has been set.


> > 3) I think it is time that the main "Develop" link goes to the /develop/
> > dokuwiki. The link to phab exists on the /contrib page where it belongs
>
> I guess that depends on the interpretation of "Develop". Developing as in a
> USEE of EFL libraries and their APIs, or developing as in working on
> E/EFL/etc.
> and EFL API's. It's a fine distinction.
>

That is why we added "contribute" to make the distinction.
I'd say that the best way to learn is to make the change and see if the
develop->contribute redirect count is less than the current docs->develop
(which could be as high as 95% depending on how you interpret the
numbers)...


> > 4) We should find a way to make our home page more appealing - when
> loaded
> > on an average monitor you need to be full screen to see anything more
> than
> > the "Window manager" section.
>
> Indeed it could be nicer. Using a wiki limits our formatting abilities as
> it's
> simpler. I would have just had large screenshots of lots of stuff to start
> with
> instead of text as really "oooh aaah pretty images" really works. At least
> "front and foremost". But I'm holding off on doing this until flat theme is
> done. At least then it'll be "oh finally they're flat" reactions.
>
> How to present those screenshots... that is in and of itself a good
> question.
> like a big horizontal banner then with a small bit of text (and links)
> below,
> one after the other? One of those lightbox things that keeps flipping
> multiple
> images with some js (would need a wiki plugin). for some things videos or
> animated gifs might actually be the best as the wow factor is in watching
> it
> move and react. Yes - it's a bandwidth hog, but it should have a huge
> impact vs
> stills. Perhaps again - a wiki plugin with a "still image" until you
> mouseover
> or maybe click/tap then the video/animated gif is loaded and plays? I don't
> know. just trying a more concrete idea "float&q

Re: [E-devel] [Efl-technical-documentation] Site statistics

[Andrew Williams]

Hi Pierre,

I, as most others here, think that picking EFL is a great choice.
We are in a time of flux but there is no reason to regret having used the
current stable (legacy) API.
As cedric notes this will be supported for many years and we will be
offering a smooth transition to the new Unified API as and when it is ready.
There are many applications built on the API that will be transitioning
with you.

Thanks for joining us :)
Andy

On Tue, 19 Dec 2017 at 06:06 Pierre Couderc  wrote:

> On 12/18/2017 05:28 PM, Stephen Houston wrote:
> > "If we are to de-prioritise the new API at the cost of further
> development
> > of legacy APIs then we are prolonging the period of time in which we
> > request developers to use an API which we are intending to discontinue."
> >
> > I don't disagree.  But if we de-prioritize the old API at the cost of
> > furthering the development of new API then we are encouraging the
> > development of unstable apis that are not complete and won't have a
> stable
> > release for X amount of time.  Which isn't exactly ideal either.  I don't
> > think either option sounds great and it's going to get to a point of
> "Don't
> > use that api, it will be discontinued, but don't use that api either
> > because it is unstable, incomplete, and will change".  New developers
> will
> > look at that say... uh... okay so what do I use? Something other than
> EFL.
> >
> >
> I am glad to have developed my first application under efl (eegrep =
> multidimensional grep).
> With legacy API.
> Should I regret not having used Gnome ?
>
> PC
>
>
>
> --
> 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

Re: [E-devel] [Efl-technical-documentation] Site statistics

[Andrew Williams]

Hi,

It is indeed confusing. We have done our best to describe the situation in
the docs and given users the choice.
What would be really helpful would be a timeline or plan so that those
making the choice can make it an informed one.

Andrew

On Mon, 18 Dec 2017 at 16:28 Stephen Houston <smhousto...@gmail.com> wrote:

> "
> If we are to de-prioritise the new API at the cost of further development
> of legacy APIs then we are prolonging the period of time in which we
> request developers to use an API which we are intending to discontinue."
>
> I don't disagree.  But if we de-prioritize the old API at the cost of
> furthering the development of new API then we are encouraging the
> development of unstable apis that are not complete and won't have a stable
> release for X amount of time.  Which isn't exactly ideal either.  I don't
> think either option sounds great and it's going to get to a point of "Don't
> use that api, it will be discontinued, but don't use that api either
> because it is unstable, incomplete, and will change".  New developers will
> look at that say... uh... okay so what do I use? Something other than EFL.
>
> On Mon, Dec 18, 2017 at 10:04 AM Andrew Williams <a...@andywilliams.me>
> wrote:
>
>> Hi,
>>
>> Apologies I was using "legacy" by way of definition to separate it from
>> "unified" APIs.
>> We are now fighting a battle of multiple focuses - Some tell me that we
>> are pushing the Unified / interfaces as fast as we can and anything (such
>> as release) would slow us down. Others are reporting that legacy is our
>> main area of development.
>> I am confused. If I am confused then anyone coming to the project surely
>> would be too.
>> If we are to de-prioritise the new API at the cost of further development
>> of legacy APIs then we are prolonging the period of time in which we
>> request developers to use an API which we are intending to discontinue.
>>
>> Whether you think that the development of BETA is skewing the results
>> there is the remaining issue that our "stable" API appears to have had a
>> total of 45 page hits in 2 weeks.
>>
>> I wonder if we have any metrics on the number of users relying on the
>> existing API (outside of our own apps).
>>
>> Andrew
>>
>> On Mon, 18 Dec 2017 at 15:44 Stephen Houston <smhousto...@gmail.com>
>> wrote:
>>
>>> I disagree with #1.  It's not Legacy API until it is actually, you know,
>>> legacy.  Who knows how long the "beta" api will be before released and how
>>> long it will be until there is a stable release of it that will work full
>>> featured for application, especially elementary, development.  To not
>>> provide improved docs with the legacy api, is to say that the primary way
>>> developers can get involved over the next couple years, the legacy api,
>>> isn't worth anything.  All current apps, including Enlightenment, are using
>>> the legacy api, because that is what is stable, and that is how we are
>>> still going to get people involved for the foreseeable future (unless they
>>> are interested in working on the actual beta api implementation).  If
>>> anything I would argue that the focus should be more on the legacy api than
>>> the beta api, since no one uses the beta api, and it isn't stable.  Just a
>>> personal take.  I would venture to say a big reason the hits are coming in
>>> more on the beta api is because that is currently receiving the majority of
>>> the active development and you are getting hits from those developers.
>>>
>>> On Mon, Dec 18, 2017 at 6:23 AM Andrew Williams via
>>> Efl-technical-documentation <efl-technical-documentat...@lists.s-osg.org>
>>> wrote:
>>>
>>>> Hi all.
>>>>
>>>> Since adding Google Analytics a while back I have some interesting
>>>> statistics that I thought I would share:
>>>>
>>>> 1) Very few people read our Stable API documentation - around 0.5% of
>>>> our page hits
>>>> 2) Over 5% of the page hits are already for the beta API documentation
>>>> 3) Most of the hits to /docs seem to result in a referral to /develop
>>>> 4) Nearly 40% of people landing on our home page leave right away
>>>> 5) Terminology is the most popular app (by page hits) and Edi is second
>>>> (1/4 times the hits) then ephoto (1/4 again)
>>>>
>>>> Not all of this requires any action but here is the action plan:
>>>> 1) I am not intending to put any further effort 

Re: [E-devel] [Efl-technical-documentation] Site statistics

[Andrew Williams]

Hi,

Apologies I was using "legacy" by way of definition to separate it from
"unified" APIs.
We are now fighting a battle of multiple focuses - Some tell me that we are
pushing the Unified / interfaces as fast as we can and anything (such as
release) would slow us down. Others are reporting that legacy is our main
area of development.
I am confused. If I am confused then anyone coming to the project surely
would be too.
If we are to de-prioritise the new API at the cost of further development
of legacy APIs then we are prolonging the period of time in which we
request developers to use an API which we are intending to discontinue.

Whether you think that the development of BETA is skewing the results there
is the remaining issue that our "stable" API appears to have had a total of
45 page hits in 2 weeks.

I wonder if we have any metrics on the number of users relying on the
existing API (outside of our own apps).

Andrew

On Mon, 18 Dec 2017 at 15:44 Stephen Houston <smhousto...@gmail.com> wrote:

> I disagree with #1.  It's not Legacy API until it is actually, you know,
> legacy.  Who knows how long the "beta" api will be before released and how
> long it will be until there is a stable release of it that will work full
> featured for application, especially elementary, development.  To not
> provide improved docs with the legacy api, is to say that the primary way
> developers can get involved over the next couple years, the legacy api,
> isn't worth anything.  All current apps, including Enlightenment, are using
> the legacy api, because that is what is stable, and that is how we are
> still going to get people involved for the foreseeable future (unless they
> are interested in working on the actual beta api implementation).  If
> anything I would argue that the focus should be more on the legacy api than
> the beta api, since no one uses the beta api, and it isn't stable.  Just a
> personal take.  I would venture to say a big reason the hits are coming in
> more on the beta api is because that is currently receiving the majority of
> the active development and you are getting hits from those developers.
>
> On Mon, Dec 18, 2017 at 6:23 AM Andrew Williams via
> Efl-technical-documentation <efl-technical-documentat...@lists.s-osg.org>
> wrote:
>
>> Hi all.
>>
>> Since adding Google Analytics a while back I have some interesting
>> statistics that I thought I would share:
>>
>> 1) Very few people read our Stable API documentation - around 0.5% of our
>> page hits
>> 2) Over 5% of the page hits are already for the beta API documentation
>> 3) Most of the hits to /docs seem to result in a referral to /develop
>> 4) Nearly 40% of people landing on our home page leave right away
>> 5) Terminology is the most popular app (by page hits) and Edi is second
>> (1/4 times the hits) then ephoto (1/4 again)
>>
>> Not all of this requires any action but here is the action plan:
>> 1) I am not intending to put any further effort into our legacy API other
>> than the extraction of eina and eo for the Beta API docs
>> 2) We can expect more people to be trying to use our Beta API - do we
>> need to prepare for this or should we put up more obvious warnings about
>> attempting?
>> 3) I think it is time that the main "Develop" link goes to the /develop/
>> dokuwiki. The link to phab exists on the /contrib page where it belongs
>> 4) We should find a way to make our home page more appealing - when
>> loaded on an average monitor you need to be full screen to see anything
>> more than the "Window manager" section.
>> 5) For our about page we may need to tell a better story about how it all
>> fits together. Otherwise it's E & EFL and a list of apps - not the how or
>> why of what we are doing...
>>
>> Please shout if you disagree with any of these action points :)
>>
>> Andrew
>> --
>> http://andywilliams.me
>> http://ajwillia.ms
>>
> ___
>> Efl-technical-documentation mailing list
>> efl-technical-documentat...@lists.s-osg.org
>> http://lists.s-osg.org/listinfo/efl-technical-documentation
>>
> --
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

[E-devel] Type info in futures

[Andrew Williams]

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

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

[E-devel] Site statistics

[Andrew Williams]

Hi all.

Since adding Google Analytics a while back I have some interesting
statistics that I thought I would share:

1) Very few people read our Stable API documentation - around 0.5% of our
page hits
2) Over 5% of the page hits are already for the beta API documentation
3) Most of the hits to /docs seem to result in a referral to /develop
4) Nearly 40% of people landing on our home page leave right away
5) Terminology is the most popular app (by page hits) and Edi is second
(1/4 times the hits) then ephoto (1/4 again)

Not all of this requires any action but here is the action plan:
1) I am not intending to put any further effort into our legacy API other
than the extraction of eina and eo for the Beta API docs
2) We can expect more people to be trying to use our Beta API - do we need
to prepare for this or should we put up more obvious warnings about
attempting?
3) I think it is time that the main "Develop" link goes to the /develop/
dokuwiki. The link to phab exists on the /contrib page where it belongs
4) We should find a way to make our home page more appealing - when loaded
on an average monitor you need to be full screen to see anything more than
the "Window manager" section.
5) For our about page we may need to tell a better story about how it all
fits together. Otherwise it's E & EFL and a list of apps - not the how or
why of what we are doing...

Please shout if you disagree with any of these action points :)

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

Re: [E-devel] FOSDEM

[Andrew Williams]

Hi,

I’m doing Friday evening to Sunday evening. Staying at hotel Barsey as it’s
walking distance from the university.

Andy
On Sun, 17 Dec 2017 at 19:51, Tom Hacohen <t...@stosb.com> wrote:

> I'm also coming. Want to book my travel. When is everyone getting
> there/leaving?
>
> I'm thinking doing Friday - Sunday?
>
> --
> Tom
>
> On 17 Dec 2017 15:01, "Carsten Haitzler" <ras...@rasterman.com> wrote:
>
>> On Wed, 22 Nov 2017 18:02:56 + Andrew Williams <a...@andywilliams.me>
>> said:
>>
>> > Hi,
>> >
>> > The supplier I work with does not do embroidery.
>> > Does anyone who will be attending Fosdem have the ability to get a full
>> > shirt with stitching organised?
>>
>> We did before get caps made that are embroidered. i have one. also towels.
>> cedric i think knows who/where...
>>
>> fyi i've booked my travel to fosdem, so i'll be there. :)
>>
>> > If not should I go ahead with a t-shirt or do folk feel strongly that
>> it is
>> > not suitable for us?
>> >
>> > Thanks,
>> > Andy
>> >
>> > p.s. still wondering if folk would pay for their own shirt or if I need
>> to
>> > get sponsorship for this?
>> >
>> > On Thu, 9 Nov 2017 at 00:24 Carsten Haitzler <ras...@rasterman.com>
>> wrote:
>> >
>> > > On Wed, 08 Nov 2017 22:05:07 + Andrew Williams <
>> a...@andywilliams.me>
>> > > said:
>> > >
>> > > > Hi,
>> > > >
>> > > > I reckon stickers are a minimum :) not sure if we can afford more
>> than
>> > > that
>> > > > to give away.
>> > > >
>> > > > I also wondered if we should get some new t-shirts - not to give
>> away but
>> > > > for a little branding and visibility. Would folk be willing to pay
>> for
>> > > > their own shirt?
>> > > >
>> > > > I was wondering about “Enlightenment” (with logo) on the front and
>> maybe
>> > > > “built on EFL” on the back :)
>> > >
>> > > Can we do more stylish than a t-shirt? Like... A proper collared shirt
>> > > maybe
>> > > with the logo embroidered? grey/black with white embroidery? :)
>> > >
>> > > > Looking forward to it,
>> > > > Andy
>> > > > On Mon, 23 Oct 2017 at 14:31, Philippe Caseiro <
>> pcase...@cadoles.com>
>> > > wrote:
>> > > >
>> > > > > Hi !!
>> > > > >
>> > > > >Stand request posted !
>> > > > >
>> > > > >Now, I will work on some goodies !
>> > > > >
>> > > > >Some ideas or proposals ?
>> > > > >
>> > > > > Regards
>> > > > >
>> > > > > Le mercredi 11 octobre 2017 14:51:03 CEST, Philippe Caseiro a
>> écrit :
>> > > > > > Le mercredi 11 octobre 2017 13:19:42 CEST, Andrew Williams a
>> écrit :
>> > > > > >> Hi,
>> > > > > >>
>> > > > > >> Good shout! I think I could make it this year and would be
>> happy to
>> > > help
>> > > > > >> with the stand and/or put forward a talk (probably around edi
>> > > > > >> ;) or getting
>> > > > > >> into efl).
>> > > > > >
>> > > > > > Great !
>> > > > > >
>> > > > > >>
>> > > > > >> One proviso: we would have to do it properly - some fixed
>> > > > > >> demos, a story to
>> > > > > >> tell and probably some stickers too...
>> > > > > >>
>> > > > > >> An empty table with a name behind us made me sad :(
>> > > > > >
>> > > > > > Yes me to this year we will try to have a nice stand !
>> > > > > >
>> > > > > >
>> > > > >
>> > > > > --
>> > > > > Philippe Caseiro
>> > > > >
>> > > > > Responsable Cadoles Services & Solutions
>> > > > > Ingénieur logiciels libres
>> > > > >
>> > > > > https://www.cadoles.com
>> > > > >
>> > > > >
>> > > > >
>> > > > >
&g

Re: [E-devel] [EGIT] [tools/examples] master 01/01: eina: Add a first pass futures example (from eina examples)

[Andrew Williams]

Hi,

Thanks so much for the suggestions. The Ecore_Timer was a copy/paste issue
but the others are all new to me :)

Andy
On Tue, 12 Dec 2017 at 20:51, Gustavo Sverzut Barbieri 
wrote:

> Thanks for your work, few comments to improve it a little more:
>
> > +typedef struct _Ctx {
> > +   Eina_Promise *p;
> > +   Eina_Bool should_fail;
> > +   Ecore_Timer *timer;
>
> efl_loop_timeout(loop, seconds) will return a future that resolves
> once at a given time, it's a non-recurring timer.
>
> if you want to use the Efl_Loop_Timer, then use that type or simply
> "Eo" to make clear it's about the new API.
>
> if you want to use 2 promises, maybe you should look at
> eina_future_race(). It takes futures and once one resolves, it "wins
> the race", cancelling the others. Thus if you want to impose a timeout
> to something, just race 'something' and a timeout ;-)
>
>
> > +static Ctx *
> > +_promise_ctx_new(Eina_Value *v)
> > +{
> > +   Ctx *ctx;
> > +   Efl_Loop *loop;
> > +   ctx = calloc(1, sizeof(Ctx));
> > +   EINA_SAFETY_ON_NULL_GOTO(ctx, err_ctx);
> > +
> > +   loop = efl_loop_main_get(EFL_LOOP_CLASS);
> > +   ctx->p = eina_promise_new(efl_loop_future_scheduler_get(loop),
> > + _promise_cancel, ctx);
> > +   EINA_SAFETY_ON_NULL_GOTO(ctx->p, err_timer);
> > +   ctx->value = v;
> > +   return ctx;
> > + err_timer:
> > +   free(ctx);
> > + err_ctx:
> > +   eina_value_free(v);
> > +   return NULL;
> > +}
> > +
> > +static void
> > +_timeout(void *data, const Efl_Event *event EINA_UNUSED)
> > +{
> > +   Ctx *ctx = data;
> > +
> > +   if (ctx->should_fail)
> > + {
> > +eina_promise_reject(ctx->p, ENETDOWN);
> > + }
> > +   else
> > + {
> > +Eina_Value v;
> > +eina_value_copy(ctx->value, );
> > +eina_promise_resolve(ctx->p, v);
> > +eina_value_free(ctx->value);
>
> if you're going to use it only once, you don't need to copy. My
> recommendation is:
>
>  - Eina_Value value; // not pointer
>
>  - eina_value_flush(>value); // for cancel or error cases.
>
>  - eina_pormise_resolve(ctx->p, ctx->value); // stole ownership, can
> ctx->value = EINA_VALUE_EMPTY if you wish to make clear.
>
>
> > +static Eina_Future *
> > +_future_get(Ctx *ctx)
> > +{
> > +   Eina_Future *f;
> > +
> > +   f = eina_future_new(ctx->p);
> > +   EINA_SAFETY_ON_NULL_GOTO(f, err_future);
> > +
> > +   efl_add(EFL_LOOP_TIMER_CLASS, NULL,
> > +   ctx->timer = efl_added,
>
> is this recommended? I don't think so, better to use:
>
> ctx->timer = efl_add(...
>
> > +static Eina_Future *
> > +_fail_future_get(void)
> > +{
> > +   Ctx *ctx = _promise_ctx_new(NULL);
> > +   EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, NULL);
> > +   ctx->should_fail = EINA_TRUE;
> > +   return _future_get(ctx);
> > +}
> > +
> > +static Eina_Future *
> > +_str_future_get(void)
> > +{
> > +   Eina_Value *v = eina_value_util_string_new(DEFAULT_MSG);
>
> if you change from "Eina_Value*" to non-pointer, then you can use
> eina_value_string_init()
>
> if you keep the pointer, remove the "util_" from the name, it's legacy
> and just calls "eina_value_string_new()"
>
> > +static Eina_Value
> > +_chain_no_errors_cb(void *data EINA_UNUSED, const Eina_Value v, const
> Eina_Future *dead_future EINA_UNUSED)
> > +{
> > +   int val;
> > +
> > +   VALUE_TYPE_CHECK(v, EINA_VALUE_TYPE_INT);
> > +   eina_value_get(, );
> > +
> > +   return *eina_value_util_int_new(val * 2);
>
> this leaks the newly allocated Eina_Value, it's better to use:
> eina_value_int_init(val * 2)
>
>
> > +static Eina_Value
> > +_chain_with_error_cb(void *data EINA_UNUSED, const Eina_Value v
> EINA_UNUSED, const Eina_Future *dead_future EINA_UNUSED)
> > +{
> > +   Eina_Value err;
> > +   eina_value_setup(, EINA_VALUE_TYPE_ERROR);
> > +   eina_value_set(, E2BIG);
>
> return eina_value_error_init(E2BIG);
>
>
> --
> 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
>
-- 
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

Re: [E-devel] Unified API docs

[Andrew Williams]

Hi,

I don’t know if there is much value including the graph - for non-trivial
classes it’s very difficult to render at any readable size. My preference
would be to remove it, the inheritance tree shows the important
information...

Thanks,
Andy
On Tue, 12 Dec 2017 at 14:06, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Tue, 12 Dec 2017 10:23:23 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi,
> >
> > Thanks for the feedback, much sounds like what I had hoped to add (this
> was
> > a first pass to trim out the bulk - more layout and styling to be done).
>
> That's cool. It's a step in a good direction then. :)
>
> > On your first point the question is whether this is abstract
> documentation
> > or language specific. The view that I have taken in formatting these docs
> > is that the declared members within a class should provide specifics but
> > all inherited items (and in some cases there are hundreds) we should not
> be
> > so verbose. The reason for this is that the current class is a unit in
> > itself, If I am browsing the API for a button then I am likely not so
> > interested in layouts or focus management. One reason that this does not
> > currently look quite right is that overridden members are omitted in the
> > class documentation - I need to fix that for this to work as planned
> (i.e.
> > where "overridden here" there will be a full spec listed higher in the
> doc).
>
> I think indeed the class itself (in this example efl.ui.button) should be
> first
> and foremost at the top alongside all methods/properties that are
> overidden by
> this class. So I agree with you there. The other things should still be
> there I
> think - just "further down the page". I would love to see parameters,
> returns
> and types - even if they are the eolian types that are "more abstract"
> rather
> than lang specific.
>
> Also P.S. the dot diagram is unusable at the size and style it's rendered
> there. there must be a better way of doing this... :)
>
> > The sorting has not been altered in this change, I agree that could be
> > worked on and I intend to look at that shortly. Grouping was next on my
> > list. The suggestion of a table is a good one, I will see how that looks.
> >
> > I'll post here when there is more to review,
> > Thanks,
> > Andy
> >
> > On Tue, 12 Dec 2017 at 02:12 Carsten Haitzler <ras...@rasterman.com>
> wrote:
> >
> > > On Mon, 11 Dec 2017 17:37:10 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > Looks good, but I think it's too trimmed. Maybe it's just that in every
> > > language I know a method, function, etc. also lists its inputs and
> outputs
> > > (return and argument names/types). and not having that there even in
> > > shorthand
> > > makes it harder to know at a glance if that is what I want.
> > >
> > >   Efl.Text.Markup.markup (get, set)
> > >   Efl.Text.text (get, set) [Overridden here]
> > >
> > > for example. what does it take? a string? i guess so... but i'm not
> sure. 1
> > > parameter or 2 what about:
> > >
> > >   Efl.Ui.Layout.theme (set)
> > >
> > > what does this take to set? i happen to know it's a string... but
> knowing
> > > at a
> > > glance what these are would make these far more useful.
> > >
> > > Also I notice sorting is odd. The protected methods are sorted
> separately
> > > to the
> > > rest. Wouldn't it make sense to at least separate off a "protected"
> section
> > > then instead of adding protected to each entry?
> > >
> > > Just for "aesthetics" wouldn't it be also nicer to put the list of
> > > methods/properties in a table?  If we're sorting by parent class
> > > (Efl.Ui.Cursor, Efl.Ui.Layout etc. etc.) why repeat this per line?
> start a
> > > table row with the class name then list all the properties/methods
> over the
> > > next N lines (perhaps indented) like:
> > >
> > >   | Efl.Text.Markup
> > > |
> > >   |  | cursor_markup_insert   | method|
> > > |
> > >   |  | markup | get | set |
> > > |
> > >   | Efl.Text
> > >  |
> > >   |  | text   | get | set | [Overridden here]
> > > |
> > >   | Efl.Ui.Autorepeat
> > > |
> > >   |  | autorepeat_enabled | get | set | [Overridden here]
> > > |
> > >   |  | autorep

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

[Andrew Williams]

Hi,

I follow. I'll regenerate the docs as soon as it's in so we can get a more
complete picture of widget inheritance within Efl.*

Thanks,
Andy

On Tue, 12 Dec 2017 at 00:49 Jean-Philippe André <j...@videolan.org> wrote:

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

Re: [E-devel] Unified API docs

[Andrew Williams]

Hi,

Thanks for the feedback, much sounds like what I had hoped to add (this was
a first pass to trim out the bulk - more layout and styling to be done).

On your first point the question is whether this is abstract documentation
or language specific. The view that I have taken in formatting these docs
is that the declared members within a class should provide specifics but
all inherited items (and in some cases there are hundreds) we should not be
so verbose. The reason for this is that the current class is a unit in
itself, If I am browsing the API for a button then I am likely not so
interested in layouts or focus management. One reason that this does not
currently look quite right is that overridden members are omitted in the
class documentation - I need to fix that for this to work as planned (i.e.
where "overridden here" there will be a full spec listed higher in the doc).

The sorting has not been altered in this change, I agree that could be
worked on and I intend to look at that shortly. Grouping was next on my
list. The suggestion of a table is a good one, I will see how that looks.

I'll post here when there is more to review,
Thanks,
Andy

On Tue, 12 Dec 2017 at 02:12 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Mon, 11 Dec 2017 17:37:10 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> Looks good, but I think it's too trimmed. Maybe it's just that in every
> language I know a method, function, etc. also lists its inputs and outputs
> (return and argument names/types). and not having that there even in
> shorthand
> makes it harder to know at a glance if that is what I want.
>
>   Efl.Text.Markup.markup (get, set)
>   Efl.Text.text (get, set) [Overridden here]
>
> for example. what does it take? a string? i guess so... but i'm not sure. 1
> parameter or 2 what about:
>
>   Efl.Ui.Layout.theme (set)
>
> what does this take to set? i happen to know it's a string... but knowing
> at a
> glance what these are would make these far more useful.
>
> Also I notice sorting is odd. The protected methods are sorted separately
> to the
> rest. Wouldn't it make sense to at least separate off a "protected" section
> then instead of adding protected to each entry?
>
> Just for "aesthetics" wouldn't it be also nicer to put the list of
> methods/properties in a table?  If we're sorting by parent class
> (Efl.Ui.Cursor, Efl.Ui.Layout etc. etc.) why repeat this per line? start a
> table row with the class name then list all the properties/methods over the
> next N lines (perhaps indented) like:
>
>   | Efl.Text.Markup
> |
>   |  | cursor_markup_insert   | method|
> |
>   |  | markup | get | set |
> |
>   | Efl.Text
>  |
>   |  | text   | get | set | [Overridden here]
> |
>   | Efl.Ui.Autorepeat
> |
>   |  | autorepeat_enabled | get | set | [Overridden here]
> |
>   |  | autorepeat_gap_timeout | get | set | [Overridden here]
> |
>   |  | autorepeat_initial_timeout | get | set | [Overridden here]
> |
>   |  | autorepeat_supported   | get | | [Overridden here]
> |
>   | Efl.Ui.Base
> |
>   |  | language   | get | set |
> |
>   |  | mirrored_automatic | get | set | [Overridden in Elm.Widget]
> |
>   |  | mirrored   | get | set | [Overridden in Elm.Widget]
> |
>
> without the actual table border lines - keep it blank with padding to
> space it
> out, perhaps the "Efl.Ui.Base" class inheritance headers having a different
> background color for the table row to delineate sections more easily.
> removal
> of the parent class to a header should create a bit more room for the
> arguments
> and returns i mentioned above...
>
> similarly for events? just suggestions.
>
> > Hi,
> >
> > I have done some significant updates to the new API docs. The layout
> still
> > wants a little tweaking but they should be more readable than they were
> > before. I've trimmed the fat out of all inherited members as discussed
> > before.
> >
> > The result is that a page like
> > www.enlightenment.org/develop/api/efl/ui/button which has no members of
> > it's own has gone down from 300k to 128k (according to curl).
> >
> > This should help our average page load time a lot - and it needs work as
> we
> > are sitting at 4sec currently!
> >
> > Let me know if you see any problems with the new trimmed rendering.
> >
> > Thanks,
> > Andy
> > --
> > http://andywilliams.me
> > http://ajwillia.ms
> >
> --
> > Check out the vibrant tech co

[E-devel] Unified API docs

[Andrew Williams]

Hi,

I have done some significant updates to the new API docs. The layout still
wants a little tweaking but they should be more readable than they were
before. I've trimmed the fat out of all inherited members as discussed
before.

The result is that a page like
www.enlightenment.org/develop/api/efl/ui/button which has no members of
it's own has gone down from 300k to 128k (according to curl).

This should help our average page load time a lot - and it needs work as we
are sitting at 4sec currently!

Let me know if you see any problems with the new trimmed rendering.

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

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

[Andrew Williams]

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?

Thanks,
Andy

On Sun, 10 Dec 2017 at 21:23 Cedric Bail  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

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

[Andrew Williams]

Hi,

That's great, thanks very much.

Andy

On Mon, 11 Dec 2017 at 06:22 Amitesh Singh <singh.amit...@gmail.com> wrote:

> On Mon, Nov 27, 2017 at 9:43 PM, Jean-Philippe André <j...@videolan.org>
> wrote:
>
> > Amitesh, please fix it!
> >
> >
> Sungtaek has fixed 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
> > >

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

[Andrew Williams]

Hi,

I had not intended to seem like I was giving up - I am pushing hard to try
and have this discussion as I think it is important. The paragraph you
referenced was intending to point out that our mailing list discussions do
not have an open nature to them so others feel it is not worth
contributing. When words like “guarantee” and “zero value” are used can you
not see how that could be received?

As I have pointed out before the interface parent ticket has new tickets
added faster than we are closing existing ones. I see also that completely
broken eo widgets are being pushed into master (see efl.ui.panes for
example) and abandoned. With that in mind can we realistically expect to
release the whole lot in one go this decade?

I will work with the folk I have been chatting with to see if I can pull
together the requirements that are driving the desire to start building on
eo api rather than legacy.

Andrew
On Sun, 10 Dec 2017 at 11:33, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Sun, 10 Dec 2017 09:35:05 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi,
> >
> > Apologies I was not aware of these plans that everyone agreed on. Can you
> > please point me to this plan? It is very difficult to make a case for
> > change without knowing the preceding plan that would need to change.
>
> that all of eo/efl interfaces is behind the same beta flag until done.
> it's the
> state you see now. there were and are no plans to pick and choose some
> interfaces to release as stable, and some not. at one point we were talking
> about making just eo stable but then we realized it needed lots of changes
> and
> this has never come up again.
>
> you want the plan? see the tickets for interfaces. that's the work to be
> done
> and the work done on the interfaces themselves feeds back to the lower
> levels
> all the time.
>
> > To require irc logs or ML emails asking for this change is to imply that
> > we, the community, are serving just this community - I thought we were
> > looking bigger picture than that. It would be a violation of trust to
> paste
> > private conversations or concerns into this email chain, perhaps those
> who
> > are in agreement will contribute to this conversation.
>
> if you're using them as a justification, then they should be quoted here.
>
> > I am confused about what you mean regarding consensus. I have seen no
> > discussion bar this about release plans or indeed the plan / priority for
> > interfaces. If we could publicly discuss or collaborate on that this
> would
> > be a lot easier. I agree that there has been little discussion on this
>
> that's because it is one blob of work and the "let's release different b
> its at
> different times" is not there because that was not agreed on, otherwise
> it'd be
> in tickets.
>
> what was agreed on is what is already there in code and tickets. the
> things to
> be eoified (well it is a rough list that gets more refined as time goes
> on).
> it's all behind the same ifdef. ...
>
> if you want to change this direction and state... you should convince many
> people it's a good idea. i, so far, am not convinced it is. you'd need to
> convince more than me too.
>
> > thread but from your first email it seemed like it would be a waste of
> time
> > discussing so I’m not surprised. This does not detract from the number of
> > people who have spoken to me that are disappointed we cannot be thinking
> > about releasing some of our work.
>
> every time i disagree you seem to take it as a "i give up". so what should
> i
> do" just shut up and pretend to agree? what is the point of a discussion
> when
> it has to become a "let me just lie and not express what i think to make
> someone else happy"? you expressed an opinion. i expressed a counter one. i
> believe the value does not justify the cost. i made that clear. convince me
> otherwise. otherwise this is not a discussion.
>
> > However if the plan you described is publicly available then I apologise
> > for the confusion. I can point these individuals to the document and we
> can
> > think harder about what the smallest change could be that provides a
> > solution for everyone.
> >
> > Thanks,
> > Andrew
> > On Sun, 10 Dec 2017 at 01:09, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> >
> > > On Sat, 09 Dec 2017 13:38:51 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > This has become a circular argument, as many do around here, vis:
> > > > *) people are asking for us to try and agree on stable areas of the
> 

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

[Andrew Williams]

Hi,

Apologies I was not aware of these plans that everyone agreed on. Can you
please point me to this plan? It is very difficult to make a case for
change without knowing the preceding plan that would need to change.

To require irc logs or ML emails asking for this change is to imply that
we, the community, are serving just this community - I thought we were
looking bigger picture than that. It would be a violation of trust to paste
private conversations or concerns into this email chain, perhaps those who
are in agreement will contribute to this conversation.

I am confused about what you mean regarding consensus. I have seen no
discussion bar this about release plans or indeed the plan / priority for
interfaces. If we could publicly discuss or collaborate on that this would
be a lot easier. I agree that there has been little discussion on this
thread but from your first email it seemed like it would be a waste of time
discussing so I’m not surprised. This does not detract from the number of
people who have spoken to me that are disappointed we cannot be thinking
about releasing some of our work.

However if the plan you described is publicly available then I apologise
for the confusion. I can point these individuals to the document and we can
think harder about what the smallest change could be that provides a
solution for everyone.

Thanks,
Andrew
On Sun, 10 Dec 2017 at 01:09, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Sat, 09 Dec 2017 13:38:51 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > This has become a circular argument, as many do around here, vis:
> > *) people are asking for us to try and agree on stable areas of the API
> so
> > we can start testing it externally
> > *) we won’t do that until there is proof that people are using our beta
> > APIs (which are currently unstable).
> > How can we break this loop?
>
> which people where are asking for a release of a small susbet of the api?
> show
> me.
>
> > I cannot believe that all of the new APIs are completely unstable until
> we
> > release - that is basically a house of cards that we hope one day will
> > become rigid. Some of what we have is more mature than other things - but
> > every single API we add immediately goes into the BETA flag for next
> > release..
>
> you are asking for a change of plans that everyone working on eo/interfaces
> agreed on. you have to make your case for that CHANGE. don't tell me
> "people
> are asking". show me the emails here asking, and from who. show me the irc
> logs or the phab tickets. i'm not talking about the full release of what
> was
> planned but the subset you mentioned. see above. those changes come with a
> cost
> (locking yourself in). we'd be stupid to pay the cost with no evidence
> beyond
> your comment "people are asking". not to mention it'd also be ignoring the
> previous agreement on what to do.
>
> until the people working on eo/interfaces can ALL come to a consensus...
> nothing is going to change. and there is no input from most of them at this
> point, and no overwhelming evidence to ignore any input from them if it
> were to
> come.
>
> > If we cannot make any release in the way previously discussed then we
> > absolutely should have some other way of illustrating our confidence in
> an
> > API. Therefore an alternative I propose is to add an ALPHA flag (which is
> > mostly what BETA feels like at the moment) where new Eo goes and those
> > marked as BETA are the classes we feel could be eliciting feedback.
> > This way we are able to show where we know we have not tested as much and
> > can show a journey through creation, testing and integration into the
> BETA
> > area.
> >
> > Without this we are just hoping that some day all our classes will be
> > stable so we can roll a release...
> >
> > Andrew
> > On Sat, 9 Dec 2017 at 12:48, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> >
> > > On Fri, 08 Dec 2017 19:06:47 -0500 Cedric Bail <ced...@ddlm.me> said:
> > >
> > > > >  Original Message 
> > > > > Subject: Re: [E-devel] What are we going to release?
> > > > > Local Time: December 7, 2017 5:06 PM
> > > > > UTC Time: December 8, 2017 1:06 AM
> > > > > From: ras...@rasterman.com
> > > > > To: Andrew Williams <a...@andywilliams.me>
> > > > > Enlightenment developer list <
> > > enlightenment-devel@lists.sourceforge.net>
> > > > >
> > > > > On Thu, 07 Dec 2017 13:45:51 + Andrew Williams
> > > a...@andywilliams.me
> > > > > said:
> > > >

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

[Andrew Williams]

This has become a circular argument, as many do around here, vis:
*) people are asking for us to try and agree on stable areas of the API so
we can start testing it externally
*) we won’t do that until there is proof that people are using our beta
APIs (which are currently unstable).
How can we break this loop?

I cannot believe that all of the new APIs are completely unstable until we
release - that is basically a house of cards that we hope one day will
become rigid. Some of what we have is more mature than other things - but
every single API we add immediately goes into the BETA flag for next
release..

If we cannot make any release in the way previously discussed then we
absolutely should have some other way of illustrating our confidence in an
API. Therefore an alternative I propose is to add an ALPHA flag (which is
mostly what BETA feels like at the moment) where new Eo goes and those
marked as BETA are the classes we feel could be eliciting feedback.
This way we are able to show where we know we have not tested as much and
can show a journey through creation, testing and integration into the BETA
area.

Without this we are just hoping that some day all our classes will be
stable so we can roll a release...

Andrew
On Sat, 9 Dec 2017 at 12:48, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Fri, 08 Dec 2017 19:06:47 -0500 Cedric Bail <ced...@ddlm.me> said:
>
> > >  Original Message 
> > > Subject: Re: [E-devel] What are we going to release?
> > > Local Time: December 7, 2017 5:06 PM
> > > UTC Time: December 8, 2017 1:06 AM
> > > From: ras...@rasterman.com
> > > To: Andrew Williams <a...@andywilliams.me>
> > > Enlightenment developer list <
> enlightenment-devel@lists.sourceforge.net>
> > >
> > > On Thu, 07 Dec 2017 13:45:51 + Andrew Williams
> a...@andywilliams.me
> > > said:
> > >
> > > Without a guarantee of no changes then you don't provide anything
> stable to
> > > build on top of. It's no different to what we do now. We could just
> say "we
> > > think these interfaces are ok now - you can try using them but we might
> > > still break them" which is is not some special beta release. it's just
> > > providing a "we think its more stable now" assessment.
> >
> > I am thinking of a stronger commitment on our part here. Basically as I
> said
> > in my email above, if a binding doesn't report a real big problem with
> what
> > is under that RC umbrella, then we do not break it.
>
> unless it's "absolutely will not break at all" then it's really no better
> in
> the end.
>
> > I am afraid that for a lot of this lower level, we are now starting to do
> > what we were doing before we release EFL 1.0. Trying to make it perfect
> > without having ever spend the time to prepare a proper release. We need
> to
> > focus and get things out.
> >
> > > but still if it's just what you were saying then what apps can be
> written
> > > using those api's - and will they be?
> >
> > EFL apps already exist. They can get migrated to the new API. That is the
> > main target of this release.
>
> other than some mechanical "sed work" like s/evas_object_del/efl_del/g ...
> which buys nothing really useful... what is really going to be done? and
> what
> will this demonstrate to us or anyone else api-wise? not much.
>
> > >> Why does it have to be black and white? releasing does not "guarantee
> no
> > >> changes", it probably does need to guarantee backward compatibility.
> The
> > >> challenge I see with our current situation is that we have published
> "beta"
> > >> which is not even close to stable and now don't have a clear next
> step to
> > >> get people involved. A "release candidate" might be an obvious step
> which
> > >> comes as part of a release plan, which is what I wanted to discuss.
> > >>
> > >> what we have is a release candidate so to speak that is clearly
> showing its
> > >> state - it's not stable.
> > >>
> > >> trying to release something as stable that is NOT (call it a release
> > >> candidate or whatever) is just being dishonest.
> > >>
> > >> I think that EFL and our community is in a different place to where
> it was
> > >> years before ecore. We should learn from (everyone's) experience and
> figure
> > >> how to apply that to our current situation. Our current reality is
> that
> > >> companies with real products want to build on what we have. Tha

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

[Andrew Williams]

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?

Thanks,
Andy
On Sat, 9 Dec 2017 at 00:10, Cedric Bail  wrote:

> >  Original Message 
> > Subject: [E-devel] Interfaces API not in EFL namespace
> > Local Time: December 8, 2017 10:35 AM
> > UTC Time: December 8, 2017 6:35 PM
> > From: a...@andywilliams.me
> > To: Enlightenment developer list <
> enlightenment-devel@lists.sourceforge.net>
> >
> > Hi,
> >
> > I've been going through our API documentation generation (for Eo API)
> and I
> > found some interesting numbers. We all know there is a lot to do in terms
> > of porting legacy to Eo API but I found a lot of API that is in Eo but is
> > not in the Efl namespace (i.e. Ecore / Elm etc) which I assume will also
> > need to be ported.
> >
> > The total number of "legacy eo" classes and types are as follows (with
> > percentage of total in each category)
> >
> > === CLASS SECTION: 442 ===
> >
> > Classes: 157 (44%)
> > Interfaces: 3 (3.5%)
> > Mixins: 8 (24%)
> > Events: 274 (48%)
> >
> > === TYPE SECTION: 807 ===
> >
> > Aliases: 62 (85%)
> > Structs: 46 (52%)
> > Struct fields: 71 (35%)
> > Enums: 92 (48%)
> > Enum fields: 534 (40%)
> >
> > Or to summarise 43% of the Eo definitions are not in the Efl namespace.
> > This is a lot of additional work to the new class creation - do we have
> > tickets to track this all as well?
>
> We have ported basically every object we had to Eo, but this doesn't mean
> they will be part of the new Eo exposed API. They can stay legacy forever
> on top of Eo API. This provide for additional safety and better integration
> between legacy object and new Eo object. I have to update the ticket
> tracking all development for the interface some time during the weekend.
> This should reflect what we intend to make part of the new API.
>
> 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

[E-devel] Interfaces API not in EFL namespace

[Andrew Williams]

Hi,

I've been going through our API documentation generation (for Eo API) and I
found some interesting numbers. We all know there is a lot to do in terms
of porting legacy to Eo API but I found a lot of API that is in Eo but is
not in the Efl namespace (i.e. Ecore / Elm etc) which I assume will also
need to be ported.

The total number of "legacy eo" classes and types are as follows (with
percentage of total in each category)

=== CLASS SECTION: 442 ===

Classes:   157 (44%)
Interfaces: 3 (3.5%)
Mixins: 8 (24%)
Events:274 (48%)

=== TYPE SECTION: 807 ===

Aliases:62 (85%)
Structs:46 (52%)
Struct fields: 71 (35%)
Enums: 92 (48%)
Enum fields:  534 (40%)

Or to summarise 43% of the Eo definitions are not in the Efl namespace.
This is a lot of additional work to the new class creation - do we have
tickets to track this all as well?

Have a happy weekend!
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

Re: [E-devel] KiwiIRC callouts

[Andrew Williams]

Hi,

Perhaps I should rephrase my question. Are we happy with these callouts?
For some reason it's proximity to our user's chat history makes me hesitate.

https://www.theguardian.com/technology/2012/apr/23/scorecardresearch-tracking-trackers-cookies-web-monitoring

Thanks,
Andrew

On Fri, 8 Dec 2017 at 01:12 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Thu, 07 Dec 2017 15:09:21 +0000 Andrew Williams <a...@andywilliams.me>
> said:
>
> > Hi,
> >
> > Did anyone know that the KiwiIRC client on our website is calling out to
> > https://www.gosquared.com/ and https://www.scorecardresearch.com/?
> > Does anyone know if we activated these extensions? I have no idea what
> > those sites do or what data they are collecting.
>
> we don't decide that. that's part of the www kiwi irc client. the irc
> client is
> a small bit of js that simply auto-selects a random irc nick, then creates
> an
> iframe from https://kiwiirc.com ... everything else is the kiwi irc client
> itself doing this. the only way to avoid this is to ... self-host our own
> back-end and hook that into freenode. the kiwi irc client as provided by
> kiwiirc.com has very limited options. very limited.
>
> > 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" --
> Carsten Haitzler - ras...@rasterman.com
>
> --
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

[E-devel] KiwiIRC callouts

[Andrew Williams]

Hi,

Did anyone know that the KiwiIRC client on our website is calling out to
https://www.gosquared.com/ and https://www.scorecardresearch.com/?
Does anyone know if we activated these extensions? I have no idea what
those sites do or what data they are collecting.

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

Re: [E-devel] Website statistics

[Andrew Williams]

Hi,

Thanks for the tip on Piwik, looks decent. To use it for free we would have
to self host and I don't think we have time to manage another service
unfortunately.

As there were no objections I went with GA for now. If anyone thinks they
should be or would like to have access to the data it's collecting then
email your google account off-list.

Thanks,
Andrew

On Tue, 5 Dec 2017 at 20:37 Jonathan Aquilina <jaquil...@eagleeyet.net>
wrote:

> Hi Andrew,
>
> There is also an open source alternative called piwik which does the same.
>
> https://piwik.org/
>
> :D
>
> On 05/12/2017 20:19, Andrew Williams wrote:
> > Hi,
> >
> > As part of the effort to rejuvenate and reshape our documentation and
> > related pages on the website it would be really helpful to get
> information
> > about where people are spending time and so forth.
> >
> > The standard way to do this these days appears to be with Google
> Analytics
> > - it is simple to set up and dokuwiki has a plugin to add it to the site.
> >
> > Unless anyone feels strongly against this I will add it in the next few
> > days.
> >
> > Thanks,
> > Andy
> >
>
>
> --
> 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

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

[Andrew Williams]

Why does it have to be black and white? releasing does not "guarantee no
changes", it probably does need to guarantee backward compatibility. The
challenge I see with our current situation is that we have published "beta"
which is not even close to stable and now don't have a clear next step to
get people involved. A "release candidate" might be an obvious step which
comes as part of a release plan, which is what I wanted to discuss.

I think that EFL and our community is in a different place to where it was
years before ecore. We should learn from (everyone's) experience and figure
how to apply that to our current situation. Our current reality is that
companies with real products want to build on what we have. That's pretty
exciting I reckon.

Until we have a release of the new API that people can actually start
relying on being somewhat stable we are expecting them to use only the old
API. In the meantime we have most active development on it's replacement.
We are basically saying "you can use the old stuff, but you'll need to port
later - or you can try and use the new stuff, which requires regular
updating to keep up". To me this looks like there is no practical way that
we can encourage new people to rely on EFL. This makes me sad.

Should we instead figure when we might start releasing and set an
expectation to the public? Something like "come back in 2019"?

Andrew

On Thu, 7 Dec 2017 at 10:37 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Thu, 07 Dec 2017 08:54:05 + Andrew Williams <a...@andywilliams.me>
> said:
>
> so what applications can you build only with efl core and efl net and
> nothing
> else?
>
> zero applications will be built with these. it will not be tested. history
> tells
> me so. BUT it will tie our hands in making changes. so what value does this
> provide? none to any developers who know that the api is STILL unstable and
> changes might be made, unless we guarantee NONE will be... and then if
> NONE are
> broken, our hands are tied.
>
> i'm speaking from experience here. i made eet 1.0 long (years) before
> ecore,
> evas, etc. etc. ... and people didn't go using it. been there. done that.
> and
> by the time the others were ready i was already going "crap - i shouldn't
> have
> done that" because eet had to hold legacy file format support (and still
> does)
> that was deprecated already in efl before edje 1.0 was done.
>
> what we have now i think is the best we can do.
>
> > Hi,
> >
> > To say that it is publicly available behind a BETA flag is one thing, but
> > to call it a Beta Release is quite a stretch. To reference The Next
> > Generation Lexicon: "Beta phase generally begins when the software is
> > feature complete but likely to contain a number of known or unknown
> bugs.".
> > Given the current state of the interfaces I would say that to treat it
> like
> > that is exceptionally generous. I have never been anywhere where the
> > developers or users have been told "It's in beta - the APIs will change -
> > we don't care" which is common parlance around here.
> >
> > I think it's unfair to say that releasing a subset has "no value". The
> APIs
> > described allow you to build a complete application - albeit without a
> > graphical front end - which is a great start, even a solid foundation.
> With
> > a little more work we could have Efl.Canvas and Efl.Gfx in there to get
> > early access to the new graphical APIs. It seems that Efl.Ui is sinking
> the
> > most time and we are having to rewrite areas of it as the underlying
> > libraries change. Surely nailing the underpinnings and releasing them
> gives
> > us a stable platform to deliver on.
> >
> > Calling for release discussions seems required to focus us. As everyone
> > acknowledges we are a team spread very thin and if we continue to have
> > little or no direction for release we will continue to work on what is
> > interesting and not to wrap up an API that is actually usable and
> reliable
> > to anyone.
> >
> > Right now I don't think it's clear what we are trying to achieve. It
> would
> > be a death knell to our chances of being taken seriously if we once again
> > take 10 years to do a major upgrade.
> >
> > Regards,
> > Andrew
> >
> > On Thu, 7 Dec 2017 at 01:22 Carsten Haitzler <ras...@rasterman.com>
> wrote:
> >
> > > On Wed, 06 Dec 2017 19:45:39 -0500 Cedric Bail <ced...@ddlm.me> said:
> > >
> > > > Hi,
> > > >
> > > > >  Original Message 
> > > > > Subject: Re:

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

[Andrew Williams]

Hi,

To say that it is publicly available behind a BETA flag is one thing, but
to call it a Beta Release is quite a stretch. To reference The Next
Generation Lexicon: "Beta phase generally begins when the software is
feature complete but likely to contain a number of known or unknown bugs.".
Given the current state of the interfaces I would say that to treat it like
that is exceptionally generous. I have never been anywhere where the
developers or users have been told "It's in beta - the APIs will change -
we don't care" which is common parlance around here.

I think it's unfair to say that releasing a subset has "no value". The APIs
described allow you to build a complete application - albeit without a
graphical front end - which is a great start, even a solid foundation. With
a little more work we could have Efl.Canvas and Efl.Gfx in there to get
early access to the new graphical APIs. It seems that Efl.Ui is sinking the
most time and we are having to rewrite areas of it as the underlying
libraries change. Surely nailing the underpinnings and releasing them gives
us a stable platform to deliver on.

Calling for release discussions seems required to focus us. As everyone
acknowledges we are a team spread very thin and if we continue to have
little or no direction for release we will continue to work on what is
interesting and not to wrap up an API that is actually usable and reliable
to anyone.

Right now I don't think it's clear what we are trying to achieve. It would
be a death knell to our chances of being taken seriously if we once again
take 10 years to do a major upgrade.

Regards,
Andrew

On Thu, 7 Dec 2017 at 01:22 Carsten Haitzler <ras...@rasterman.com> wrote:

> On Wed, 06 Dec 2017 19:45:39 -0500 Cedric Bail <ced...@ddlm.me> said:
>
> > Hi,
> >
> > >  Original Message 
> > > Subject: Re: [E-devel] What are we going to release?
> > > Local Time: December 6, 2017 6:13 AM
> > > UTC Time: December 6, 2017 2:13 PM
> > > From: dan...@octaforge.org
> > > To: enlightenment-devel@lists.sourceforge.net
> > >
> > > On Wed, Dec 6, 2017, at 14:26, Andrew Williams wrote:
> > >
> > >> Hi all,
> > >> As our last release was over 4 months ago I think we really need to
> > >> figure
> > >> what the next release will be, and when, so we can start focusing on
> > >> making
> > >> that subsection of our work releasable.
> > >> Clearly we are not going to get the interfaces completed any time
> soon.
> > >> The
> > >> list of things to port keeps getting longer and we have too many
> > >> outstanding patches to count. I have heard suggestions that we could
> > >> release a subset, for example Efl_Core and Efl_Net now that they we
> have
> > >> the Efl namespace split into groups.
> > >> This would mean releasing the API (
> > >> https://www.enlightenment.org/develop/api/start) that is prefixed
> efl_io,
> > >> efl_net, efl_event or efl_loop and that's about it (as well as eina
> and
> > >> eo
> > >> which need to get merged into the non-legacy docs somehow).
> > >> Is this a good approach? Right now it seems like we need to focus on
> > >> completing portions of this and cut a release of some sort so that we
> can
> > >> have people look at usage, bindings and porting existing code. I'd
> love
> > >> to
> > >> get our website updated to filter just the APIs we plan to release
> soon.
> > >> And then generate another section for the work-in-progress completion
> of
> > >> interfaces...
> > >>
> > >> Hi,
> > >>
> > >> I told you on IRC already but I'm going to say it here publicly -
> > >> personally I don't think it's a good idea to release APIs unless we're
> > >> sure that it's really the API we want (i.e. it can be defined in
> Eolian
> > >> once it's stable, it can be used for bindings and it's
> > >> real-world-tested, i.e. we're sure of its practicality). I don't see
> any
> > >> real benefit in releasing a subset of our APIs, only potential issues.
> >
> > We have been working on EFL interfaces for years now. Literrally. We
> have to
> > do a release in the next 6 months. The main question is how to get there
> and
> > have something good enough for everyone.
> >
> > My current take is that we finish cleaning up Efl_Core and Efl_Net for a
> beta
> > release (which mean no further change except if something is really bad)
> and
> > do an EFL release with that. This would ma

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

[Andrew Williams]

Hi all,

As our last release was over 4 months ago I think we really need to figure
what the next release will be, and when, so we can start focusing on making
that subsection of our work releasable.

Clearly we are not going to get the interfaces completed any time soon. The
list of things to port keeps getting longer and we have too many
outstanding patches to count. I have heard suggestions that we could
release a subset, for example Efl_Core and Efl_Net now that they we have
the Efl namespace split into groups.
This would mean releasing the API (
https://www.enlightenment.org/develop/api/start) that is prefixed efl_io,
efl_net, efl_event or efl_loop and that's about it (as well as eina and eo
which need to get merged into the non-legacy docs somehow).

Is this a good approach? Right now it seems like we need to focus on
completing portions of this and cut a release of some sort so that we can
have people look at usage, bindings and porting existing code. I'd love to
get our website updated to filter just the APIs we plan to release soon.
And then generate another section for the work-in-progress completion of
interfaces...

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

Re: [E-devel] Rust bindings

[Andrew Williams]

I too was looking at a Rust binding.
The auto-generated one has dome bit-pack issues I have not resolved.
Ideally this would be largely automatic through Eo - but first you need to
map the eina equivalent into native space  and that is pretty much manual...

Andy

On Wed, 6 Dec 2017 at 10:13 Vincent Torri  wrote:

> shouldn't binding be automatically generated ?
>
> Vincent
>
> On Wed, Dec 6, 2017 at 3:09 AM, Vinícius dos Santos Oliveira
>  wrote:
> > 2017-12-05 23:54 GMT-03:00 Cedric Bail :
> >
> >> Care to share the link to that repo you found ?
> >>
> >
> > https://github.com/arlowhite/rust-efl
> >
> > --
> > Vinícius dos Santos Oliveira
> > https://vinipsmaker.github.io/
> >
> --
> > 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
--
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: eo: Update header for readability

[Andrew Williams]

Absolutely, good catch thanks.

Andy

On Tue, 5 Dec 2017 at 20:46  wrote:

> Hello,
>
> On Tue, Dec 05, 2017 at 09:04:12AM -0800, Andy Williams wrote:
> > ajwillia-ms pushed a commit to branch master.
> >
> >
> http://git.enlightenment.org/core/efl.git/commit/?id=b6b0fac978750eaf814c8ab9ea35abfbcecc0b5c
> >
> > commit b6b0fac978750eaf814c8ab9ea35abfbcecc0b5c
> > Author: Andy Williams 
> > Date:   Tue Dec 5 17:04:19 2017 +
> >
> > eo: Update header for readability
> >
> > Author: Nate Drake
> > Reviewer: Andy Williams
> > ---
> >  src/lib/eo/Eo.h | 414
> 
> >  1 file changed, 205 insertions(+), 209 deletions(-)
> >
> > diff --git a/src/lib/eo/Eo.h b/src/lib/eo/Eo.h
> > index e7e4bc3c96..99d61b0d82 100644
> > --- a/src/lib/eo/Eo.h
> > +++ b/src/lib/eo/Eo.h
> > @@ -10,7 +10,7 @@
> >
> >  #define EOLIAN
> >
> [...]
>
> > /* Private for EFL internal use only. Do not use these! */
> >  EAPI int ___efl_ref2_count(const Eo *obj_id);
> >  EAPI void ___efl_ref2_reset(const Eo *obj_id);
> > -EAPI void ___efl_auto_unref_set(Eo *obj_id, Eina_Bool val);
> >
>
> Ehm, ... thats not a readability issue? Can i add it back?
>
>
> >  #endif
> >
> >
> > --
> >
> >
>
>
> --
> 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

[E-devel] API naming: futures_get

[Andrew Williams]

Hi,

The method efl_promise_future_get has a peculiar name.
It's function is to allocate a new Efl_Loop_Future object, add it to a list
of all futures on the promise and propagate appropriate messages.

Following our convention of _get returning an existing value and _add
creating a new one should this method not be efl_promise_future_add?

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

[E-devel] Website statistics

[Andrew Williams]

Hi,

As part of the effort to rejuvenate and reshape our documentation and
related pages on the website it would be really helpful to get information
about where people are spending time and so forth.

The standard way to do this these days appears to be with Google Analytics
- it is simple to set up and dokuwiki has a plugin to add it to the site.

Unless anyone feels strongly against this I will add it in the next few
days.

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

[E-devel] API cleaning eina_str etc

[Andrew Williams]

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

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.

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

Re: [E-devel] Enlightenment Developer Days 2018 location proposals

[Andrew Williams]

Hi,

It's perhaps worth noting that ELCE will be in Edinburgh this year -
http://events.linuxfoundation.org/events/embedded-linux-conference-europe .
The venue is really close to where I had proposed for the E Dev Day, I know
it's later in the year but perhaps we could schedule to co-inside?

Just a thought,
Andy



On Mon, 4 Dec 2017 at 12:35 Stefan Schmidt  wrote:

> Hello.
>
>
> On 11/22/2017 05:50 PM, Stefan Schmidt wrote:
> > Hello.
> >
> >
> > The end of the year is near and we should start thinking about the next
> edition of the Enlightenment developer days.
> >
> >
> > So far we have been doing good with starting to source a suitable
> location first and find the best dates after that. I would go the same
> > route this year.
> >
> > Loking back at last years location voting we can see that Malta was on
> the top position together with Toulouse. With a close follow up of
> > Paris and Edinburgh.
> >
> > https://phab.enlightenment.org/V27
> >
> >
> > The questions comes up if our location proposals are still up to date.
> Are the persons willing to do the local organization still available?
> > (move, different employer). If your name is listed on the location
> proposals list please clarify if this is still valid or not. Simply
> > remove it if not.
> >
> > https://phab.enlightenment.org/w/events/location_proposals/
> >
> >
> > One location that is not listed on the wiki which I brought up at last
> years event was Bangkok. As far as I know we have nobody in our
> > community from there but if we would like to aim for a non EU event
> again this might be a sweet spot. In terms of flight prices from Europe
> > and being in good reach for all Asia. Just an idea, we would need to
> find local help if people are interested in it.
> >
> >
> > Please update the location proposals and start your discussion here.
> >
>
> Feedback has so far been very limited. Andy confirmed that Edinburgh would
> be possible with a good lead time for the venue.
>
> Any more comments? I would like to hear comments on potential locations as
> well as actual location offers.
>
> History has shown that we should start to plan for this early on to make
> sure things can get sorted out in time.
>
> 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
>
-- 
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

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

[Andrew Williams]

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

Maybe that’s just me.
Andy
On Fri, 1 Dec 2017 at 18:50, Davide Andreoli  wrote:

> 2017-12-01 3:12 GMT+01:00 Jean-Philippe André :
>
> > On Fri, Dec 1, 2017 at 3:49 AM, Davide Andreoli 
> > wrote:
> >
> > > 2017-11-30 3:36 GMT+01:00 Jean-Philippe ANDRÉ :
> > >
> > > > jpeg pushed a commit to branch master.
> > > >
> > > > http://git.enlightenment.org/core/efl.git/commit/?id=
> > > > bd5b76508b0b3bdc5d92f5f7db9741c100d47d3c
> > > >
> > > > commit bd5b76508b0b3bdc5d92f5f7db9741c100d47d3c
> > > > Author: Jean-Philippe Andre 
> > > > 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 +-
> > > >  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 \
> > > >  

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

[Andrew Williams]

Hi,

I called the parent method as indicated.
Unfortunately that returned FAILED and broke the functionality so, for now,
I don't check the return of the super call.
I guess I need to look more into theme application and swapping out layouts
to understand why it's not working as expected.

Thanks for the pointer,
Andy

On Tue, 28 Nov 2017 at 04:52 Jean-Philippe André  wrote:

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

[E-devel] Efl.Ui.Text.Interactive events

[Andrew Williams]

Hi,

I have an EFL_UI_TEXT_CLASS object in my app and I have registered for 2
interactive text events

efl_event_callback_add(efl_added,
EFL_UI_TEXT_INTERACTIVE_EVENT_SELECTION_CHANGED, _editor_selection_changed,
NULL),
efl_event_callback_add(efl_added,
EFL_UI_TEXT_INTERACTIVE_EVENT_CHANGED_USER, _editor_changed, NULL),

Neither of these are called. Am I doing something wrong or should I report
a bug?

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