Re: [E-devel] [Efl-technical-documentation] Site statistics
On 12/23/2017 09:56 AM, Vincent Torri wrote: On Thu, Dec 21, 2017 at 8:54 AM, Pierre Couderc wrote: On 12/19/2017 09:44 AM, Vincent Torri wrote: I am glad to have developed my first application under efl (eegrep = multidimensional grep). With legacy API. The more there are EFL apps, the better. But the project should also do advertising (phoronix, /., linuxfr.org for french, reddit, lwn, etc...) imho Mmm, maybe... But : - I am not fully sure eegrep has a big interest... maybe some people could find it useful. Is there any link or doc ? Not soon as it is too much alpha release for the moment... - How people can use it ? That is, it needs efl. How potential users will install efl ? I am not speaking of the members of this mailing list, but the rest of the world...? if eegrep is in a linux distro, then efl will be installed de facto as a dependency of eegrep Mmm, ok. -- 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-technical-documentation] Site statistics
On Thu, Dec 21, 2017 at 8:54 AM, Pierre Couderc wrote: > On 12/19/2017 09:44 AM, Vincent Torri wrote: >>> >>> >>> I am glad to have developed my first application under efl (eegrep = >>> multidimensional grep). >>> With legacy API. >>> >> The more there are EFL apps, the better. >> >> But the project should also do advertising (phoronix, /., linuxfr.org >> for french, reddit, lwn, etc...) imho >> > Mmm, maybe... But : > - I am not fully sure eegrep has a big interest... maybe some people could find it useful. Is there any link or doc ? > - How people can use it ? That is, it needs efl. How potential users will > install efl ? I am not speaking of the members of this mailing list, but the > rest of the world...? if eegrep is in a linux distro, then efl will be installed de facto as a dependency of eegrep Vincent -- 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-technical-documentation] Site statistics
On 12/19/2017 07:05 AM, Pierre Couderc wrote: I am glad to have developed my first application under efl (eegrep = multidimensional grep). With legacy API. Thanks for all your comments. I am glad that you all encourage my choice... ;) -- 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-technical-documentation] Site statistics
On 12/19/2017 09:44 AM, Vincent Torri wrote: I am glad to have developed my first application under efl (eegrep = multidimensional grep). With legacy API. The more there are EFL apps, the better. But the project should also do advertising (phoronix, /., linuxfr.org for french, reddit, lwn, etc...) imho Mmm, maybe... But : - I am not fully sure eegrep has a big interest... - How people can use it ? That is, it needs efl. How potential users will install efl ? I am not speaking of the members of this mailing list, but the rest of the world...? -- 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-technical-documentation] Site statistics
On 12/19/2017 08:15 PM, William L. Thomson Jr. wrote: On Tue, 19 Dec 2017 07:05:28 +0100 Pierre Couderc wrote: I am glad to have developed my first application under efl (eegrep = multidimensional grep). With legacy API. Should I regret not having used Gnome ? Not to mention the treatment for new people learning to develop apps wit EFL Mmm, sure I had - and I still have - some difficults to enter in the doc of efl. The best basic tutorial I have found after the "hello word" was old but efficient http://louis-du-verdier.developpez.com/efl/debuter/ alla Descartes... Maybe, the tutorial part of the e site is a bit fragmented. But I never failed to get help on the user list a few hours after each of my questions, and usually from the Rasterman himself ! I understand very well that the last git is unstable. I use git but only tagged releases. Thanks all brave developers. -- 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-technical-documentation] Site statistics
On Tue, 19 Dec 2017 12:31:04 -0500 Cedric Bail said: > The open question will be for bindings, especially the one that have already > an existing user base. I would love to see the python bindings allow for the > same smooth transition as for the C API, for the same reason as we already I think this would make sense. At the start there is a "hard break" between current python bindings and the eo generated python bindings (if they exist eventually in a usable form). python bindings should somehow generate so that you can use the new "hard break" bindings OR the older manual python bindings and even migrate object by object... maybe? -- - 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-technical-documentation] Site statistics
On Tue, 19 Dec 2017 14:15:33 -0500 "William L. Thomson Jr." wrote: > On Tue, 19 Dec 2017 07:05:28 +0100 > Pierre Couderc wrote: > > > I am glad to have developed my first application under efl (eegrep > > = multidimensional grep). > > With legacy API. > > Should I regret not having used Gnome ? > > Not at all, stuff like the following is wonderful! New one today > https://github.com/Obsidian-StudiosInc/ecrire/issues > > Not to mention the treatment for new people learning to develop apps > wit EFL. Rather than help just see rudeness, kicked from IRC, and > eventually banned from phab... Basically made it as far as I have > figuring everything out on my own. I cannot thank a single person > surely not for anything that was not trivial. I do have major regrets > in my choice of tech NOT my conduct. That is easy to justify... I love it when others prove my point. No professional will want to put up with this madness... https://github.com/Obsidian-StudiosInc/ecrire/issues/29 One EFL devs says one thing, use elm_code, another says not to... I regretted that since day one. Do I switch back to elm_enty or just go do GTK or other development? EFL seems to be a total mess. Not like anyone has had interest in ecrire for years. Most the stuff I was looking to do, epad did outside of E community via python-elm-extensions... https://github.com/JeffHoogland/python-elm-extensions Which is ironic as tabs is a feature request for ecrire. Thus far seems elm lacks tabs and other things. Maybe a way to replicate tabs. But there is nothing tab related in elm_tests... Once again I can leave, be blocked, etc. That will not improve anything. Others will run into what I have just the same. You can listen or ignore. I assume you will ignore and this mess will continue on. Yet you assume that will attract others? You did not attract me, I came on my own. I have been nothing but encouraged to stop and leave since day 1 Why no apps exist in EFL, nor is anyone looking to do apps in EFL, Over many years... Enlightenment has been around for 20 or so years. Why no one runs it, few distros support etc. That is my fault right? That can change, if the attitude of the development community changes. -- William L. Thomson Jr. -- William L. Thomson Jr. pgpx0egHZvpiA.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Efl-technical-documentation] Site statistics
On Tue, 19 Dec 2017 07:05:28 +0100 Pierre Couderc wrote: > I am glad to have developed my first application under efl (eegrep = > multidimensional grep). > With legacy API. > Should I regret not having used Gnome ? Not at all, stuff like the following is wonderful! New one today https://github.com/Obsidian-StudiosInc/ecrire/issues Not to mention the treatment for new people learning to develop apps wit EFL. Rather than help just see rudeness, kicked from IRC, and eventually banned from phab... Basically made it as far as I have figuring everything out on my own. I cannot thank a single person surely not for anything that was not trivial. I do have major regrets in my choice of tech NOT my conduct. That is easy to justify... I bet I can use GTK apps I developed years ago ~06 with little change for GTK2 maybe even GTK3. I have little to no confidence a EFL app will work without major issues or changes some 10+ year later. There are numerous issues and more showing up within my first year of EFL. Given its been in development for who knows how long for E. Which EFL changes seem to be blowing up E. I cannot even use E22 anymore on my desktop. Also for what ever reason Pinentry was released without the EFL interface. Despite 2 new ones going in within the last year, FLTK and TQT in addition to QT and GTK ones. https://dev.gnupg.org/T3279#106938 https://github.com/gpg/pinentry I never got an answer why EFL was left out. I can only assume issues with EFL in what ever distro. Not conduct as I had regular communication on list. I thought it was committed when advising TQT author on some submissions on list... For what ever reason others have no interest in EFL. I withdrew my submission. Mike can proceed with his and wait another year or what ever. I have it for my needs. I care less if others have a EFL interface to Pinentry. Seems that is how most feel. I think the grab aspect did not help. Given that is not possible with Wayland and I was told for Ecrire and other things here not to bind EFL apps to ecore_x. Likely should have ignored EFL devs and just done what was needed to make gnupg devs happy. Just another example. I see nothing being done to help EFL application developers nor EFL application development. My experience has been worse than having healthy adult teeth pulled for no reason. Any discussions I find some what laughable. As most have been directly responsible for giving me a hard miserable time in my first year around EFL. Not to mention all EFL developers. Not sure I have come across anyone else like me just doing EFL app development who is NOT a E or EFL developer furthering EFL. Lots of people patting each other on the back. Not receptive to feedback or criticism from others who are not part of the group. None the less since I am insane I continue on, I have not jumped shipped yet... Despite miss-treatment and how I am portrayed. -- William L. Thomson Jr. pgpfrwH7OAn2y.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Efl-technical-documentation] Site statistics
Hello Pierre, My intent was never to suggest that. I was only suggesting that the distinctions within the api could be confusing enough that a new developer could easily mistake it or misunderstand it and decide not to use either. Andrew, myself, and most other developers involved have used and continued to use the legacy api for our applications including Enlightenment. EFL is the best choice! My apologies :-) Stephen On Tue, Dec 19, 2017, 11:56 AM Andrew Williams wrote: > Hi Pierre, > > I, as most others here, think that picking EFL is a great choice. > We are in a time of flux but there is no reason to regret having used the > current stable (legacy) API. > As cedric notes this will be supported for many years and we will be > offering a smooth transition to the new Unified API as and when it is > ready. > There are many applications built on the API that will be transitioning > with you. > > Thanks for joining us :) > Andy > > On Tue, 19 Dec 2017 at 06:06 Pierre Couderc wrote: > > > On 12/18/2017 05:28 PM, Stephen Houston wrote: > > > "If we are to de-prioritise the new API at the cost of further > > development > > > of legacy APIs then we are prolonging the period of time in which we > > > request developers to use an API which we are intending to > discontinue." > > > > > > I don't disagree. But if we de-prioritize the old API at the cost of > > > furthering the development of new API then we are encouraging the > > > development of unstable apis that are not complete and won't have a > > stable > > > release for X amount of time. Which isn't exactly ideal either. I > don't > > > think either option sounds great and it's going to get to a point of > > "Don't > > > use that api, it will be discontinued, but don't use that api either > > > because it is unstable, incomplete, and will change". New developers > > will > > > look at that say... uh... okay so what do I use? Something other than > > EFL. > > > > > > > > I am glad to have developed my first application under efl (eegrep = > > multidimensional grep). > > With legacy API. > > Should I regret not having used Gnome ? > > > > PC > > > > > > > > > -- > > 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 > -- 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-technical-documentation] Site statistics
Hi Pierre, I, as most others here, think that picking EFL is a great choice. We are in a time of flux but there is no reason to regret having used the current stable (legacy) API. As cedric notes this will be supported for many years and we will be offering a smooth transition to the new Unified API as and when it is ready. There are many applications built on the API that will be transitioning with you. Thanks for joining us :) Andy On Tue, 19 Dec 2017 at 06:06 Pierre Couderc wrote: > On 12/18/2017 05:28 PM, Stephen Houston wrote: > > "If we are to de-prioritise the new API at the cost of further > development > > of legacy APIs then we are prolonging the period of time in which we > > request developers to use an API which we are intending to discontinue." > > > > I don't disagree. But if we de-prioritize the old API at the cost of > > furthering the development of new API then we are encouraging the > > development of unstable apis that are not complete and won't have a > stable > > release for X amount of time. Which isn't exactly ideal either. I don't > > think either option sounds great and it's going to get to a point of > "Don't > > use that api, it will be discontinued, but don't use that api either > > because it is unstable, incomplete, and will change". New developers > will > > look at that say... uh... okay so what do I use? Something other than > EFL. > > > > > I am glad to have developed my first application under efl (eegrep = > multidimensional grep). > With legacy API. > Should I regret not having used Gnome ? > > PC > > > > -- > 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] [Efl-technical-documentation] Site statistics
> Original Message > Subject: Re: [E-devel] [Efl-technical-documentation] Site statistics > Local Time: December 18, 2017 10:05 PM > UTC Time: December 19, 2017 6:05 AM > From: pie...@couderc.eu > To: enlightenment-devel@lists.sourceforge.net > > On 12/18/2017 05:28 PM, Stephen Houston wrote: > >> "If we are to de-prioritise the new API at the cost of further development >> of legacy APIs then we are prolonging the period of time in which we >> request developers to use an API which we are intending to discontinue." >> I don't disagree. But if we de-prioritize the old API at the cost of >> furthering the development of new API then we are encouraging the >> development of unstable apis that are not complete and won't have a stable >> release for X amount of time. Which isn't exactly ideal either. I don't >> think either option sounds great and it's going to get to a point of "Don't >> use that api, it will be discontinued, but don't use that api either >> because it is unstable, incomplete, and will change". New developers will >> look at that say... uh... okay so what do I use? Something other than EFL. > > I am glad to have developed my first application under efl (eegrep = > multidimensional grep). > With legacy API. > Should I regret not having used Gnome ? My personnal take on where we are heading with all of this, is that legacy API will still be part of EFL and be still maintained for the next 5 years at least. As the new unified API can be used in a legacy application allowing for a smooth transition out of legacy. It does seems to me that the unified API does allow for new features that were not easy to do in the legacy API (animator as an event on the object for example) which is why I expect going forward new feature to come on the unified API first and maybe only. The open question will be for bindings, especially the one that have already an existing user base. I would love to see the python bindings allow for the same smooth transition as for the C API, for the same reason as we already have a developers base that we shouldn't screw up. For other bindings, they will be 100% around the new unified API. I hope this idea is shared with most of the developers here and that we move forward with this in mind. 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] [Efl-technical-documentation] Site statistics
On Tue, Dec 19, 2017 at 7:05 AM, Pierre Couderc wrote: > On 12/18/2017 05:28 PM, Stephen Houston wrote: >> >> "If we are to de-prioritise the new API at the cost of further development >> of legacy APIs then we are prolonging the period of time in which we >> request developers to use an API which we are intending to discontinue." >> >> I don't disagree. But if we de-prioritize the old API at the cost of >> furthering the development of new API then we are encouraging the >> development of unstable apis that are not complete and won't have a stable >> release for X amount of time. Which isn't exactly ideal either. I don't >> think either option sounds great and it's going to get to a point of >> "Don't >> use that api, it will be discontinued, but don't use that api either >> because it is unstable, incomplete, and will change". New developers will >> look at that say... uh... okay so what do I use? Something other than EFL. >> >> > I am glad to have developed my first application under efl (eegrep = > multidimensional grep). > With legacy API. > Should I regret not having used Gnome ? The more there are EFL apps, the better. But the project should also do advertising (phoronix, /., linuxfr.org for french, reddit, lwn, etc...) imho Vincent -- 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-technical-documentation] Site statistics
On 12/18/2017 05:28 PM, Stephen Houston wrote: "If we are to de-prioritise the new API at the cost of further development of legacy APIs then we are prolonging the period of time in which we request developers to use an API which we are intending to discontinue." I don't disagree. But if we de-prioritize the old API at the cost of furthering the development of new API then we are encouraging the development of unstable apis that are not complete and won't have a stable release for X amount of time. Which isn't exactly ideal either. I don't think either option sounds great and it's going to get to a point of "Don't use that api, it will be discontinued, but don't use that api either because it is unstable, incomplete, and will change". New developers will look at that say... uh... okay so what do I use? Something other than EFL. I am glad to have developed my first application under efl (eegrep = multidimensional grep). With legacy API. Should I regret not having used Gnome ? PC -- 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-technical-documentation] Site statistics
Hi, It is indeed confusing. We have done our best to describe the situation in the docs and given users the choice. What would be really helpful would be a timeline or plan so that those making the choice can make it an informed one. Andrew On Mon, 18 Dec 2017 at 16:28 Stephen Houston wrote: > " > If we are to de-prioritise the new API at the cost of further development > of legacy APIs then we are prolonging the period of time in which we > request developers to use an API which we are intending to discontinue." > > I don't disagree. But if we de-prioritize the old API at the cost of > furthering the development of new API then we are encouraging the > development of unstable apis that are not complete and won't have a stable > release for X amount of time. Which isn't exactly ideal either. I don't > think either option sounds great and it's going to get to a point of "Don't > use that api, it will be discontinued, but don't use that api either > because it is unstable, incomplete, and will change". New developers will > look at that say... uh... okay so what do I use? Something other than EFL. > > On Mon, Dec 18, 2017 at 10:04 AM Andrew Williams > wrote: > >> Hi, >> >> Apologies I was using "legacy" by way of definition to separate it from >> "unified" APIs. >> We are now fighting a battle of multiple focuses - Some tell me that we >> are pushing the Unified / interfaces as fast as we can and anything (such >> as release) would slow us down. Others are reporting that legacy is our >> main area of development. >> I am confused. If I am confused then anyone coming to the project surely >> would be too. >> If we are to de-prioritise the new API at the cost of further development >> of legacy APIs then we are prolonging the period of time in which we >> request developers to use an API which we are intending to discontinue. >> >> Whether you think that the development of BETA is skewing the results >> there is the remaining issue that our "stable" API appears to have had a >> total of 45 page hits in 2 weeks. >> >> I wonder if we have any metrics on the number of users relying on the >> existing API (outside of our own apps). >> >> Andrew >> >> On Mon, 18 Dec 2017 at 15:44 Stephen Houston >> wrote: >> >>> I disagree with #1. It's not Legacy API until it is actually, you know, >>> legacy. Who knows how long the "beta" api will be before released and how >>> long it will be until there is a stable release of it that will work full >>> featured for application, especially elementary, development. To not >>> provide improved docs with the legacy api, is to say that the primary way >>> developers can get involved over the next couple years, the legacy api, >>> isn't worth anything. All current apps, including Enlightenment, are using >>> the legacy api, because that is what is stable, and that is how we are >>> still going to get people involved for the foreseeable future (unless they >>> are interested in working on the actual beta api implementation). If >>> anything I would argue that the focus should be more on the legacy api than >>> the beta api, since no one uses the beta api, and it isn't stable. Just a >>> personal take. I would venture to say a big reason the hits are coming in >>> more on the beta api is because that is currently receiving the majority of >>> the active development and you are getting hits from those developers. >>> >>> On Mon, Dec 18, 2017 at 6:23 AM Andrew Williams via >>> Efl-technical-documentation >>> wrote: >>> Hi all. Since adding Google Analytics a while back I have some interesting statistics that I thought I would share: 1) Very few people read our Stable API documentation - around 0.5% of our page hits 2) Over 5% of the page hits are already for the beta API documentation 3) Most of the hits to /docs seem to result in a referral to /develop 4) Nearly 40% of people landing on our home page leave right away 5) Terminology is the most popular app (by page hits) and Edi is second (1/4 times the hits) then ephoto (1/4 again) Not all of this requires any action but here is the action plan: 1) I am not intending to put any further effort into our legacy API other than the extraction of eina and eo for the Beta API docs 2) We can expect more people to be trying to use our Beta API - do we need to prepare for this or should we put up more obvious warnings about attempting? 3) I think it is time that the main "Develop" link goes to the /develop/ dokuwiki. The link to phab exists on the /contrib page where it belongs 4) We should find a way to make our home page more appealing - when loaded on an average monitor you need to be full screen to see anything more than the "Window manager" section. 5) For our about page we may need to tell a better story about how it all fits together. Otherwise it's E & EFL and a list of apps - not the ho
Re: [E-devel] [Efl-technical-documentation] Site statistics
"If we are to de-prioritise the new API at the cost of further development of legacy APIs then we are prolonging the period of time in which we request developers to use an API which we are intending to discontinue." I don't disagree. But if we de-prioritize the old API at the cost of furthering the development of new API then we are encouraging the development of unstable apis that are not complete and won't have a stable release for X amount of time. Which isn't exactly ideal either. I don't think either option sounds great and it's going to get to a point of "Don't use that api, it will be discontinued, but don't use that api either because it is unstable, incomplete, and will change". New developers will look at that say... uh... okay so what do I use? Something other than EFL. On Mon, Dec 18, 2017 at 10:04 AM Andrew Williams wrote: > Hi, > > Apologies I was using "legacy" by way of definition to separate it from > "unified" APIs. > We are now fighting a battle of multiple focuses - Some tell me that we > are pushing the Unified / interfaces as fast as we can and anything (such > as release) would slow us down. Others are reporting that legacy is our > main area of development. > I am confused. If I am confused then anyone coming to the project surely > would be too. > If we are to de-prioritise the new API at the cost of further development > of legacy APIs then we are prolonging the period of time in which we > request developers to use an API which we are intending to discontinue. > > Whether you think that the development of BETA is skewing the results > there is the remaining issue that our "stable" API appears to have had a > total of 45 page hits in 2 weeks. > > I wonder if we have any metrics on the number of users relying on the > existing API (outside of our own apps). > > Andrew > > On Mon, 18 Dec 2017 at 15:44 Stephen Houston > wrote: > >> I disagree with #1. It's not Legacy API until it is actually, you know, >> legacy. Who knows how long the "beta" api will be before released and how >> long it will be until there is a stable release of it that will work full >> featured for application, especially elementary, development. To not >> provide improved docs with the legacy api, is to say that the primary way >> developers can get involved over the next couple years, the legacy api, >> isn't worth anything. All current apps, including Enlightenment, are using >> the legacy api, because that is what is stable, and that is how we are >> still going to get people involved for the foreseeable future (unless they >> are interested in working on the actual beta api implementation). If >> anything I would argue that the focus should be more on the legacy api than >> the beta api, since no one uses the beta api, and it isn't stable. Just a >> personal take. I would venture to say a big reason the hits are coming in >> more on the beta api is because that is currently receiving the majority of >> the active development and you are getting hits from those developers. >> >> On Mon, Dec 18, 2017 at 6:23 AM Andrew Williams via >> Efl-technical-documentation >> wrote: >> >>> Hi all. >>> >>> Since adding Google Analytics a while back I have some interesting >>> statistics that I thought I would share: >>> >>> 1) Very few people read our Stable API documentation - around 0.5% of >>> our page hits >>> 2) Over 5% of the page hits are already for the beta API documentation >>> 3) Most of the hits to /docs seem to result in a referral to /develop >>> 4) Nearly 40% of people landing on our home page leave right away >>> 5) Terminology is the most popular app (by page hits) and Edi is second >>> (1/4 times the hits) then ephoto (1/4 again) >>> >>> Not all of this requires any action but here is the action plan: >>> 1) I am not intending to put any further effort into our legacy API >>> other than the extraction of eina and eo for the Beta API docs >>> 2) We can expect more people to be trying to use our Beta API - do we >>> need to prepare for this or should we put up more obvious warnings about >>> attempting? >>> 3) I think it is time that the main "Develop" link goes to the /develop/ >>> dokuwiki. The link to phab exists on the /contrib page where it belongs >>> 4) We should find a way to make our home page more appealing - when >>> loaded on an average monitor you need to be full screen to see anything >>> more than the "Window manager" section. >>> 5) For our about page we may need to tell a better story about how it >>> all fits together. Otherwise it's E & EFL and a list of apps - not the how >>> or why of what we are doing... >>> >>> Please shout if you disagree with any of these action points :) >>> >>> Andrew >>> -- >>> http://andywilliams.me >>> http://ajwillia.ms >>> >> ___ >>> Efl-technical-documentation mailing list >>> efl-technical-documentat...@lists.s-osg.org >>> http://lists.s-osg.org/listinfo/efl-technical-documentation >>> >> -- > ht
Re: [E-devel] [Efl-technical-documentation] Site statistics
Hi, Apologies I was using "legacy" by way of definition to separate it from "unified" APIs. We are now fighting a battle of multiple focuses - Some tell me that we are pushing the Unified / interfaces as fast as we can and anything (such as release) would slow us down. Others are reporting that legacy is our main area of development. I am confused. If I am confused then anyone coming to the project surely would be too. If we are to de-prioritise the new API at the cost of further development of legacy APIs then we are prolonging the period of time in which we request developers to use an API which we are intending to discontinue. Whether you think that the development of BETA is skewing the results there is the remaining issue that our "stable" API appears to have had a total of 45 page hits in 2 weeks. I wonder if we have any metrics on the number of users relying on the existing API (outside of our own apps). Andrew On Mon, 18 Dec 2017 at 15:44 Stephen Houston wrote: > I disagree with #1. It's not Legacy API until it is actually, you know, > legacy. Who knows how long the "beta" api will be before released and how > long it will be until there is a stable release of it that will work full > featured for application, especially elementary, development. To not > provide improved docs with the legacy api, is to say that the primary way > developers can get involved over the next couple years, the legacy api, > isn't worth anything. All current apps, including Enlightenment, are using > the legacy api, because that is what is stable, and that is how we are > still going to get people involved for the foreseeable future (unless they > are interested in working on the actual beta api implementation). If > anything I would argue that the focus should be more on the legacy api than > the beta api, since no one uses the beta api, and it isn't stable. Just a > personal take. I would venture to say a big reason the hits are coming in > more on the beta api is because that is currently receiving the majority of > the active development and you are getting hits from those developers. > > On Mon, Dec 18, 2017 at 6:23 AM Andrew Williams via > Efl-technical-documentation > wrote: > >> Hi all. >> >> Since adding Google Analytics a while back I have some interesting >> statistics that I thought I would share: >> >> 1) Very few people read our Stable API documentation - around 0.5% of our >> page hits >> 2) Over 5% of the page hits are already for the beta API documentation >> 3) Most of the hits to /docs seem to result in a referral to /develop >> 4) Nearly 40% of people landing on our home page leave right away >> 5) Terminology is the most popular app (by page hits) and Edi is second >> (1/4 times the hits) then ephoto (1/4 again) >> >> Not all of this requires any action but here is the action plan: >> 1) I am not intending to put any further effort into our legacy API other >> than the extraction of eina and eo for the Beta API docs >> 2) We can expect more people to be trying to use our Beta API - do we >> need to prepare for this or should we put up more obvious warnings about >> attempting? >> 3) I think it is time that the main "Develop" link goes to the /develop/ >> dokuwiki. The link to phab exists on the /contrib page where it belongs >> 4) We should find a way to make our home page more appealing - when >> loaded on an average monitor you need to be full screen to see anything >> more than the "Window manager" section. >> 5) For our about page we may need to tell a better story about how it all >> fits together. Otherwise it's E & EFL and a list of apps - not the how or >> why of what we are doing... >> >> Please shout if you disagree with any of these action points :) >> >> Andrew >> -- >> http://andywilliams.me >> http://ajwillia.ms >> > ___ >> Efl-technical-documentation mailing list >> efl-technical-documentat...@lists.s-osg.org >> http://lists.s-osg.org/listinfo/efl-technical-documentation >> > -- 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-technical-documentation] Site statistics
With 4 and 5, I think this should be sent in a follow up to cedric's website redesign thread. As I think, and a lot of people agree, the look and feel of the website needs a lot more work than just a few layout/content changes. On Mon, Dec 18, 2017 at 9:43 AM Stephen Houston wrote: > I disagree with #1. It's not Legacy API until it is actually, you know, > legacy. Who knows how long the "beta" api will be before released and how > long it will be until there is a stable release of it that will work full > featured for application, especially elementary, development. To not > provide improved docs with the legacy api, is to say that the primary way > developers can get involved over the next couple years, the legacy api, > isn't worth anything. All current apps, including Enlightenment, are using > the legacy api, because that is what is stable, and that is how we are > still going to get people involved for the foreseeable future (unless they > are interested in working on the actual beta api implementation). If > anything I would argue that the focus should be more on the legacy api than > the beta api, since no one uses the beta api, and it isn't stable. Just a > personal take. I would venture to say a big reason the hits are coming in > more on the beta api is because that is currently receiving the majority of > the active development and you are getting hits from those developers. > > On Mon, Dec 18, 2017 at 6:23 AM Andrew Williams via > Efl-technical-documentation > wrote: > >> Hi all. >> >> Since adding Google Analytics a while back I have some interesting >> statistics that I thought I would share: >> >> 1) Very few people read our Stable API documentation - around 0.5% of our >> page hits >> 2) Over 5% of the page hits are already for the beta API documentation >> 3) Most of the hits to /docs seem to result in a referral to /develop >> 4) Nearly 40% of people landing on our home page leave right away >> 5) Terminology is the most popular app (by page hits) and Edi is second >> (1/4 times the hits) then ephoto (1/4 again) >> >> Not all of this requires any action but here is the action plan: >> 1) I am not intending to put any further effort into our legacy API other >> than the extraction of eina and eo for the Beta API docs >> 2) We can expect more people to be trying to use our Beta API - do we >> need to prepare for this or should we put up more obvious warnings about >> attempting? >> 3) I think it is time that the main "Develop" link goes to the /develop/ >> dokuwiki. The link to phab exists on the /contrib page where it belongs >> 4) We should find a way to make our home page more appealing - when >> loaded on an average monitor you need to be full screen to see anything >> more than the "Window manager" section. >> 5) For our about page we may need to tell a better story about how it all >> fits together. Otherwise it's E & EFL and a list of apps - not the how or >> why of what we are doing... >> >> Please shout if you disagree with any of these action points :) >> >> Andrew >> -- >> http://andywilliams.me >> http://ajwillia.ms >> ___ >> Efl-technical-documentation mailing list >> efl-technical-documentat...@lists.s-osg.org >> http://lists.s-osg.org/listinfo/efl-technical-documentation >> > -- 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-technical-documentation] Site statistics
I disagree with #1. It's not Legacy API until it is actually, you know, legacy. Who knows how long the "beta" api will be before released and how long it will be until there is a stable release of it that will work full featured for application, especially elementary, development. To not provide improved docs with the legacy api, is to say that the primary way developers can get involved over the next couple years, the legacy api, isn't worth anything. All current apps, including Enlightenment, are using the legacy api, because that is what is stable, and that is how we are still going to get people involved for the foreseeable future (unless they are interested in working on the actual beta api implementation). If anything I would argue that the focus should be more on the legacy api than the beta api, since no one uses the beta api, and it isn't stable. Just a personal take. I would venture to say a big reason the hits are coming in more on the beta api is because that is currently receiving the majority of the active development and you are getting hits from those developers. On Mon, Dec 18, 2017 at 6:23 AM Andrew Williams via Efl-technical-documentation wrote: > Hi all. > > Since adding Google Analytics a while back I have some interesting > statistics that I thought I would share: > > 1) Very few people read our Stable API documentation - around 0.5% of our > page hits > 2) Over 5% of the page hits are already for the beta API documentation > 3) Most of the hits to /docs seem to result in a referral to /develop > 4) Nearly 40% of people landing on our home page leave right away > 5) Terminology is the most popular app (by page hits) and Edi is second > (1/4 times the hits) then ephoto (1/4 again) > > Not all of this requires any action but here is the action plan: > 1) I am not intending to put any further effort into our legacy API other > than the extraction of eina and eo for the Beta API docs > 2) We can expect more people to be trying to use our Beta API - do we need > to prepare for this or should we put up more obvious warnings about > attempting? > 3) I think it is time that the main "Develop" link goes to the /develop/ > dokuwiki. The link to phab exists on the /contrib page where it belongs > 4) We should find a way to make our home page more appealing - when loaded > on an average monitor you need to be full screen to see anything more than > the "Window manager" section. > 5) For our about page we may need to tell a better story about how it all > fits together. Otherwise it's E & EFL and a list of apps - not the how or > why of what we are doing... > > Please shout if you disagree with any of these action points :) > > Andrew > -- > http://andywilliams.me > http://ajwillia.ms > ___ > Efl-technical-documentation mailing list > efl-technical-documentat...@lists.s-osg.org > http://lists.s-osg.org/listinfo/efl-technical-documentation > -- 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
