<div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">Hi</div><div class="gmail_extra"><br><div class="gmail_quote">On 16 May 2016 at 17:07, Sam P. <span dir="ltr"><<a href="mailto:sam@sam.today" target="_blank">sam@sam.today</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>Lionel - we've already discussed this before. </div></blockquote><div><br></div><div>Sure, and while I posited a conclusion (that JS is strategic but Py is perhaps richer today) I am happy to revise it. In particular my reasoning for Py was that the Sugar Desktop has 100,000s of known daily active users in schools, but Sugarizer appears to have no schools using it daily yet, and since the font editor GSOC is about core systems work, it seemed to me to make more sense to work with the Sugar desktop - even though I dearly wish the core systems focus was on Sugarizer :) <br><br>But I realised after posting this reasoning that sugar-web makes it possible to package a JS app for the Sugar desktop, so the addressable market is actually the same for JS and Py based Activities. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div> Python is objectively better for every activity; Gtk+ is more stable, has more stability, creates better code quality and supports collaboration.<br></div></blockquote><div><br></div><div>I don't know if a PyGTK based is more stable than a web based UI; but it seems both are very stable. <br></div><div><br></div><div>Code quality is not related to language</div><div><br></div><div>It seems odd to me to imply that web applications do not support real time collaboration. </div><div><br></div><div>What I can say is that, in the last 2 weeks since I suggested we try a GTK approach, Yash and Eli have found it difficult to learn how to create a font editor prototype with PyGTK in the last week, but both already have web development skills that mean that they could have spent a week developing a prototype instead of learning a new toolset.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>
But for the font editor world, python has even more advantages.  There are tonnes of libraries for font editing and none of them are for the 'JavaScript' language.  They are for python.<br></div></blockquote><div><br></div><div>In the last 3 years myself and some others were able to fund the development of JS libraries that match the python ones (sources: defcon / ufoJS, binaries: fontTools / OpenType.js) For a while the JS ones were ahead (with source to binary compilation) and now they are more or less at parity. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>
I don't think it will ever be ported to sugarizer even.  Sugatizer is just cheap in comparison to the smooth and feature rich sugar environment.  Who wants to edit fonts in a browser?</div></blockquote></div><br clear="all"><div>I think this is the future, which is why I funded <a href="http://www.metapolator.com">www.metapolator.com</a> heavily. </div><div><br></div>-- <br><div class="gmail_signature">Cheers<br>Dave</div>
</div></div>