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

[William L. Thomson Jr.]

Many projects face hardships. I am optimistic still. Though I maybe seen
as troublesome, unwanted, bad apple, etc by some. It is good to bring
such issues up and discuss them. Problems do not solve themselves.

On Thu, 01 Mar 2018 19:28:15 +
Stephen Houston  wrote:
>
> Community based projects can't succeed
> in an environment where there is seemingly no project management and
> discussions only happen when a feature or change is pushed and one
> person overrides it.  This project needs to have more project
> management.  Goals need to be laid out.  Road maps need to be
> developed.  Release plans need to be created and adhered to.  This
> project needs structure,

I fully agree on organization and structure! To many think volunteer
and FOSS projects do not need organization and leadership. Those that
can organize can thrive. Those who cannot, do not.

> and frankly this structure needs to come
> from more than just one person.  There needs to be a team of project
> managers who determine whether changes, features, or proposal are
> accepted, not only one person.  There needs to be a team of project
> managers determining the direction of the project and developing road
> maps for it.  This team needs to be represented of our developers,
> our corporate interests, and our community user base.  Having a team
> will keep from personal bias, desires, or egos getting in the way.
> Once we have some structure in place, it will become much easier for
> us to band together to work towards meeting our goals.

I would caution a move to decision by committee. It was the almost
death of Apple. It has not really been a good thing for other
organizations. Best example is Gentoo. Since its move to a Gentoo
Council. Gentoo has had more issues with leadership, direction, etc.
IMHO it had a better initial approach to management.

Something like this may work for E.
https://www.gentoo.org/glep/glep-0004.html

Say Raster is top. Then a managers team below. Then each project has
its own. Now E/EFL does not really have projects in the same sense. I
would say someone would be like Elementary Manager, EINA, etc. Parts of
EFL a person would be the manager for, working with other managers, and
any team beneath them. Someone for E, maybe a modules/bryce manager,
etc. A Wayland manager, X11, etc. Various parts, Windows OS, OS X, etc.

IMHO this has been total crap and why Gentoo has had so many issues
since its early years. GLEP-39 replaces GLEP-4, management structure
 https://www.gentoo.org/glep/glep-0039.html

I also like Debians approach of an annually elected leader.
https://www.debian.org/devel/leader
https://en.wikipedia.org/wiki/List_of_Debian_project_leaders

I highly recommend using existing forms of structure and leadership or
some combination there of that works. Gentoo has always experimented
with unique structure and organization that is really a failed
experiment. Many have yet to get past denial and make effort to
correct. Just doubling down on status quo and trying to make something
that will never work, work...

Read Daniel Robbins comments here. It tells the tail of how the Gentoo
Council came to be... It very much is a failed experiment.
https://archives.gentoo.org/gentoo-project/message/3ac5418dd061fc53f4b8d55a99773f4c


Extra comments

IMHO there is always going to be various social issues around anything
technical. Many technical people are not great a social stuff in person
or in general. Not insulting anyone, we all have strengths and
weaknesses. Even non technical, the world has a hard time getting along
in general. FOSS projects cross many boarders, cultures, etc. Its
natural there be issues a a result of such. But seems the era of thick
skin etc is dead, its now Code of Conduct, ban, punish, drive away etc.
Those things do not help grow communities.

-- 
William L. Thomson Jr.


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

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

[Stephen Houston]

I've been pondering writing this email for some time now.  As others have
mentioned - our community has been trending downwards.  Work from Samsung
aside, and those that use E/EFL through Samsung's work -- The developer and
user base has been getting smaller and smaller.  That is regular members of
the community contributing work and regular members of the community using
E/EFL as an option for their linux desktops/laptops.  The number of
arguments that are now occurring among those of us still left has been
rising.  The current state of the project is such that dissenting
opinions/code are not allowed and get reverted or overruled in discussions,
this likely directly related to our structure and our lack of documented
road maps, goals, and plans.

This project has been around for decades.  Many of our developers have
spent blood sweat and tears adding code to this project and working on it.
Many of our developers have poured just as much code into this project as
the next has.  The project has become so much more than just one person's
vision or one person's opinion.  As it is the project is really not set up
to handle this.  There is no clear decision tree. No clear path for what is
and is not accepted.  No clear direction of what the goal is to
accomplish.  This has been leading to so much animosity, and frankly a
stagnant project that is dwindling instead of growing.  Sure plenty of code
gets written, rewritten, or worked on, but the majority of it is not seen
in the product.  It is working on rewrites for performance, bug fixes for
corner cases, implementing new apis that are not used anywhere, etc...,
etc..., and all of that is fine and necessary, but other very important
work gets left out.  Take Enlightenment from late 2000s - now.  A lot of
work has been done.  Compositing, Wayland, e_widgets -> Elm, etc..., etc...
But in the last say 10 years... You could pull up versions of Enlightenment
and without a technical sense or from someone following the project, you
would think it is the same... Same menus, same settings, same gadgets, same
shelves, same themes, same look, same interface, etc..., etc...  EFL
consistently is worked on and sure is doing really cool new stuff like
Interfaces... but does it matter if no one is even using it? (Samsung
aside).  We have 3 or 4 applications that we have always had and there
seems to be very little growth.  We have people who have decided to fork
off work or go their own route... see Moksha, Fyne, etc... due to problems
within our community or our vision.  This is difficult for a community like
ours to overcome when and if we lose users when we already have few to
begin with.

I believe it is time that we as a community revisit ourselves and consider
restructuring.  Projects can't just be YOLO with no clear laid out
direction or plan.  Community based projects can't succeed in an
environment where there is seemingly no project management and discussions
only happen when a feature or change is pushed and one person overrides
it.  This project needs to have more project management.  Goals need to be
laid out.  Road maps need to be developed.  Release plans need to be
created and adhered to.  This project needs structure, and frankly this
structure needs to come from more than just one person.  There needs to be
a team of project managers who determine whether changes, features, or
proposal are accepted, not only one person.  There needs to be a team of
project managers determining the direction of the project and developing
road maps for it.  This team needs to be represented of our developers, our
corporate interests, and our community user base.  Having a team will keep
from personal bias, desires, or egos getting in the way.  Once we have some
structure in place, it will become much easier for us to band together to
work towards meeting our goals.

As it is - It really feels like if we continue on the path we are on, the
future is not bright at all.  If we treat this project's goals as whatever
meets the desires or ideas of one or two, that is what it will eventually
become - a project used by one or two.  I'm pleading with everyone to put
egos aside, put personal ambitions, personal goals, and related aside and
begin working as a team.  The current climate will improve dramatically if
that happens.

Before you get upset and respond angrily at this email, remember I love
this project and have worked on it for over 15 years and developed
relationships with most of you along the way, and so I am in no way sending
this email with ill intent or to anger or hurt anyone.  I'm sending this
email in hopes that we can only improve as we move forward.

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

Re: [E-devel] [EGIT] [bindings/python/python-efl] master 01/01: Elm: add test for elm_image_get() before a set() call

[Kai Huuhko]

Is there an issue that this test exposes?

2018-03-01 19:34 GMT+02:00 Dave Andreoli :

> davemds pushed a commit to branch master.
>
> http://git.enlightenment.org/bindings/python/python-efl.git/commit/?id=
> 4b8ddcff7d2333afba38a76774c7d18c5e0ed93b
>
> commit 4b8ddcff7d2333afba38a76774c7d18c5e0ed93b
> Author: Dave Andreoli 
> Date:   Thu Mar 1 18:32:46 2018 +0100
>
> Elm: add test for elm_image_get() before a set() call
> ---
>  tests/elementary/test_02_image_icon.py | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/tests/elementary/test_02_image_icon.py
> b/tests/elementary/test_02_image_icon.py
> index cc0b48a..b106a10 100644
> --- a/tests/elementary/test_02_image_icon.py
> +++ b/tests/elementary/test_02_image_icon.py
> @@ -29,9 +29,10 @@ class TestElmImage(unittest.TestCase):
>  self.assertEqual(Eo.parent_get(self.o), self.w)
>
>  def testImageFile(self):
> -self.o.file = os.path.join(script_path, u"icon.png")
> -self.assertEqual(self.o.file[0],
> - os.path.join(script_path, u"icon.png"))
> +img_file = os.path.join(script_path, u"icon.png")
> +self.assertEqual(self.o.file, (None, None))
> +self.o.file = img_file
> +self.assertEqual(self.o.file, (img_file, None))
>  self.assertEqual(self.o.object_size, (48, 48))
>
>  def testImageFileException(self):
>
> --
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/03: efl: create Efl.App class, the parent of Efl.Loop

[Carsten Haitzler]

On Wed, 28 Feb 2018 17:09:18 -0500 Cedric Bail  said:

>  Original Message 
>  On February 27, 2018 9:18 PM, Carsten Haitzler  wrote:
> 
> >On Tue, 27 Feb 2018 13:12:59 -0500 Cedric Bail ced...@ddlm.me said:
> >
> > wo.. a cedric! long time...
> >
> >>For whatever reason, I didn't receive the first email of this chain, so will
> >> answer here.
> >> Original Message 
> >> On February 27, 2018 7:21 AM, Mike Blumenkrantz
> >>michael.blumenkra...@gmail.com wrote:
> >>>You've certainly raised some valid points which bear further looking into,
> >>> thanks!
> >>>At a minimum, this patch was intended to introduce a base implementation of
> >>> a singleton "app" object which could (and should) have tests written for
> >>> it as it's improved upon. If you or others want to do that work feel free,
> >>> I've moved on to other items for the near future.
> >>>On Tue, Feb 27, 2018 at 12:07 AM Carsten Haitzler ras...@rasterman.com
> >>> wrote:
> On Mon, 26 Feb 2018 11:03:03 -0800 Mike Blumenkrantz
> michael.blumenkra...@gmail.com said:
>  this change has a fair few problems to it... i don't think this is the
>  right
>  way to go.
>  this change from efl_main_loop_get() doesn't make sense
>  - job = efl_add(EFL_IO_MANAGER_CLASS, efl_main_loop_get());
> 
>  - job = efl_add(EFL_IO_MANAGER_CLASS,
>  efl_app_main_loop_get(efl_app_get()));
> 
> 
> >>>I disagree on both of those line. You get the main loop when your
> >>>application
> >> start and all your object do get you there. The scenario in which you need
> >> to directly access the main loop should be really limited (tests and
> >> legacy code are what come to my mind).
> >>
> > i literally have test code that does:
> >
> > if (loop == efl_main_loop_get()) { } else  { }
> 
> Where is that code ? In efl, it can make sense in some case, but application

it's in my test code locally. it's how a callback knows if it's a main loop or
some other thread. i re-used the same cb for both and have it do slightly
different things.

my point here is that if you need access to the app object to get the main loop
object... a non- main loop thread cant access the app object unless it's
shared... and then we get into the shared mixed with non-shared. :)

> should not rely on that as this facility is not available to bindings. It
> would prove that we have a design issue and that you can't write the same
> application in C as in Python due to our objects limitation.

there is a class function that does the same.

   return efl_app_loop_main_get(EFL_APP_CLASS);

for example. that's bindable. just there is a wrapper on top to cut the typing
in c/c++ and thats what i used above. the above is btw the sample in my tree.
in the efl app parent it's efl_app_main_loop_get(()) ... and that
still relies on the C wrapper efl_app_get()...

> > i can't do that anymore from threads. the loop does not have an EO parent
> > set to the efl app object, so i cant get the parent of my loop and do an
> > isa on it... that's why i say... this doesn't make sense... it also doesn't
> > make sense to just make it longer.
> 
> This is confusing. Basically you want to be able to do pointer comparison of
> something that is not valid (in the thread domain sense) in the thread

actually it is due to the domain id of main being different to threads and
domain id is in the eoid. thus they will always have a difference. between 2
threads you can't tell the difference though.

> context you are in, in C. This point exactly to my remark above. Language
> that do not have pointer, like almost every single one binding, won't be able
> to do this kind of code. So the logic above is a problem that need solving. I
> haven't seen that kind of code before in our code base and can't find it. So
> I am at a loss of understanding what you are trying to do here.

and that is why having different classes is the right thing efl_isa() can tell
me if i'm main or some other thread instantly with a superclass mechanism. :) i
don't need access to any object but the loop object i was passed when the thread
started (the main loop is sent an arguments event, so are other thread you
create - so it's passed in here and the arguments callback handles setup just
like main loop).

you haven't seen this code before btw... because we haven';t had thread be
symmetrical to the main loop. ecore_thread has been special and you know
you're in a thread vs main loop.. and there could be only 1 main loop.

> you can't access the app object from anywhere other than the main loop
>  thread because it's a thread local object (the default)... so all this
>  does it make this longer for no benefit.
> 
> >>>This is the point. Why would you need to access this object from another
> >> thread ?
> >>
> > you can't know if your loop is the main loop or not with this scheme. if you
> > use superclassing then isa() can tell you. if it 

Re: [E-devel] [EGIT] [core/efl] master 01/03: efl: create Efl.App class, the parent of Efl.Loop

[The Rasterman]

On Wed, 28 Feb 2018 15:30:24 + Mike Blumenkrantz
 said:

> It seems like there's strong opinions here, and since this is something
> which potentially matters to all future EFL development I would propose
> that instead of arguing about this on the list for another X number of
> weeks both of you write up the key points (pros and cons, code snippets) of
> your side on a wiki page such as https://phab.enlightenment.org/w/efl_app/ .
> This will make it easier for everyone to make an informed decision and will
> further allow us to reuse the information in documentation later on if
> anyone ever questions why it was done in this way.

i'll put up something there to describe what i think is a clean design for this
that will work well with minimal trouble.

i've actually been implementing efl.thread too. i ended up making an
efl.appthread parent class that specifically is for non-mainloop threads, where
efl.app is the main loop thread.

i have threads (parent loop and child threads at least) 2-way communicating
right now etc. i need to fix the efl.io on efl.app so it goes to stdin/out for
efl.exe to mirror efl.thread behaviour.

then i will take a look at the tests you added and adjust them or re-add them
back.

as i said - i've been holding off on tests until things settle. my test code i
have to alter regularly to fit and its not a digestible automated test (it
printfs so i know whats going on).

> On Wed, Feb 28, 2018 at 12:35 AM Carsten Haitzler 
> wrote:
> 
> > On Tue, 27 Feb 2018 13:12:59 -0500 Cedric Bail  said:
> >
> > wo.. a cedric! long time...
> >
> > > For whatever reason, I didn't receive the first email of this chain, so
> > will
> > > answer here.
> > >
> > >  Original Message 
> > >  On February 27, 2018 7:21 AM, Mike Blumenkrantz
> > >  wrote:
> > > >You've certainly raised some valid points which bear further looking
> > into,
> > > > thanks!
> > > >
> > > > At a minimum, this patch was intended to introduce a base
> > implementation of
> > > > a singleton "app" object which could (and should) have tests written
> > for it
> > > > as it's improved upon. If you or others want to do that work feel free,
> > > > I've moved on to other items for the near future.
> > > >
> > > > On Tue, Feb 27, 2018 at 12:07 AM Carsten Haitzler ras...@rasterman.com
> > > >wrote:
> > > >
> > > >>On Mon, 26 Feb 2018 11:03:03 -0800 Mike Blumenkrantz
> > > >>michael.blumenkra...@gmail.com said:
> > > >>this change has a fair few problems to it... i don't think this is the
> > > >> right
> > > >> way to go.
> > > >>this change from efl_main_loop_get() doesn't make sense
> > > >> - job = efl_add(EFL_IO_MANAGER_CLASS, efl_main_loop_get());
> > > >>
> > > >> - job = efl_add(EFL_IO_MANAGER_CLASS,
> > > >> efl_app_main_loop_get(efl_app_get()));
> > >
> > > I disagree on both of those line. You get the main loop when your
> > application
> > > start and all your object do get you there. The scenario in which you
> > need to
> > > directly access the main loop should be really limited (tests and legacy
> > code
> > > are what come to my mind).
> >
> > i literally have test code that does:
> >
> > if (loop == efl_main_loop_get()) { } else  { }
> >
> > i can't do that anymore from threads. the loop does not have an EO parent
> > set
> > to the efl app object, so i cant get the parent of my loop and do an isa on
> > it... that's why i say... this doesn't make sense... it also doesn't make
> > sense
> > to just make it longer.
> >
> > > >>you can't access the app object from anywhere other than the main loop
> > > >> thread because it's a thread local object (the default)... so all this
> > > >> does it make this longer for no benefit.
> > >
> > > This is the point. Why would you need to access this object from another
> > > thread ?
> >
> > you can't know if your loop is the main loop or not with this scheme. if
> > you
> > use superclassing then isa() can tell you. if it actually used eo parent
> > objects, then getting parent could tell you, with the exception that the
> > parent
> > is thread local so this cant work. if it was shared you cross domains too.
> >
> > it's better to superclass here than use parent/child.
> >
> > > >> if can't be a shared object either because you also do things like:
> > > >> - EINA_LIST_FOREACH_SAFE(pd->loops, l, ll, loop)
> > > >> - efl_del(loop);
> > > >>
> > > >>you want to have multiple loops in a single thread-local shared
> > object? you
> > > >> can't mix shared and non-share objects.
> > >
> > > There is a lot in this sentence. The fact we can't mix shared and
> > non-shared
> > > object is going to be a serious problem with our parent model and object
> > > refcounting in general. Basically we will require to have another tree of
> > > shared object on the side that is not connected to the one that are not
> > > shared. And all of this object have to be controlled by 

Re: [E-devel] [EGIT] [core/efl] master 11/13: theme: rename "default" theme to "dark"

[The Rasterman]

On Thu, 1 Mar 2018 19:01:36 +1030 Simon Lees  said:

> 
> 
> On 01/03/18 18:12, Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 28 Feb 2018 13:05:51 -0800 Mike Blumenkrantz
> >  said:
> > 
> >> discomfitor pushed a commit to branch master.
> >>
> >> http://git.enlightenment.org/core/efl.git/commit/?id=d764e0b2790b322778e6db80932c168ae0d43b96
> >>
> >> commit d764e0b2790b322778e6db80932c168ae0d43b96
> >> Author: Mike Blumenkrantz 
> >> Date:   Tue Feb 27 17:31:40 2018 -0500
> >>
> >> theme: rename "default" theme to "dark"
> >> 
> >> this inhibits maintenance and development of multiple stock themes
> >> 
> >> a symlink is created to 'default.edj' to preserve compatibility
> > 
> > ummm errr... this breaks efl compatibility. you can't do this. the symlinks
> > isn't a solution because of windows. no symlinks there (well on ntfs only as
> > only as administrator, so they don't exist).
> > 
> > modifying config for switch from default to dark also will break the case
> > where someone put ~/.elementary/themes/default.edj there and it just is
> > different to the system one and how their theme changes on them as it
> > switches to dark.
> > 
> > basically we can't rename a theme like this mid-flight in efl. default is
> > default and has to stay that name. it can change the look, but not the name.
> > 
> > i think the apparent reasoning behind this is not a good one. the work on
> > flat is temporary. i don't think we will ever maintain multiple "default
> > themes" as its just far too much work.
> > 
> > we can maintain color SCHEMES which are just a list of colorclasses and
> > colors for them - that's separate to a theme and would override. right now
> > these things don't exist. we are not going to create a dark.edj and a
> > light.edj just to store differing default colorclass values. we should be
> > doing the above with colorclass "color palette/scheme/whatever" files that
> > override those named colorclasses globally on init.
> > 
> 
> On openSUSE we rename the default theme to dark and then name one of our
> themes default.edj (unless you use the upstream branding package) but
> the concept of a "default" theme is really useful, there needs to be a

this is ok. as long as a theme called "default" exists AND has a complete set
of content as is expected of default.

you effectively alter the default theme just by dropping in your own
replacement which is actually the right way to do.

> theme loaded when e's wizard is launched for the first time and having
> it be "default.edj" on the filesystem is more useful then having to
> patch code to pick the theme we as a distro wants to use as its default.
> I don't really care what default.edj looks like, but as long as it still
> exists and thats the first theme that's looked for on a new system I'm
> happy.
> 
> -- 
> 
> 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
> 


-- 
- 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] [EGIT] [core/efl] master 01/03: efl: create Efl.App class, the parent of Efl.Loop

[Cedric Bail]

So resending this email as it seems yesterday Sourceforge decided this mailing 
list didn't exist anymore. Not a great week for our infrastructure...

 Original Message 
 On February 27, 2018 9:18 PM, Carsten Haitzler  wrote:

>On Tue, 27 Feb 2018 13:12:59 -0500 Cedric Bail ced...@ddlm.me said:
>
> wo.. a cedric! long time...
>
>>For whatever reason, I didn't receive the first email of this chain, so will
>> answer here.
>> Original Message 
>> On February 27, 2018 7:21 AM, Mike Blumenkrantz
>>michael.blumenkra...@gmail.com wrote:
>>>You've certainly raised some valid points which bear further looking into,
>>> thanks!
>>>At a minimum, this patch was intended to introduce a base implementation of
>>> a singleton "app" object which could (and should) have tests written for it
>>> as it's improved upon. If you or others want to do that work feel free,
>>> I've moved on to other items for the near future.
>>>On Tue, Feb 27, 2018 at 12:07 AM Carsten Haitzler ras...@rasterman.com
>>> wrote:
On Mon, 26 Feb 2018 11:03:03 -0800 Mike Blumenkrantz
michael.blumenkra...@gmail.com said:
 this change has a fair few problems to it... i don't think this is the
 right
 way to go.
 this change from efl_main_loop_get() doesn't make sense
 - job = efl_add(EFL_IO_MANAGER_CLASS, efl_main_loop_get());

 - job = efl_add(EFL_IO_MANAGER_CLASS,
 efl_app_main_loop_get(efl_app_get()));


>>>I disagree on both of those line. You get the main loop when your application
>> start and all your object do get you there. The scenario in which you need to
>> directly access the main loop should be really limited (tests and legacy code
>> are what come to my mind).
>>
> i literally have test code that does:
>
> if (loop == efl_main_loop_get()) { } else  { }

Where is that code ? In efl, it can make sense in some case, but application 
should not rely on that as this facility is not available to bindings. It would 
prove that we have a design issue and that you can't write the same application 
in C as in Python due to our objects limitation. 

> i can't do that anymore from threads. the loop does not have an EO parent set
> to the efl app object, so i cant get the parent of my loop and do an isa on
> it... that's why i say... this doesn't make sense... it also doesn't make 
> sense
> to just make it longer.

This is confusing. Basically you want to be able to do pointer comparison of 
something that is not valid (in the thread domain sense) in the thread context 
you are in, in C. This point exactly to my remark above. Language that do not 
have pointer, like almost every binding, won't be able to do this kind of code. 
So the logic above is a problem that need solving. I haven't seen that kind of 
code before in our code base and can't find it. So I am at a loss of 
understanding what you are trying to do here. 

you can't access the app object from anywhere other than the main loop
 thread because it's a thread local object (the default)... so all this
 does it make this longer for no benefit.

>>>This is the point. Why would you need to access this object from another
>> thread ?
>>
> you can't know if your loop is the main loop or not with this scheme. if you
> use superclassing then isa() can tell you. if it actually used eo parent
> objects, then getting parent could tell you, with the exception that the 
> parent
> is thread local so this cant work. if it was shared you cross domains too.

Why do you need to know if your loop is the main loop or not ?

> it's better to superclass here than use parent/child.
>
if can't be a shared object either because you also do things like:
 - EINA_LIST_FOREACH_SAFE(pd->loops, l, ll, loop)

 - efl_del(loop);
you want to have multiple loops in a single thread-local shared object? you
 can't mix shared and non-share objects.

>>>There is a lot in this sentence. The fact we can't mix shared and non-shared
>> object is going to be a serious problem with our parent model and object
>> refcounting in general. Basically we will require to have another tree of
>> shared object on the side that is not connected to the one that are not
>> shared. And all of this object have to be controlled by the user call to the
>> domain API. This is a lot of receipe for error and problems.
>>
> correct. it's just not practical to mix objects that are locked and protected
> with ones that have no locking on them. delete a shared obj and it tires to
> delete non-0shared children. BOOM. the children aren't protected with locks
> etc. ... there are good reasons not to allow the "streams to cross". and they
> have nothing to do with the shared objects that provide locking for you, but 
> to
> do with locked vs not-locked objects/data interacting in general

I think this is another problem to put on the list of problem that the current 
domain system bring and another argument to not 

Re: [E-devel] Pre-release tarballs for efl 1.20.7

[William L. Thomson Jr.]

On Thu, 1 Mar 2018 09:28:53 +0100
Stefan Schmidt  wrote:
>
> On 02/28/2018 10:03 PM, Quelrond wrote:
> > Hi,
> >
> > I've just tested the git version (probably not so far from release
> > this evening) on FreeBSD 11.1.  
> 
> Git version from which branch would be the question here.
> The 1.20.7 is coming from the efl-1.20 branch as it is a stable
> update for 1.20.X
> 
> If you tested git master this would be very far away from what the
> 1.20.7 tarballs contain.

That likely explains issues with Ecrire under git. Per the following.
https://github.com/Obsidian-StudiosInc/ecrire/issues/29

I will see about modifying build to prevent build from git. Not sure I
can require it to be from some branch in build system.

Thanks for passing that along. I had not looked into the git situation.

-- 
William L. Thomson Jr.


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

[Gustavo Sverzut Barbieri]

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

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


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



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

if the user needs the object, he can pass that as his future cb data.

the idea is that these things can be chained, including transformations... like:

  bla.run().then(uppercase).then(console.log)

we even offer some converters and a console future for such things.
Actually we should even do more,
like those exposed by http://reactivex.io, handling multiple wait,
debounce, etc.


> oooh... no no no. first - i don;t need know now if the handler has been added
> or removed because callback_call handles that for me.
> and calling end() sent a
> signal to the child process to request it to end... it does not mean it has
> ended yet. so you would never sensibly call end from the exit event cb because
> that's sending end to a process that no longer exists... just the object
> representing it does still to store the results.
>
> so maybe you mean "del()" the object if the caller isn't listening for exit
> events... It'd LOVE to do that, but c++ people will hate autodel... which is
> exactly what that would be.

well, that's 

Re: [E-devel] [Enlightenment-intl] Missing da.po in EFL 1.20.7 release

[Massimo Maiurana]

Oh, I see now. Well, I don't follow all releases so I think I'll keep
committing to master, even if a minor release doesn't contain
translation updates it should not be a big problem :)

Thanks
Massimo

Stefan Schmidt ha scritto il 01/03/2018 alle 13:15:
> Hello.
> 
> 
> On 03/01/2018 01:02 PM, Massimo Maiurana wrote:
>> I don't know why that translation was not included in release tag, I
>> usually commit all files in git master. I include the devel list in
>> recipients.
> 
> 1.20.7 is done from the efl-1.20 branch as it is only a stable update to the 
> major 1.20 release.
> 
> If you commit files to master but not the stable branch they will only show 
> up in the next major release which will be 1.21
> 
> If you wanted to get translation updates into the stable updates (which is 
> fine from my side)you would need to backport them into the stable
> branch.
> 
> regards
> Stefan Schmidt
> 
> 
>> Massimo
>>
>> scootergrisen ha scritto il 01/03/2018 alle 11:24:
>>> I just got e-mail with topic:
>>> [Enlightenment-release] EFL 1.20.7 release
>>>
>>> But danish translation is not included (da.po).
>>> Why not?
>>>
>>> I think i sent it months ago.
>>> https://git.enlightenment.org/core/efl.git/tree/po
>>> https://git.enlightenment.org/core/efl.git/commit/?id=9e98ddb63b2795e38ad2873455ebc3b0295f36f9
>>>
> 


-- 
Massimo Maiurana
Ragusa (RG)

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

Re: [E-devel] [Enlightenment-intl] Missing da.po in EFL 1.20.7 release

[Stefan Schmidt]

Hello.


On 03/01/2018 01:02 PM, Massimo Maiurana wrote:
> I don't know why that translation was not included in release tag, I
> usually commit all files in git master. I include the devel list in
> recipients.

1.20.7 is done from the efl-1.20 branch as it is only a stable update to the 
major 1.20 release.

If you commit files to master but not the stable branch they will only show up 
in the next major release which will be 1.21

If you wanted to get translation updates into the stable updates (which is fine 
from my side)you would need to backport them into the stable
branch.

regards
Stefan Schmidt


> Massimo
>
> scootergrisen ha scritto il 01/03/2018 alle 11:24:
>> I just got e-mail with topic:
>> [Enlightenment-release] EFL 1.20.7 release
>>
>> But danish translation is not included (da.po).
>> Why not?
>>
>> I think i sent it months ago.
>> https://git.enlightenment.org/core/efl.git/tree/po
>> https://git.enlightenment.org/core/efl.git/commit/?id=9e98ddb63b2795e38ad2873455ebc3b0295f36f9
>>


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

Re: [E-devel] [Enlightenment-intl] Missing da.po in EFL 1.20.7 release

[Massimo Maiurana]

I don't know why that translation was not included in release tag, I
usually commit all files in git master. I include the devel list in
recipients.

Massimo

scootergrisen ha scritto il 01/03/2018 alle 11:24:
> I just got e-mail with topic:
> [Enlightenment-release] EFL 1.20.7 release
> 
> But danish translation is not included (da.po).
> Why not?
> 
> I think i sent it months ago.
> https://git.enlightenment.org/core/efl.git/tree/po
> https://git.enlightenment.org/core/efl.git/commit/?id=9e98ddb63b2795e38ad2873455ebc3b0295f36f9
> 
> 
> --
> 
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Enlightenment-intl mailing list
> enlightenment-i...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-intl


-- 
Massimo Maiurana
Ragusa (RG)

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

[E-devel] EFL 1.20.7 release

[Stefan Schmidt]

Our seventh update on the 1.20 release.

==Fixes:==

   * ecore ipc/con: fix nasty ... they dont mutually exclude
   * evas: Fix potential crash with draw context
   * disable async mode (use sync mode) for ibus when keymap changes
   * eio: make inotify monitors fork-safe
   * ecore-file: make monitoring truly fork-safe
   * efl-wl: unset kbd mods changed flag after sending modifiers
   * efl-wl: fix no-op of setting keyboard enter on already-entered surface
   * ecore-x: re-add implementation of ecore_x_connection_get()
   * ecore-x: filter XkbNewKeyboardNotifyEvent before emitting ecore-x event
   * elementary config: Fix to use ELEMENTARY_BASE_DIR for configure path
   * ecore-x: add more null checks for functions
   * ecore-x: perform internal shutdown on io error if callback is set
   * ecore-wl2: correctly translate spacebar keyname into key events (T6620)
   * efl-wl: immediately unset a destroyed surface's cursor
   * efl-wl: remove some broken logic for activating toplevel parents
   * efl-wl: set event ON_HOLD flag when they are sent to a surface
   * efl-wl: propagate surface activation back to parent if child is hidden
   * efl-wl: send more mouse buttons to clients
   * efl theme - fix bug in e init splash that would do hide anim 2x (T6619)
   * ecore-drm2: return supported rotations if not using hardware
   * ecore-drm2: Fix enabling outputs
   * ecore evas init - init ecore then evas not the other way...
   * emotion: unset DISPLAY when loading an engine under wayland (T6418)
   * elm: fix memleak in combobox
   * ecore_con: bug workaround SO_REUSEADDR and EADDRINUSE from bind (fix)
   * eina: fix random segfaults when displaying BT
   * eldbus test - del not unref obj as it has a parent ...
   * eeze: Remove unused device variables
   * eeze: Don't leak udev enumeration
   * eina: Fix typo in doxygen
   * ecore-evas-drm: Check for XDG_SEAT existence (T6455)
   * eina_file: make sure we use a stringshare when virtualized. (T6449)
   * elm ifrace scrollable - fix uninitialized values on scroll asjust
   * eo - by default on 64bit only use 47 bits because of luajit
   * elm_code_widget: make sure the widget is cleared properly. (T6185)
   * elm_code_widget: keep track of visibility.
   * edje - entry - fix empty item handling (T6668)
 
==Download:==
http://download.enlightenment.org/rel/libs/efl/efl-1.20.7.tar.xz

b0a9b765bcd7b012f1072da1d491fc8671aa089473f746901d93f5807a2c76fe





--
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 11/13: theme: rename "default" theme to "dark"

[Simon Lees]

On 01/03/18 18:12, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 28 Feb 2018 13:05:51 -0800 Mike Blumenkrantz
>  said:
> 
>> discomfitor pushed a commit to branch master.
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=d764e0b2790b322778e6db80932c168ae0d43b96
>>
>> commit d764e0b2790b322778e6db80932c168ae0d43b96
>> Author: Mike Blumenkrantz 
>> Date:   Tue Feb 27 17:31:40 2018 -0500
>>
>> theme: rename "default" theme to "dark"
>> 
>> this inhibits maintenance and development of multiple stock themes
>> 
>> a symlink is created to 'default.edj' to preserve compatibility
> 
> ummm errr... this breaks efl compatibility. you can't do this. the symlinks
> isn't a solution because of windows. no symlinks there (well on ntfs only as
> only as administrator, so they don't exist).
> 
> modifying config for switch from default to dark also will break the case 
> where
> someone put ~/.elementary/themes/default.edj there and it just is different to
> the system one and how their theme changes on them as it switches to dark.
> 
> basically we can't rename a theme like this mid-flight in efl. default is
> default and has to stay that name. it can change the look, but not the name.
> 
> i think the apparent reasoning behind this is not a good one. the work on flat
> is temporary. i don't think we will ever maintain multiple "default themes" as
> its just far too much work.
> 
> we can maintain color SCHEMES which are just a list of colorclasses and colors
> for them - that's separate to a theme and would override. right now these 
> things
> don't exist. we are not going to create a dark.edj and a light.edj just to
> store differing default colorclass values. we should be doing the above with
> colorclass "color palette/scheme/whatever" files that override those named
> colorclasses globally on init.
> 

On openSUSE we rename the default theme to dark and then name one of our
themes default.edj (unless you use the upstream branding package) but
the concept of a "default" theme is really useful, there needs to be a
theme loaded when e's wizard is launched for the first time and having
it be "default.edj" on the filesystem is more useful then having to
patch code to pick the theme we as a distro wants to use as its default.
I don't really care what default.edj looks like, but as long as it still
exists and thats the first theme that's looked for on a new system I'm
happy.

-- 

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] Pre-release tarballs for efl 1.20.7

[Stefan Schmidt]

Hello.

[I added the e-devel list back in CC to allow others comment on this as well]


On 02/28/2018 10:03 PM, Quelrond wrote:
> Hi,
>
> I've just tested the git version (probably not so far from release this 
> evening) on FreeBSD 11.1.

Git version from which branch would be the question here.
The 1.20.7 is coming from the efl-1.20 branch as it is a stable update for 
1.20.X

If you tested git master this would be very far away from what the 1.20.7 
tarballs contain.

regards
Stefan Schmidt


>
> I have many strange messages starting Terminology (these two messages 
> come on every keydown) :
>
> ERR<2557>:ecore lib/ecore/ecore.c:798 _ecore_magic_fail() *** ECORE 
> ERROR: Ecore Magic Check Failed!!! in: ecore_imf_context_filter_event()
> ERR<2557>:ecore lib/ecore/ecore.c:800 _ecore_magic_fail() Input 
> handle pointer is NULL!
>
> Ephoto is not really happy neither:
>
> ERR<3039>:eina_safety lib/evas/canvas/evas_events.c:1451 
> evas_event_thaw_eval() safety check failed: efl_isa(eo_e, 
> EVAS_CANVAS_CLASS) is false
> ERR<3039>:elementary lib/elementary/efl_ui_focus_manager_calc.c:1542 
> _efl_ui_focus_manager_calc_efl_ui_focus_manager_manager_focus_set() 
> Could not fetch a node located at 0x4040f06a
> ERR<3039>:elementary lib/elementary/efl_selection_manager.c:4240 
> _anim_icons_make() calling icon_list_func
> ERR<3039>:elementary lib/elementary/efl_selection_manager.c:4258 
> _anim_icons_make() made icon list
> ERR<3039>:elementary lib/elementary/efl_selection_manager.c:4273 
> _cont_obj_drag_start() going to start draging
> ERR<3039>:elementary lib/elementary/efl_ui_win.c:8433 
> elm_win_resize_object_add() could not add sub object 0x0 to window 
> 0x40506635
>
>
> Best regards,
>
> Peter
>
>
> On 20/02/2018 12:12, Stefan Schmidt wrote:
>> [This seems to have never arrived yesterday, resend. I still will do the 
>> final release today. There was plenty of time for testing.]
>>
>> Hello.
>>
>>
>> The 1.20.7 is not really going smoothly. My typos in the mails, sf.net mail 
>> outage...
>>
>>
>> On 02/15/2018 10:04 AM, Stefan Schmidt wrote:
>>> [This mail was supposed to arrive here yesterday evening already]
>>>
>>> Hello.
>>>
>>>
>>> A bit delayed but here are the 1.20.7 pre-release tarballs for testing
>>>
>>> If I hear nothing problematic within the next 24 hours, I will do the
>>> final release on tomorrow.
>>>
>> A have a new spin of these pre-release tarballs for testing. Two more fixes 
>> for elm_code have been added.
>> The 24h clock starts again now.
>>
>> https://download.enlightenment.org/pre-releases/efl-1.20.7-pre.tar.gz
>> 883229eeebf9bd290ef01e84eefdd816a642f2ec8e3708dd3c9f8a3e6264d80c
>>
>> https://download.enlightenment.org/pre-releases/efl-1.20.7-pre.tar.xz
>>
>> b0a9b765bcd7b012f1072da1d491fc8671aa089473f746901d93f5807a2c76fe
>>
>> regards
>> Stefan Schmidt
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


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