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

[Jean-Philippe André]

Hi,

On Tue, Dec 19, 2017 at 2:43 AM, Stephen Houston 
wrote:

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

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

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

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

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

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

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

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


I would love to stabilize the API in parts.

Best regards,



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

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

[Pierre Couderc]

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

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

[Jean-Philippe André]

Hey raster,

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

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



On Mon, Dec 18, 2017 at 8:16 PM, Jean-Philippe André 
wrote:

>
>
> On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler 
> 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
>> > destroying this object is ging to create trouble in the future as it
>> will be
>> > one object that doesn't have the same behavior as every other one.
>>
>> that doesn't change the fact that destruction is expensive and generally
>> pointless. there may b e some cases where it's nice. like "detecting
>> leaks by
>> looking at what is still allocated on exit" which frankly doesn't work
>> too well
>> anyway. but i found problems in eldbus for example when finally
>> everything was
>> really children of the loop object and destroying the loop object had
>> issues
>> that spider out everywhere. i was chasing one thing after the other in the
>> tests there and decided for now just to not delete the loop object so i
>> can
>> move on.
>>
>
> I disagree. If you want your app to exit quickly just call exit(0) and be
> done with it.
> Clean shutdown seems to me like a big plus for anything that pretends to
> call itself a library. It helps in various scenarios, like valgrind, GDB
> inside make check, etc... I know I personally rely on it quite a lot when
> make check fails.
>
> I pushed a series of patches fixing most of this shutdown cycle. But most
> of the ecore event types are stored as static variables and aren't properly
> re-initialized after 

Re: [E-devel] Type info in futures

[Jean-Philippe André]

Hi,

On Tue, Dec 19, 2017 at 12:25 AM, Andrew Williams 
wrote:

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


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

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

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

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

Re: [E-devel] Site statistics

[Simon Lees]

On 18/12/17 22:53, Andrew Williams 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

I'm not sure how concerned we should be about this one, enlightenment is
such a broad term we are likely to get false hits, someone who is
atleast vaguely interested in enlightenment will stay for more then a
few seconds. People are used to bad open source websites. Having said
that having a secondary "Screenshots" page thats listed up the top would
be an improvement so people can better see what Enlightenment is. Yes
the layouting can be fixed (maybe I did try once) but I don't think this
is pointing to a we really need to redo the whole website people don't /
shouldn't choose there window manager based off a website.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
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] What are we going to release?

[Stephen Houston]

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

On Mon, Dec 11, 2017 at 8:13 PM Carsten Haitzler 
wrote:

> On Mon, 11 Dec 2017 13:11:53 +0900 Jean-Philippe André 
> said:
>
> > Hi,
> >
> >
> > Just a word about panes and other new widgets: yes they got broken at
> some
> > point but should be fixed now that the "EO" theme API has been merged.
> > I think most of the existing Efl.Ui.Xxx widgets should soon become
> usable.
> > But I am not ready to commit yet for all of elementary (note: the model
> API
> > is still in flux and the [gen]list widget isn't here yet).
> >
> >
> > @netstar proposed branching off to EFL 2 and no one responded to that (as
> > far as I can tell).
>
> I just dopn't think that'd be good for the project as a while, no matter
> that
> pain of having to keep legacy and eo/interfaces going at once.
>
> > I very very much wish we had taken that route as the most painful part in
> > this interfaces rework is to keep legacy working.
>
> we are trying to do:
>
> https://www.youtube.com/watch?v=B_1bAnLqlMo
>
> yup. it's hard. :) it would have been easier to start fresh from the code
> we
> have and just nuke what we are not keeping. but as you say below, there are
> reasons.
>
> > Unfortunately we have reasons for not branching off, as follows:
> > - We need the existing ecosystem for testing (E, apps, Tizen, etc...).
> > Breaking compilation or runtime or existing apps would be a huge PITA.
> > Having a separate .so file (libefl.so.2) would mean a lot less
> > out-of-the-box testing.
> > Yes, we break stuff in legacy, but this is by accident, not by design. I
> > hope it is clear that we are still trying hard to keep things in order.
> > - We expect the existing ecosystem to progressively adapt to the EO API,
> by
> > modifying a UI component here and there, adding a new view or whatnot in
> > the application, etc... We don't expect an immediate port of existing
> > legacy apps to EO-only API.
>
> it likely will be a multi-year port for apps. certainly for enlightenment
> it
> will be a long long long path.
>
> > OTOH when it comes to bindings (Lua, C++, C# for now), everything is new,
> > so legacy doesn't really matter.
> > Cedric mentioned to me a couple of times how long it took large projects
> > using Qt4 to finally move on to Qt5. So we're trying to avoid that
> > bottleneck.
> >
> >
> > I would very much like releasing at least something. Maybe the
> distinction
> > between ALPHA and BETA is a good idea. (BETA for eo, eolian, ecore, and
> > ALPHA for evas, edje, elm). efl/interfaces is a mix of both.
> > Then we can commit to stop changing those "BETA" API's unless it's
> > absolutely necessary (unlike a lot of the changes happening now in the
> > interfaces).
> > As for specific APIs we can also make use of @beta in EO.
> >
> >
> > Best regards,
> >
> >
> > PS: I say "EO" here as I heard about the idea of calling this API the
> > "unified interface" (whilst I like the name, it boils down to UI and UI
> > means user interface^^).
> >
> >
> > On Mon, Dec 11, 2017 at 9:46 AM, Carsten Haitzler 
> > wrote:
> >
> > > On Sun, 10 Dec 2017 23:41:20 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > 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?
> > >
> > > because i have seen history and those words are the truth given history
> > > and my
> > > experience. ok "zero value" is like "it's worth a few cups of coffee
> when
> > > we're looking at buying a car". not literally zero but very very very
> low
> > > value
> > > compared to the big picture. yes. they are strong words. i feel
> strongly
> > > about
> > > this. are you saying that i am not allowed to feel strongly about this
> and
> > > should tone everything down just in case you get discouraged. i have to
> > > pretend to not feel strongly and be dishonest about my opinion? i
> expected
> > > better of you.
> > >
> > > i KNOW who wants interfaces in things like c# and a subset is useless
> to
> > > them.
> > > they have to be able to build entire apps with the ui in that language.
> > > it's
> > > all of it or not bother. this applies to js, lua and python too.
> > >
> > > i also know that 

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

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

[Stephen Houston]

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

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

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

[Stephen Houston]

With 4 and 5, I think this should be sent in a follow up to cedric's
website redesign thread.  As I think, and a lot of people agree, the look
and feel of the website needs a lot more work than just a few
layout/content changes.

On Mon, Dec 18, 2017 at 9:43 AM Stephen Houston 
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 
> 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
>>
>
--
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

[Stephen Houston]

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 
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
>
--
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] ecore / efl loop work

[Jean-Philippe André]

On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler 
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
> > destroying this object is ging to create trouble in the future as it
> will be
> > one object that doesn't have the same behavior as every other one.
>
> that doesn't change the fact that destruction is expensive and generally
> pointless. there may b e some cases where it's nice. like "detecting leaks
> by
> looking at what is still allocated on exit" which frankly doesn't work too
> well
> anyway. but i found problems in eldbus for example when finally everything
> was
> really children of the loop object and destroying the loop object had
> issues
> that spider out everywhere. i was chasing one thing after the other in the
> tests there and decided for now just to not delete the loop object so i can
> move on.
>

I disagree. If you want your app to exit quickly just call exit(0) and be
done with it.
Clean shutdown seems to me like a big plus for anything that pretends to
call itself a library. It helps in various scenarios, like valgrind, GDB
inside make check, etc... I know I personally rely on it quite a lot when
make check fails.

I pushed a series of patches fixing most of this shutdown cycle. But most
of the ecore event types are stored as static variables and aren't properly
re-initialized after re-init. This breaks behavior with legacy where the
event handlers table simply didn't change after shutdown/init. Not sure if
all the event types should be reset (after flush) or if we should keep a
static table for legacy ecore event.




> > 
> >
> > > this api is NOT FINAL. it's a good first stab at doing all of this
> work. it
> > > could probably improve. i need to clear up some of the internal bits
> that
> > > still use single mainloop dependent calls as per the commit and above,
> and
> > > some other things need a design and implementation... and then actually
> > > create multiple threads with loops and even decide HOW threads and
> loops
> > > are created and spawned and hooked up 

Re: [E-devel] FOSDEM 2017

[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 2017 and the
> > > Desktops DevRoom will take place on Sunday, February 5th 2017.
> > >
> > > We will contact every submitter with a “yes” or “no” before December 11th
> > > 2016.
> > >
> > > Recording permission
> > >
> > > The talks in the Desktops DevRoom will be audio and video recorded,
> > > and possibly streamed live too.
> > >
> > > In the "Submission notes" field, please indicate that you agree that
> > > your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0
> > > license and that you agree to have your presentation recorded. For
> > > example:
> > >
> > > "If my presentation is accepted for FOSDEM, I hereby agree to license
> > > all recordings, slides, and other associated materials under the
> > > Creative Commons Attribution Share-Alike 4.0 International License.
> > > Sincerely, ."
> > >
> > > If you want us to stop the recording in the Q & A part (should you
> > > have one), please tell us. We can do that but only for the Q & A part.
> > >
> > > More information
> > >
> > > The official communication channel for the Desktops DevRoom is its
> > > mailing list desktops-devr...@lists.fosdem.org.
> > >
> > > Use this page to manage your subscription:
> > > https://lists.fosdem.org/listinfo/desktops-devroom
> > >
> > >
> > > Organization
> > >
> > > The Desktops DevRoom 2017 is managed by a team representing the most
> > > notable open desktops:
> > >
> > > Pau 

Re: [E-devel] FOSDEM

[Carsten Haitzler]

On Sun, 17 Dec 2017 19:51:13 + Tom Hacohen  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"  wrote:
> 
> > On Wed, 22 Nov 2017 18:02:56 + Andrew Williams 
> > 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 
> > 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  > >
> > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > 
> > --
> > > > > > Check out the vibrant tech community on one of the world's most
> > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > > > ___
> > > > > > enlightenment-devel mailing list
> > > > > > enlightenment-devel@lists.sourceforge.net
> > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > > > >
> > > > > --
> > > > > http://andywilliams.me
> > > > > http://ajwillia.ms
> > > > >
> > > > 
> > --
> > > > > Check out the vibrant tech community on one of the world's most
> > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > > ___
> > > > > enlightenment-devel mailing list
> > > > > enlightenment-devel@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > >
> > > >
> > > > --
> > > > - Codito, ergo sum - "I code, therefore I am"
> > --
> > > > Carsten Haitzler - ras...@rasterman.com
> > > >
> > > > --
> > > http://andywilliams.me
> > > http://ajwillia.ms
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > Carsten Haitzler - ras...@rasterman.com
> >
> >
> > 
> > --
> > Check out the vibrant tech community on one of the