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 wrote:
> On Wed, 03 Jan 2018 09:51:54 + Andrew Williams
> said:
>
> > Seems like this is something th
On Wed, 03 Jan 2018 00:41:30 -0500 Cedric Bail said:
> > 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
On Wed, 03 Jan 2018 09:51:54 + Andrew Williams 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
On Wed, 03 Jan 2018 09:43:16 + Andrew Williams 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 ve
On Wed, 03 Jan 2018 19:03:39 -0500 Cedric Bail said:
> > 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
> >
>
On Wed, 03 Jan 2018 09:36:34 + Andrew Williams said:
> 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));
>
On Wed, 3 Jan 2018 21:09:17 -0500 Michael Blumenkrantz
said:
> On Sat, 23 Dec 2017 19:37:31 +0900
> Carsten Haitzler wrote:
>
> > On Fri, 22 Dec 2017 19:54:02 + Andrew Williams
> > said:
> >
> > > Hi Vincent,
> > >
> > > I would really love this too - in fact I have been pushing for it.
On Sat, 23 Dec 2017 19:37:31 +0900
Carsten Haitzler wrote:
> On Fri, 22 Dec 2017 19:54:02 + Andrew Williams
> 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
>
> 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
>
> Hi Cedric,
>
> I think I agree, if we can tidy the definitions then
On Wed, Jan 3, 2018 at 1:07 PM, Andrew Williams wrote:
> 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
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
On Wed, Jan 3, 2018 at 11:55 AM, Andrew Williams 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,
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
wrote:
> On We
On Wed, Jan 3, 2018 at 11:07 AM, Andrew Williams 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
aut
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.enl
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 1
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 Blume
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
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); /
19 matches
Mail list logo
