Re: [E-devel] Website Table of Contents

[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. :) 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 
> > 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 spend
> > unlimited
> > time on doing the www layout, design and content so I had to make
> > compromises
> > of work vs result. If i could get css/whatever to columnize layout somehow
> > nicely across multiple screen sizes/types in dokuwiki it may have been a
> > better
> > solution. But time and effort.
> >
> > Anyway - that's why i did it and what i think about the TOC thing.
> >
> > > Frustratingly it's a global config, though it can be turned off on a
> > > per-page basis. We can tweak what is included (again globally) but I
> > > thought I would get a feeling for whether anyone felt strongly about this
> >
> > That was part of the issue and why I just turned it off as I thought it was
> > more pain than good (as above) for much of the site. I generally think if
> > your
> > page is so long you need a TOC... perhaps you should split it up into
> > multiple
> > pages? :)
> >
> > My thoughts on it anyway...
> >
> > > 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
> >
> > --
> 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 

Re: [E-devel] efl_refcount_get

[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 improvement so I intend to go
> forward with it as discussed.

i'm fine with it. i was just explaining why i disagreed in detail about it
being misleading. :)

> Thanks,
> Andy
> On Tue, 7 Nov 2017 at 13:57, Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
> 
> > 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(), eina_hash_population(), etc) and
> > seems like a clear improvement. Nice work.
> >
> > On Tue, Nov 7, 2017 at 7:41 AM Carsten Haitzler 
> > wrote:
> >
> > > 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 see something like:
> > >
> > > Eo   *efl_ref(Eo *obj);
> > > int   efl_ref_get(Eo *obj);
> > > void  efl_unref(Eo *obj);
> > > ...
> > >
> > > i.e. the context of the api, and to me it screams of "ref is reference or
> > > references" and since there is something to ref and unref already ref_get
> > > returning an int obviously is returning a reference count (to me). since
> > > i'm
> > > familiar with reference counting techniques in general (nothing to do
> > with
> > > the
> > > code implementation or api here), to me it's obvious that this returns
> > the
> > > reference count (an integer) and it's short form for that.
> > >
> > > if i saw this api in glib or gtk or libjpeg or libpng or zlib or any
> > other
> > > library i'd think the same with zero documentation and just api
> > signatures
> > > like
> > > the above.
> > >
> > > i've learned api's by just reading .h files (like xlib) and seeing this
> > and
> > > taking a guess as to what it means. an int generally to me indicates it's
> > > returning a number as opposed to something opaque in higher level libs
> > like
> > > efl/gtk etc.. it has meaning. libc calls return ints and are different as
> > > they
> > > tend to mean an error or success, but look at glib or gtk or others and
> > > they
> > > dont do this and efl doesn't do the libc thing either as a whole.
> > >
> > > so given the context as a whole and as a sub-part of the api like
> > above...
> > > i
> > > disagree that its misleading. to me its pretty obvious. maybe because
> > i've
> > > spent a lot of time with various api's and so on i tend to fill in the
> > > blanks
> > > quickly seeing this kind of information. i don't know.
> > >
> > > but if you think it's misleading can you give more information? why is it
> > > misleading? what is it leading you to think it is and why is that? what
> > is
> > > the
> > > difference in view point or experience and how conclusions are being
> > > attained?
> > >
> > > > We have ref_add and wref_add that are talking about actual references
> > but
> > > > ref_get returns a count?
> > > > This is misleading.
> > > >
> > > > Andy
> > > >
> > > > On Mon, 6 Nov 2017 at 09:49 Carsten Haitzler 
> > > wrote:
> > > >
> > > > > On Mon, 06 Nov 2017 09:46:41 + Andrew Williams <
> > > a...@andywilliams.me>
> > > > > said:
> > > > >
> > > > > i'd have to disagree on it being misleading... :/
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Whilst writing the docs we have realised that efl_ref_get is a
> > > slightly
> > > > > > misleading method name as it returns the reference count. Whilst we
> > > are
> > > > > > breaking APIs for our first interfaces release would people mind me
> > > > > > changing efl_ref_get to efl_refcount_get (as per this eo patch, and
> > > all
> > > > > the
> > > > > > efl ramifications).
> > > > > >
> > > > > > I'd prefer not to leave the old method in place but could do so if
> > > you
> > > > > > think there is a big problem making this breaking change?
> > > > > >
> > > > > > Thanks :)
> > > > > > Andy
> > > > > >
> > > > > >
> > > > > > --
> > > > > > http://andywilliams.me
> > > > > > http://ajwillia.ms
> > > > >
> > > > >
> > > > > --
> > > > > - Codito, ergo sum - "I code, therefore I am"
> > > --
> > > > > Carsten Haitzler - ras...@rasterman.com
> > > > >
> > > > > --
> > > > http://andywilliams.me
> > > > http://ajwillia.ms
> > > >
> > >
> > --
> > > > Check out the vibrant tech community on one of the world's most
> > > 

Re: [E-devel] Git Feature/ Proposal

[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 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 visibility for feature branches as well as promote further
> collaboration even from those who are not directly involved in creating the
> feature. The initial feature development could be done in a dev/ branch,
> and then it could later move to a feature/ branch once it has progressed to
> the point where it is ready for public visibility and increased
> collaboration.
>
> Lastly, feature branches would not be required use, just encouraged. This
> allows people to continue the current EFL standard of always committing
> only to master without any prior testing or branching, the need for which
> has defeated other proposals which would prevent such action.
>
> I think this could yield significant improvements to the community's
> overall workflow without massively changing the structure under which the
> everyone has been functioning.
>
> --
> 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

Re: [E-devel] Git Feature/ Proposal

[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 

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.


Is the session crashing the part you like Cedric ?? ;)



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 visibility for feature branches as well as promote further
collaboration even from those who are not directly involved in creating the
feature. The initial feature development could be done in a dev/ branch,
and then it could later move to a feature/ branch once it has progressed to
the point where it is ready for public visibility and increased
collaboration.

Lastly, feature branches would not be required use, just encouraged. This
allows people to continue the current EFL standard of always committing
only to master without any prior testing or branching, the need for which
has defeated other proposals which would prevent such action.

I think this could yield significant improvements to the community's
overall workflow without massively changing the structure under which the
everyone has been functioning.


I like this proposal as it should help team work. Good idea.

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

[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 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 visibility for feature branches as well as promote further
> collaboration even from those who are not directly involved in creating the
> feature. The initial feature development could be done in a dev/ branch,
> and then it could later move to a feature/ branch once it has progressed to
> the point where it is ready for public visibility and increased
> collaboration.
>
> Lastly, feature branches would not be required use, just encouraged. This
> allows people to continue the current EFL standard of always committing
> only to master without any prior testing or branching, the need for which
> has defeated other proposals which would prevent such action.
>
> I think this could yield significant improvements to the community's
> overall workflow without massively changing the structure under which the
> everyone has been functioning.

I like this proposal as it should help team work. Good idea.

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] Autotools removal

[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 the removal within the next couple days.
>
> On Mon, Nov 6, 2017 at 4:43 PM Simon Lees  wrote:
>
>>
>>
>> On 07/11/17 05:57, Ross Vandegrift wrote:
>> > On Mon, Nov 06, 2017 at 01:26:02PM +, Mike Blumenkrantz wrote:
>> >> I'd rather not start creating meta build systems that we then need to
>> track
>> >> and maintain. I will temporarily add a tarball for meson 0.39 until
>> Debian
>> >> decides to do an update for the package.
>> >
>> > I wouldn't bother - there's already a backport of meson 0.42 available
>> > for current Debian stable.  It'd be reasonable to require that the user
>> > installs that version first.
>> >
>> > Debian unstable has meson 0.43, so all is good there.
>> >
>> > Ross
>> >
>>
>> Yeah if its available in backports that seems reasonable enough for me.
>>
>> --
>>
>> 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
>>
>>
>> --
>> 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

[E-devel] Git Feature/ Proposal

[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
* 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 visibility for feature branches as well as promote further
collaboration even from those who are not directly involved in creating the
feature. The initial feature development could be done in a dev/ branch,
and then it could later move to a feature/ branch once it has progressed to
the point where it is ready for public visibility and increased
collaboration.

Lastly, feature branches would not be required use, just encouraged. This
allows people to continue the current EFL standard of always committing
only to master without any prior testing or branching, the need for which
has defeated other proposals which would prevent such action.

I think this could yield significant improvements to the community's
overall workflow without massively changing the structure under which the
everyone has been functioning.
--
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] Website Table of Contents

[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 page
content.
https://www.enlightenment.org/develop/legacy/program_guide/eina/arrays

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

Thanks,
Andrew

On Tue, 7 Nov 2017 at 12:51 Carsten Haitzler  wrote:

> 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 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 spend
> unlimited
> time on doing the www layout, design and content so I had to make
> compromises
> of work vs result. If i could get css/whatever to columnize layout somehow
> nicely across multiple screen sizes/types in dokuwiki it may have been a
> better
> solution. But time and effort.
>
> Anyway - that's why i did it and what i think about the TOC thing.
>
> > Frustratingly it's a global config, though it can be turned off on a
> > per-page basis. We can tweak what is included (again globally) but I
> > thought I would get a feeling for whether anyone felt strongly about this
>
> That was part of the issue and why I just turned it off as I thought it was
> more pain than good (as above) for much of the site. I generally think if
> your
> page is so long you need a TOC... perhaps you should split it up into
> multiple
> pages? :)
>
> My thoughts on it anyway...
>
> > 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
>
> --
http://andywilliams.me
http://ajwillia.ms
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] efl_refcount_get

[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 13:57, Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:

> 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(), eina_hash_population(), etc) and
> seems like a clear improvement. Nice work.
>
> On Tue, Nov 7, 2017 at 7:41 AM Carsten Haitzler 
> wrote:
>
> > 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 see something like:
> >
> > Eo   *efl_ref(Eo *obj);
> > int   efl_ref_get(Eo *obj);
> > void  efl_unref(Eo *obj);
> > ...
> >
> > i.e. the context of the api, and to me it screams of "ref is reference or
> > references" and since there is something to ref and unref already ref_get
> > returning an int obviously is returning a reference count (to me). since
> > i'm
> > familiar with reference counting techniques in general (nothing to do
> with
> > the
> > code implementation or api here), to me it's obvious that this returns
> the
> > reference count (an integer) and it's short form for that.
> >
> > if i saw this api in glib or gtk or libjpeg or libpng or zlib or any
> other
> > library i'd think the same with zero documentation and just api
> signatures
> > like
> > the above.
> >
> > i've learned api's by just reading .h files (like xlib) and seeing this
> and
> > taking a guess as to what it means. an int generally to me indicates it's
> > returning a number as opposed to something opaque in higher level libs
> like
> > efl/gtk etc.. it has meaning. libc calls return ints and are different as
> > they
> > tend to mean an error or success, but look at glib or gtk or others and
> > they
> > dont do this and efl doesn't do the libc thing either as a whole.
> >
> > so given the context as a whole and as a sub-part of the api like
> above...
> > i
> > disagree that its misleading. to me its pretty obvious. maybe because
> i've
> > spent a lot of time with various api's and so on i tend to fill in the
> > blanks
> > quickly seeing this kind of information. i don't know.
> >
> > but if you think it's misleading can you give more information? why is it
> > misleading? what is it leading you to think it is and why is that? what
> is
> > the
> > difference in view point or experience and how conclusions are being
> > attained?
> >
> > > We have ref_add and wref_add that are talking about actual references
> but
> > > ref_get returns a count?
> > > This is misleading.
> > >
> > > Andy
> > >
> > > On Mon, 6 Nov 2017 at 09:49 Carsten Haitzler 
> > wrote:
> > >
> > > > On Mon, 06 Nov 2017 09:46:41 + Andrew Williams <
> > a...@andywilliams.me>
> > > > said:
> > > >
> > > > i'd have to disagree on it being misleading... :/
> > > >
> > > > > Hi,
> > > > >
> > > > > Whilst writing the docs we have realised that efl_ref_get is a
> > slightly
> > > > > misleading method name as it returns the reference count. Whilst we
> > are
> > > > > breaking APIs for our first interfaces release would people mind me
> > > > > changing efl_ref_get to efl_refcount_get (as per this eo patch, and
> > all
> > > > the
> > > > > efl ramifications).
> > > > >
> > > > > I'd prefer not to leave the old method in place but could do so if
> > you
> > > > > think there is a big problem making this breaking change?
> > > > >
> > > > > Thanks :)
> > > > > Andy
> > > > >
> > > > >
> > > > > --
> > > > > http://andywilliams.me
> > > > > http://ajwillia.ms
> > > >
> > > >
> > > > --
> > > > - Codito, ergo sum - "I code, therefore I am"
> > --
> > > > Carsten Haitzler - ras...@rasterman.com
> > > >
> > > > --
> > > 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
> >
> >
> >
> >
> 

Re: [E-devel] efl_refcount_get

[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(), eina_hash_population(), etc) and
seems like a clear improvement. Nice work.

On Tue, Nov 7, 2017 at 7:41 AM Carsten Haitzler 
wrote:

> 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 see something like:
>
> Eo   *efl_ref(Eo *obj);
> int   efl_ref_get(Eo *obj);
> void  efl_unref(Eo *obj);
> ...
>
> i.e. the context of the api, and to me it screams of "ref is reference or
> references" and since there is something to ref and unref already ref_get
> returning an int obviously is returning a reference count (to me). since
> i'm
> familiar with reference counting techniques in general (nothing to do with
> the
> code implementation or api here), to me it's obvious that this returns the
> reference count (an integer) and it's short form for that.
>
> if i saw this api in glib or gtk or libjpeg or libpng or zlib or any other
> library i'd think the same with zero documentation and just api signatures
> like
> the above.
>
> i've learned api's by just reading .h files (like xlib) and seeing this and
> taking a guess as to what it means. an int generally to me indicates it's
> returning a number as opposed to something opaque in higher level libs like
> efl/gtk etc.. it has meaning. libc calls return ints and are different as
> they
> tend to mean an error or success, but look at glib or gtk or others and
> they
> dont do this and efl doesn't do the libc thing either as a whole.
>
> so given the context as a whole and as a sub-part of the api like above...
> i
> disagree that its misleading. to me its pretty obvious. maybe because i've
> spent a lot of time with various api's and so on i tend to fill in the
> blanks
> quickly seeing this kind of information. i don't know.
>
> but if you think it's misleading can you give more information? why is it
> misleading? what is it leading you to think it is and why is that? what is
> the
> difference in view point or experience and how conclusions are being
> attained?
>
> > We have ref_add and wref_add that are talking about actual references but
> > ref_get returns a count?
> > This is misleading.
> >
> > Andy
> >
> > On Mon, 6 Nov 2017 at 09:49 Carsten Haitzler 
> wrote:
> >
> > > On Mon, 06 Nov 2017 09:46:41 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > i'd have to disagree on it being misleading... :/
> > >
> > > > Hi,
> > > >
> > > > Whilst writing the docs we have realised that efl_ref_get is a
> slightly
> > > > misleading method name as it returns the reference count. Whilst we
> are
> > > > breaking APIs for our first interfaces release would people mind me
> > > > changing efl_ref_get to efl_refcount_get (as per this eo patch, and
> all
> > > the
> > > > efl ramifications).
> > > >
> > > > I'd prefer not to leave the old method in place but could do so if
> you
> > > > think there is a big problem making this breaking change?
> > > >
> > > > Thanks :)
> > > > Andy
> > > >
> > > >
> > > > --
> > > > http://andywilliams.me
> > > > http://ajwillia.ms
> > >
> > >
> > > --
> > > - Codito, ergo sum - "I code, therefore I am"
> --
> > > Carsten Haitzler - ras...@rasterman.com
> > >
> > > --
> > 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
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___

Re: [E-devel] Website Table of Contents

[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 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 spend unlimited
time on doing the www layout, design and content so I had to make compromises
of work vs result. If i could get css/whatever to columnize layout somehow
nicely across multiple screen sizes/types in dokuwiki it may have been a better
solution. But time and effort.

Anyway - that's why i did it and what i think about the TOC thing.

> Frustratingly it's a global config, though it can be turned off on a
> per-page basis. We can tweak what is included (again globally) but I
> thought I would get a feeling for whether anyone felt strongly about this

That was part of the issue and why I just turned it off as I thought it was
more pain than good (as above) for much of the site. I generally think if your
page is so long you need a TOC... perhaps you should split it up into multiple
pages? :)

My thoughts on it anyway...

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

[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 see something like:

Eo   *efl_ref(Eo *obj);
int   efl_ref_get(Eo *obj);
void  efl_unref(Eo *obj);
...

i.e. the context of the api, and to me it screams of "ref is reference or
references" and since there is something to ref and unref already ref_get
returning an int obviously is returning a reference count (to me). since i'm
familiar with reference counting techniques in general (nothing to do with the
code implementation or api here), to me it's obvious that this returns the
reference count (an integer) and it's short form for that.

if i saw this api in glib or gtk or libjpeg or libpng or zlib or any other
library i'd think the same with zero documentation and just api signatures like
the above.

i've learned api's by just reading .h files (like xlib) and seeing this and
taking a guess as to what it means. an int generally to me indicates it's
returning a number as opposed to something opaque in higher level libs like
efl/gtk etc.. it has meaning. libc calls return ints and are different as they
tend to mean an error or success, but look at glib or gtk or others and they
dont do this and efl doesn't do the libc thing either as a whole.

so given the context as a whole and as a sub-part of the api like above... i
disagree that its misleading. to me its pretty obvious. maybe because i've
spent a lot of time with various api's and so on i tend to fill in the blanks
quickly seeing this kind of information. i don't know.

but if you think it's misleading can you give more information? why is it
misleading? what is it leading you to think it is and why is that? what is the
difference in view point or experience and how conclusions are being attained?

> We have ref_add and wref_add that are talking about actual references but
> ref_get returns a count?
> This is misleading.
> 
> Andy
> 
> On Mon, 6 Nov 2017 at 09:49 Carsten Haitzler  wrote:
> 
> > On Mon, 06 Nov 2017 09:46:41 + Andrew Williams 
> > said:
> >
> > i'd have to disagree on it being misleading... :/
> >
> > > Hi,
> > >
> > > Whilst writing the docs we have realised that efl_ref_get is a slightly
> > > misleading method name as it returns the reference count. Whilst we are
> > > breaking APIs for our first interfaces release would people mind me
> > > changing efl_ref_get to efl_refcount_get (as per this eo patch, and all
> > the
> > > efl ramifications).
> > >
> > > I'd prefer not to leave the old method in place but could do so if you
> > > think there is a big problem making this breaking change?
> > >
> > > Thanks :)
> > > Andy
> > >
> > >
> > > --
> > > http://andywilliams.me
> > > http://ajwillia.ms
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > Carsten Haitzler - ras...@rasterman.com
> >
> > --
> 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] OS X build error

[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é :

>
>
> 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 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 lib_evas_libevas_la-evas_font_
>> load.o
>> >
>> >   _evas_common_font_load in lib_evas_libevas_la-evas_font_load.o
>> >
>> >   _evas_common_font_init in lib_evas_libevas_la-evas_font_main.o
>> >
>> > ld: symbol(s) not found for architecture x86_64
>> >
>> > clang: error: linker command failed with exit code 1 (use -v to see
>> > invocation)
>> >
>> > make[4]: *** [lib/evas/libevas.la] Error 1
>>
>> that is very odd. they are specced with
>>
>> src/lib/evas/common/evas_font.h:EAPI RGBA_Font
>> *evas_common_font_memory_load  (const char *source, const char
>> *name,
>> int size, const void *data, int data_size, Font_Rend_Flags wanted_rend,
>> Efl_Text_Font_Bitmap_Scalable bitmap_scalable);
>>
>> for example. EAPI ... should still be defined to make these visible
>> functions.
>> could EAPI be mis-defined there causing this?
>>
>>
> Nah. LKI is undefined. The evas functions reference it.
> LKI is a macro. Somehow didn't get defined, thus became a symbol.,
> I wonder why it works for us.
>
> I pushed a patch, please test.
>
>
>> >
>> > Thanks,
>> >
>> > Andy
>> >
>> > On Tue, 7 Nov 2017 at 01:48 Jean-Philippe André 
>> wrote:
>> >
>> > > EAPI is redefined to (nothing/dllimport) after Elementary.h, so I had
>> > > introduced elm_module_helper.h to re-define EAPI for those modules.
>> > > I think that keeping EAPI defined after Elementary.h caused problems
>> on
>> > > Windows where application's EAPI were marked as dllimport instead of
>> > > dllexport (or something like that, I can't remember very well).
>> > >
>> > > Anyway I pushed a patch, let us know if this fixes the build for OSX.
>> > > Thanks!
>> > >
>> > >
>> > > 2017-11-07 5:37 GMT+09:00 Jean Guyomarc'h :
>> > >
>> > > > Hi,
>> > > >
>> > > > Eo events are generated as:
>> > > >   EWAPI const Efl_Event_Description __BLAH =
>> > > EFL_EVENT_DESCRIPTION("blah");
>> > > >
>> > > > this yields private symbols that are not exported outside of
>> > > libelementary.
>> > > > Hence link failure with elm modules...
>> > > > But I don't understand why.
>> > > >
>> > > >
>> > > > Jean
>> > > >
>> > > > On Sat, Nov 4, 2017 at 5:39 PM, Jean Guyomarc'h <
>> > > jean.guyoma...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > hi,
>> > > > >
>> > > > > i'm not at home, and cannot really help. if there is a ticket
>> open, i
>> > > may
>> > > > > have a look on  monday. is that on git master ?
>> > > > >
>> > > > > thanks
>> > > > > Jean
>> > > > >
>> > > > >
>> > > > > On Nov 4, 2017 15:03, "Carsten Haitzler" 
>> wrote:
>> > > > >
>> > > > > On Sat, 04 Nov 2017 11:21:09 + Andrew Williams <
>> > > a...@andywilliams.me
>> > > > >
>> > > > > said:
>> > > > >
>> > > > > > Can anyone help with this one please?
>> > > > > >
>> > > > > >
>> > > > > > Thanks,
>> > > > > >
>> > > > > > Andy
>> > > > > >
>> > > > > >
>> > > > > >   CC
>> > > > > > modules/elementary/clock_input_ctxpopup/modules_elementary_
>> > > > > clock_input_ctxpopup_module_la-clock_input_ctxpopup.lo
>> > > > > >
>> > > > > >   CCLD modules/elementary/clock_input_ctxpopup/module.la
>> > > > > >
>> > > > > > Undefined symbols for architecture x86_64:
>> > > > > >
>> > > > > >   "__ELM_CTXPOPUP_EVENT_DISMISSED", referenced from:
>> > > > > >
>> > > > > >   __field_clicked_cb in
>> > > > > > modules_elementary_clock_input_ctxpopup_module_la-
>> > > > clock_input_ctxpopup.o
>> > > > >
>> > > > > that sounds totally bizarre because the function is
>> _field_clicked_cb:
>> > > > >
>> > > > > static void
>> > > > > _field_clicked_cb(void *data, const Efl_Event *event)
>> > > > > {
>> > > > >
>> > > > > > ld: symbol(s) not found for architecture x86_64
>> > > > > >
>> > > > > > clang: error: linker command failed with exit code 1 (use -v to
>> see
>> > > > > > invocation)
>> > > > > >
>> > > > > > make[4]: *** [modules/elementary/clock_input_ctxpopup/module.la
>> ]
>> > > > Error 1
>> > > > > >
>> > > > > > make[3]: *** [all-recursive] Error 1
>> > > > > >
>> > > > > > make[2]: *** [all] Error 2
>> > > > > >
>> > > > > > make[1]: *** [all-recursive] Error 1
>> > > > > >
>> > > > > > make: *** [all] Error 2
>> > > > > > --
>> > 

Re: [E-devel] OS X build error

[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 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 lib_evas_libevas_la-evas_font_
> load.o
> >
> >   _evas_common_font_load in lib_evas_libevas_la-evas_font_load.o
> >
> >   _evas_common_font_init in lib_evas_libevas_la-evas_font_main.o
> >
> > ld: symbol(s) not found for architecture x86_64
> >
> > clang: error: linker command failed with exit code 1 (use -v to see
> > invocation)
> >
> > make[4]: *** [lib/evas/libevas.la] Error 1
>
> that is very odd. they are specced with
>
> src/lib/evas/common/evas_font.h:EAPI RGBA_Font
> *evas_common_font_memory_load  (const char *source, const char
> *name,
> int size, const void *data, int data_size, Font_Rend_Flags wanted_rend,
> Efl_Text_Font_Bitmap_Scalable bitmap_scalable);
>
> for example. EAPI ... should still be defined to make these visible
> functions.
> could EAPI be mis-defined there causing this?
>
>
Nah. LKI is undefined. The evas functions reference it.
LKI is a macro. Somehow didn't get defined, thus became a symbol.,
I wonder why it works for us.

I pushed a patch, please test.


> >
> > Thanks,
> >
> > Andy
> >
> > On Tue, 7 Nov 2017 at 01:48 Jean-Philippe André 
> wrote:
> >
> > > EAPI is redefined to (nothing/dllimport) after Elementary.h, so I had
> > > introduced elm_module_helper.h to re-define EAPI for those modules.
> > > I think that keeping EAPI defined after Elementary.h caused problems on
> > > Windows where application's EAPI were marked as dllimport instead of
> > > dllexport (or something like that, I can't remember very well).
> > >
> > > Anyway I pushed a patch, let us know if this fixes the build for OSX.
> > > Thanks!
> > >
> > >
> > > 2017-11-07 5:37 GMT+09:00 Jean Guyomarc'h :
> > >
> > > > Hi,
> > > >
> > > > Eo events are generated as:
> > > >   EWAPI const Efl_Event_Description __BLAH =
> > > EFL_EVENT_DESCRIPTION("blah");
> > > >
> > > > this yields private symbols that are not exported outside of
> > > libelementary.
> > > > Hence link failure with elm modules...
> > > > But I don't understand why.
> > > >
> > > >
> > > > Jean
> > > >
> > > > On Sat, Nov 4, 2017 at 5:39 PM, Jean Guyomarc'h <
> > > jean.guyoma...@gmail.com>
> > > > wrote:
> > > >
> > > > > hi,
> > > > >
> > > > > i'm not at home, and cannot really help. if there is a ticket
> open, i
> > > may
> > > > > have a look on  monday. is that on git master ?
> > > > >
> > > > > thanks
> > > > > Jean
> > > > >
> > > > >
> > > > > On Nov 4, 2017 15:03, "Carsten Haitzler" 
> wrote:
> > > > >
> > > > > On Sat, 04 Nov 2017 11:21:09 + Andrew Williams <
> > > a...@andywilliams.me
> > > > >
> > > > > said:
> > > > >
> > > > > > Can anyone help with this one please?
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Andy
> > > > > >
> > > > > >
> > > > > >   CC
> > > > > > modules/elementary/clock_input_ctxpopup/modules_elementary_
> > > > > clock_input_ctxpopup_module_la-clock_input_ctxpopup.lo
> > > > > >
> > > > > >   CCLD modules/elementary/clock_input_ctxpopup/module.la
> > > > > >
> > > > > > Undefined symbols for architecture x86_64:
> > > > > >
> > > > > >   "__ELM_CTXPOPUP_EVENT_DISMISSED", referenced from:
> > > > > >
> > > > > >   __field_clicked_cb in
> > > > > > modules_elementary_clock_input_ctxpopup_module_la-
> > > > clock_input_ctxpopup.o
> > > > >
> > > > > that sounds totally bizarre because the function is
> _field_clicked_cb:
> > > > >
> > > > > static void
> > > > > _field_clicked_cb(void *data, const Efl_Event *event)
> > > > > {
> > > > >
> > > > > > ld: symbol(s) not found for architecture x86_64
> > > > > >
> > > > > > clang: error: linker command failed with exit code 1 (use -v to
> see
> > > > > > invocation)
> > > > > >
> > > > > > make[4]: *** [modules/elementary/clock_input_ctxpopup/module.la]
> > > > Error 1
> > > > > >
> > > > > > make[3]: *** [all-recursive] Error 1
> > > > > >
> > > > > > make[2]: *** [all] Error 2
> > > > > >
> > > > > > make[1]: *** [all-recursive] Error 1
> > > > > >
> > > > > > make: *** [all] Error 2
> > > > > > --
> > > > > > 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
> > > > > > 

Re: [E-devel] OS X build error

[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:
> 
>   __evas_common_font_int_cache_init in
> lib_evas_libevas_la-evas_font_load.o
> 
>   _evas_common_font_memory_load in lib_evas_libevas_la-evas_font_load.o
> 
>   _evas_common_font_load in lib_evas_libevas_la-evas_font_load.o
> 
>   _evas_common_font_init in lib_evas_libevas_la-evas_font_main.o
> 
> ld: symbol(s) not found for architecture x86_64
> 
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> 
> make[4]: *** [lib/evas/libevas.la] Error 1

that is very odd. they are specced with

src/lib/evas/common/evas_font.h:EAPI RGBA_Font
*evas_common_font_memory_load  (const char *source, const char *name,
int size, const void *data, int data_size, Font_Rend_Flags wanted_rend,
Efl_Text_Font_Bitmap_Scalable bitmap_scalable);

for example. EAPI ... should still be defined to make these visible functions.
could EAPI be mis-defined there causing this?

> 
> Thanks,
> 
> Andy
> 
> On Tue, 7 Nov 2017 at 01:48 Jean-Philippe André  wrote:
> 
> > EAPI is redefined to (nothing/dllimport) after Elementary.h, so I had
> > introduced elm_module_helper.h to re-define EAPI for those modules.
> > I think that keeping EAPI defined after Elementary.h caused problems on
> > Windows where application's EAPI were marked as dllimport instead of
> > dllexport (or something like that, I can't remember very well).
> >
> > Anyway I pushed a patch, let us know if this fixes the build for OSX.
> > Thanks!
> >
> >
> > 2017-11-07 5:37 GMT+09:00 Jean Guyomarc'h :
> >
> > > Hi,
> > >
> > > Eo events are generated as:
> > >   EWAPI const Efl_Event_Description __BLAH =
> > EFL_EVENT_DESCRIPTION("blah");
> > >
> > > this yields private symbols that are not exported outside of
> > libelementary.
> > > Hence link failure with elm modules...
> > > But I don't understand why.
> > >
> > >
> > > Jean
> > >
> > > On Sat, Nov 4, 2017 at 5:39 PM, Jean Guyomarc'h <
> > jean.guyoma...@gmail.com>
> > > wrote:
> > >
> > > > hi,
> > > >
> > > > i'm not at home, and cannot really help. if there is a ticket open, i
> > may
> > > > have a look on  monday. is that on git master ?
> > > >
> > > > thanks
> > > > Jean
> > > >
> > > >
> > > > On Nov 4, 2017 15:03, "Carsten Haitzler"  wrote:
> > > >
> > > > On Sat, 04 Nov 2017 11:21:09 + Andrew Williams <
> > a...@andywilliams.me
> > > >
> > > > said:
> > > >
> > > > > Can anyone help with this one please?
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Andy
> > > > >
> > > > >
> > > > >   CC
> > > > > modules/elementary/clock_input_ctxpopup/modules_elementary_
> > > > clock_input_ctxpopup_module_la-clock_input_ctxpopup.lo
> > > > >
> > > > >   CCLD modules/elementary/clock_input_ctxpopup/module.la
> > > > >
> > > > > Undefined symbols for architecture x86_64:
> > > > >
> > > > >   "__ELM_CTXPOPUP_EVENT_DISMISSED", referenced from:
> > > > >
> > > > >   __field_clicked_cb in
> > > > > modules_elementary_clock_input_ctxpopup_module_la-
> > > clock_input_ctxpopup.o
> > > >
> > > > that sounds totally bizarre because the function is _field_clicked_cb:
> > > >
> > > > static void
> > > > _field_clicked_cb(void *data, const Efl_Event *event)
> > > > {
> > > >
> > > > > ld: symbol(s) not found for architecture x86_64
> > > > >
> > > > > clang: error: linker command failed with exit code 1 (use -v to see
> > > > > invocation)
> > > > >
> > > > > make[4]: *** [modules/elementary/clock_input_ctxpopup/module.la]
> > > Error 1
> > > > >
> > > > > make[3]: *** [all-recursive] Error 1
> > > > >
> > > > > make[2]: *** [all] Error 2
> > > > >
> > > > > make[1]: *** [all-recursive] Error 1
> > > > >
> > > > > make: *** [all] Error 2
> > > > > --
> > > > > 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
> > > > 

Re: [E-devel] efl_refcount_get

[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
> references but has no mention of count in the name.
> We have ref_add and wref_add that are talking about actual references but
> ref_get returns a count?
> This is misleading.
>
> Andy
>
> On Mon, 6 Nov 2017 at 09:49 Carsten Haitzler  wrote:
>
>> On Mon, 06 Nov 2017 09:46:41 + Andrew Williams 
>> said:
>>
>> i'd have to disagree on it being misleading... :/
>>
>> > Hi,
>> >
>> > Whilst writing the docs we have realised that efl_ref_get is a slightly
>> > misleading method name as it returns the reference count. Whilst we are
>> > breaking APIs for our first interfaces release would people mind me
>> > changing efl_ref_get to efl_refcount_get (as per this eo patch, and all
>> the
>> > efl ramifications).
>> >
>> > I'd prefer not to leave the old method in place but could do so if you
>> > think there is a big problem making this breaking change?
>> >
>> > Thanks :)
>> > Andy
>> >
>> >
>> > --
>> > http://andywilliams.me
>> > http://ajwillia.ms
>>
>>
>> --
>> - Codito, ergo sum - "I code, therefore I am" --
>> Carsten Haitzler - ras...@rasterman.com
>>
>> --
> http://andywilliams.me
> http://ajwillia.ms
>
-- 
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] OS X build error

[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 lib_evas_libevas_la-evas_font_load.o

  _evas_common_font_load in lib_evas_libevas_la-evas_font_load.o

  _evas_common_font_init in lib_evas_libevas_la-evas_font_main.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see
invocation)

make[4]: *** [lib/evas/libevas.la] Error 1


Thanks,

Andy

On Tue, 7 Nov 2017 at 01:48 Jean-Philippe André  wrote:

> EAPI is redefined to (nothing/dllimport) after Elementary.h, so I had
> introduced elm_module_helper.h to re-define EAPI for those modules.
> I think that keeping EAPI defined after Elementary.h caused problems on
> Windows where application's EAPI were marked as dllimport instead of
> dllexport (or something like that, I can't remember very well).
>
> Anyway I pushed a patch, let us know if this fixes the build for OSX.
> Thanks!
>
>
> 2017-11-07 5:37 GMT+09:00 Jean Guyomarc'h :
>
> > Hi,
> >
> > Eo events are generated as:
> >   EWAPI const Efl_Event_Description __BLAH =
> EFL_EVENT_DESCRIPTION("blah");
> >
> > this yields private symbols that are not exported outside of
> libelementary.
> > Hence link failure with elm modules...
> > But I don't understand why.
> >
> >
> > Jean
> >
> > On Sat, Nov 4, 2017 at 5:39 PM, Jean Guyomarc'h <
> jean.guyoma...@gmail.com>
> > wrote:
> >
> > > hi,
> > >
> > > i'm not at home, and cannot really help. if there is a ticket open, i
> may
> > > have a look on  monday. is that on git master ?
> > >
> > > thanks
> > > Jean
> > >
> > >
> > > On Nov 4, 2017 15:03, "Carsten Haitzler"  wrote:
> > >
> > > On Sat, 04 Nov 2017 11:21:09 + Andrew Williams <
> a...@andywilliams.me
> > >
> > > said:
> > >
> > > > Can anyone help with this one please?
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Andy
> > > >
> > > >
> > > >   CC
> > > > modules/elementary/clock_input_ctxpopup/modules_elementary_
> > > clock_input_ctxpopup_module_la-clock_input_ctxpopup.lo
> > > >
> > > >   CCLD modules/elementary/clock_input_ctxpopup/module.la
> > > >
> > > > Undefined symbols for architecture x86_64:
> > > >
> > > >   "__ELM_CTXPOPUP_EVENT_DISMISSED", referenced from:
> > > >
> > > >   __field_clicked_cb in
> > > > modules_elementary_clock_input_ctxpopup_module_la-
> > clock_input_ctxpopup.o
> > >
> > > that sounds totally bizarre because the function is _field_clicked_cb:
> > >
> > > static void
> > > _field_clicked_cb(void *data, const Efl_Event *event)
> > > {
> > >
> > > > ld: symbol(s) not found for architecture x86_64
> > > >
> > > > clang: error: linker command failed with exit code 1 (use -v to see
> > > > invocation)
> > > >
> > > > make[4]: *** [modules/elementary/clock_input_ctxpopup/module.la]
> > Error 1
> > > >
> > > > make[3]: *** [all-recursive] Error 1
> > > >
> > > > make[2]: *** [all] Error 2
> > > >
> > > > make[1]: *** [all-recursive] Error 1
> > > >
> > > > make: *** [all] Error 2
> > > > --
> > > > 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
> > >
> > >
> > >
> > 
> > --
> > 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
> >
> >
>
>
> --
> Jean-Philippe André
>
> --
> Check out the vibrant tech community on one of the