Re: [E-devel] Improving web site accessibility

[Carsten Haitzler]

On Thu, 16 Nov 2017 22:28:13 + Stephen Houston  said:

> Oh I almost forgot. Please please please full width as well. No one does
> the centered page with large left and right margins anymore. Use the space,
> don't waste it. Full width will make documentation much easier to read as
> well.

I think you're incorrect. People who publish for a living professionally would
tell you otherwise. Reading long lines is hard. I'm just going to take 5 major
media publications as an example:

http://www.smh.com.au/
http://www.bbc.com/
http://edition.cnn.com/
http://www.nytimes.com/
http://www.washingtonpost.com/

No one does it anymore? Really? Professionals who produce content to read have
no idea what they are doing?

We read down with short lines much better than across, so keep lines short-ish
and pan vertically.

https://baymard.com/blog/line-length-readability

Waste space if necessary. Unless you want to flow columns across the screen
like a newspaper and scroll horizontally. Good luck with making that work well
with a wiki like dokuwiki. Or manually manage content to have their own private
column within a page.

Keep the site as it is. I did this very specifically for a reason because it
makes it easier to read and more visually pleasing. The professionals agree and
the examples in daily life are all around you.

> On Thu, Nov 16, 2017, 4:26 PM Stephen Houston  wrote:
> 
> > +1 I've been saying we need a new website bad. And one that is sleek,
> > modern, and yes white.  Time to look up to date and kept with the times.
> > You will notice nearly every major linux distribution and nearly all major
> > linux software websites are in the confines of what you describe. Simple,
> > flat, white background and black text, sharp but small images that are
> > mostly subtle, and responsive design to look good across devices. The
> > reason being that this is proven to be the easiest on the eyes and the most
> > pleasing to the reader as you said.
> >
> > On Thu, Nov 16, 2017, 3:58 PM Cedric Bail  wrote:
> >
> >> Hi,
> >>
> >> As some of you may have noticed we are doing some improvement to our
> >> documentation and trying to get things easier when starting with EFL. One
> >> of the main issue we are facing is that our website is definitively hard to
> >> read for a lot of people. So Paul went on trying to figure out why.
> >>
> >> The first problem is actually the constrast ratio between background and
> >> text. According to W3C accessibility guidelines (
> >> https://www.w3.org/TR/WCAG21/#contrast-minimum )it should be 4.5:1 at
> >> least. Our colors are #818181 for the text and #303030 which give a
> >> contrast ratio of 3.39:1 ( https://webaim.org/resources/contrastchecker/
> >> ). And it is worth for people with vision impairment where it should be
> >> 7:1.
> >>
> >> Black on white or white on black would work, but according to some random
> >> person on Internet (could not find a scientific evidence/citation of it) a
> >> white background force your pupils to contracts, making it easier to focus
> >> your eye with a smaller pupil (much like the depth of field is increased
> >> with a smaller camera lens). This could be shown by a test carried on 136
> >> subject, where the people reading black text on a white background scored
> >> better than any other combination of colors (
> >> http://lite.mst.edu/media/research/ctel/documents/LITE-2003-04.pdf ).
> >>
> >> The second problem are our links that are difficult to tell wether they
> >> have been clicked on or not. Also they have a slight glow around the links
> >> that makes them harder to read. The best link on the subject we can point
> >> to would be
> >> https://www.nngroup.com/articles/guidelines-for-visualizing-links/ .
> >>
> >> So it would be best to come up with a more accessible design for our web
> >> site. If someone want to suggest a new design within those constraint, it
> >> would be great, but I would suggest to look at
> >> https://gstreamer.freedesktop.org/documentation/ or at http://doc.qt.io/
> >> . They are simple and work well in term of readability. We could easily go
> >> with something like that. What do you think ?
> >>
> >> 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
> >>
> >
> --
> 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] Improving web site accessibility

[Carsten Haitzler]

On Thu, 16 Nov 2017 22:26:01 + Stephen Houston  said:

> +1 I've been saying we need a new website bad. And one that is sleek,
> modern, and yes white.  Time to look up to date and kept with the times.
> You will notice nearly every major linux distribution and nearly all major
> linux software websites are in the confines of what you describe. Simple,
> flat, white background and black text, sharp but small images that are
> mostly subtle, and responsive design to look good across devices. The
> reason being that this is proven to be the easiest on the eyes and the most
> pleasing to the reader as you said.

Our design is responsive. It actually was based off bootstrap. Tried reading
e.org on a phone or tablet as well as a PC? It works well. There is no need to
mess with that I think.

Contrast ratio is up for discussion. Links could change color too. Move to
#a0a0a0 for text and done (5:1). Change links a bit. Saying "We must be black on
white bg" I wholly disagree with. This is part of an identity and that is what
our default theme is for our software. Might I point out Windows 10 is light
text on dark bg too by default? Visual studio code is too. So is Atom, So is
Photoshop and Lightroom ... It's a choice. An artistic and design choice.

I made the choice to not look the same and to stand out. Being the same as
everyone else is simply not the identity of Enlightenment. It was not created
for that nor does it bear that philosophy. Dark backgrounds are common enough
and still being done by professionals and winning awards, and they stand out
because they are not "just like everyone else". See:

https://www.awwwards.com/
https://www.awwwards.com/websites/

Examples:

http://beta.wind-and-words.com/
https://www.mirandajoan.com/home
http://www.mirrorconf.com/
https://envylabs.com/
https://www.dowhatyoucant.at/ (combo light/dark + dark/light)
http://2017.tdsgn.ru/
http://www.thegreat.agency/
http://www.arcys.fr/
http://www.karipidi.gr/ (combo)
https://www.artistsweb.com/ (combo)

Go find all the sites that are not a white bg, dark text (are dark bg and
light text). This has nothing to do with being modern or "keeping up with the
times". Professional design studios TODAY often enough choose light on dark.
Please don't confuse a design choice of color scheme with "keeping with the
times".

P.S. I also would argue a big region of blaring white is NOT easy on the eyes.
it strains them. Like staring into a light bulb. It certainly does for me. 

> On Thu, Nov 16, 2017, 3:58 PM Cedric Bail  wrote:
> 
> > Hi,
> >
> > As some of you may have noticed we are doing some improvement to our
> > documentation and trying to get things easier when starting with EFL. One
> > of the main issue we are facing is that our website is definitively hard to
> > read for a lot of people. So Paul went on trying to figure out why.
> >
> > The first problem is actually the constrast ratio between background and
> > text. According to W3C accessibility guidelines (
> > https://www.w3.org/TR/WCAG21/#contrast-minimum )it should be 4.5:1 at
> > least. Our colors are #818181 for the text and #303030 which give a
> > contrast ratio of 3.39:1 ( https://webaim.org/resources/contrastchecker/
> > ). And it is worth for people with vision impairment where it should be 7:1.
> >
> > Black on white or white on black would work, but according to some random
> > person on Internet (could not find a scientific evidence/citation of it) a
> > white background force your pupils to contracts, making it easier to focus
> > your eye with a smaller pupil (much like the depth of field is increased
> > with a smaller camera lens). This could be shown by a test carried on 136
> > subject, where the people reading black text on a white background scored
> > better than any other combination of colors (
> > http://lite.mst.edu/media/research/ctel/documents/LITE-2003-04.pdf ).
> >
> > The second problem are our links that are difficult to tell wether they
> > have been clicked on or not. Also they have a slight glow around the links
> > that makes them harder to read. The best link on the subject we can point
> > to would be
> > https://www.nngroup.com/articles/guidelines-for-visualizing-links/ .
> >
> > So it would be best to come up with a more accessible design for our web
> > site. If someone want to suggest a new design within those constraint, it
> > would be great, but I would suggest to look at
> > https://gstreamer.freedesktop.org/documentation/ or at http://doc.qt.io/
> > . They are simple and work well in term of readability. We could easily go
> > with something like that. What do you think ?
> >
> > 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
> 

Re: [E-devel] Improving web site accessibility

[Carsten Haitzler]

On Thu, 16 Nov 2017 23:38:05 + jaquilina  said:

> Hi guys this is something I can contribute to in terms of website. and I 
> can even host it if you all so desire. Question is do you want this 
> built off a framework, such as wordpress where it will be easy to 
> include a forums section or something custom built?

We don't need hosting. We have that. We have a framework: Dokuwiki. Our content
depends on it and its markdown. It also has discussion forums too. They are
activated on several pages.

This discussion is really about styling and maybe layout.

> On 2017-11-16 22:26, Stephen Houston wrote:
> > +1 I've been saying we need a new website bad. And one that is sleek,
> > modern, and yes white.  Time to look up to date and kept with the 
> > times.
> > You will notice nearly every major linux distribution and nearly all 
> > major
> > linux software websites are in the confines of what you describe. 
> > Simple,
> > flat, white background and black text, sharp but small images that are
> > mostly subtle, and responsive design to look good across devices. The
> > reason being that this is proven to be the easiest on the eyes and the 
> > most
> > pleasing to the reader as you said.
> > 
> > On Thu, Nov 16, 2017, 3:58 PM Cedric Bail  wrote:
> > 
> >> Hi,
> >> 
> >> As some of you may have noticed we are doing some improvement to our
> >> documentation and trying to get things easier when starting with EFL. 
> >> One
> >> of the main issue we are facing is that our website is definitively 
> >> hard to
> >> read for a lot of people. So Paul went on trying to figure out why.
> >> 
> >> The first problem is actually the constrast ratio between background 
> >> and
> >> text. According to W3C accessibility guidelines (
> >> https://www.w3.org/TR/WCAG21/#contrast-minimum )it should be 4.5:1 at
> >> least. Our colors are #818181 for the text and #303030 which give a
> >> contrast ratio of 3.39:1 ( 
> >> https://webaim.org/resources/contrastchecker/
> >> ). And it is worth for people with vision impairment where it should 
> >> be 7:1.
> >> 
> >> Black on white or white on black would work, but according to some 
> >> random
> >> person on Internet (could not find a scientific evidence/citation of 
> >> it) a
> >> white background force your pupils to contracts, making it easier to 
> >> focus
> >> your eye with a smaller pupil (much like the depth of field is 
> >> increased
> >> with a smaller camera lens). This could be shown by a test carried on 
> >> 136
> >> subject, where the people reading black text on a white background 
> >> scored
> >> better than any other combination of colors (
> >> http://lite.mst.edu/media/research/ctel/documents/LITE-2003-04.pdf ).
> >> 
> >> The second problem are our links that are difficult to tell wether 
> >> they
> >> have been clicked on or not. Also they have a slight glow around the 
> >> links
> >> that makes them harder to read. The best link on the subject we can 
> >> point
> >> to would be
> >> https://www.nngroup.com/articles/guidelines-for-visualizing-links/ .
> >> 
> >> So it would be best to come up with a more accessible design for our 
> >> web
> >> site. If someone want to suggest a new design within those constraint, 
> >> it
> >> would be great, but I would suggest to look at
> >> https://gstreamer.freedesktop.org/documentation/ or at 
> >> http://doc.qt.io/
> >> . They are simple and work well in term of readability. We could 
> >> easily go
> >> with something like that. What do you think ?
> >> 
> >> 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
> >> 
> > --
> > 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
> 


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

Re: [E-devel] Improving web site accessibility

[Bryce Harrington]

On Fri, Nov 17, 2017 at 10:30:21AM +1030, Simon Lees wrote:
> 
> 
> On 17/11/17 10:08, jaquilina wrote:
> > Hi guys this is something I can contribute to in terms of website. and I
> > can even host it if you all so desire. Question is do you want this
> > built off a framework, such as wordpress where it will be easy to
> > include a forums section or something custom built?
> > 
> 
> I think that given doku is already so heavily integrated into everything
> all we really need to do is update its style sheets. We can probably set
> up doku to have a dark on light stylesheet and a light on dark where
> users can choose which they prefer.

The latter would be a nice feature if it's easy enough to implement
within the existing framework, although note there are tons of "night
mode" browser extensions out there that change white-on-black into
black-on-white, so if it isn't easy, well there's other (probably
better) ways for users to achieve it.

Bryce
 
> > On 2017-11-16 22:26, Stephen Houston wrote:
> >> +1 I've been saying we need a new website bad. And one that is sleek,
> >> modern, and yes white.  Time to look up to date and kept with the times.
> >> You will notice nearly every major linux distribution and nearly all
> >> major
> >> linux software websites are in the confines of what you describe. Simple,
> >> flat, white background and black text, sharp but small images that are
> >> mostly subtle, and responsive design to look good across devices. The
> >> reason being that this is proven to be the easiest on the eyes and the
> >> most
> >> pleasing to the reader as you said.
> >>
> >> On Thu, Nov 16, 2017, 3:58 PM Cedric Bail  wrote:
> >>
> >>> Hi,
> >>>
> >>> As some of you may have noticed we are doing some improvement to our
> >>> documentation and trying to get things easier when starting with EFL.
> >>> One
> >>> of the main issue we are facing is that our website is definitively
> >>> hard to
> >>> read for a lot of people. So Paul went on trying to figure out why.
> >>>
> >>> The first problem is actually the constrast ratio between background and
> >>> text. According to W3C accessibility guidelines (
> >>> https://www.w3.org/TR/WCAG21/#contrast-minimum )it should be 4.5:1 at
> >>> least. Our colors are #818181 for the text and #303030 which give a
> >>> contrast ratio of 3.39:1 ( https://webaim.org/resources/contrastchecker/
> >>> ). And it is worth for people with vision impairment where it should
> >>> be 7:1.
> >>>
> >>> Black on white or white on black would work, but according to some
> >>> random
> >>> person on Internet (could not find a scientific evidence/citation of
> >>> it) a
> >>> white background force your pupils to contracts, making it easier to
> >>> focus
> >>> your eye with a smaller pupil (much like the depth of field is increased
> >>> with a smaller camera lens). This could be shown by a test carried on
> >>> 136
> >>> subject, where the people reading black text on a white background
> >>> scored
> >>> better than any other combination of colors (
> >>> http://lite.mst.edu/media/research/ctel/documents/LITE-2003-04.pdf ).
> >>>
> >>> The second problem are our links that are difficult to tell wether they
> >>> have been clicked on or not. Also they have a slight glow around the
> >>> links
> >>> that makes them harder to read. The best link on the subject we can
> >>> point
> >>> to would be
> >>> https://www.nngroup.com/articles/guidelines-for-visualizing-links/ .
> >>>
> >>> So it would be best to come up with a more accessible design for our web
> >>> site. If someone want to suggest a new design within those
> >>> constraint, it
> >>> would be great, but I would suggest to look at
> >>> https://gstreamer.freedesktop.org/documentation/ or at http://doc.qt.io/
> >>> . They are simple and work well in term of readability. We could
> >>> easily go
> >>> with something like that. What do you think ?
> >>>
> >>> 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
> >>>
> >> --
> >>
> >> 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 

Re: [E-devel] Improving web site accessibility

[Simon Lees]

On 17/11/17 10:08, jaquilina wrote:
> Hi guys this is something I can contribute to in terms of website. and I
> can even host it if you all so desire. Question is do you want this
> built off a framework, such as wordpress where it will be easy to
> include a forums section or something custom built?
> 

I think that given doku is already so heavily integrated into everything
all we really need to do is update its style sheets. We can probably set
up doku to have a dark on light stylesheet and a light on dark where
users can choose which they prefer.

> On 2017-11-16 22:26, Stephen Houston wrote:
>> +1 I've been saying we need a new website bad. And one that is sleek,
>> modern, and yes white.  Time to look up to date and kept with the times.
>> You will notice nearly every major linux distribution and nearly all
>> major
>> linux software websites are in the confines of what you describe. Simple,
>> flat, white background and black text, sharp but small images that are
>> mostly subtle, and responsive design to look good across devices. The
>> reason being that this is proven to be the easiest on the eyes and the
>> most
>> pleasing to the reader as you said.
>>
>> On Thu, Nov 16, 2017, 3:58 PM Cedric Bail  wrote:
>>
>>> Hi,
>>>
>>> As some of you may have noticed we are doing some improvement to our
>>> documentation and trying to get things easier when starting with EFL.
>>> One
>>> of the main issue we are facing is that our website is definitively
>>> hard to
>>> read for a lot of people. So Paul went on trying to figure out why.
>>>
>>> The first problem is actually the constrast ratio between background and
>>> text. According to W3C accessibility guidelines (
>>> https://www.w3.org/TR/WCAG21/#contrast-minimum )it should be 4.5:1 at
>>> least. Our colors are #818181 for the text and #303030 which give a
>>> contrast ratio of 3.39:1 ( https://webaim.org/resources/contrastchecker/
>>> ). And it is worth for people with vision impairment where it should
>>> be 7:1.
>>>
>>> Black on white or white on black would work, but according to some
>>> random
>>> person on Internet (could not find a scientific evidence/citation of
>>> it) a
>>> white background force your pupils to contracts, making it easier to
>>> focus
>>> your eye with a smaller pupil (much like the depth of field is increased
>>> with a smaller camera lens). This could be shown by a test carried on
>>> 136
>>> subject, where the people reading black text on a white background
>>> scored
>>> better than any other combination of colors (
>>> http://lite.mst.edu/media/research/ctel/documents/LITE-2003-04.pdf ).
>>>
>>> The second problem are our links that are difficult to tell wether they
>>> have been clicked on or not. Also they have a slight glow around the
>>> links
>>> that makes them harder to read. The best link on the subject we can
>>> point
>>> to would be
>>> https://www.nngroup.com/articles/guidelines-for-visualizing-links/ .
>>>
>>> So it would be best to come up with a more accessible design for our web
>>> site. If someone want to suggest a new design within those
>>> constraint, it
>>> would be great, but I would suggest to look at
>>> https://gstreamer.freedesktop.org/documentation/ or at http://doc.qt.io/
>>> . They are simple and work well in term of readability. We could
>>> easily go
>>> with something like that. What do you think ?
>>>
>>> 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
>>>
>> --
>>
>> 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

-- 

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 

Re: [E-devel] Improving web site accessibility

[Stephen Houston]

I said yes, but the general consensus to that on IRC was strongly leaving
toward just theming the doku we have.

On Thu, Nov 16, 2017, 5:38 PM jaquilina  wrote:

> Hi guys this is something I can contribute to in terms of website. and I
> can even host it if you all so desire. Question is do you want this
> built off a framework, such as wordpress where it will be easy to
> include a forums section or something custom built?
>
> On 2017-11-16 22:26, Stephen Houston wrote:
> > +1 I've been saying we need a new website bad. And one that is sleek,
> > modern, and yes white.  Time to look up to date and kept with the
> > times.
> > You will notice nearly every major linux distribution and nearly all
> > major
> > linux software websites are in the confines of what you describe.
> > Simple,
> > flat, white background and black text, sharp but small images that are
> > mostly subtle, and responsive design to look good across devices. The
> > reason being that this is proven to be the easiest on the eyes and the
> > most
> > pleasing to the reader as you said.
> >
> > On Thu, Nov 16, 2017, 3:58 PM Cedric Bail  wrote:
> >
> >> Hi,
> >>
> >> As some of you may have noticed we are doing some improvement to our
> >> documentation and trying to get things easier when starting with EFL.
> >> One
> >> of the main issue we are facing is that our website is definitively
> >> hard to
> >> read for a lot of people. So Paul went on trying to figure out why.
> >>
> >> The first problem is actually the constrast ratio between background
> >> and
> >> text. According to W3C accessibility guidelines (
> >> https://www.w3.org/TR/WCAG21/#contrast-minimum )it should be 4.5:1 at
> >> least. Our colors are #818181 for the text and #303030 which give a
> >> contrast ratio of 3.39:1 (
> >> https://webaim.org/resources/contrastchecker/
> >> ). And it is worth for people with vision impairment where it should
> >> be 7:1.
> >>
> >> Black on white or white on black would work, but according to some
> >> random
> >> person on Internet (could not find a scientific evidence/citation of
> >> it) a
> >> white background force your pupils to contracts, making it easier to
> >> focus
> >> your eye with a smaller pupil (much like the depth of field is
> >> increased
> >> with a smaller camera lens). This could be shown by a test carried on
> >> 136
> >> subject, where the people reading black text on a white background
> >> scored
> >> better than any other combination of colors (
> >> http://lite.mst.edu/media/research/ctel/documents/LITE-2003-04.pdf ).
> >>
> >> The second problem are our links that are difficult to tell wether
> >> they
> >> have been clicked on or not. Also they have a slight glow around the
> >> links
> >> that makes them harder to read. The best link on the subject we can
> >> point
> >> to would be
> >> https://www.nngroup.com/articles/guidelines-for-visualizing-links/ .
> >>
> >> So it would be best to come up with a more accessible design for our
> >> web
> >> site. If someone want to suggest a new design within those constraint,
> >> it
> >> would be great, but I would suggest to look at
> >> https://gstreamer.freedesktop.org/documentation/ or at
> >> http://doc.qt.io/
> >> . They are simple and work well in term of readability. We could
> >> easily go
> >> with something like that. What do you think ?
> >>
> >> 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
> >>
> >
> --
> > 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

Re: [E-devel] Improving web site accessibility

[jaquilina]

Hi guys this is something I can contribute to in terms of website. and I 
can even host it if you all so desire. Question is do you want this 
built off a framework, such as wordpress where it will be easy to 
include a forums section or something custom built?


On 2017-11-16 22:26, Stephen Houston wrote:

+1 I've been saying we need a new website bad. And one that is sleek,
modern, and yes white.  Time to look up to date and kept with the 
times.
You will notice nearly every major linux distribution and nearly all 
major
linux software websites are in the confines of what you describe. 
Simple,

flat, white background and black text, sharp but small images that are
mostly subtle, and responsive design to look good across devices. The
reason being that this is proven to be the easiest on the eyes and the 
most

pleasing to the reader as you said.

On Thu, Nov 16, 2017, 3:58 PM Cedric Bail  wrote:


Hi,

As some of you may have noticed we are doing some improvement to our
documentation and trying to get things easier when starting with EFL. 
One
of the main issue we are facing is that our website is definitively 
hard to

read for a lot of people. So Paul went on trying to figure out why.

The first problem is actually the constrast ratio between background 
and

text. According to W3C accessibility guidelines (
https://www.w3.org/TR/WCAG21/#contrast-minimum )it should be 4.5:1 at
least. Our colors are #818181 for the text and #303030 which give a
contrast ratio of 3.39:1 ( 
https://webaim.org/resources/contrastchecker/
). And it is worth for people with vision impairment where it should 
be 7:1.


Black on white or white on black would work, but according to some 
random
person on Internet (could not find a scientific evidence/citation of 
it) a
white background force your pupils to contracts, making it easier to 
focus
your eye with a smaller pupil (much like the depth of field is 
increased
with a smaller camera lens). This could be shown by a test carried on 
136
subject, where the people reading black text on a white background 
scored

better than any other combination of colors (
http://lite.mst.edu/media/research/ctel/documents/LITE-2003-04.pdf ).

The second problem are our links that are difficult to tell wether 
they
have been clicked on or not. Also they have a slight glow around the 
links
that makes them harder to read. The best link on the subject we can 
point

to would be
https://www.nngroup.com/articles/guidelines-for-visualizing-links/ .

So it would be best to come up with a more accessible design for our 
web
site. If someone want to suggest a new design within those constraint, 
it

would be great, but I would suggest to look at
https://gstreamer.freedesktop.org/documentation/ or at 
http://doc.qt.io/
. They are simple and work well in term of readability. We could 
easily go

with something like that. What do you think ?

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


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

Re: [E-devel] Improving web site accessibility

[Stephen Houston]

Oh I almost forgot. Please please please full width as well. No one does
the centered page with large left and right margins anymore. Use the space,
don't waste it. Full width will make documentation much easier to read as
well.

On Thu, Nov 16, 2017, 4:26 PM Stephen Houston  wrote:

> +1 I've been saying we need a new website bad. And one that is sleek,
> modern, and yes white.  Time to look up to date and kept with the times.
> You will notice nearly every major linux distribution and nearly all major
> linux software websites are in the confines of what you describe. Simple,
> flat, white background and black text, sharp but small images that are
> mostly subtle, and responsive design to look good across devices. The
> reason being that this is proven to be the easiest on the eyes and the most
> pleasing to the reader as you said.
>
> On Thu, Nov 16, 2017, 3:58 PM Cedric Bail  wrote:
>
>> Hi,
>>
>> As some of you may have noticed we are doing some improvement to our
>> documentation and trying to get things easier when starting with EFL. One
>> of the main issue we are facing is that our website is definitively hard to
>> read for a lot of people. So Paul went on trying to figure out why.
>>
>> The first problem is actually the constrast ratio between background and
>> text. According to W3C accessibility guidelines (
>> https://www.w3.org/TR/WCAG21/#contrast-minimum )it should be 4.5:1 at
>> least. Our colors are #818181 for the text and #303030 which give a
>> contrast ratio of 3.39:1 ( https://webaim.org/resources/contrastchecker/
>> ). And it is worth for people with vision impairment where it should be 7:1.
>>
>> Black on white or white on black would work, but according to some random
>> person on Internet (could not find a scientific evidence/citation of it) a
>> white background force your pupils to contracts, making it easier to focus
>> your eye with a smaller pupil (much like the depth of field is increased
>> with a smaller camera lens). This could be shown by a test carried on 136
>> subject, where the people reading black text on a white background scored
>> better than any other combination of colors (
>> http://lite.mst.edu/media/research/ctel/documents/LITE-2003-04.pdf ).
>>
>> The second problem are our links that are difficult to tell wether they
>> have been clicked on or not. Also they have a slight glow around the links
>> that makes them harder to read. The best link on the subject we can point
>> to would be
>> https://www.nngroup.com/articles/guidelines-for-visualizing-links/ .
>>
>> So it would be best to come up with a more accessible design for our web
>> site. If someone want to suggest a new design within those constraint, it
>> would be great, but I would suggest to look at
>> https://gstreamer.freedesktop.org/documentation/ or at http://doc.qt.io/
>> . They are simple and work well in term of readability. We could easily go
>> with something like that. What do you think ?
>>
>> 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
>>
>
--
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] Improving web site accessibility

[Stephen Houston]

+1 I've been saying we need a new website bad. And one that is sleek,
modern, and yes white.  Time to look up to date and kept with the times.
You will notice nearly every major linux distribution and nearly all major
linux software websites are in the confines of what you describe. Simple,
flat, white background and black text, sharp but small images that are
mostly subtle, and responsive design to look good across devices. The
reason being that this is proven to be the easiest on the eyes and the most
pleasing to the reader as you said.

On Thu, Nov 16, 2017, 3:58 PM Cedric Bail  wrote:

> Hi,
>
> As some of you may have noticed we are doing some improvement to our
> documentation and trying to get things easier when starting with EFL. One
> of the main issue we are facing is that our website is definitively hard to
> read for a lot of people. So Paul went on trying to figure out why.
>
> The first problem is actually the constrast ratio between background and
> text. According to W3C accessibility guidelines (
> https://www.w3.org/TR/WCAG21/#contrast-minimum )it should be 4.5:1 at
> least. Our colors are #818181 for the text and #303030 which give a
> contrast ratio of 3.39:1 ( https://webaim.org/resources/contrastchecker/
> ). And it is worth for people with vision impairment where it should be 7:1.
>
> Black on white or white on black would work, but according to some random
> person on Internet (could not find a scientific evidence/citation of it) a
> white background force your pupils to contracts, making it easier to focus
> your eye with a smaller pupil (much like the depth of field is increased
> with a smaller camera lens). This could be shown by a test carried on 136
> subject, where the people reading black text on a white background scored
> better than any other combination of colors (
> http://lite.mst.edu/media/research/ctel/documents/LITE-2003-04.pdf ).
>
> The second problem are our links that are difficult to tell wether they
> have been clicked on or not. Also they have a slight glow around the links
> that makes them harder to read. The best link on the subject we can point
> to would be
> https://www.nngroup.com/articles/guidelines-for-visualizing-links/ .
>
> So it would be best to come up with a more accessible design for our web
> site. If someone want to suggest a new design within those constraint, it
> would be great, but I would suggest to look at
> https://gstreamer.freedesktop.org/documentation/ or at http://doc.qt.io/
> . They are simple and work well in term of readability. We could easily go
> with something like that. What do you think ?
>
> 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
>
--
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] Improving web site accessibility

[Cedric Bail]

Hi,

As some of you may have noticed we are doing some improvement to our 
documentation and trying to get things easier when starting with EFL. One of 
the main issue we are facing is that our website is definitively hard to read 
for a lot of people. So Paul went on trying to figure out why.

The first problem is actually the constrast ratio between background and text. 
According to W3C accessibility guidelines ( 
https://www.w3.org/TR/WCAG21/#contrast-minimum )it should be 4.5:1 at least. 
Our colors are #818181 for the text and #303030 which give a contrast ratio of 
3.39:1 ( https://webaim.org/resources/contrastchecker/ ). And it is worth for 
people with vision impairment where it should be 7:1.

Black on white or white on black would work, but according to some random 
person on Internet (could not find a scientific evidence/citation of it) a 
white background force your pupils to contracts, making it easier to focus your 
eye with a smaller pupil (much like the depth of field is increased with a 
smaller camera lens). This could be shown by a test carried on 136 subject, 
where the people reading black text on a white background scored better than 
any other combination of colors ( 
http://lite.mst.edu/media/research/ctel/documents/LITE-2003-04.pdf ).

The second problem are our links that are difficult to tell wether they have 
been clicked on or not. Also they have a slight glow around the links that 
makes them harder to read. The best link on the subject we can point to would 
be https://www.nngroup.com/articles/guidelines-for-visualizing-links/ .

So it would be best to come up with a more accessible design for our web site. 
If someone want to suggest a new design within those constraint, it would be 
great, but I would suggest to look at 
https://gstreamer.freedesktop.org/documentation/ or at http://doc.qt.io/ . They 
are simple and work well in term of readability. We could easily go with 
something like that. What do you think ?

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] Eina_Array step confusion

[Cedric Bail]

>  Original Message 
> Subject: Re: [E-devel] Eina_Array step confusion
> Local Time: November 16, 2017 6:11 AM
> UTC Time: November 16, 2017 2:11 PM
> From: a...@andywilliams.me
> To: Enlightenment developer list 
>
> Admittedly I still don't understand parameter 2. What is the point of
> passing in a variable when it's value is required to be constant?
>
> if (sizeof (Eina_Array) != sizeof_eina_array)
> ERR("Unknow Eina_Array size ! Got %i, expected %i !\n"

If Eina or the application was compiled with an older version of the Eina_Array 
structure which would have been different, it would have just randomly crashed. 
Arguably this should be a CRI and not just an ERR. Basically it is a protection 
against past ABI change (pre eina 1.0) and futur ABI change.

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] Eina_Array step confusion

[Andrew Williams]

Admittedly I still don't understand parameter 2. What is the point of
passing in a variable when it's value is required to be constant?

if (sizeof (Eina_Array) != sizeof_eina_array)
ERR("Unknow Eina_Array size ! Got %i, expected %i !\n"

Thanks,
Andy

On Thu, 16 Nov 2017 at 12:50 Andrew Williams  wrote:

> Hi,
>
> Yeah, see my follow up, I got the wrong end of the stick so I will go fix
> the docs instead.
>
> Andy
>
> On Thu, 16 Nov 2017 at 12:40 Jérémy Zurcher  wrote:
>
>> Hello,
>>
>> On Thursday 16 November 2017  11:00, Andrew Williams wrote :
>> > Hi,
>> >
>> > Are there any objections to me:
>> >
>> > 1) changing the parameter name on array creation to "size" from "step"
>>
>> this is not the size of the array that is set here,
>> but the # of array elements used to automatically grow or shrink.
>>
>> see eina_array_remove or eina_array_grow called from eina_array_push
>>
>> > 2) adding eina_array_size_set which additionally does not take a sizeof
>> > param
>>
>> that eina_array_size_set is weird,
>> the sizeof check is here to ... detect a wrong pointer I guess
>> plus if I'm not mistaken, it will silently leak if called on an non empty
>> array !
>>
>> > 3) deprecate the eina_array_step_set as it's semantics are strange (as
>> per
>> > previous email).
>> >
>> > Thanks.
>> > Andy
>> >
>> > On Tue, 14 Nov 2017 at 13:04 Andrew Williams 
>> wrote:
>> >
>> > > Hi,
>> > >
>> > > When talking about arrays my understanding that "step" typically
>> refers to
>> > > the number of items to jump when iterating (i.e. 1). However the eina
>> docs
>> > > use step on initialisation and on step_set to indicate "size" or
>> "count".
>> > >
>> > > Additionally eina_array_step_set takes a parameter sizeof_eina_array
>> which
>> > > is documented to need to be sizeof(Eina_Array), but obviously the
>> > > eina_array is the first parameter. Is there any reason why we have to
>> pass
>> > > that parameter?
>> > > What I am wonder is - can't we just create
>> "eina_array_size_set(uint)"?
>> > >
>> > > Thanks,
>> > > Andy
>> > > --
>> > > 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
>> --- Hell'O from Yverdoom
>>
>> Jérémy (jeyzu)
>>
>>
>> --
>> 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
>
-- 
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] Eina_Array step confusion

[Andrew Williams]

Hi,

Yeah, see my follow up, I got the wrong end of the stick so I will go fix
the docs instead.

Andy

On Thu, 16 Nov 2017 at 12:40 Jérémy Zurcher  wrote:

> Hello,
>
> On Thursday 16 November 2017  11:00, Andrew Williams wrote :
> > Hi,
> >
> > Are there any objections to me:
> >
> > 1) changing the parameter name on array creation to "size" from "step"
>
> this is not the size of the array that is set here,
> but the # of array elements used to automatically grow or shrink.
>
> see eina_array_remove or eina_array_grow called from eina_array_push
>
> > 2) adding eina_array_size_set which additionally does not take a sizeof
> > param
>
> that eina_array_size_set is weird,
> the sizeof check is here to ... detect a wrong pointer I guess
> plus if I'm not mistaken, it will silently leak if called on an non empty
> array !
>
> > 3) deprecate the eina_array_step_set as it's semantics are strange (as
> per
> > previous email).
> >
> > Thanks.
> > Andy
> >
> > On Tue, 14 Nov 2017 at 13:04 Andrew Williams 
> wrote:
> >
> > > Hi,
> > >
> > > When talking about arrays my understanding that "step" typically
> refers to
> > > the number of items to jump when iterating (i.e. 1). However the eina
> docs
> > > use step on initialisation and on step_set to indicate "size" or
> "count".
> > >
> > > Additionally eina_array_step_set takes a parameter sizeof_eina_array
> which
> > > is documented to need to be sizeof(Eina_Array), but obviously the
> > > eina_array is the first parameter. Is there any reason why we have to
> pass
> > > that parameter?
> > > What I am wonder is - can't we just create "eina_array_size_set(uint)"?
> > >
> > > Thanks,
> > > Andy
> > > --
> > > 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
> --- Hell'O from Yverdoom
>
> Jérémy (jeyzu)
>
>
> --
> 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] Eina_Array step confusion

[Jérémy Zurcher]

Hello,

On Thursday 16 November 2017  11:00, Andrew Williams wrote :
> Hi,
> 
> Are there any objections to me:
> 
> 1) changing the parameter name on array creation to "size" from "step"

this is not the size of the array that is set here,
but the # of array elements used to automatically grow or shrink.

see eina_array_remove or eina_array_grow called from eina_array_push

> 2) adding eina_array_size_set which additionally does not take a sizeof
> param

that eina_array_size_set is weird,
the sizeof check is here to ... detect a wrong pointer I guess
plus if I'm not mistaken, it will silently leak if called on an non empty array 
!

> 3) deprecate the eina_array_step_set as it's semantics are strange (as per
> previous email).
> 
> Thanks.
> Andy
> 
> On Tue, 14 Nov 2017 at 13:04 Andrew Williams  wrote:
> 
> > Hi,
> >
> > When talking about arrays my understanding that "step" typically refers to
> > the number of items to jump when iterating (i.e. 1). However the eina docs
> > use step on initialisation and on step_set to indicate "size" or "count".
> >
> > Additionally eina_array_step_set takes a parameter sizeof_eina_array which
> > is documented to need to be sizeof(Eina_Array), but obviously the
> > eina_array is the first parameter. Is there any reason why we have to pass
> > that parameter?
> > What I am wonder is - can't we just create "eina_array_size_set(uint)"?
> >
> > Thanks,
> > Andy
> > --
> > 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
--- Hell'O from Yverdoom

Jérémy (jeyzu)

--
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] Eina_Array step confusion

[Andrew Williams]

Wow, turns out this was a big misunderstanding, the docs for "step_set"
were confusing and I got the wrong end of the stick!

Instead of the elaborate plan above I will change the "step" parameter to
"grow_step" in init and in step_set and write some meaningful docs.
With that the meaning should be clear enough.

Apologies for the noise,
Andy

On Thu, 16 Nov 2017 at 11:00 Andrew Williams  wrote:

> Hi,
>
> Are there any objections to me:
>
> 1) changing the parameter name on array creation to "size" from "step"
> 2) adding eina_array_size_set which additionally does not take a sizeof
> param
> 3) deprecate the eina_array_step_set as it's semantics are strange (as per
> previous email).
>
> Thanks.
> Andy
>
> On Tue, 14 Nov 2017 at 13:04 Andrew Williams  wrote:
>
>> Hi,
>>
>> When talking about arrays my understanding that "step" typically refers
>> to the number of items to jump when iterating (i.e. 1). However the eina
>> docs use step on initialisation and on step_set to indicate "size" or
>> "count".
>>
>> Additionally eina_array_step_set takes a parameter sizeof_eina_array
>> which is documented to need to be sizeof(Eina_Array), but obviously the
>> eina_array is the first parameter. Is there any reason why we have to pass
>> that parameter?
>> What I am wonder is - can't we just create "eina_array_size_set(uint)"?
>>
>> Thanks,
>> Andy
>> --
>> http://andywilliams.me
>> http://ajwillia.ms
>>
> --
> 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] Eina_str split/join

[Andrew Williams]

Hi,

In addition to the above if 2) is the desired approach would there be any
opposition to changing eina_str_join and eina_str_join_static (and
potentially eina_str_join_len even) to be variadic?

Thanks,
Andy

On Thu, 16 Nov 2017 at 10:56 Andrew Williams  wrote:

> Hi.
>
> Looking at eina_str and I see handy split and join methods.
> Split returns an array but join accepts only two strings to join.
> This feels unbalanced and I wonder what people feel about this. Most libs
> seem to balance it by passing an array to join().
>
> Looking through efl it seems that neither str_join or str_join_static are
> used (str_join_len is used in file_join but it's understanable that passing
> lengths as well makes an array less attractive).
>
> I have two potential proposals:
> 1) to change the signature of eina_str_join (and eina_str_join_static) to
> pass an array
> 2) add eina_str_join_array and eina_str_join_static_array that perform the
> expected operation.
>
> Any thoughts from the team?
> Andy
> --
> 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] Eina_Array step confusion

[Andrew Williams]

Hi,

Are there any objections to me:

1) changing the parameter name on array creation to "size" from "step"
2) adding eina_array_size_set which additionally does not take a sizeof
param
3) deprecate the eina_array_step_set as it's semantics are strange (as per
previous email).

Thanks.
Andy

On Tue, 14 Nov 2017 at 13:04 Andrew Williams  wrote:

> Hi,
>
> When talking about arrays my understanding that "step" typically refers to
> the number of items to jump when iterating (i.e. 1). However the eina docs
> use step on initialisation and on step_set to indicate "size" or "count".
>
> Additionally eina_array_step_set takes a parameter sizeof_eina_array which
> is documented to need to be sizeof(Eina_Array), but obviously the
> eina_array is the first parameter. Is there any reason why we have to pass
> that parameter?
> What I am wonder is - can't we just create "eina_array_size_set(uint)"?
>
> Thanks,
> Andy
> --
> 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

[E-devel] Eina_str split/join

[Andrew Williams]

Hi.

Looking at eina_str and I see handy split and join methods.
Split returns an array but join accepts only two strings to join.
This feels unbalanced and I wonder what people feel about this. Most libs
seem to balance it by passing an array to join().

Looking through efl it seems that neither str_join or str_join_static are
used (str_join_len is used in file_join but it's understanable that passing
lengths as well makes an array less attractive).

I have two potential proposals:
1) to change the signature of eina_str_join (and eina_str_join_static) to
pass an array
2) add eina_str_join_array and eina_str_join_static_array that perform the
expected operation.

Any thoughts from the team?
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