Re: [E-devel] ecore main loop -> efl_loop full convert

[Jean-Philippe André]

Hi,

I talked to raster for clarification.

2017-11-22 14:57 GMT+09:00 Carsten Haitzler :

> So we had a partly done move to efl_loop. it still was all built on top of
> the
> main loop globals. If this is all done right then we can have multiple
> loops
> (e.g. one per thread) and that is a good thing.
>
> So I've been fixing that. I've done just about all the globals in ecore
> EXCEPT
> ecore events. I now have to think about how to do this in eo/interfaces
> with
> efl loop objects and so on. I'm mulling how to do it.
>
> We still have some need for a deferred event bus/queue. A lot of things
> that
> are ecore events should be callbacks on objects directly and that's being
> fixed, but an event queue + types is still needed.
>
> So there are a few aspects to this.
>
> 1. Creating of new event types at runtime (and allocating a unique
> identifier
> for them).
> 2. Being able to submit them to a queue to be "processed later"
> 3. Being able to call callbacks that are listening for that type of event
> and
> hand them the deferred event data.
>
> This is used as the backing for ecore_jobs and pretty much every i/o thing
> (input events, i/o and more) as well as in-process custom event bus+events.
>
> My current thought is this.
>
> 1. event types are still ints with a single global shared backing table of
> all
> event types (allocated once ever much like atoms in x).
> 2. event event is an eo object on the queue (of some type).
> 3. some event object "factory" on the loop that creates and "deletes"
> (caches
> then) these event objects for recycling.
>
> Does anyone have better ideas? I considered the event type being an object
> itself and also doubling as a factory per event type but due to multiple
> threads you'd probably be creating an object then per thread per event
> type and
> I do not like that.



Basically we have two base EO types:

 - "ecore event type" EO class:
singleton per loop, it's a handle
you can request the loop for the handle  given the UUID
contains the read-only UUID, maybe a string description, and an EO event
"received" or whatever
created and managed by the Efl.Loop (each Loop would need to create their
own handles)
listeners add an EO callback for "received" to that handle, this keeps the
listeners list per loop
the loop has a special function to send an event

 - "ecore event info" EO class:
an ecore event that carries no info could even use null
event info is a base class with a link to its type
the loop creates and manages these temporary objects as events are being
processed


This is consistent with input events (info type are EO objects with a
common base class).
I see no major issue with this design, besides extra memory requirements.

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

[E-devel] Enlightenment DR 0.22.1 Release

[Simon Lees]

CHANGES
https://git.enlightenment.org/core/enlightenment.git/tree/NEWS?h=v0.22.1


207b6b88dafc4932ab007a835510823c5a1dd8c191876ac037628176ca77a7e0
http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.22.1.tar.xz

See the full announcement for more details:
https://www.enlightenment.org/news/e0.22.1_release


-- 

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

[E-devel] ecore main loop -> efl_loop full convert

[Carsten Haitzler]

So we had a partly done move to efl_loop. it still was all built on top of the
main loop globals. If this is all done right then we can have multiple loops
(e.g. one per thread) and that is a good thing.

So I've been fixing that. I've done just about all the globals in ecore EXCEPT
ecore events. I now have to think about how to do this in eo/interfaces with
efl loop objects and so on. I'm mulling how to do it.

We still have some need for a deferred event bus/queue. A lot of things that
are ecore events should be callbacks on objects directly and that's being
fixed, but an event queue + types is still needed.

So there are a few aspects to this.

1. Creating of new event types at runtime (and allocating a unique identifier
for them).
2. Being able to submit them to a queue to be "processed later"
3. Being able to call callbacks that are listening for that type of event and
hand them the deferred event data.

This is used as the backing for ecore_jobs and pretty much every i/o thing
(input events, i/o and more) as well as in-process custom event bus+events.

My current thought is this.

1. event types are still ints with a single global shared backing table of all
event types (allocated once ever much like atoms in x).
2. event event is an eo object on the queue (of some type).
3. some event object "factory" on the loop that creates and "deletes" (caches
then) these event objects for recycling.

Does anyone have better ideas? I considered the event type being an object
itself and also doubling as a factory per event type but due to multiple
threads you'd probably be creating an object then per thread per event type and
I do not like that.

-- 
- 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] Eo API docs: Large inheritance content

[Jean-Philippe André]

Hi,

2017-11-22 9:14 GMT+09:00 Carsten Haitzler :

> On Tue, 21 Nov 2017 16:57:18 + Andrew Williams 
> said:
>
> > Hi team,
> >
> > Looking at some of our larger inheritance trees, such as
> > https://www.enlightenment.org/develop/api/class/efl/ui/clock , may
> provide
> > only 8 members but the page runs to hundreds of items - a complete bed
> time
> > read in itself. I think for the sanity of our readers it would be good to
> > list the members it inherits in short hand. Like the somewhat
> standardised
> > JavaDoc output -
> > https://docs.oracle.com/javase/7/docs/api/java/io/
> OutputStreamWriter.html
> >
> > Additionally the complete heirarchy tree at the top of each page takes a
> > lot of space and repeats a lot - it would make sense to flatten this to a
> > list.
>
> I like the tree at the top... It does contain very useful information of
> where the class comes from in the scheme of things. Why not use a foldable
> section? Expand it if you want the tree, otherwise stay collapsed?
>
> Same for all of the inherited methods/properties etc. - put them all in
> foldable sections you expand?
>

The tree view in our doc pages has some issues indeed. It repeats the same
classes multiple times (multiple inheritance leading to that), like
Efl.Object on the page Andy mentioned.
I think it would be acceptable to separate between direct inheritance and
interfaces, like in JavaDoc? Not sure where mixins would go, maybe in a
special category as well.

In JavaDoc, QtDoc and all, we also find usually a summary of the methods,
and the inherited methods, with links to the full description.
We already have this separation (full doc for edit_mode is under its own
page:
https://www.enlightenment.org/develop/api/class/efl/ui/clock/property/edit_mode)
but the view is probably not condensed enough. Basically the table view in
"Method Summary" is good but could be better if left side as the method
name (+get/set), right side the brief description and maybe a
pseudo-language signature, if that's possible.

PS: The inheritance graph picture should not be generated with a max size,
as it becomes unreadable.

-- 
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] Git Feature/ Proposal

[Jean-Philippe André]

My problem is that those branches won't be in sync with master.
This will lead to merge conflicts. I am these days reviewing a lot of work
done in dev branches or phab patches and it almost never applies nicely on
master, because the interfaces change.
A lot of work is done in branches (model, c#, eo widgets, ...) and those
tasks are both long term and involve more than a single dev. They require
constant rebasing on master or the final rebase will be a nightmare. Right
now this is done by people pulling other devs branches, and then rebasing
onto master in their own dev branch.

Rewriting history on a shared branch has major downsides too. No problem
for dev branches as there's only one committer, but anyone pulling a
rewritten history will endure pain.

Honestly I don't have a solution.

It's a move in the right direction, but I'm not sure it's solving the
problems I'm facing :(



2017-11-22 3:43 GMT+09:00 Tom Hacohen :

> Only problem would be the commit emails being resent (because
> technically they are new commits). One can mitigate that by first
> pushing them to a dev branch. Commits there have first been there
> don't trigger emails.
>
> On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
>  wrote:
> > In the issue where a significant rebase against master is necessary then
> > it's trivial enough to either push to a new feature branch or delete and
> > re-create the existing branch.
> >
> > On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:
> >
> >> As Mike said, the rebase/sync to master is being done locally before
> >> the merge. If you are talking about keeping this branch in sync with
> >> master constantly while developing, yes it's a problem. But I guess
> >> it's not intended for long term features.
> >>
> >> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
> >>  wrote:
> >> > I don't see a difference in the merge process? A feature branch
> should be
> >> > treated exactly the same as master; the only difference is that it's a
> >> > branch which people must specifically pull in order to use instead of
> >> being
> >> > master.
> >> >
> >> > When merging, you can either do a regular rebase/merge as in the git
> >> > practices documentation or you can choose to rebase/squash on the
> >> branched
> >> > commits prior to pushing the merge. There is no rewriting within the
> >> > branch, but you can still rewrite anything which has not been pushed
> to
> >> > master just prior to pushing it to master.
> >> >
> >> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
> j...@videolan.org>
> >> > wrote:
> >> >
> >> >> Hey,
> >> >>
> >> >> If we can't rewrite history on those branches (rebase and push -f),
> how
> >> >> should we proceed with the merge to/from master?
> >> >> Usually when we merge a branch to master, we rebase it on top of
> master
> >> >> first and then rebase. That's how our history remains linear and
> simple.
> >> >>
> >> >> What's the idea here? I wonder.
> >> >>
> >> >> Thanks for implementing this btw,
> >> >>
> >> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
> >> >>
> >> >> > I'm not sure about jenkins, that's Stefan's role.
> >> >> >
> >> >> > Anyhow, pushed the changes according to the wiki. Please consider
> >> >> > especially mentioning probies when you say "everyone can push to".
> >> >> >
> >> >> > --
> >> >> > Tom.
> >> >> >
> >> >> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
> >> >> >  wrote:
> >> >> > > I've added all the necessary info to the documentation at
> >> >> > >
> >> >>
> >> https://www.enlightenment.org/contrib/devs/git-guide.md#
> Feature_Branches
> >> >> > >
> >> >> > > If the jenkins concept is not possible then feel free to remove,
> but
> >> >> the
> >> >> > > rest should be in line with what we want.
> >> >> > >
> >> >> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen 
> wrote:
> >> >> > >
> >> >> > >> So what has been decided? What should I do? I need specs,
> >> preferably
> >> >> > >> already added to the git wiki page so there are docs for this
> >> thing.
> >> >> > >>
> >> >> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
> >> >> ras...@rasterman.com
> >> >> > >
> >> >> > >> wrote:
> >> >> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
> >> >> > >> >  said:
> >> >> > >> >
> >> >> > >> >> Key points for the implementation:
> >> >> > >> >>
> >> >> > >> >> * all commits send mails to the list
> >> >> > >> >> * no rewrite of pushed commits
> >> >> > >> >>
> >> >> > >> >> Things to consider:
> >> >> > >> >> * how are feature/ branches deleted?
> >> >> > >> >>  - maybe anyone can delete?
> >> >> > >> >
> >> >> > >> > Good point. these need deletion. after a few years it'll be a
> >> mess
> >> >> of
> >> >> > old
> >> >> > >> > feature branches no one will ever look at again. The merge to
> >> master
> >> >> > >> should
> >> 

Re: [E-devel] Website Table of Contents

[Carsten Haitzler]

On Mon, 20 Nov 2017 12:18:09 + Andrew Williams  said:

> Hi,
> 
> So I've tried to get a ToC appended to the nav sidebar and I'm not
> disappointed with the result.
> https://www.enlightenment.org/ss/display.php?image=e-5a12a60dc3d772.36151853.jpg
> 
> If there is space the bar is static on the top right of the screen, if
> there is not a wide enough gutter then it inlines at the top right of the
> content.

It seems this is broken (overlaps a lot of content - just by luck the content
doesn't have long enough lines there to be hidden):

  https://www.enlightenment.org/develop/api/class/efl/object

  http://www.enlightenment.org/ss/e-5a14c363eec9d0.43575629.png

It shouldn't "gutter" IMHO in this case either like on mobile like displays. I
think you need a better solution. Most of that ToC IMHO is not useful while
reading reference docs. Especially the Tutorials, Setup and APIs. Tutorials
there is hopefully going to expand to 100's of items  making this pretty
pointless. The Page Contents is the useful part as a "jump to this section". I
assume for now most of that is "sample content" and will be reconsidered in
future?

I am thinking this should really just be a dropdown menu like Options etc.
perhaps displayed by default? At least so I can hide it and read the content
underneath?

> It appears when there are 3 or more headings at level 2 and 3 - that means
> we ignore top level headings (usually a page title) and expand 1 level if
> the current top level area has child elements. Most of this is the ToC
> plugin in dokuwiki and works quite well.
> 
> Comments welcome, plenty of opportunity to adapt it to suit our style.
> Andy
> 
> On Wed, 8 Nov 2017 at 07:27 Carsten Haitzler  wrote:
> 
> > On Tue, 07 Nov 2017 15:59:24 + Andrew Williams 
> > said:
> >
> > > Hi,
> > >
> > > The amount of space it takes up is a stylistic issue - our template
> > > explicitly reserves 1/4 of the screen for a ToC which is clearly not a
> > > requirement.
> >
> > that was my major thing about it. stylistic. :) also the original css for
> > it
> > was a bit blergh and i didn't feel like fixing it up to be nicer so
> > removing was
> > less work. that's why i didnt do the TOC though. if you're going to do
> > one...
> > do it well. :)
> >
> > > Additionally of concern is that many of our pages (specifically the
> > program
> > > guide) have (manually entered) contents areas that are within the page
> > > content.
> > > https://www.enlightenment.org/develop/legacy/program_guide/eina/arrays
> >
> > That's kind of odd... I'd just remove it IMHO... :)
> >
> > > As part of this documentation effort we are seeing navigation as an area
> > in
> > > which we are significantly lacking so I think we can spend some time
> > fixing
> > > it.
> > > I am a little unsure as to whether the main objection here is that we see
> > > ToC as a bad thing or if we just did not find a way to include it neatly
> > in
> > > our layout.
> >
> > a little of the first but mostly the second. if you need a TOC because the
> > page
> > is so big ... i kind of think it should be split up... :)
> >
> > > If it were possible to make it well presented would people be generally
> > in
> > > favour of moving the ToCs into a standard (sidebar?) area so, where pages
> > > need it, we can have the contents presented in a standard form (whilst
> > > being auto generated)?
> >
> > see the first above :)
> >
> > > Thanks,
> > > Andrew
> > >
> > > On Tue, 7 Nov 2017 at 12:51 Carsten Haitzler 
> > wrote:
> > >
> > > > On Mon, 06 Nov 2017 18:47:45 + Andrew Williams <
> > a...@andywilliams.me>
> > > > said:
> > > >
> > > > > Hi,
> > > > >
> > > > > With some of the examples in our new documentation there is a lot of
> > > > > content and there was a request to generate a table of contents.
> > > > > This feature has been turned off on our wiki and I wondered how
> > people
> > > > > would feel about us turning this back on. With the current styling it
> > > > looks
> > > > > like this screenshot:
> > > > > https://www.enlightenment.org/ss/e-5a00adba813593.05237914.jpg
> > > >
> > > > Hmmm... My take is that I don't like it. Dokuwiki by default had a TOC
> > and
> > > > I
> > > > actually turned it off it. It took up too much horizontal space in most
> > > > places.
> > > > it comes off badly when your browser windows are not maximized or on
> > > > portrait
> > > > screens (tablets, phones)... so that is why I did this.
> > > >
> > > > Making pages too wide (expand so they fill a maximize screen) generally
> > > > makes
> > > > line reading harder (there is a reason newspapers etc. use narrow
> > > > columns), thus
> > > > why limiting the width of content tended to make for nicer
> > presentation.
> > > > And
> > > > dokuwiki was all about presenting the front of "enlightenment.org"
> > nicely
> > > > to
> > > > the world, so that's why I limited the width. I wasn't going to 

Re: [E-devel] [EGIT] [core/efl] master 01/01: ecore: reformat ecore_exe_posix.c

[Carsten Haitzler]

On Tue, 21 Nov 2017 09:31:38 -0800 Mike Blumenkrantz
 said:

Just a request... can you not do "reformatting" of anything in ecore
(src/lib/ecore) right now. I am actually in the middle of ACTUALLY making the
main loop a real object (moving fd handlers, win32 handlers, timers, event
queue etc.) actually our of global variables into the actual loop object to
pave the way for actual multiple loop objects. it's proving problematic as i'm
discovering all the nasties like provider_find failing during construction and
destruction (thanks to losing parent) etc. and this has also meant rejigging
chunks of code and cleaning up a decade or 2 of "mess" just to see the forest
from the trees. It'll make my life easier with fewer or smaller conflicts. :)

> discomfitor pushed a commit to branch master.
> 
> http://git.enlightenment.org/core/efl.git/commit/?id=7cdbe6e029be7fe5db0d12b8af1e17101692943f
> 
> commit 7cdbe6e029be7fe5db0d12b8af1e17101692943f
> Author: Mike Blumenkrantz 
> Date:   Tue Nov 21 12:24:51 2017 -0500
> 
> ecore: reformat ecore_exe_posix.c
> ---
>  src/lib/ecore/ecore_exe_posix.c | 1413 +++
> +--- 1 file changed, 708 insertions(+), 705 deletions(-)
> 
> diff --git a/src/lib/ecore/ecore_exe_posix.c b/src/lib/ecore/ecore_exe_posix.c
> index 3cbba20f44..bebfce26a1 100644
> --- a/src/lib/ecore/ecore_exe_posix.c
> +++ b/src/lib/ecore/ecore_exe_posix.c
> @@ -49,52 +49,54 @@ struct _ecore_exe_dead_exe
> char *cmd;
>  };
>  
> -static inline void _ecore_exe_exec_it(const char *exe_cmd,
> +static inline void _ecore_exe_exec_it(const char *exe_cmd,
>Ecore_Exe_Flags flags);
> -static Eina_Bool   _ecore_exe_data_generic_handler(void *data,
> +static Eina_Bool   _ecore_exe_data_generic_handler(void *data,
> Ecore_Fd_Handler
> *fd_handler,
> -   Ecore_Exe_Flags   flags);
> -static Eina_Bool_ecore_exe_data_error_handler(void
> *data,
> -  Ecore_Fd_Handler
> *fd_handler); -static Eina_Bool_ecore_exe_data_read_handler
> (void *data,
> - Ecore_Fd_Handler
> *fd_handler); -static Eina_Bool_ecore_exe_data_write_handler
> (void *data,
> -  Ecore_Fd_Handler
> *fd_handler); -static void _ecore_exe_flush(Ecore_Exe *obj);
> -static Ecore_Exe   *_ecore_exe_is_it_alive(pid_t pid);
> -static Eina_Bool_ecore_exe_make_sure_its_dead(void *data);
> -static Eina_Bool_ecore_exe_make_sure_its_really_dead(void *data);
> -static void _ecore_exe_dead_attach(Ecore_Exe *obj);
> +   Ecore_Exe_Flags flags);
> +static Eina_Bool   _ecore_exe_data_error_handler(void *data,
> + Ecore_Fd_Handler
> *fd_handler); +static Eina_Bool   _ecore_exe_data_read_handler(void *data,
> +Ecore_Fd_Handler
> *fd_handler); +static Eina_Bool   _ecore_exe_data_write_handler(void *data,
> + Ecore_Fd_Handler
> *fd_handler); +static void_ecore_exe_flush(Ecore_Exe *obj);
> +static Ecore_Exe  *_ecore_exe_is_it_alive(pid_t pid);
> +static Eina_Bool   _ecore_exe_make_sure_its_dead(void *data);
> +static Eina_Bool   _ecore_exe_make_sure_its_really_dead(void *data);
> +static void_ecore_exe_dead_attach(Ecore_Exe *obj);
>  
>  static const char *shell = NULL;
>  
>  /* FIXME: This errno checking stuff should be put elsewhere for everybody to
> use.
>   * For now it lives here though, just to make testing easier.
>   */
> -static int _ecore_exe_check_errno(int result,
> -  const char *file,
> -  int line);
> +static int _ecore_exe_check_errno(int result,
> +  const char *file,
> +  int line);
>  
> -#define E_IF_NO_ERRNO(result, foo,
> ok)   \
> -  while (((ok) = _ecore_exe_check_errno((result) = (foo), __FILE__,
> __LINE__)) == -1) sleep(1);  \
> -  if (ok)
> +#define E_IF_NO_ERRNO(result, foo,
> ok)\
> +  while (((ok) = _ecore_exe_check_errno((result) = (foo), __FILE__,
> __LINE__)) == -1) \
> +sleep
> (1); \
> +  if (ok)
>  
> -#define E_NO_ERRNO(result, foo, ok) \
> -  while (((ok) = _ecore_exe_check_errno((result) = (foo), __FILE__,
> __LINE__)) == -1) sleep(1) +#define 

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon

[Carsten Haitzler]

On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz
 said:

> The wording is intentional. The meson build has a tendency to touch build
> files during the install phase (which must be run as root to install to the
> base system), meaning that failure to use sudo during general build will
> fail for subsequent builds anyway due to permissions errors when attempting
> to modify root-owned files.

i have never had a permission error after a "sudo ninja install" to just run
ninja as me to rebuild whatever changed. it's just the gmo files (and install
log which obviously is written as root) from gettext... and they are only
re-generated by root so ... root overwrites root files. you can delete these
files because they are in a directory owned by you (the user).

so where is the actual permission problem? a ninja && sudo ninja install will
succeed without permission problems (see above). you as a user can delete the
effected files too.

but suggestion people compile as root is a bad idea.

???

> On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler 
> wrote:
> 
> > On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz
> >  said:
> >
> > > Issues had been found at an inconvenient time during review, so I left
> > the
> > > branch unmerged so that someone could either push while I was gone or I
> > > could push when I returned.
> >
> > I saw you pushed now. so we know the status. This also clears up the build
> > system state. I guess I should ensure it's documented. I see README
> > changed but
> > i am not sure it's correct as it's going to do a build as root... i'll deal
> > with it. :)
> >
> > > On Sun, Nov 19, 2017 at 6:56 PM Carsten Haitzler 
> > > wrote:
> > >
> > > > On Sun, 19 Nov 2017 13:05:06 + Andrew Williams <
> > a...@andywilliams.me>
> > > > said:
> > > >
> > > > > Hi,
> > > > >
> > > > > As the autotool/Makefiles are still in place I fixed the build for
> > users
> > > > > not yet using the E meson build.
> > > >
> > > > i was assuming autotools was dead - mike did say he'd push his
> > autotools
> > > > removal branch "in a day or 2 if no issues"... that about 1-2 weeks
> > back. i
> > > > didn't see it happen and didn't hear of issues...
> > > >
> > > > are there any? I'd consider merging his branch to remove autofoo at
> > this
> > > > point.
> > > > If meson has issues it should be tested and they should be fixed.
> > > >
> > > > > Andy
> > > > >
> > > > > On Fri, 17 Nov 2017 at 03:19 Carsten Haitzler 
> > > > wrote:
> > > > >
> > > > > > raster pushed a commit to branch master.
> > > > > >
> > > > > >
> > > > > >
> > > >
> > http://git.enlightenment.org/core/enlightenment.git/commit/?id=f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > > > >
> > > > > > commit f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > > > > Author: Carsten Haitzler (Rasterman) 
> > > > > > Date:   Fri Nov 17 12:17:42 2017 +0900
> > > > > >
> > > > > > music-control - install properly with meson build with icon
> > > > > >
> > > > > > @fix
> > > > > > ---
> > > > > >  ...-module-music_control.edj => e-module-music-control.edj} | Bin
> > > > > >  src/modules/music-control/meson.build   |   2
> > --
> > > > > >  src/modules/music-control/module.desktop|   2
> > +-
> > > > > >  3 files changed, 1 insertion(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/src/modules/music-control/e-module-music_control.edj
> > > > > > b/src/modules/music-control/e-module-music-control.edj
> > > > > > similarity index 100%
> > > > > > rename from src/modules/music-control/e-module-music_control.edj
> > > > > > rename to src/modules/music-control/e-module-music-control.edj
> > > > > > diff --git a/src/modules/music-control/meson.build
> > > > > > b/src/modules/music-control/meson.build
> > > > > > index 996b4196f..a84f5ea8e 100644
> > > > > > --- a/src/modules/music-control/meson.build
> > > > > > +++ b/src/modules/music-control/meson.build
> > > > > > @@ -18,5 +18,3 @@ src += custom_target('gen-dbus',
> > > > > >   command: [eldbus_codegen, '@INPUT@', '-O',
> > > > '@OUTDIR@
> > > > > > '],
> > > > > >   output : created_file
> > > > > >  )
> > > > > > -
> > > > > > -no_icon = true
> > > > > > diff --git a/src/modules/music-control/module.desktop
> > > > > > b/src/modules/music-control/module.desktop
> > > > > > index 99a2d9143..2e12677e3 100644
> > > > > > --- a/src/modules/music-control/module.desktop
> > > > > > +++ b/src/modules/music-control/module.desktop
> > > > > > @@ -27,5 +27,5 @@ Comment[nl]=Beheers uw muziek op uw plank
> > > > > >  Comment[ru]=Модуль для управления воспроизведением музыки
> > > > > >  Comment[sr]=Управљајте музиком са полице
> > > > > >  Comment[tr]=Müziğinizi rafta kontrol edin
> > > > > > -Icon=e-module-music_control
> > > > > > 

Re: [E-devel] Eo API docs: Large inheritance content

[Carsten Haitzler]

On Tue, 21 Nov 2017 16:57:18 + Andrew Williams  said:

> Hi team,
> 
> Looking at some of our larger inheritance trees, such as
> https://www.enlightenment.org/develop/api/class/efl/ui/clock , may provide
> only 8 members but the page runs to hundreds of items - a complete bed time
> read in itself. I think for the sanity of our readers it would be good to
> list the members it inherits in short hand. Like the somewhat standardised
> JavaDoc output -
> https://docs.oracle.com/javase/7/docs/api/java/io/OutputStreamWriter.html
> 
> Additionally the complete heirarchy tree at the top of each page takes a
> lot of space and repeats a lot - it would make sense to flatten this to a
> list.

I like the tree at the top... It does contain very useful information of
where the class comes from in the scheme of things. Why not use a foldable
section? Expand it if you want the tree, otherwise stay collapsed?

Same for all of the inherited methods/properties etc. - put them all in
foldable sections you expand?

> Are there any objections to these changes?
> 
> Thanks,
> Andy
> -- 
> http://andywilliams.me
> http://ajwillia.ms
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
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] SPDX header

[Carsten Haitzler]

On Tue, 21 Nov 2017 13:36:08 -0500 Cedric Bail  said:

> Hi,
> 
> If you have followed the kernel development, you may have seen that they are
> prefixxing all there source code file with a SPDX comment like :
> 
> /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> 
> This headers help automated tool to figure out the licenses of a specific
> file and allow companies to properly act on this information. EFL has a lot
> of different licenses and it would be a very good idea to actually roll that
> in. Is anyone opposed to this being rolled in during the next few weeks ?

are you going to automate it based on the licensing info we already have (just
run a script over a tree or subtree)?

can you leave src/lib/ecore/* alone for now? do this later...


-- 
- 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] Git Feature/ Proposal

[Tom Hacohen]

Only problem would be the commit emails being resent (because
technically they are new commits). One can mitigate that by first
pushing them to a dev branch. Commits there have first been there
don't trigger emails.

On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
 wrote:
> In the issue where a significant rebase against master is necessary then
> it's trivial enough to either push to a new feature branch or delete and
> re-create the existing branch.
>
> On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:
>
>> As Mike said, the rebase/sync to master is being done locally before
>> the merge. If you are talking about keeping this branch in sync with
>> master constantly while developing, yes it's a problem. But I guess
>> it's not intended for long term features.
>>
>> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
>>  wrote:
>> > I don't see a difference in the merge process? A feature branch should be
>> > treated exactly the same as master; the only difference is that it's a
>> > branch which people must specifically pull in order to use instead of
>> being
>> > master.
>> >
>> > When merging, you can either do a regular rebase/merge as in the git
>> > practices documentation or you can choose to rebase/squash on the
>> branched
>> > commits prior to pushing the merge. There is no rewriting within the
>> > branch, but you can still rewrite anything which has not been pushed to
>> > master just prior to pushing it to master.
>> >
>> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André 
>> > wrote:
>> >
>> >> Hey,
>> >>
>> >> If we can't rewrite history on those branches (rebase and push -f), how
>> >> should we proceed with the merge to/from master?
>> >> Usually when we merge a branch to master, we rebase it on top of master
>> >> first and then rebase. That's how our history remains linear and simple.
>> >>
>> >> What's the idea here? I wonder.
>> >>
>> >> Thanks for implementing this btw,
>> >>
>> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
>> >>
>> >> > I'm not sure about jenkins, that's Stefan's role.
>> >> >
>> >> > Anyhow, pushed the changes according to the wiki. Please consider
>> >> > especially mentioning probies when you say "everyone can push to".
>> >> >
>> >> > --
>> >> > Tom.
>> >> >
>> >> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
>> >> >  wrote:
>> >> > > I've added all the necessary info to the documentation at
>> >> > >
>> >>
>> https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches
>> >> > >
>> >> > > If the jenkins concept is not possible then feel free to remove, but
>> >> the
>> >> > > rest should be in line with what we want.
>> >> > >
>> >> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen  wrote:
>> >> > >
>> >> > >> So what has been decided? What should I do? I need specs,
>> preferably
>> >> > >> already added to the git wiki page so there are docs for this
>> thing.
>> >> > >>
>> >> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
>> >> ras...@rasterman.com
>> >> > >
>> >> > >> wrote:
>> >> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
>> >> > >> >  said:
>> >> > >> >
>> >> > >> >> Key points for the implementation:
>> >> > >> >>
>> >> > >> >> * all commits send mails to the list
>> >> > >> >> * no rewrite of pushed commits
>> >> > >> >>
>> >> > >> >> Things to consider:
>> >> > >> >> * how are feature/ branches deleted?
>> >> > >> >>  - maybe anyone can delete?
>> >> > >> >
>> >> > >> > Good point. these need deletion. after a few years it'll be a
>> mess
>> >> of
>> >> > old
>> >> > >> > feature branches no one will ever look at again. The merge to
>> master
>> >> > >> should
>> >> > >> > contain all the history and log that is needed at that point for
>> >> > history
>> >> > >> > digging.
>> >> > >> >
>> >> > >> >> * do probies get feature/ push access?
>> >> > >> >>  - seems like they should?
>> >> > >> >>
>> >> > >> >> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen 
>> wrote:
>> >> > >> >>
>> >> > >> >> > Yeah, good idea.
>> >> > >> >> >
>> >> > >> >> > I'll take a look into implementing it soon.
>> >> > >> >> >
>> >> > >> >> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams <
>> >> > a...@andywilliams.me
>> >> > >> >
>> >> > >> >> > wrote:
>> >> > >> >> > > Hi,
>> >> > >> >> > >
>> >> > >> >> > > That sounds great - the ability to work together on features
>> >> > >> off-master
>> >> > >> >> > > would be really helpful.
>> >> > >> >> > >
>> >> > >> >> > > Andy
>> >> > >> >> > >
>> >> > >> >> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
>> >> > >> >> > > michael.blumenkra...@gmail.com> wrote:
>> >> > >> >> > >
>> >> > >> >> > >> After some discussions about git organization, it's become
>> >> clear
>> >> > >> to me
>> >> > >> >> > that
>> >> > >> >> > >> we should be trying to enact some changes which 

Re: [E-devel] Git Feature/ Proposal

[Mike Blumenkrantz]

In the issue where a significant rebase against master is necessary then
it's trivial enough to either push to a new feature branch or delete and
re-create the existing branch.

On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:

> As Mike said, the rebase/sync to master is being done locally before
> the merge. If you are talking about keeping this branch in sync with
> master constantly while developing, yes it's a problem. But I guess
> it's not intended for long term features.
>
> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
>  wrote:
> > I don't see a difference in the merge process? A feature branch should be
> > treated exactly the same as master; the only difference is that it's a
> > branch which people must specifically pull in order to use instead of
> being
> > master.
> >
> > When merging, you can either do a regular rebase/merge as in the git
> > practices documentation or you can choose to rebase/squash on the
> branched
> > commits prior to pushing the merge. There is no rewriting within the
> > branch, but you can still rewrite anything which has not been pushed to
> > master just prior to pushing it to master.
> >
> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André 
> > wrote:
> >
> >> Hey,
> >>
> >> If we can't rewrite history on those branches (rebase and push -f), how
> >> should we proceed with the merge to/from master?
> >> Usually when we merge a branch to master, we rebase it on top of master
> >> first and then rebase. That's how our history remains linear and simple.
> >>
> >> What's the idea here? I wonder.
> >>
> >> Thanks for implementing this btw,
> >>
> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
> >>
> >> > I'm not sure about jenkins, that's Stefan's role.
> >> >
> >> > Anyhow, pushed the changes according to the wiki. Please consider
> >> > especially mentioning probies when you say "everyone can push to".
> >> >
> >> > --
> >> > Tom.
> >> >
> >> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
> >> >  wrote:
> >> > > I've added all the necessary info to the documentation at
> >> > >
> >>
> https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches
> >> > >
> >> > > If the jenkins concept is not possible then feel free to remove, but
> >> the
> >> > > rest should be in line with what we want.
> >> > >
> >> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen  wrote:
> >> > >
> >> > >> So what has been decided? What should I do? I need specs,
> preferably
> >> > >> already added to the git wiki page so there are docs for this
> thing.
> >> > >>
> >> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
> >> ras...@rasterman.com
> >> > >
> >> > >> wrote:
> >> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
> >> > >> >  said:
> >> > >> >
> >> > >> >> Key points for the implementation:
> >> > >> >>
> >> > >> >> * all commits send mails to the list
> >> > >> >> * no rewrite of pushed commits
> >> > >> >>
> >> > >> >> Things to consider:
> >> > >> >> * how are feature/ branches deleted?
> >> > >> >>  - maybe anyone can delete?
> >> > >> >
> >> > >> > Good point. these need deletion. after a few years it'll be a
> mess
> >> of
> >> > old
> >> > >> > feature branches no one will ever look at again. The merge to
> master
> >> > >> should
> >> > >> > contain all the history and log that is needed at that point for
> >> > history
> >> > >> > digging.
> >> > >> >
> >> > >> >> * do probies get feature/ push access?
> >> > >> >>  - seems like they should?
> >> > >> >>
> >> > >> >> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen 
> wrote:
> >> > >> >>
> >> > >> >> > Yeah, good idea.
> >> > >> >> >
> >> > >> >> > I'll take a look into implementing it soon.
> >> > >> >> >
> >> > >> >> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams <
> >> > a...@andywilliams.me
> >> > >> >
> >> > >> >> > wrote:
> >> > >> >> > > Hi,
> >> > >> >> > >
> >> > >> >> > > That sounds great - the ability to work together on features
> >> > >> off-master
> >> > >> >> > > would be really helpful.
> >> > >> >> > >
> >> > >> >> > > Andy
> >> > >> >> > >
> >> > >> >> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
> >> > >> >> > > michael.blumenkra...@gmail.com> wrote:
> >> > >> >> > >
> >> > >> >> > >> After some discussions about git organization, it's become
> >> clear
> >> > >> to me
> >> > >> >> > that
> >> > >> >> > >> we should be trying to enact some changes which facilitate
> >> > >> >> > collaboration,
> >> > >> >> > >> both between existing contributors and keeping in mind
> future
> >> > >> >> > contributors.
> >> > >> >> > >>
> >> > >> >> > >> The current git branch policy is this:
> >> > >> >> > >>
> >> > >> >> > >> * master
> >> > >> >> > >> * $project-$version
> >> > >> >> > >> * devs/$name/$branchname
> >> > >> >> > >>
> >> > >> >> > >> No others are allowed. This fits many use cases, 

[E-devel] SPDX header

[Cedric Bail]

Hi,

If you have followed the kernel development, you may have seen that they are 
prefixxing all there source code file with a SPDX comment like :

/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */

This headers help automated tool to figure out the licenses of a specific file 
and allow companies to properly act on this information. EFL has a lot of 
different licenses and it would be a very good idea to actually roll that in. 
Is anyone opposed to this being rolled in during the next few weeks ?

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

Re: [E-devel] Git Feature/ Proposal

[Tom Hacohen]

As Mike said, the rebase/sync to master is being done locally before
the merge. If you are talking about keeping this branch in sync with
master constantly while developing, yes it's a problem. But I guess
it's not intended for long term features.

On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
 wrote:
> I don't see a difference in the merge process? A feature branch should be
> treated exactly the same as master; the only difference is that it's a
> branch which people must specifically pull in order to use instead of being
> master.
>
> When merging, you can either do a regular rebase/merge as in the git
> practices documentation or you can choose to rebase/squash on the branched
> commits prior to pushing the merge. There is no rewriting within the
> branch, but you can still rewrite anything which has not been pushed to
> master just prior to pushing it to master.
>
> On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André 
> wrote:
>
>> Hey,
>>
>> If we can't rewrite history on those branches (rebase and push -f), how
>> should we proceed with the merge to/from master?
>> Usually when we merge a branch to master, we rebase it on top of master
>> first and then rebase. That's how our history remains linear and simple.
>>
>> What's the idea here? I wonder.
>>
>> Thanks for implementing this btw,
>>
>> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
>>
>> > I'm not sure about jenkins, that's Stefan's role.
>> >
>> > Anyhow, pushed the changes according to the wiki. Please consider
>> > especially mentioning probies when you say "everyone can push to".
>> >
>> > --
>> > Tom.
>> >
>> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
>> >  wrote:
>> > > I've added all the necessary info to the documentation at
>> > >
>> https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches
>> > >
>> > > If the jenkins concept is not possible then feel free to remove, but
>> the
>> > > rest should be in line with what we want.
>> > >
>> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen  wrote:
>> > >
>> > >> So what has been decided? What should I do? I need specs, preferably
>> > >> already added to the git wiki page so there are docs for this thing.
>> > >>
>> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
>> ras...@rasterman.com
>> > >
>> > >> wrote:
>> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
>> > >> >  said:
>> > >> >
>> > >> >> Key points for the implementation:
>> > >> >>
>> > >> >> * all commits send mails to the list
>> > >> >> * no rewrite of pushed commits
>> > >> >>
>> > >> >> Things to consider:
>> > >> >> * how are feature/ branches deleted?
>> > >> >>  - maybe anyone can delete?
>> > >> >
>> > >> > Good point. these need deletion. after a few years it'll be a mess
>> of
>> > old
>> > >> > feature branches no one will ever look at again. The merge to master
>> > >> should
>> > >> > contain all the history and log that is needed at that point for
>> > history
>> > >> > digging.
>> > >> >
>> > >> >> * do probies get feature/ push access?
>> > >> >>  - seems like they should?
>> > >> >>
>> > >> >> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen  wrote:
>> > >> >>
>> > >> >> > Yeah, good idea.
>> > >> >> >
>> > >> >> > I'll take a look into implementing it soon.
>> > >> >> >
>> > >> >> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams <
>> > a...@andywilliams.me
>> > >> >
>> > >> >> > wrote:
>> > >> >> > > Hi,
>> > >> >> > >
>> > >> >> > > That sounds great - the ability to work together on features
>> > >> off-master
>> > >> >> > > would be really helpful.
>> > >> >> > >
>> > >> >> > > Andy
>> > >> >> > >
>> > >> >> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
>> > >> >> > > michael.blumenkra...@gmail.com> wrote:
>> > >> >> > >
>> > >> >> > >> After some discussions about git organization, it's become
>> clear
>> > >> to me
>> > >> >> > that
>> > >> >> > >> we should be trying to enact some changes which facilitate
>> > >> >> > collaboration,
>> > >> >> > >> both between existing contributors and keeping in mind future
>> > >> >> > contributors.
>> > >> >> > >>
>> > >> >> > >> The current git branch policy is this:
>> > >> >> > >>
>> > >> >> > >> * master
>> > >> >> > >> * $project-$version
>> > >> >> > >> * devs/$name/$branchname
>> > >> >> > >>
>> > >> >> > >> No others are allowed. This fits many use cases, but it does
>> not
>> > >> >> > actually
>> > >> >> > >> help us work towards collaborating on features/patchsets and
>> > >> instead
>> > >> >> > >> promotes developing in isolation.
>> > >> >> > >>
>> > >> >> > >> A simple proposal could improve this without requiring or
>> > >> significantly
>> > >> >> > >> changing our workflow: add "feature/" branches. For example,
>> if
>> > >> Cedric
>> > >> >> > and
>> > >> >> > >> I decide to work on a "feature" which scrapes the archive of
>> > this
>> > >> >> 

Re: [E-devel] [EGIT] [core/efl] master 01/01: ecore: reformat ecore_exe_posix.c

[Mike Blumenkrantz]

This is what a commit from a feature branch looks like once it gets merged
to master.

On Tue, Nov 21, 2017 at 12:31 PM Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:

> discomfitor pushed a commit to branch master.
>
>
> http://git.enlightenment.org/core/efl.git/commit/?id=7cdbe6e029be7fe5db0d12b8af1e17101692943f
>
> commit 7cdbe6e029be7fe5db0d12b8af1e17101692943f
> Author: Mike Blumenkrantz 
> Date:   Tue Nov 21 12:24:51 2017 -0500
>
> ecore: reformat ecore_exe_posix.c
> ---
>  src/lib/ecore/ecore_exe_posix.c | 1413
> ---
>  1 file changed, 708 insertions(+), 705 deletions(-)
>
>
--
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] feature/ecore_exe_formatting 01/01: ecore: reformat ecore_exe_posix.c

[Mike Blumenkrantz]

This is what a commit to a feature branch will look like publicly. It gets
treated the same as a commit to master for mails here and can be reviewed
the same as any other commit.

On Tue, Nov 21, 2017 at 12:26 PM Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:

> discomfitor pushed a commit to branch feature/ecore_exe_formatting.
>
>
> http://git.enlightenment.org/core/efl.git/commit/?id=a0a9468f4c1624b5e73e42f5012f01e921d6f80f
>
> commit a0a9468f4c1624b5e73e42f5012f01e921d6f80f
> Author: Mike Blumenkrantz 
> Date:   Tue Nov 21 12:24:51 2017 -0500
>
> ecore: reformat ecore_exe_posix.c
> ---
>  src/lib/ecore/ecore_exe_posix.c | 1413
> ---
>  1 file changed, 708 insertions(+), 705 deletions(-)
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Eo API docs: Large inheritance content

[Andrew Williams]

Hi team,

Looking at some of our larger inheritance trees, such as
https://www.enlightenment.org/develop/api/class/efl/ui/clock , may provide
only 8 members but the page runs to hundreds of items - a complete bed time
read in itself. I think for the sanity of our readers it would be good to
list the members it inherits in short hand. Like the somewhat standardised
JavaDoc output -
https://docs.oracle.com/javase/7/docs/api/java/io/OutputStreamWriter.html

Additionally the complete heirarchy tree at the top of each page takes a
lot of space and repeats a lot - it would make sense to flatten this to a
list.

Are there any objections to these changes?

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

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon

[Mike Blumenkrantz]

The wording is intentional. The meson build has a tendency to touch build
files during the install phase (which must be run as root to install to the
base system), meaning that failure to use sudo during general build will
fail for subsequent builds anyway due to permissions errors when attempting
to modify root-owned files.

On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler 
wrote:

> On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz
>  said:
>
> > Issues had been found at an inconvenient time during review, so I left
> the
> > branch unmerged so that someone could either push while I was gone or I
> > could push when I returned.
>
> I saw you pushed now. so we know the status. This also clears up the build
> system state. I guess I should ensure it's documented. I see README
> changed but
> i am not sure it's correct as it's going to do a build as root... i'll deal
> with it. :)
>
> > On Sun, Nov 19, 2017 at 6:56 PM Carsten Haitzler 
> > wrote:
> >
> > > On Sun, 19 Nov 2017 13:05:06 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > Hi,
> > > >
> > > > As the autotool/Makefiles are still in place I fixed the build for
> users
> > > > not yet using the E meson build.
> > >
> > > i was assuming autotools was dead - mike did say he'd push his
> autotools
> > > removal branch "in a day or 2 if no issues"... that about 1-2 weeks
> back. i
> > > didn't see it happen and didn't hear of issues...
> > >
> > > are there any? I'd consider merging his branch to remove autofoo at
> this
> > > point.
> > > If meson has issues it should be tested and they should be fixed.
> > >
> > > > Andy
> > > >
> > > > On Fri, 17 Nov 2017 at 03:19 Carsten Haitzler 
> > > wrote:
> > > >
> > > > > raster pushed a commit to branch master.
> > > > >
> > > > >
> > > > >
> > >
> http://git.enlightenment.org/core/enlightenment.git/commit/?id=f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > > >
> > > > > commit f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > > > Author: Carsten Haitzler (Rasterman) 
> > > > > Date:   Fri Nov 17 12:17:42 2017 +0900
> > > > >
> > > > > music-control - install properly with meson build with icon
> > > > >
> > > > > @fix
> > > > > ---
> > > > >  ...-module-music_control.edj => e-module-music-control.edj} | Bin
> > > > >  src/modules/music-control/meson.build   |   2
> --
> > > > >  src/modules/music-control/module.desktop|   2
> +-
> > > > >  3 files changed, 1 insertion(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/src/modules/music-control/e-module-music_control.edj
> > > > > b/src/modules/music-control/e-module-music-control.edj
> > > > > similarity index 100%
> > > > > rename from src/modules/music-control/e-module-music_control.edj
> > > > > rename to src/modules/music-control/e-module-music-control.edj
> > > > > diff --git a/src/modules/music-control/meson.build
> > > > > b/src/modules/music-control/meson.build
> > > > > index 996b4196f..a84f5ea8e 100644
> > > > > --- a/src/modules/music-control/meson.build
> > > > > +++ b/src/modules/music-control/meson.build
> > > > > @@ -18,5 +18,3 @@ src += custom_target('gen-dbus',
> > > > >   command: [eldbus_codegen, '@INPUT@', '-O',
> > > '@OUTDIR@
> > > > > '],
> > > > >   output : created_file
> > > > >  )
> > > > > -
> > > > > -no_icon = true
> > > > > diff --git a/src/modules/music-control/module.desktop
> > > > > b/src/modules/music-control/module.desktop
> > > > > index 99a2d9143..2e12677e3 100644
> > > > > --- a/src/modules/music-control/module.desktop
> > > > > +++ b/src/modules/music-control/module.desktop
> > > > > @@ -27,5 +27,5 @@ Comment[nl]=Beheers uw muziek op uw plank
> > > > >  Comment[ru]=Модуль для управления воспроизведением музыки
> > > > >  Comment[sr]=Управљајте музиком са полице
> > > > >  Comment[tr]=Müziğinizi rafta kontrol edin
> > > > > -Icon=e-module-music_control
> > > > > +Icon=e-module-music-control
> > > > >  X-Enlightenment-ModuleType=utils
> > > > >
> > > > > --
> > > > >
> > > > >
> > > > > --
> > > > 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
> > >
> > >
> > >
> > >
> --
> > > Check out the vibrant 

Re: [E-devel] Git Feature/ Proposal

[Mike Blumenkrantz]

I don't see a difference in the merge process? A feature branch should be
treated exactly the same as master; the only difference is that it's a
branch which people must specifically pull in order to use instead of being
master.

When merging, you can either do a regular rebase/merge as in the git
practices documentation or you can choose to rebase/squash on the branched
commits prior to pushing the merge. There is no rewriting within the
branch, but you can still rewrite anything which has not been pushed to
master just prior to pushing it to master.

On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André 
wrote:

> Hey,
>
> If we can't rewrite history on those branches (rebase and push -f), how
> should we proceed with the merge to/from master?
> Usually when we merge a branch to master, we rebase it on top of master
> first and then rebase. That's how our history remains linear and simple.
>
> What's the idea here? I wonder.
>
> Thanks for implementing this btw,
>
> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
>
> > I'm not sure about jenkins, that's Stefan's role.
> >
> > Anyhow, pushed the changes according to the wiki. Please consider
> > especially mentioning probies when you say "everyone can push to".
> >
> > --
> > Tom.
> >
> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
> >  wrote:
> > > I've added all the necessary info to the documentation at
> > >
> https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches
> > >
> > > If the jenkins concept is not possible then feel free to remove, but
> the
> > > rest should be in line with what we want.
> > >
> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen  wrote:
> > >
> > >> So what has been decided? What should I do? I need specs, preferably
> > >> already added to the git wiki page so there are docs for this thing.
> > >>
> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
> ras...@rasterman.com
> > >
> > >> wrote:
> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
> > >> >  said:
> > >> >
> > >> >> Key points for the implementation:
> > >> >>
> > >> >> * all commits send mails to the list
> > >> >> * no rewrite of pushed commits
> > >> >>
> > >> >> Things to consider:
> > >> >> * how are feature/ branches deleted?
> > >> >>  - maybe anyone can delete?
> > >> >
> > >> > Good point. these need deletion. after a few years it'll be a mess
> of
> > old
> > >> > feature branches no one will ever look at again. The merge to master
> > >> should
> > >> > contain all the history and log that is needed at that point for
> > history
> > >> > digging.
> > >> >
> > >> >> * do probies get feature/ push access?
> > >> >>  - seems like they should?
> > >> >>
> > >> >> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen  wrote:
> > >> >>
> > >> >> > Yeah, good idea.
> > >> >> >
> > >> >> > I'll take a look into implementing it soon.
> > >> >> >
> > >> >> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams <
> > a...@andywilliams.me
> > >> >
> > >> >> > wrote:
> > >> >> > > Hi,
> > >> >> > >
> > >> >> > > That sounds great - the ability to work together on features
> > >> off-master
> > >> >> > > would be really helpful.
> > >> >> > >
> > >> >> > > Andy
> > >> >> > >
> > >> >> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
> > >> >> > > michael.blumenkra...@gmail.com> wrote:
> > >> >> > >
> > >> >> > >> After some discussions about git organization, it's become
> clear
> > >> to me
> > >> >> > that
> > >> >> > >> we should be trying to enact some changes which facilitate
> > >> >> > collaboration,
> > >> >> > >> both between existing contributors and keeping in mind future
> > >> >> > contributors.
> > >> >> > >>
> > >> >> > >> The current git branch policy is this:
> > >> >> > >>
> > >> >> > >> * master
> > >> >> > >> * $project-$version
> > >> >> > >> * devs/$name/$branchname
> > >> >> > >>
> > >> >> > >> No others are allowed. This fits many use cases, but it does
> not
> > >> >> > actually
> > >> >> > >> help us work towards collaborating on features/patchsets and
> > >> instead
> > >> >> > >> promotes developing in isolation.
> > >> >> > >>
> > >> >> > >> A simple proposal could improve this without requiring or
> > >> significantly
> > >> >> > >> changing our workflow: add "feature/" branches. For example,
> if
> > >> Cedric
> > >> >> > and
> > >> >> > >> I decide to work on a "feature" which scrapes the archive of
> > this
> > >> >> > mailing
> > >> >> > >> list and then crashes the session of anyone who replies to
> this
> > >> thread,
> > >> >> > we
> > >> >> > >> might jointly create a branch named
> "feature/discussion_helper"
> > >> and push
> > >> >> > >> commits to it.
> > >> >> > >>
> > >> >> > >> A key point of this proposal would be that the feature/
> branches
> > >> must
> > >> >> > >> trigger mails to the mailing list just like stable branches.
> > This
> > >> would
> > >> >> > >> increase 

Re: [E-devel] Weekly news from the automated build and QA front

[Stefan Schmidt]

Hello.


On 11/21/2017 12:29 PM, Andrew Williams wrote:
> Hi Stefan,
>
> Thanks for this. The 5 -> 21% build failures is the biggest jump by far, so
> we have a commentary on the cause/issue here?
>
Yeah, I should have commented on that. Its basically due to one of the slave 
being down sometimes.
Not really something on the efl code site being a problem.

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

Re: [E-devel] Weekly news from the automated build and QA front

[Andrew Williams]

Hi Stefan,

Thanks for this. The 5 -> 21% build failures is the biggest jump by far, so
we have a commentary on the cause/issue here?

Thanks,
Andy
On Tue, 21 Nov 2017 at 10:52, Stefan Schmidt  wrote:

> Hello.
>
> Summary:
> o Been a long time since the last report. But I am back now and should run
> this regularly again.
>
>
> This should give everyone an overview over what has happened in the last
> week on the QA front. The numbers in parentheses reflect the values from
> last week to give you a trend.
>
> CI:
> o Overall build statistic: 21.07% (5.84%) failed.
> https://build.enlightenment.org/
>
> Unit tests:
> o N/A (N/A) unit tests for efl
>
> Coverage:
> o EFL total coverage is at 27.9% (N/A%) lines, 31.9% (N/A%) functions and
> N/A (N/A) branches
> https://build.enlightenment.org/view/Test%20Coverage/
>
> Coverity:
> o EFL: Outstanding defects 47 (44) with a density of 0.04 (0.04)
> o Enlightenment: Outstanding defects 0 (0) with a density of 0 (0)
> o Terminology: Outstanding defects 0 (0) with a density of 0 (0)
> o Rage: Outstanding defects 2 (2) with a density of 0.04 (0.04)
>
> Phab:
> o EFL bug count: 532 (460)
> o E bug count: 346 (333)
> https://phab.enlightenment.org/maniphest/report/burn/
> o Pending patch reviews: 197 (208)
>
> regards
> Stefan Schmidt
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
-- 
http://andywilliams.me
http://ajwillia.ms
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Weekly news from the automated build and QA front

[Stefan Schmidt]

Hello.

Summary:
o Been a long time since the last report. But I am back now and should run this 
regularly again.


This should give everyone an overview over what has happened in the last
week on the QA front. The numbers in parentheses reflect the values from
last week to give you a trend.

CI:
o Overall build statistic: 21.07% (5.84%) failed.
https://build.enlightenment.org/

Unit tests:
o N/A (N/A) unit tests for efl

Coverage:
o EFL total coverage is at 27.9% (N/A%) lines, 31.9% (N/A%) functions and N/A 
(N/A) branches
https://build.enlightenment.org/view/Test%20Coverage/

Coverity:
o EFL: Outstanding defects 47 (44) with a density of 0.04 (0.04)
o Enlightenment: Outstanding defects 0 (0) with a density of 0 (0)
o Terminology: Outstanding defects 0 (0) with a density of 0 (0)
o Rage: Outstanding defects 2 (2) with a density of 0.04 (0.04)

Phab:
o EFL bug count: 532 (460)
o E bug count: 346 (333)
https://phab.enlightenment.org/maniphest/report/burn/
o Pending patch reviews: 197 (208)

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