<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">This thread illustrates the crazy
situation we have put ourselves in. Now we don't use github
because we have too many repositories.<br>
<br>
The simple solution is to separate repositories into a Sugar
collection and an Activity collection. The use of fructose (and
honey,...) should be deprecated. The terms have no meaning and are
confusing. Can you imagine the user launching the
chat-fructose.activity (not to mention translating 'fructose' to
100+ languages). Searching 300+ activities is not necessary if
they are sorted alphabetically (abacus.activity, write.activity)
and would be made easier if the activity names in ASLO matched the
repostory names.<br>
<br>
The repositories in Sugar should be ones required for a build. A
build requires co-ordinated use of multiple repositories.
Activities should be independent of each other and of Sugar
builds. The maker of a build selects the activities to include in
the build from those released.<br>
<br>
Browse illustrates the problem with using common dependencies. Now
it is critical to use the Browse version which works with the
right build. This is contrary to the spirit of activities - that
Sugar exists to provide the execution environment for activities.
Meanwhile, the functionality of Browse becomes increasingly
impaired. For example, Browse cannot download or resume html
pages. It does not have configuration capabilities. A 404 error
triggers a google search even when the connection is to a school
server. It is not able to display console.log statements in
javascript. It is not able to show the source code of a web page.
It is not capable of saving a web page in the Journal (it saves
urls of open tabs which is normally useless and consumes time
discovering that the XO is not online). <br>
<br>
Meanwhile, moving development support to github is making it more
difficult for users to modify their own installation. First, we
chose 'view source' which suggests 'look but don't touch'. Then we
wrapped Python programming in pippy where a user can create an
activity by pippy magic. This, of course, hides the process from
the user -- similar to the effect of using Dreamweaver to create
html/css. Now we have taken development support away from the user
who does not have ready internet access (i.e. more than half our
users).<br>
<br>
Tomorrow I am scheduled to give a class to secondary school
students on programming. The students are already capable of using
the Terminal activity to navigate and manage the XO file system.
Generally I encourage them to use the Documents folder since it is
visible in the Journal activity. <br>
<br>
I plan to start with the Hello World activity. The repository for
this activity is hello-world-fork-master - this for the activity
intended to illustrate the simplest possible activity!!! To
display 'Hello World!' on the screen takes 42 lines of python
code. The hello-world-fork-master repository is a conversion of
the original to gtk3 but continues to be version 6!<br>
<br>
I have moved the toolbar related code to a separate file -
toolbar.py. This file is imported into activity.py. This reduces
the number of lines from 42 to 10. This is version 7.<br>
<br>
More importantly, this activity is a useful template for
user-developed activities. Al Sweigart
has written three books on Python programming for children and has
given them a Creative Commons license! My plan for the class is
to show the students how to make Al Sweigart's examples into Sugar
activities by copying the hello-world.activity to
guessing-game.activity and updating activity.info in the new
activity. Then the students can copy and paste their code into
activity.py.<br>
<br>
None of the programs in the Al Sweigart's first two books use GTK
(only print and raw_input). Naturally this is a problem for a
Sugar activity which displays print statements in the log and
requires gtk to display text on the screen. However, this is a
learning opportunity for the students.<br>
<br>
I truly wish some of this community effort and ingenuity were
applied to making Sugar a better educational environment, giving
our users the opportunity to explore and create rather than
restricting it to elite developers.<br>
<br>
Tony<br>
<br>
<br>
<br>
<br>
On Wednesday, 28 February, 2018 08:34 AM, Walter Bender wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CADf7C8tt3Uc9ML9t+s6ruRiwcc3TJoVYfZESkDzD2fsjN2A=JQ@mail.gmail.com">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Feb 27, 2018 at 10:02 PM,
James Cameron <span dir="ltr"><<a
href="mailto:quozl@laptop.org" target="_blank"
moz-do-not-send="true">quozl@laptop.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">My list
of critical repositories was on a thread focused on Sugar<br>
desktop and Python activity code review. It is less
relevant for<br>
Sugar Labs as a whole.<br>
<br>
The mismatch at heart is GitHub's scalability of features
for large<br>
open source projects with many repositories. We have 292
at the<br>
moment. Most are orphaned or abandoned. Using search is
critical.<br>
<br>
Once a developer is familiar with our repository layout,
the problem<br>
disappears for them. Does our ramp-up documentation
explain well<br>
enough? I don't think I've heard many "where is X?"
questions.<br>
<br>
We could waste a lot of time moving repositories around to
meet<br>
consistent naming standards; I'd like to see reasoned
benefit before<br>
doing that.<br>
<br>
I recently changed the pinned repositories. I'd have
pinned Sugarizer<br>
and Music Blocks, but they are both being developed
outside Sugar Labs<br>
on GitHub personal accounts. That's why I've got Browse
and Turtle<br>
Art pinned.<br>
</blockquote>
<div><br>
</div>
<div>The reason Turtle Blocks and Music Blocks are still
hosted in my personal repo is because we have had a
backlog on sysadmin support, it has not been practical to
host projects on the Sugar Labs servers. Using <a
href="http://github.io" moz-do-not-send="true">github.io</a>
makes things pretty painless. But because we have not yet
set up a github,io presence for Sugar Labs, so I haven't
moved the repos. I'll try to finally wrap my head around
what <a href="http://sugarlabs.github.io"
moz-do-not-send="true">sugarlabs.github.io</a> might
look like and make some suggestions on this list.</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We could also waste a lot of time on dashboards or other<br>
meta-development. If we have a volunteer to do that,
great, but I'm<br>
not putting my hand up.<br>
<br>
Repositories containing submodules for a collection of
activities<br>
might be interesting, but it brings a new problem;
maintenance of the<br>
repository in the face of ongoing change in the
submodules. We've had<br>
to back away from submodules in Browse because of
repeating bugs where<br>
a downstream used a GitHub release tag instead of our
tarball.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
James Cameron<br>
<a href="http://quozl.netrek.org/" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://quozl.netrek.org/</a><br>
</font></span>
<div class="HOEnZb">
<div class="h5">______________________________<wbr>_________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org"
moz-do-not-send="true">Sugar-devel@lists.sugarlabs.<wbr>org</a><br>
<a
href="http://lists.sugarlabs.org/listinfo/sugar-devel"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.sugarlabs.org/<wbr>listinfo/sugar-devel</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div><font><font>Walter Bender</font></font><br>
<font><font>Sugar Labs</font></font></div>
<div><font><a href="http://www.sugarlabs.org"
target="_blank" moz-do-not-send="true"><font>http://www.sugarlabs.org</font></a></font><br>
<br>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Sugar-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>