Re: [E-devel] Website Table of Contents

2017-11-07 Thread Carsten Haitzler
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. :)

Re: [E-devel] efl_refcount_get

2017-11-07 Thread Carsten Haitzler
On Tue, 07 Nov 2017 14:18:04 + Andrew Williams said: > Hi, > > Indeed on later reading I see it was lacking in detail so I followed up > later. > > It’s unclear if, following rasters last email, he is still in agreement > with the _count() change but it seems like an

Re: [E-devel] Git Feature/ Proposal

2017-11-07 Thread Andrew Williams
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

Re: [E-devel] Git Feature/ Proposal

2017-11-07 Thread Christopher Michael
On 11/07/2017 01:10 PM, Cedric Bail wrote: Hi, Original Message Subject: [E-devel] Git Feature/ Proposal Local Time: November 7, 2017 8:13 AM UTC Time: November 7, 2017 4:13 PM From: michael.blumenkra...@gmail.com To: Enlightenment developer list

Re: [E-devel] Git Feature/ Proposal

2017-11-07 Thread Cedric Bail
Hi, > Original Message > Subject: [E-devel] Git Feature/ Proposal > Local Time: November 7, 2017 8:13 AM > UTC Time: November 7, 2017 4:13 PM > From: michael.blumenkra...@gmail.com > To: Enlightenment developer list > > After some

Re: [E-devel] Autotools removal

2017-11-07 Thread Mike Blumenkrantz
I've pushed an autotools_removal branch which should successfully remove all the appropriate files. If there are no issues reported with it within a day or two then I will merge. On Mon, Nov 6, 2017 at 5:35 PM Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > Tremendous, I'll execute

[E-devel] Git Feature/ Proposal

2017-11-07 Thread Mike Blumenkrantz
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 *

Re: [E-devel] Website Table of Contents

2017-11-07 Thread Andrew Williams
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. Additionally of concern is that many of our pages (specifically the program guide) have (manually entered) contents areas that are within the

Re: [E-devel] efl_refcount_get

2017-11-07 Thread Andrew Williams
Hi, Indeed on later reading I see it was lacking in detail so I followed up later. It’s unclear if, following rasters last email, he is still in agreement with the _count() change but it seems like an improvement so I intend to go forward with it as discussed. Thanks, Andy On Tue, 7 Nov 2017 at

Re: [E-devel] efl_refcount_get

2017-11-07 Thread Mike Blumenkrantz
In this case I would agree with raster; the original mail could have provided a little more detail because it is non-obvious to the reader why this could be misleading for users. efl_ref_count() is in line with the rest of our naming (e.g., eina_array_count(), eina_list_count(),

Re: [E-devel] Website Table of Contents

2017-11-07 Thread Carsten Haitzler
On Mon, 06 Nov 2017 18:47:45 + Andrew Williams 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

Re: [E-devel] efl_refcount_get

2017-11-07 Thread Carsten Haitzler
On Mon, 06 Nov 2017 09:53:32 + Andrew Williams said: > Can you please explain why? This is a method that returns a count of > references but has no mention of count in the name. Well your original email gave no details as to why it's misleading. I disagree because i

Re: [E-devel] OS X build error

2017-11-07 Thread Jean-Philippe André
The difference between my build (Linux) and OSX seems to be the presence or not of cserve2 which lead to the inclusion of all of evas private headers, thus LKI() was well defined (and LKD, etc... were defined multiple times). 2017-11-07 20:22 GMT+09:00 Jean-Philippe André : >

Re: [E-devel] OS X build error

2017-11-07 Thread Jean-Philippe André
2017-11-07 20:20 GMT+09:00 Carsten Haitzler : > On Tue, 07 Nov 2017 09:08:04 + Andrew Williams > said: > > > Hi, > > > > It got us much closer - it now fails with the following: > > > > CXXLDlib/evas/libevas.la > > > > Undefined symbols for

Re: [E-devel] OS X build error

2017-11-07 Thread Carsten Haitzler
On Tue, 07 Nov 2017 09:08:04 + Andrew Williams said: > Hi, > > It got us much closer - it now fails with the following: > > CXXLDlib/evas/libevas.la > > Undefined symbols for architecture x86_64: > > "_LKI", referenced from: > >

Re: [E-devel] efl_refcount_get

2017-11-07 Thread Andrew Williams
Hi all, After a chat on IRC we settled on efl_ref_count( Unless anyone comes up with reasons not to I will apply this change later today. Andy On Mon, 6 Nov 2017 at 09:53 Andrew Williams wrote: > Can you please explain why? This is a method that returns a count of >

Re: [E-devel] OS X build error

2017-11-07 Thread Andrew Williams
Hi, It got us much closer - it now fails with the following: CXXLDlib/evas/libevas.la Undefined symbols for architecture x86_64: "_LKI", referenced from: __evas_common_font_int_cache_init in lib_evas_libevas_la-evas_font_load.o _evas_common_font_memory_load in