[E-devel] A step to improving communication - Meetings

[William L. Thomson Jr.]

One thing I have seen be of benefit in other communities is having
regular meetings.

It was definitely beneficial to Gentoo Java Team, long ago. This some
what helped create a team, and definitely helped keep people on the same
page, helped with communication, etc. When meetings ended, so did the
team over time. They helped make the team and broke it...

Does the E developer community ever meet beyond like EDD? Like regular
monthly meetings in IRC or other?

Even if no other organization beyond that, I think it would help with
communication all around. I think that would be helpful step if not
done currently. That is not only good for current developers, but
users, and looky-loos.

-- 
William L. Thomson Jr.


pgp6eHbvBDnLT.pgp
Description: OpenPGP digital signature
--
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

[William L. Thomson Jr.]

On Thu, 8 Mar 2018 17:14:21 +0900
Carsten Haitzler (The Rasterman)  wrote:
>
> But that is the reality. They can call the shots and listen to users.
> Users are not always right. But listening is good. In the end people
> doing work make the final decisions. And I guess to some extent I
> hold a veto power over those which I generally choose not to exercise
> except on rare occasions when I think it is warranted.

Not for all, I think those that balance user needs the most tend to
prosper the most. It is the same for companies that make products. They
choose what to make, and how. But the ultimate decider if they were
right or not is the market, the users.

Apple was never big on focus groups, but if a product hit market and
did not do well. That was a tell as to product failure or success.
Either method relies on the end user, before, during, or after. Users
tend to make or break things, determine if it was successful or not.

Gentoo has had an ever increasing focus on those doing the work vs
users and its not had a good effect. I try to always put users needs
above my own. Even when I am the one doing the work.

> I think there is a balance. Moving forward with minimal interference,
> yet still trying to maintain quality too. You will never have
> perfect. Perfect is the enemy of good.

I completely agree. I think in FOSS there is to much striving for
perfection. When in closed source, at some point must ship to make
money and recoup investment. I think FOSS has more hang ups to shipping
less than perfect software. When the world is based on less than
perfect software as is now.

Take GNU kernel vs Linux. Keep striving for perfect, was taking
forever, and Linux screamed on by. Good example of such.

> > > I don't think we need STRUCTURE. I think we need communication. I
> > > think people have become awfully bad at this. Here is what people
> > > need to do IMHO.  
> > 
> > I agree on communication, but I also believe structure is important
> > to organizing any group of people to work together on anything.  
> 
> structure is no good without communication to begin with.

I agree, communication is the core to it all. An organization cannot do
a thing without good communication. You will have a hard time
organizing at all without communication.
   
> > > f) I still think E should have the filemanager built in. It's far
> > > too useful to not do this. It's pretty much necessary for icons on
> > > the desktop and consistent FM UI. If its done in-process or
> > > outside is another matter, but it has to be deeply integrated.   
> > 
> > In brief, I am not a big fan of such. Seems like a Windows concept
> > where Explorer ( not Internet Explorer) is deeply integrated. Pretty
> > much any issue I have with E that is non-recoverable comes from
> > EFM.  
> 
> actually ... this pre-dates windows. amiga workbench had it all
> integrated before windows 1.0 was around. and i'm an amiga fan. a lot
> of e was inspired from those days. i firmly believe a filemanager has
> to be deeply integrated.

Maybe best for another thread. I am curious what benefits you see in a
deeply integrated file manager. I think that goes against the Unix
philosophy of not deeply integrating anything.

I just do not like any one thing taking out other stuff. The more
things can be limited and only effect themselves, the better IMHO.

> what are the non-recoverable issues you have? i don't see those. i do
> use efm... sometimes thumbnails are blank - scrol lup and down again
> and it fixes... recently dnd seems to be flaky and stop working but
> that's not an efm change. something in efl did this i think. efm
> doesn't have a transhcan. that should be added.

The main one, maybe theme issue, is some animation I cannot easily
replicate. Where there are arrows on all four corners of the box around
the selected file/folder. It does an animation and never ends and gets
stuck. Remains on screen after closing EFM. I have had other issues
where I could not close it.  Those are what I can recall offhand.
Pretty sure there are more. I really try to avoid it.

Aside from curiosity the main reason I have verne installed is issues
with EFM. I really try to avoid it due to past history with it.

Trashcan is some what moot to me, as I rarely delete files via a file
manager.

Along the same lines, I cannot select multiple files/folders/icons on
the desktop. Though maybe related to main menu being left click. You
can do that in the file manager itself.



-- 
William L. Thomson Jr.


pgpdzQ8Da225_.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/02: gl_drm: Move the gl symbol check to immediately after display init

[Derek Foreman]

On 2018-03-07 11:26 PM, Carsten Haitzler (The Rasterman) wrote:

On Wed, 07 Mar 2018 13:25:27 -0800 Derek Foreman  said:

this brings back memories of problems with checking for extension symbols
before a context is set up. the context may change the symbols (procaddress
returned functions) as for example the same symbol for gles1.1 might vary for
2.0 and then 3.0 ...

i know we've had these issue because that that's why the checks happen after
context init.

are you sure this is right?


I think so, but I'm not sure all of this stuff is working as intended.

As far as I can tell from the spec, we need an initialized display to 
query these strings (or NO_DISPLAY to query client extensions, which we 
really should be doing too). It's the GL_EXTENSIONS, not EGL that need a 
bound context.


It was my commit that split up and moved the gl symbols for this engine 
in commit eda81c6dffd84f so I think I was overly zealous there.  I think 
before that maybe were were using an invalid/no display and getting just 
the client strings, which are quite different.  (We actually should be 
using client strings to determine if we can use eglGetPlatformDisplay)


I've tested here and I get exactly the same string before and after the 
recent change on my intel hardware.  Haven't checked all the procaddress 
pointers.


Other compositors do the same thing (weston), so I think it's right this 
way.


What we probably should be doing is:
query egl client extensions
create display (with platform base if it's in client exts)
init display
query egl extensions
create context (perhaps using IMG's priority ext)
makecurrent
query gl extensions

but I'm having a really hard time understanding the guts of 
evas_gl_symbols() as it seems to expect the EGL_EXTENSIONS string to be 
passed in (it looks for EGL_KHR_image_base), but it also looks for stuff 
like GL_OES_mapbuffer which would be in the gl extension string you 
can't get until you have a context bound.


So am I supposed to call this function twice, once with EGL extensions 
and once with GL extensions?  or strcat the strings (which means I have 
to call after my context is bound?) or ??


Thanks,
Derek


derekf pushed a commit to branch master.

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

commit f8658d25fa604f885ee23b20e94a2892d340bceb
Author: Derek Foreman 
Date:   Wed Mar 7 13:11:45 2018 -0600

 gl_drm: Move the gl symbol check to immediately after display init
 
 We don't actually need a context first, just an initialized display.

---
  src/modules/evas/engines/gl_drm/evas_outbuf.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/modules/evas/engines/gl_drm/evas_outbuf.c
b/src/modules/evas/engines/gl_drm/evas_outbuf.c index aff5de87bf..b1235355cc
100644
--- a/src/modules/evas/engines/gl_drm/evas_outbuf.c
+++ b/src/modules/evas/engines/gl_drm/evas_outbuf.c
@@ -226,6 +226,8 @@ _evas_outbuf_egl_setup(Outbuf *ob)
  return EINA_FALSE;
   }
  
+   eng_gl_symbols(ob->egl.disp);

+
 if (!eglGetConfigs(ob->egl.disp, NULL, 0, ) || (ncfg == 0))
   {
  ERR("eglGetConfigs() fail. code=%#x", eglGetError());
@@ -334,8 +336,6 @@ _evas_outbuf_egl_setup(Outbuf *ob)
  goto err;
   }
  
-   eng_gl_symbols(ob->egl.disp);

-
 ob->gl_context = glsym_evas_gl_common_context_new();
 if (!ob->gl_context) goto err;
  


--








--
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] futures again... :(

[Felipe Magno de Almeida]

On Thu, Mar 8, 2018 at 4:58 AM, Carsten Haitzler  wrote:
> On Thu, 1 Mar 2018 14:11:26 -0300 Gustavo Sverzut Barbieri 
> 
> said:

[snip]

> no. we can't auto-del the object no matter how much i'd love to. felipe would
> kill me. :) ...

:D. Or myself.

[snip]

-- 
Felipe Magno de Almeida

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

Re: [E-devel] WWW 2

[The Rasterman]

On Thu, 8 Mar 2018 10:11:52 +0100 Vincent Torri  said:

> On Thu, Mar 8, 2018 at 9:55 AM, Carsten Haitzler  wrote:
> > On Mon, 5 Mar 2018 00:42:14 +0100 Knapp  said:
> >
> >> I am researching a project to make a new WWW; WWW2. It would be completely
> >> non-backwards compatible with WWW.
> >> So a few questions.
> >>
> >> Would your libraries be good for this, noting that I want to make Apple, MS
> >> and Linux WWW2 Browsers as the first step?
> >>
> >> What sort of support to you provide for 3d? Could a 3d game be made with
> >> your libraires? How about 3d glasses support? I see the future WWW2 as
> >> having a strong 3d and 2d support as well as smartphone and tablet support
> >> built in.
> >>
> >> Thanks for any support you can give!
> >
> > ther'es evas gl api that exposes a gl rendering api. see the elm glview
> > widget and examples in elementary_test.
> >
> > there is also a whole evas_3d object with a full scene graph inside. someone
> > has actually made games with it before. a battleship game i think? the
> > problem is gl wont really work well on windows. :/
> 
> Except if we use the Angle library. It coudl be easy to add a win32 gl engine.
> 
> raster : you told me that, first, you need to clean it (too many
> copy/paste in the gl engines iirc)

it does need cleaning indeed.

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

Re: [E-devel] WWW 2

[Vincent Torri]

On Thu, Mar 8, 2018 at 9:55 AM, Carsten Haitzler  wrote:
> On Mon, 5 Mar 2018 00:42:14 +0100 Knapp  said:
>
>> I am researching a project to make a new WWW; WWW2. It would be completely
>> non-backwards compatible with WWW.
>> So a few questions.
>>
>> Would your libraries be good for this, noting that I want to make Apple, MS
>> and Linux WWW2 Browsers as the first step?
>>
>> What sort of support to you provide for 3d? Could a 3d game be made with
>> your libraires? How about 3d glasses support? I see the future WWW2 as
>> having a strong 3d and 2d support as well as smartphone and tablet support
>> built in.
>>
>> Thanks for any support you can give!
>
> ther'es evas gl api that exposes a gl rendering api. see the elm glview widget
> and examples in elementary_test.
>
> there is also a whole evas_3d object with a full scene graph inside. someone
> has actually made games with it before. a battleship game i think? the problem
> is gl wont really work well on windows. :/

Except if we use the Angle library. It coudl be easy to add a win32 gl engine.

raster : you told me that, first, you need to clean it (too many
copy/paste in the gl engines iirc)

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

Re: [E-devel] WWW 2

[The Rasterman]

On Mon, 5 Mar 2018 00:42:14 +0100 Knapp  said:

> I am researching a project to make a new WWW; WWW2. It would be completely
> non-backwards compatible with WWW.
> So a few questions.
> 
> Would your libraries be good for this, noting that I want to make Apple, MS
> and Linux WWW2 Browsers as the first step?
> 
> What sort of support to you provide for 3d? Could a 3d game be made with
> your libraires? How about 3d glasses support? I see the future WWW2 as
> having a strong 3d and 2d support as well as smartphone and tablet support
> built in.
> 
> Thanks for any support you can give!

ther'es evas gl api that exposes a gl rendering api. see the elm glview widget
and examples in elementary_test.

there is also a whole evas_3d object with a full scene graph inside. someone
has actually made games with it before. a battleship game i think? the problem
is gl wont really work well on windows. :/

> PS, I am open to anyone else that would be interested in pursuing this
> project.
> -- 
> Douglas E Knapp, MSAOM, LAc.
> --
> 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

Re: [E-devel] Ecore - Efl.Loop + Task + Thread + App + Appthread + Exe

[The Rasterman]

On Mon, 05 Mar 2018 17:25:09 -0500 Cedric Bail  said:

> On March 5, 2018 6:00 AM, Gustavo Sverzut Barbieri  wrote:
> 
> 
> 
> > Well, I already mentioned this to you in irc, but replying here just
> > to make my point:
> > 
> > I think the design is upside down, trying to make life easier at some
> > point resulted in messy at the other side.
> > 
> > okay, call it a task, work for both process and threads, the hope is
> > to facilitate "switch from threads to process, and vice versa", but
> > we're getting the worst part of each it seems.
> > 
> > ie: most thread usage is about sending shared memory back and forth,
> > after all the benefit of threads is just that: shared memory. What we
> > got? argv + int, useless for real life threads.
> > 
> > solution? "stdio" for threads... you can send/receive I/O, done with
> > pipes, like it would be for processes.
> > 
> > I really, really don't like that design. To me threads should be
> > exposed as such, with pointer argument and result... if you wish to
> > make it easier, you could "box" it someway, like eina_value... or just
> > let the traditional "void *pointer". But that's fundamental, say for
> > Python bindings to use threads, you want to send PyObject pointer to
> > the thread, that object will contain the information to callback the
> > user (the user's Python-callable). And for most usages as well, like
> > sending file info to be opened/decoded, etc.
> 
> I do second you completely Gustavo. I have been raising my discontent with
> this design for a long time now and fully agree with your point here.
> 
> > thread I/O, while useful in some cases, I don't see why they should
> > always exist. They should be optional, and as such they should be
> > created explicitly.
> 
> Agreed.
> 
> > Last but not least, I'd expose the stack just like in the OS, to not
> > make confusion:
> > 
> > -   Application ("the binary") -> Processes -> Threads -> main loop
> > 
> > you can present "getters" that make it easier to access (ie: main loop
> > "get" application, in addition to "get parent" which would return the
> > thread).
> > 
> > But mixing stuff "in the hope to make it easier" it not, it's just
> > making things more complicated... ALSO note that the developer that
> > would use this kind of API is "not the average developer", these don't
> > mess with such low level primitives. The developer that is likely to
> > use these primitives will say "what the fuck is this? I'm used to
> > processes and threads, these guys just messed it up".
> >
> > I'm in favor of interfaces for things that are the same, so if the
> > methods in process and threads share the same concept, behavior and
> > parameters, make them an interface... when switching from process x
> > threads one doesn't need to "sed" everything. However, definitely
> > constructors are NOT the same concept, behavior or parameters, thus
> > not part of the interface.
> 
> I would add that this thread model doesn't satisfy any of the use case we
> ourself have. For example :
> 
> - Ector: use thread to offload CPU and memory heavy task to another thread.
> The simple change to BFL has slowed us down. Now, if we do have to
> serialize/unserialize everything ? I have already my bet on the result.

ector using eo was and is a mistake. it's a performance sensitve part of
rendering and going through eo to do everything is bad/wrong.

the alternative is even slower eo with more locking on a global table or no
locking which is what we originally had and then we had mysterious random
crashes instead. hooray!

don't use eo for ector. simple. it's inappropriate.

> - Evas async renderer: same case as Ector. Nobody might remember, but at the
> beginning it was really slower, because of the memory copy that was done and
> it had to be removed. If we were to use this new infrastructure, it would
> lead to be back to a slower solution.

eh? it was barely noticeable. and i've been very clear that thew i/o using using
a pipe as an IMPLEMENTATION DETAIL. it could use shared buffers. but they still
require a copy into the shared buffer in userspace then out again. something
like thread queue when it doesn't do copies has thread queue about 1.6x the
speed for high volume messages in and out. i've done the benchmarks. arm
seems to have a hiccup that shouldn't be the case and is maybe. i shall bring
numbers to my aid:

https://phab.enlightenment.org/P170
https://phab.enlightenment.org/P168

a pipe is 60% slower than a zero-copy thread queue (x86) on arm 8x slower and
as kernel devs told me "that shouldn't be the case" so it's a bug it seems. the
io interface can't work with zero copy because that requires allocating your
buffers ON the thread queue to avoid a copy and not passing them in like the io
iface does. so you'd add a copy into the thread queue anyway... which i would
suspect would nuke even more of delta between them. it's barely worth talking
about in terms of performance 

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

[The Rasterman]

On Mon, 5 Mar 2018 10:48:02 -0500 "William L. Thomson Jr."
 said:

> On Mon, 5 Mar 2018 20:57:17 +0900
> Carsten Haitzler (The Rasterman)  wrote:
> >
> > People who do the work get to call the shots.
> 
> That is a fine balance. I am not really a fan of say ignoring users
> wishes or others because of who is doing the work and doing it their
> way vs whats best for all with others input beyond their own opinion.

But that is the reality. They can call the shots and listen to users. Users are
not always right. But listening is good. In the end people doing work make the
final decisions. And I guess to some extent I hold a veto power over those
which I generally choose not to exercise except on rare occasions when I think
it is warranted.

> > If we made everything code-reviewed ala phab, I think it'd be far
> > worse.
> 
> This is true, it happens all the time with Gentoo. One of your own 
> Bertrand Jacquin has been stuck in such endless review... 68 comments
> https://github.com/gentoo/gentoo/pull/5832
> 
> I have been there myself with 1 line change, and no longer bother
> https://github.com/gentoo/gentoo/pull/101
> 
> > development would dwindle and die.
> 
> Yes! Just look at Gentoo for proof. QA is killing it slowly
> 
> >  I absolutely know that I'd  personally just stop if I had to put
> > every commit I do through review. 
> 
> I stopped, as have others. Your sentiments are shared by many others.

I think there is a balance. Moving forward with minimal interference, yet still
trying to maintain quality too. You will never have perfect. Perfect is the
enemy of good.

> > I don't think we need STRUCTURE. I think we need communication. I
> > think people have become awfully bad at this. Here is what people
> > need to do IMHO.
> 
> I agree on communication, but I also believe structure is important to
> organizing any group of people to work together on anything.

structure is no good without communication to begin with.

> > 4. Writing down goals
> 
> Why I started these pages I can no longer edit.
> https://phab.enlightenment.org/w/efl_apps_todo/
> https://phab.enlightenment.org/w/elm_code/syntax_support/
> 
> > f) I still think E should have the filemanager built in. It's far
> > too useful to not do this. It's pretty much necessary for icons on
> > the desktop and consistent FM UI. If its done in-process or outside
> > is another matter, but it has to be deeply integrated. 
> 
> In brief, I am not a big fan of such. Seems like a Windows concept
> where Explorer ( not Internet Explorer) is deeply integrated. Pretty
> much any issue I have with E that is non-recoverable comes from EFM.

actually ... this pre-dates windows. amiga workbench had it all integrated
before windows 1.0 was around. and i'm an amiga fan. a lot of e was inspired
from those days. i firmly believe a filemanager has to be deeply integrated.

what are the non-recoverable issues you have? i don't see those. i do use
efm... sometimes thumbnails are blank - scrol lup and down again and it
fixes... recently dnd seems to be flaky and stop working but that's not an efm
change. something in efl did this i think. efm doesn't have a transhcan. that
should be added.

> Maybe a stand alone widget/app could render Icons on desktop and be
> creative there. 3d icons, animated, etc. Integrate say a screen saver
> and live desktop, so icons move to as screen saver and for aesthetics.
> Like having an animated or live background image.
> 
> > i'm sure many people have their own ideas and priorities on what they
> > think is important/right. i'm just dropping the above out there. if
> > you want direction and can't submit your own instead, then look at
> > the above and expand on it as logical.
> 
> Maybe a start is creating more like ToDo or Wish List type pages under
> Phab to identify various interests and goals of each. Or even a simple
> EFL goals or E goals page.
> 
> -- 
> William L. Thomson Jr.


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

Re: [E-devel] futures again... :(

[The Rasterman]

On Thu, 1 Mar 2018 14:11:26 -0300 Gustavo Sverzut Barbieri 
said:

> On Wed, Feb 28, 2018 at 2:33 AM, Carsten Haitzler 
> wrote:
> > On Tue, 27 Feb 2018 18:34:59 -0500 Cedric Bail  said:
> >
> >>  Original Message 
> >>  On February 27, 2018 2:52 PM, Carsten Haitzler 
> >> wrote:
> >>
> >> >so I'm implementing a new efl.exe class (and efl.task and some others)
> >> >and i
> >> > WAS going to use a future as the return for run() ... but after just
> >> > writing about 20 lines of code (get a scheduler, create a promise alloc
> >> > promise data and all the checking in between) and i then realized...
> >> > it's ballooning to an insane amount of code vs event_callback_call which
> >> > is a 1 line func call when the event happens.
> >> >
> >> > let me just copy and paste the relevant lines i had sketched out (was not
> >> > final or even compiling yet):
> >> >
> >> > typedef struct _Efl_Exe_Run_Data
> >> > {
> >> > Eo *obj;
> >> > } Efl_Exe_Run_Data;
> 
> not sure you need this

i need to report the object the future is for with the future... and i don't
want to rely on people having to use the data ptr for that. this is probably
one of the most common needs/uses of a future - that it's a one off action FOR
an object.

> >> > static void
> >> > _efl_exe_run_cancel(void *data, const Eina_Promise *dead_ptr EINA_UNUSED)
> >> > {
> >> > Efl_Exe_Run_Data *d = data;
> >> >
> >> > efl_task_end(d->obj);
> >> >}
> >> >
> >> > Efl_Exe_Run_Data *d;
> >> > Eina_Promise *p;
> >> >
> >> > d = calloc(1, sizeof(Efl_Exe_Run_Data));
> >> > EINA_SAFETY_ON_NULL_RETURN_VAL(d, NULL);
> >> > d->obj = obj;
> >> >p = eina_promise_new(sched, _efl_exe_run_cancel, d);
> >> > EINA_SAFETY_ON_NULL_RETURN_VAL(p, NULL);
> >> > d->promise = p;
> >> >d->run_future = efl_future_Eina_FutureXXX_then(obj, eina_future_new(p));
> >> >return d->run_future;
> >>
> >> You do not need to keep the future at all in your structure. You are good
> >> to go with just :
> >>
> >> return efl_future_Eina_FutureXXX_then(obj, eina_future_new(p));
> >
> > then how do i trigger success or failure of the future if i don't have a
> > handle on it - well promise/future... whatever. same thing to me. i dislike
> > the whole division of promise vs future. to me it's an async task that at
> > some point in the future triggers a success or failure then disappears
> > after that.
> 
> you just keep the write/send side: Eina_Promise: p... that's where you
> send your results.

well i need to keep a handle to something. that's my point.

> >> And once we have migrate future<> in .eo to Eina_Future, it will become
> >> just :
> >>
> >> return eina_future_new(p);
> >
> > still have to store it in the object to trigger it and pass in results like
> > exit codes ... or object handles. and as below. i can't pass an obj handle
> > via an eina_value. :( the caller has to remember to pass in the obj as the
> > data ptr... not very nice compared to events that always give you the obj
> > the event happened on.
> 
> you can, there is an EO: EINA_VALUE_TYPE_OBJECT, it's juste declared
> down in the stack:
> 
> https://git.enlightenment.org/core/efl.git/tree/src/lib/eo/Eo.h#n2049

you're right. i was looking in the eina_value headers. not in eo headers.

> >> > // XXX: no eina value for eo obj handles... :( call where exe exit
> >> > handled Eina_Value *val = eina_value_new(EINA_VALUE_TYPE_UINT64);
> >> > eina_promise_resolve(d->run_future, val);
> >>
> >> This line can be properly written as :
> >> eina_promise_resolve(d->promise, eina_value_uint_init(ret));
> >
> > errr... but i want to pass an object to the promise, not an int...
> 
>eina_value_object_init(obj)
> 
> 
> >> > i got to 22 lines and i wasn't even done yet (need to do some more
> >> > housekeeping)... vs 1 line for event_callback_call. i'm going with events
> >> > until futures/promises are not a crazy amount of code compared to events.
> >> > this is it with events:
> >> >
> >> > efl_event_callback_call(obj, EFL_TASK_EVENT_EXIT, NULL);
> >>
> >> This is absolutely not doing what the future code is doing. You are not
> >> detecting when a user has removed the handler and so call efl_task_end
> >> accordingly. You are also not sending a structure with the exit code either
> >
> > i don't need to send the data in a future - it's stored on the object
> > anyway. you pick it up with a get from the object.
> 
> well, that's misuse of the promise result... if you're running
> something to get data, that's what you should get at the end, not the
> object...

the object represents the execution of that task (exe) d it survives the
death of the exe or thread until its voluntarily deleted so data can be
retrieved from it "at leisure". i don't think storing this data on the object
is wrong at all because it does need to exist somewhere and storing it here is
far more convenient. it's not transient data. it doesn't keep changing like