Gaining Traction

[Scott Elcomb]

Hi all,

I'm finally starting to get some traction on the project; I have a
preliminary, hand-crafted distro together and Alex should be having a
look at that soon. An updated image will be coming later today and
likely one more in a few days (which I expect to be able to share with
everyone).

In the distro, we've fallen back to using the chromium that is
available by default from apt. This will allow us to pick up future
updates and reduce the amount of time it takes to construct the pine
distro. (Last I heard, hexxeh is not expecting update his version of
chromium and his version scores exactly the same as the default
chromium on <http://html5test.com>)

In order to deal with certain difficulties, I've redesigned the
front-end which is now based on AngularJS. Critically, this allows us
to:

a) have a simple GUI that is capable of loading any number of HTML5
games without leaving the Pine front-end or using iframes
b) offload most of the Express server's work to the browser
c) deal with limitations in Raspbian's browsers (ie, none of them
support Web Audio yet)

Here's my plan for the repository on Github, extracted from my last
message to Alex:

I created a new repo last night
<https://github.com/psema4/pine-client> and in the new [today's] image
this repo constitutes the pine user's home directory. This makes
updating the front-end a snap: just do a 'git pull'. Eventually this
can also be turned into a system update service (like the Sound
service) allowing users to update their Pine client directly from the
GUI.

I'll also be creating 2 other repo's soon: pine-server which will
contain a basic Pine Store to download games from and pine-distro
which will eventually hold an updated version of auto-pine. The
primary pine repo will then be reconfigured as follows: everything in
branch master will be moved into a new branch called 'oldmaster', The
three new repo's (pine-client, pine-server, & pine-distro) will then
be added as submodules. Essentially the master Pine repo will become
a meta-repo to hold documentation and references to the code repo's.
(This way the system update service mentioned above works without
having to download unnecessary components to a users Pine box.)

Please let me know if you see any issues or have any concerns
regarding the git repo's; I think this is the right way to go; it
allows us to keep the project's history while cleaning up the main
repo & organizing the key components of the system.


This is a pretty rough overview of changes in the last week and
there's lots missing. More details soon.

--
Scott Elcomb
@psema4 on Twitter / Identi.ca / Github & more

Atomic OS: Self Contained Microsystems
http://code.google.com/p/atomos/

Member of the Pirate Party of Canada
http://www.pirateparty.ca/

[Jeremy Kahn]

Wow, lots of progress lately!  The division of the repos seems to make a lot of sense.  I would caution against using Git submodules — I'm not sure how familiar/comfortable you are with them, but in my experience they tend to create more problems than they solve in the long run.  I have found that using Twitter Bower (http://bower.io/) is much more effective for managing dependencies.  Git submodules would certainly do the job, but they may not be the simplest option.

--
You received this message because you are subscribed to the Google Groups "Pine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pine-discuss...@googlegroups.com.
To post to this group, send email to pine-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pine-discuss/CAEx-jsO068PnBFk08zRNoC%3Dp147XbFjwLcnpuzD7krLFw1MBmw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Jeremy Kahn

jerem...@gmail.com

https://github.com/jeremyckahn

[Scott Elcomb]

On Sat, Jul 6, 2013 at 6:01 PM, Jeremy Kahn <jerem...@gmail.com> wrote:
> Wow, lots of progress lately! The division of the repos seems to make a lot
> of sense. I would caution against using Git submodules — I'm not sure how
> familiar/comfortable you are with them, but in my experience they tend to
> create more problems than they solve in the long run. I have found that
> using Twitter Bower (http://bower.io/) is much more effective for managing
> dependencies. Git submodules would certainly do the job, but they may not
> be the simplest option.

In general I tend to avoid submodules as well (for one thing they're
an absolute horror behind firewalls) but I think in this case it'll be
ok; really the idea is to get the code out of the main repo. There
wouldn't be much need even to initialize the submodules - maybe for
code reviews or something.

I can't wait... it's so close to being the real deal now =D