librelist archives

« back to archive

Proposal

Proposal

From:
Hawley Waldman
Date:
2012-09-08 @ 20:53
I would like to put forth the idea that we, as shoes enthusiasts, should 
put much more emphasis on having a working packager then we are.

My controversial statement is: without a working packager shoes will 
remain in the domain of the esoteric.

A more nuanced and gentle way of putting it is: 

If, using shoes allowed you to easily create cool graphical apps which ran
inside the shoes environment (which it does), and it also allowed you to 
easily create _free-standing_ applications, that ran  on osx, windows and 
linux without the necessity of downloading all kinds of support libraries 
(a feature it promises, but doesn't seem to deliver), we would see many, 
many, many, more people using shoes and, in all likelihood, that would 
attract more attention from programmers to support the code/project.

If a young person, learning to program could put their program on a thumb 
drive and give it to all of their friends to play play with that would get
them a lot more excited about programming.

If an amateur or hobbyist programmer could use ruby and shoes to create a 
program that their friends could run/use, it would create a lot of 
enthusiasm (and possibly more help with maintenance and support)

If professional programmers could use shoes to easily create good looking,
commercially viable, desktop-ish applications they would get excited and 
jump on board, being much more likely to contribute to development and 
maintenance.

Our "product" is shoes, a tool that makes it easy for people to create 
programs with cool gui's, but people aren't going to buy in because _their
product is widget.app, or widget.exe and widget.<whatever> needs to be 
easy for _their customers to install and run.

We write the code for a program once, hoping in general that we are 
creating something that will be used again, and again. If we lose track of
that goal we are just spending our time in a kind of masturbatory world, 
and masturbation just ain't as fun in the long term as, well, you know 
what.

I don't think that shoes needs to become a bloated, swiss army knife of a 
toolkit, it can keep the slick, simple (and powerful) features that it has
(although I'm thrilled with the talked about refinement of how listbox 
will work in shoes4) and it will still be good enough to do many / most 
things. 

A good enough toolkit, that lets you create programs that you can easily 
share and which might benefit others. That's what I would like to see 
shoes become.  An epitome of "appropriate laziness", what an former 
professor of mine described as an essential characteristic of a computer 
scientist.


So, what do you say? Can we get some enthusiasm  and momentum going for 
fixing  our packager/application wrapper service, or creating a new one?  
Once that is done each of the groovy rewritten features for shoes4, or 
green_shoes, or <insert color here>_shoes, would have an immediate impact 
on the world.  We need one packager, but many, many features, how about 
getting the packager done so that we can use as many features as we choose
to write in the infinite future?

sincerely, respectfully and gently,
Hawley

Re: [shoes] Proposal

From:
David Eastman
Date:
2012-09-08 @ 21:27
+1

On Sat, Sep 8, 2012 at 9:53 PM, Hawley Waldman <hawleyw@gmail.com> wrote:

> I would like to put forth the idea that we, as shoes enthusiasts, should
> put much more emphasis on having a working packager then we are.
>
> My controversial statement is: without a working packager shoes will
> remain in the domain of the esoteric.
>
> A more nuanced and gentle way of putting it is:
>
> If, using shoes allowed you to easily create cool graphical apps which ran
> inside the shoes environment (which it does), and it also allowed you to
> easily create _free-standing_ applications, that ran  on osx, windows and
> linux without the necessity of downloading all kinds of support libraries
> (a feature it promises, but doesn't seem to deliver), we would see many,
> many, many, more people using shoes and, in all likelihood, that would
> attract more attention from programmers to support the code/project.
>
> If a young person, learning to program could put their program on a thumb
> drive and give it to all of their friends to play play with that would get
> them a lot more excited about programming.
>
> If an amateur or hobbyist programmer could use ruby and shoes to create a
> program that their friends could run/use, it would create a lot of
> enthusiasm (and possibly more help with maintenance and support)
>
> If professional programmers could use shoes to easily create good looking,
> commercially viable, desktop-ish applications they would get excited and
> jump on board, being much more likely to contribute to development and
> maintenance.
>
> Our "product" is shoes, a tool that makes it easy for people to create
> programs with cool gui's, but people aren't going to buy in because _their
> product is widget.app, or widget.exe and widget.<whatever> needs to be easy
> for _their customers to install and run.
>
> We write the code for a program once, hoping in general that we are
> creating something that will be used again, and again. If we lose track of
> that goal we are just spending our time in a kind of masturbatory world,
> and masturbation just ain't as fun in the long term as, well, you know what.
>
> I don't think that shoes needs to become a bloated, swiss army knife of a
> toolkit, it can keep the slick, simple (and powerful) features that it has
> (although I'm thrilled with the talked about refinement of how listbox will
> work in shoes4) and it will still be good enough to do many / most things.
>
> A good enough toolkit, that lets you create programs that you can easily
> share and which might benefit others. That's what I would like to see shoes
> become.  An epitome of "appropriate laziness", what an former professor of
> mine described as an essential characteristic of a computer scientist.
>
>
> So, what do you say? Can we get some enthusiasm  and momentum going for
> fixing  our packager/application wrapper service, or creating a new one?
>  Once that is done each of the groovy rewritten features for shoes4, or
> green_shoes, or <insert color here>_shoes, would have an immediate impact
> on the world.  We need one packager, but many, many features, how about
> getting the packager done so that we can use as many features as we choose
> to write in the infinite future?
>
> sincerely, respectfully and gently,
> Hawley
>

Re: [shoes] Proposal

From:
Jenna Fox
Date:
2012-09-08 @ 23:43
I agree fully. I've long held the view that shoes is effectively dead if 
packaging doesn't work.  

—
Jenna


On Sunday, 9 September 2012 at 6:53 AM, Hawley Waldman wrote:

> I would like to put forth the idea that we, as shoes enthusiasts, should
put much more emphasis on having a working packager then we are.
>  
> My controversial statement is: without a working packager shoes will 
remain in the domain of the esoteric.
>  
> A more nuanced and gentle way of putting it is:  
>  
> If, using shoes allowed you to easily create cool graphical apps which 
ran inside the shoes environment (which it does), and it also allowed you 
to easily create _free-standing_ applications, that ran on osx, windows 
and linux without the necessity of downloading all kinds of support 
libraries (a feature it promises, but doesn't seem to deliver), we would 
see many, many, many, more people using shoes and, in all likelihood, that
would attract more attention from programmers to support the code/project.
>  
> If a young person, learning to program could put their program on a 
thumb drive and give it to all of their friends to play play with that 
would get them a lot more excited about programming.
>  
> If an amateur or hobbyist programmer could use ruby and shoes to create 
a program that their friends could run/use, it would create a lot of 
enthusiasm (and possibly more help with maintenance and support)
>  
> If professional programmers could use shoes to easily create good 
looking, commercially viable, desktop-ish applications they would get 
excited and jump on board, being much more likely to contribute to 
development and maintenance.
>  
> Our "product" is shoes, a tool that makes it easy for people to create 
programs with cool gui's, but people aren't going to buy in because _their
product is widget.app, or widget.exe and widget.<whatever> needs to be 
easy for _their customers to install and run.
>  
> We write the code for a program once, hoping in general that we are 
creating something that will be used again, and again. If we lose track of
that goal we are just spending our time in a kind of masturbatory world, 
and masturbation just ain't as fun in the long term as, well, you know 
what.
>  
> I don't think that shoes needs to become a bloated, swiss army knife of 
a toolkit, it can keep the slick, simple (and powerful) features that it 
has (although I'm thrilled with the talked about refinement of how listbox
will work in shoes4) and it will still be good enough to do many / most 
things.  
>  
> A good enough toolkit, that lets you create programs that you can easily
share and which might benefit others. That's what I would like to see 
shoes become. An epitome of "appropriate laziness", what an former 
professor of mine described as an essential characteristic of a computer 
scientist.
>  
>  
> So, what do you say? Can we get some enthusiasm and momentum going for 
fixing our packager/application wrapper service, or creating a new one? 
Once that is done each of the groovy rewritten features for shoes4, or 
green_shoes, or <insert color here>_shoes, would have an immediate impact 
on the world. We need one packager, but many, many features, how about 
getting the packager done so that we can use as many features as we choose
to write in the infinite future?
>  
> sincerely, respectfully and gently,
> Hawley
>  
>  

Re: [shoes] Proposal

From:
Peter Fitzgibbons
Date:
2012-09-09 @ 00:14
+1.

I believe that we have proven that SWT can handle all the features in the
required list.
It is indeed time to resurrect the packaging issue.

Thanks for bringing it up again Hawley.

Kindest Regards,
Peter Fitzgibbons
(847) 859-9550
Email: peter.fitzgibbons@gmail.com
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@gmail.com


On Sat, Sep 8, 2012 at 6:43 PM, Jenna Fox <a@creativepony.com> wrote:

>  I agree fully. I've long held the view that shoes is effectively dead if
> packaging doesn't work.
>
> —
> Jenna
>
> On Sunday, 9 September 2012 at 6:53 AM, Hawley Waldman wrote:
>
> I would like to put forth the idea that we, as shoes enthusiasts, should
> put much more emphasis on having a working packager then we are.
>
> My controversial statement is: without a working packager shoes will
> remain in the domain of the esoteric.
>
> A more nuanced and gentle way of putting it is:
>
> If, using shoes allowed you to easily create cool graphical apps which ran
> inside the shoes environment (which it does), and it also allowed you to
> easily create _free-standing_ applications, that ran on osx, windows and
> linux without the necessity of downloading all kinds of support libraries
> (a feature it promises, but doesn't seem to deliver), we would see many,
> many, many, more people using shoes and, in all likelihood, that would
> attract more attention from programmers to support the code/project.
>
> If a young person, learning to program could put their program on a thumb
> drive and give it to all of their friends to play play with that would get
> them a lot more excited about programming.
>
> If an amateur or hobbyist programmer could use ruby and shoes to create a
> program that their friends could run/use, it would create a lot of
> enthusiasm (and possibly more help with maintenance and support)
>
> If professional programmers could use shoes to easily create good looking,
> commercially viable, desktop-ish applications they would get excited and
> jump on board, being much more likely to contribute to development and
> maintenance.
>
> Our "product" is shoes, a tool that makes it easy for people to create
> programs with cool gui's, but people aren't going to buy in because _their
> product is widget.app, or widget.exe and widget.<whatever> needs to be easy
> for _their customers to install and run.
>
> We write the code for a program once, hoping in general that we are
> creating something that will be used again, and again. If we lose track of
> that goal we are just spending our time in a kind of masturbatory world,
> and masturbation just ain't as fun in the long term as, well, you know what.
>
> I don't think that shoes needs to become a bloated, swiss army knife of a
> toolkit, it can keep the slick, simple (and powerful) features that it has
> (although I'm thrilled with the talked about refinement of how listbox will
> work in shoes4) and it will still be good enough to do many / most things.
>
> A good enough toolkit, that lets you create programs that you can easily
> share and which might benefit others. That's what I would like to see shoes
> become. An epitome of "appropriate laziness", what an former professor of
> mine described as an essential characteristic of a computer scientist.
>
>
> So, what do you say? Can we get some enthusiasm and momentum going for
> fixing our packager/application wrapper service, or creating a new one?
> Once that is done each of the groovy rewritten features for shoes4, or
> green_shoes, or <insert color here>_shoes, would have an immediate impact
> on the world. We need one packager, but many, many features, how about
> getting the packager done so that we can use as many features as we choose
> to write in the infinite future?
>
> sincerely, respectfully and gently,
> Hawley
>
>
>

Re: [shoes] Proposal

From:
Cecil Coupe
Date:
2012-09-09 @ 02:13
On 09/08/2012 05:43 PM, Jenna Fox wrote:
> I agree fully. I've long held the view that shoes is effectively dead if
> packaging doesn't work.
>
> —
> Jenna
>

In the case of Red Shoes 3.x, I completely agree. Packaging has been 
half broken or half working for several years.  I know Ashbb has a 
windows shoes version that works well (on Windows) and I know Eric did 
some work on the OSX parts. I don't know that either of them made it to 
the website for initial user download and that they request the newer 
updated Shoes when packaging a script for either one.

I stopped beating the drum on the packaging issues of Red Shoes because 
maintenance of Red Shoes is a very low priority for the C level 
developers. Red Shoes is not being maintained or updated for lack of 
developer interest in doing it.  All we need is a Windows MingW C 
developer and an OSX/Obj-c developer that are willing to tackle the 
challenge and finish the task.

--Cecil


Re: [shoes] Proposal

From:
Peter Fitzgibbons
Date:
2012-09-09 @ 09:06
HI Cecil,

The reasons for abandoned support of RedShoes 3.x build is that OS versions
have clobbered the cross-platform build process.

What this means;  Windows compilations have been shaky at best since
WindowsVista/Windows7.  The expectation is that a single build and packaged
binary can be created that will run WinXP AND Win7 (now also Win8).
On Mac, OSX Lion has solidified the 32bit -> 64bit upgrade, and with that
taken away the ability for a single build and packaged binary to work in
both environments.  In fact we have not even been able to do cross-version
builds at all.  A Lion build wont' work on SnowLeopard at all.
The Linux situation is a bit better but overall the same situation, 32bit
-> 64bit upgrade breaks the cross-platform build process.

So, recall that RedShoes was heavily dependent upon custom-C and external
libraries, which are built cross-platform into a single monolithic,
cross-platform compatible tarball (zip, installer, whatever).  _why created
this in a masterful way, in the day when 32-bit was new-ish, Win95 was in
full-steam, WinXP was on the horizon, most Linux distros were just becoming
pure 32bit, and OS 'X' was now solid (Tiger -> Leopard days).

Now we are on another bit-upgrade horizon, 32bit -> 64bit, and the build
systems across the board are radically changing, for the better we hope.
 The side-effect of this is that cross-platform compilation is not feasible.

The birth of Shoes4 / Jruby / SWT was a move to alleviate our packaging
woes by leveraging the vast Java community and their continuing work on
cross-platform compatability.  While acknowledging that dependency on an
external binary is a bit of a "risk" in some ways, the benefits and clear
stable-base of the JVM community gives us the space to build (or use) a
packager that works cross-platform and builds cross-platform.

Although we have been focused in the past 2-3 months on SWT, that work has
been a proof that SWT has the tools and capability we need to produce in
Shoes.  This email thread is quite coincidental as this week I had started
my own thought process around when would be the best time to re-energize
the packaging question.

Thank you all for your work and inspiration.  With some Java packaging
mojo, we might even be able to release a Shoes4 Preview that the world
could use and begin to play with.

Kindest Regards,

Peter Fitzgibbons
(847) 859-9550
Email: peter.fitzgibbons@gmail.com
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@gmail.com


On Sat, Sep 8, 2012 at 9:13 PM, Cecil Coupe <ccoupe@cableone.net> wrote:

> On 09/08/2012 05:43 PM, Jenna Fox wrote:
> > I agree fully. I've long held the view that shoes is effectively dead if
> > packaging doesn't work.
> >
> > —
> > Jenna
> >
>
> In the case of Red Shoes 3.x, I completely agree. Packaging has been
> half broken or half working for several years.  I know Ashbb has a
> windows shoes version that works well (on Windows) and I know Eric did
> some work on the OSX parts. I don't know that either of them made it to
> the website for initial user download and that they request the newer
> updated Shoes when packaging a script for either one.
>
> I stopped beating the drum on the packaging issues of Red Shoes because
> maintenance of Red Shoes is a very low priority for the C level
> developers. Red Shoes is not being maintained or updated for lack of
> developer interest in doing it.  All we need is a Windows MingW C
> developer and an OSX/Obj-c developer that are willing to tackle the
> challenge and finish the task.
>
> --Cecil
>
>
>
>

Re: [shoes] Proposal

From:
Jenna Fox
Date:
2012-09-09 @ 09:37
I don't buy it. Löve 2D continues to have a functional cross platform 
packager. It's open source too! If Löve can do it, so can Shoes - them's 
the rules in this turing complete world of ours. Everything else is an 
excuse.

In the past two weeks a severe java vulnerability was publicised which 
oracle sat on for six months, allowing applets in webpages and other java 
apps to escalate privileges to arbitrary settings without user permission 
or deception. Oracle gave the security community the finger, and the 
security community gave them the finger back. Meanwhile this week an FBI 
agent had interesting files copied from their laptop via a java security 
vulnerability (AtomicArrayReference) which was then published online via 
bittorrent and the likes. Pretty hilarious ownage 
http://www.metafilter.com/119597/1-million-Apple-UUIDs-leaked-after-FBI-security-breach

I can't in good faith recommend anyone use Shoes, or the flawed and 
dangerous technologies it is increasingly being built on.

I'd love to see what would happen if Löve 2D met mruby. A Ruby Löve would 
be pretty outstanding. Till then, I observe the demise of shoes from afar.


—
Jenna


On Sunday, 9 September 2012 at 7:06 PM, Peter Fitzgibbons wrote:

> HI Cecil,
>  
> The reasons for abandoned support of RedShoes 3.x build is that OS 
versions have clobbered the cross-platform build process.
>  
> What this means;  Windows compilations have been shaky at best since 
WindowsVista/Windows7.  The expectation is that a single build and 
packaged binary can be created that will run WinXP AND Win7 (now also 
Win8).  
> On Mac, OSX Lion has solidified the 32bit -> 64bit upgrade, and with 
that taken away the ability for a single build and packaged binary to work
in both environments.  In fact we have not even been able to do 
cross-version builds at all.  A Lion build wont' work on SnowLeopard at 
all.
> The Linux situation is a bit better but overall the same situation, 
32bit -> 64bit upgrade breaks the cross-platform build process.
>  
> So, recall that RedShoes was heavily dependent upon custom-C and 
external libraries, which are built cross-platform into a single 
monolithic, cross-platform compatible tarball (zip, installer, whatever).
_why created this in a masterful way, in the day when 32-bit was new-ish, 
Win95 was in full-steam, WinXP was on the horizon, most Linux distros were
just becoming pure 32bit, and OS 'X' was now solid (Tiger -> Leopard 
days).  
>  
> Now we are on another bit-upgrade horizon, 32bit -> 64bit, and the build
systems across the board are radically changing, for the better we hope.  
The side-effect of this is that cross-platform compilation is not 
feasible.  
>  
> The birth of Shoes4 / Jruby / SWT was a move to alleviate our packaging 
woes by leveraging the vast Java community and their continuing work on 
cross-platform compatability.  While acknowledging that dependency on an 
external binary is a bit of a "risk" in some ways, the benefits and clear 
stable-base of the JVM community gives us the space to build (or use) a 
packager that works cross-platform and builds cross-platform.  
>  
> Although we have been focused in the past 2-3 months on SWT, that work 
has been a proof that SWT has the tools and capability we need to produce 
in Shoes.  This email thread is quite coincidental as this week I had 
started my own thought process around when would be the best time to 
re-energize the packaging question.  
>  
> Thank you all for your work and inspiration.  With some Java packaging 
mojo, we might even be able to release a Shoes4 Preview that the world 
could use and begin to play with.
>  
> Kindest Regards,
>  
> Peter Fitzgibbons
> (847) 859-9550
> Email: peter.fitzgibbons@gmail.com (mailto:peter.fitzgibbons@gmail.com)
> IM GTalk: peter.fitzgibbons
> IM AOL: peter.fitzgibbons@gmail.com (mailto:peter.fitzgibbons@gmail.com)
>  
>  
> On Sat, Sep 8, 2012 at 9:13 PM, Cecil Coupe <ccoupe@cableone.net 
(mailto:ccoupe@cableone.net)> wrote:
> > On 09/08/2012 05:43 PM, Jenna Fox wrote:
> > > I agree fully. I've long held the view that shoes is effectively dead if
> > > packaging doesn't work.
> > >
> > > —
> > > Jenna
> > >
> >  
> > In the case of Red Shoes 3.x, I completely agree. Packaging has been
> > half broken or half working for several years.  I know Ashbb has a
> > windows shoes version that works well (on Windows) and I know Eric did
> > some work on the OSX parts. I don't know that either of them made it to
> > the website for initial user download and that they request the newer
> > updated Shoes when packaging a script for either one.
> >  
> > I stopped beating the drum on the packaging issues of Red Shoes because
> > maintenance of Red Shoes is a very low priority for the C level
> > developers. Red Shoes is not being maintained or updated for lack of
> > developer interest in doing it.  All we need is a Windows MingW C
> > developer and an OSX/Obj-c developer that are willing to tackle the
> > challenge and finish the task.
> >  
> > --Cecil
> >  
> >  
> >  
>  

Re: [shoes] Proposal

From:
Peter Fitzgibbons
Date:
2012-09-09 @ 10:41
You've piqued my interest.
I've read 
CVE-2012-0507<https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-0507>,
dated 2012-02-09. The first patch was released to RedHat EL 6 on
2012-02-14, with releases to other distro root streams in subsequent days.
 On 2012-02-17 the original bug was renamed (aliased in bugzilla) and
rolled into the JavaCriticalPatchUpdateFeb2012.  On Feb/Mar 2012

several<http://www.h-online.com/security/news/item/Critical-Java-hole-being-exploited-on-a-large-scale-Update-1485681.html>

bloggers<http://krebsonsecurity.com/2012/03/new-java-attack-rolled-into-exploit-packs/>

noted<http://blogs.technet.com/b/mmpc/archive/2012/03/20/an-interesting-case-of-jre-sandbox-breach-cve-2012-0507.aspx>the
unpatched hole being actively exploited.

Could you tell me when the patch was originally discovered by/reported to
Oracle/Java Bugzilla, and when that report was publicly available (say via
Bugzilla)?

Peter Fitzgibbons
(847) 859-9550
Email: peter.fitzgibbons@gmail.com
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@gmail.com


On Sun, Sep 9, 2012 at 4:37 AM, Jenna Fox <a@creativepony.com> wrote:

> I don't buy it. Löve 2D continues to have a functional cross platform
> packager. It's open source too! If Löve can do it, so can Shoes - them's
> the rules in this turing complete world of ours. Everything else is an
> excuse.
>
> In the past two weeks a severe java vulnerability was publicised which
> oracle sat on for six months, allowing applets in webpages and other java
> apps to escalate privileges to arbitrary settings without user permission
> or deception. Oracle gave the security community the finger, and the
> security community gave them the finger back. Meanwhile this week an FBI
> agent had interesting files copied from their laptop via a java security
> vulnerability (AtomicArrayReference) which was then published online via
> bittorrent and the likes. Pretty hilarious ownage
> 
http://www.metafilter.com/119597/1-million-Apple-UUIDs-leaked-after-FBI-security-breach
>
> I can't in good faith recommend anyone use Shoes, or the flawed and
> dangerous technologies it is increasingly being built on.
>
> I'd love to see what would happen if Löve 2D met mruby. A Ruby Löve would
> be pretty outstanding. Till then, I observe the demise of shoes from afar.
>
> —
> Jenna
>
> On Sunday, 9 September 2012 at 7:06 PM, Peter Fitzgibbons wrote:
>
> HI Cecil,
>
> The reasons for abandoned support of RedShoes 3.x build is that OS
> versions have clobbered the cross-platform build process.
>
> What this means;  Windows compilations have been shaky at best since
> WindowsVista/Windows7.  The expectation is that a single build and packaged
> binary can be created that will run WinXP AND Win7 (now also Win8).
> On Mac, OSX Lion has solidified the 32bit -> 64bit upgrade, and with that
> taken away the ability for a single build and packaged binary to work in
> both environments.  In fact we have not even been able to do cross-version
> builds at all.  A Lion build wont' work on SnowLeopard at all.
> The Linux situation is a bit better but overall the same situation, 32bit
> -> 64bit upgrade breaks the cross-platform build process.
>
> So, recall that RedShoes was heavily dependent upon custom-C and external
> libraries, which are built cross-platform into a single monolithic,
> cross-platform compatible tarball (zip, installer, whatever).  _why created
> this in a masterful way, in the day when 32-bit was new-ish, Win95 was in
> full-steam, WinXP was on the horizon, most Linux distros were just becoming
> pure 32bit, and OS 'X' was now solid (Tiger -> Leopard days).
>
> Now we are on another bit-upgrade horizon, 32bit -> 64bit, and the build
> systems across the board are radically changing, for the better we hope.
>  The side-effect of this is that cross-platform compilation is not feasible.
>
> The birth of Shoes4 / Jruby / SWT was a move to alleviate our packaging
> woes by leveraging the vast Java community and their continuing work on
> cross-platform compatability.  While acknowledging that dependency on an
> external binary is a bit of a "risk" in some ways, the benefits and clear
> stable-base of the JVM community gives us the space to build (or use) a
> packager that works cross-platform and builds cross-platform.
>
> Although we have been focused in the past 2-3 months on SWT, that work has
> been a proof that SWT has the tools and capability we need to produce in
> Shoes.  This email thread is quite coincidental as this week I had started
> my own thought process around when would be the best time to re-energize
> the packaging question.
>
> Thank you all for your work and inspiration.  With some Java packaging
> mojo, we might even be able to release a Shoes4 Preview that the world
> could use and begin to play with.
>
> Kindest Regards,
>
> Peter Fitzgibbons
> (847) 859-9550
> Email: peter.fitzgibbons@gmail.com
> IM GTalk: peter.fitzgibbons
> IM AOL: peter.fitzgibbons@gmail.com
>
>
> On Sat, Sep 8, 2012 at 9:13 PM, Cecil Coupe <ccoupe@cableone.net> wrote:
>
> On 09/08/2012 05:43 PM, Jenna Fox wrote:
> > I agree fully. I've long held the view that shoes is effectively dead if
> > packaging doesn't work.
> >
> > —
> > Jenna
> >
>
> In the case of Red Shoes 3.x, I completely agree. Packaging has been
> half broken or half working for several years.  I know Ashbb has a
> windows shoes version that works well (on Windows) and I know Eric did
> some work on the OSX parts. I don't know that either of them made it to
> the website for initial user download and that they request the newer
> updated Shoes when packaging a script for either one.
>
> I stopped beating the drum on the packaging issues of Red Shoes because
> maintenance of Red Shoes is a very low priority for the C level
> developers. Red Shoes is not being maintained or updated for lack of
> developer interest in doing it.  All we need is a Windows MingW C
> developer and an OSX/Obj-c developer that are willing to tackle the
> challenge and finish the task.
>
> --Cecil
>
>
>
>
>
>

Re: [shoes] Proposal

From:
Peter Fitzgibbons
Date:
2012-09-09 @ 10:19
So, given that Löve has binaries for all platforms, a few questions :
1. How is the build process.  Does that developer team have to build on
that many different source-systems in order to get their builds?   Shoes
was originally created to "cross-build"...  a Windows Shoes can build a
Mac-compatible zip/install, and Linux -> WIndows, all the permutations.
2. What would your recommendation be for the most user-friendly
cross-platform profile for Shoes?  Keep in mind that our target audience is
Kids, so think beginners, age maybe 8+ (yes, yes, there are a few outliers
who are devving video drivers at 6.  blah.  So are mine.)
3. Packaging issues aside, what should we do about the two other main
issues with Redshoes : audio driver, layout manager?  Bloopsaphone is just
plain custom; should we go external a-la the video (VLC)? The group did do
some preliminary work to move some of the Shoes-C logic out of C into Ruby.
 Though I'll bet that a lot of what's in C is performance related (even if
by slices).  Remember that _why is a very shrewd analyst of the inner
workings of many things.

Looking forward to your thoughts.
Peter Fitzgibbons
(847) 859-9550
Email: peter.fitzgibbons@gmail.com
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@gmail.com


On Sun, Sep 9, 2012 at 4:37 AM, Jenna Fox <a@creativepony.com> wrote:

> I don't buy it. Löve 2D continues to have a functional cross platform
> packager. It's open source too! If Löve can do it, so can Shoes - them's
> the rules in this turing complete world of ours. Everything else is an
> excuse.
>
> In the past two weeks a severe java vulnerability was publicised which
> oracle sat on for six months, allowing applets in webpages and other java
> apps to escalate privileges to arbitrary settings without user permission
> or deception. Oracle gave the security community the finger, and the
> security community gave them the finger back. Meanwhile this week an FBI
> agent had interesting files copied from their laptop via a java security
> vulnerability (AtomicArrayReference) which was then published online via
> bittorrent and the likes. Pretty hilarious ownage
> 
http://www.metafilter.com/119597/1-million-Apple-UUIDs-leaked-after-FBI-security-breach
>
> I can't in good faith recommend anyone use Shoes, or the flawed and
> dangerous technologies it is increasingly being built on.
>
> I'd love to see what would happen if Löve 2D met mruby. A Ruby Löve would
> be pretty outstanding. Till then, I observe the demise of shoes from afar.
>
> —
> Jenna
>
> On Sunday, 9 September 2012 at 7:06 PM, Peter Fitzgibbons wrote:
>
> HI Cecil,
>
> The reasons for abandoned support of RedShoes 3.x build is that OS
> versions have clobbered the cross-platform build process.
>
> What this means;  Windows compilations have been shaky at best since
> WindowsVista/Windows7.  The expectation is that a single build and packaged
> binary can be created that will run WinXP AND Win7 (now also Win8).
> On Mac, OSX Lion has solidified the 32bit -> 64bit upgrade, and with that
> taken away the ability for a single build and packaged binary to work in
> both environments.  In fact we have not even been able to do cross-version
> builds at all.  A Lion build wont' work on SnowLeopard at all.
> The Linux situation is a bit better but overall the same situation, 32bit
> -> 64bit upgrade breaks the cross-platform build process.
>
> So, recall that RedShoes was heavily dependent upon custom-C and external
> libraries, which are built cross-platform into a single monolithic,
> cross-platform compatible tarball (zip, installer, whatever).  _why created
> this in a masterful way, in the day when 32-bit was new-ish, Win95 was in
> full-steam, WinXP was on the horizon, most Linux distros were just becoming
> pure 32bit, and OS 'X' was now solid (Tiger -> Leopard days).
>
> Now we are on another bit-upgrade horizon, 32bit -> 64bit, and the build
> systems across the board are radically changing, for the better we hope.
>  The side-effect of this is that cross-platform compilation is not feasible.
>
> The birth of Shoes4 / Jruby / SWT was a move to alleviate our packaging
> woes by leveraging the vast Java community and their continuing work on
> cross-platform compatability.  While acknowledging that dependency on an
> external binary is a bit of a "risk" in some ways, the benefits and clear
> stable-base of the JVM community gives us the space to build (or use) a
> packager that works cross-platform and builds cross-platform.
>
> Although we have been focused in the past 2-3 months on SWT, that work has
> been a proof that SWT has the tools and capability we need to produce in
> Shoes.  This email thread is quite coincidental as this week I had started
> my own thought process around when would be the best time to re-energize
> the packaging question.
>
> Thank you all for your work and inspiration.  With some Java packaging
> mojo, we might even be able to release a Shoes4 Preview that the world
> could use and begin to play with.
>
> Kindest Regards,
>
> Peter Fitzgibbons
> (847) 859-9550
> Email: peter.fitzgibbons@gmail.com
> IM GTalk: peter.fitzgibbons
> IM AOL: peter.fitzgibbons@gmail.com
>
>
> On Sat, Sep 8, 2012 at 9:13 PM, Cecil Coupe <ccoupe@cableone.net> wrote:
>
> On 09/08/2012 05:43 PM, Jenna Fox wrote:
> > I agree fully. I've long held the view that shoes is effectively dead if
> > packaging doesn't work.
> >
> > —
> > Jenna
> >
>
> In the case of Red Shoes 3.x, I completely agree. Packaging has been
> half broken or half working for several years.  I know Ashbb has a
> windows shoes version that works well (on Windows) and I know Eric did
> some work on the OSX parts. I don't know that either of them made it to
> the website for initial user download and that they request the newer
> updated Shoes when packaging a script for either one.
>
> I stopped beating the drum on the packaging issues of Red Shoes because
> maintenance of Red Shoes is a very low priority for the C level
> developers. Red Shoes is not being maintained or updated for lack of
> developer interest in doing it.  All we need is a Windows MingW C
> developer and an OSX/Obj-c developer that are willing to tackle the
> challenge and finish the task.
>
> --Cecil
>
>
>
>
>
>

Re: [shoes] Proposal

From:
David Eastman
Date:
2012-09-09 @ 11:37
I don't want to just pile on here, but am worried by the spurious "target
audience is kids" thing.

You mean the target audience is beginners, many of whom are probably kids,
right?

Or better yet, the target audience does not have a background in
development, so presentation cannot assume knowledge of other platforms or
concepts. I hope no one is second guessing what kids do or don't need.
Surely _why didn't. Maybe the thinking here is kids don't need packaging??

OK, rant off. But I'm as keen as Jenna seems to be to not allow strange
motivations to stunt shoes.

I can't work out if there is enough interest in Bloopsaphone to maintain it
as a library. Seen a flurry of chiptunes nostalgia things 2 years back. I'm
sure that moving code to ruby just makes sense; there will always be other
ways to address performance issues.

One thing Jenna said that caught my attention: "there really aren't that
many gems and libraries which are important for making a game or a little
program" - I have found that to be strangely true. Apart from a json and
json schema library, I can't think of any other gems I needed recently for
smaller/gaming apps. Might well be a thing worth surveying to help guide
decisions.


On Sun, Sep 9, 2012 at 11:19 AM, Peter Fitzgibbons <
peter.fitzgibbons@gmail.com> wrote:

> So, given that Löve has binaries for all platforms, a few questions :
> 1. How is the build process.  Does that developer team have to build on
> that many different source-systems in order to get their builds?   Shoes
> was originally created to "cross-build"...  a Windows Shoes can build a
> Mac-compatible zip/install, and Linux -> WIndows, all the permutations.
> 2. What would your recommendation be for the most user-friendly
> cross-platform profile for Shoes?  Keep in mind that our target audience is
> Kids, so think beginners, age maybe 8+ (yes, yes, there are a few outliers
> who are devving video drivers at 6.  blah.  So are mine.)
> 3. Packaging issues aside, what should we do about the two other main
> issues with Redshoes : audio driver, layout manager?  Bloopsaphone is just
> plain custom; should we go external a-la the video (VLC)? The group did do
> some preliminary work to move some of the Shoes-C logic out of C into Ruby.
>  Though I'll bet that a lot of what's in C is performance related (even if
> by slices).  Remember that _why is a very shrewd analyst of the inner
> workings of many things.
>
> Looking forward to your thoughts.
> Peter Fitzgibbons
> (847) 859-9550
> Email: peter.fitzgibbons@gmail.com
> IM GTalk: peter.fitzgibbons
> IM AOL: peter.fitzgibbons@gmail.com
>
>
> On Sun, Sep 9, 2012 at 4:37 AM, Jenna Fox <a@creativepony.com> wrote:
>
>> I don't buy it. Löve 2D continues to have a functional cross platform
>> packager. It's open source too! If Löve can do it, so can Shoes - them's
>> the rules in this turing complete world of ours. Everything else is an
>> excuse.
>>
>> In the past two weeks a severe java vulnerability was publicised which
>> oracle sat on for six months, allowing applets in webpages and other java
>> apps to escalate privileges to arbitrary settings without user permission
>> or deception. Oracle gave the security community the finger, and the
>> security community gave them the finger back. Meanwhile this week an FBI
>> agent had interesting files copied from their laptop via a java security
>> vulnerability (AtomicArrayReference) which was then published online via
>> bittorrent and the likes. Pretty hilarious ownage
>> 
http://www.metafilter.com/119597/1-million-Apple-UUIDs-leaked-after-FBI-security-breach
>>
>> I can't in good faith recommend anyone use Shoes, or the flawed and
>> dangerous technologies it is increasingly being built on.
>>
>> I'd love to see what would happen if Löve 2D met mruby. A Ruby Löve would
>> be pretty outstanding. Till then, I observe the demise of shoes from afar.
>>
>> —
>> Jenna
>>
>> On Sunday, 9 September 2012 at 7:06 PM, Peter Fitzgibbons wrote:
>>
>> HI Cecil,
>>
>> The reasons for abandoned support of RedShoes 3.x build is that OS
>> versions have clobbered the cross-platform build process.
>>
>> What this means;  Windows compilations have been shaky at best since
>> WindowsVista/Windows7.  The expectation is that a single build and packaged
>> binary can be created that will run WinXP AND Win7 (now also Win8).
>> On Mac, OSX Lion has solidified the 32bit -> 64bit upgrade, and with that
>> taken away the ability for a single build and packaged binary to work in
>> both environments.  In fact we have not even been able to do cross-version
>> builds at all.  A Lion build wont' work on SnowLeopard at all.
>> The Linux situation is a bit better but overall the same situation, 32bit
>> -> 64bit upgrade breaks the cross-platform build process.
>>
>> So, recall that RedShoes was heavily dependent upon custom-C and external
>> libraries, which are built cross-platform into a single monolithic,
>> cross-platform compatible tarball (zip, installer, whatever).  _why created
>> this in a masterful way, in the day when 32-bit was new-ish, Win95 was in
>> full-steam, WinXP was on the horizon, most Linux distros were just becoming
>> pure 32bit, and OS 'X' was now solid (Tiger -> Leopard days).
>>
>> Now we are on another bit-upgrade horizon, 32bit -> 64bit, and the build
>> systems across the board are radically changing, for the better we hope.
>>  The side-effect of this is that cross-platform compilation is not feasible.
>>
>> The birth of Shoes4 / Jruby / SWT was a move to alleviate our packaging
>> woes by leveraging the vast Java community and their continuing work on
>> cross-platform compatability.  While acknowledging that dependency on an
>> external binary is a bit of a "risk" in some ways, the benefits and clear
>> stable-base of the JVM community gives us the space to build (or use) a
>> packager that works cross-platform and builds cross-platform.
>>
>> Although we have been focused in the past 2-3 months on SWT, that work
>> has been a proof that SWT has the tools and capability we need to produce
>> in Shoes.  This email thread is quite coincidental as this week I had
>> started my own thought process around when would be the best time to
>> re-energize the packaging question.
>>
>> Thank you all for your work and inspiration.  With some Java packaging
>> mojo, we might even be able to release a Shoes4 Preview that the world
>> could use and begin to play with.
>>
>> Kindest Regards,
>>
>> Peter Fitzgibbons
>> (847) 859-9550
>> Email: peter.fitzgibbons@gmail.com
>> IM GTalk: peter.fitzgibbons
>> IM AOL: peter.fitzgibbons@gmail.com
>>
>>
>> On Sat, Sep 8, 2012 at 9:13 PM, Cecil Coupe <ccoupe@cableone.net> wrote:
>>
>> On 09/08/2012 05:43 PM, Jenna Fox wrote:
>> > I agree fully. I've long held the view that shoes is effectively dead if
>> > packaging doesn't work.
>> >
>> > —
>> > Jenna
>> >
>>
>> In the case of Red Shoes 3.x, I completely agree. Packaging has been
>> half broken or half working for several years.  I know Ashbb has a
>> windows shoes version that works well (on Windows) and I know Eric did
>> some work on the OSX parts. I don't know that either of them made it to
>> the website for initial user download and that they request the newer
>> updated Shoes when packaging a script for either one.
>>
>> I stopped beating the drum on the packaging issues of Red Shoes because
>> maintenance of Red Shoes is a very low priority for the C level
>> developers. Red Shoes is not being maintained or updated for lack of
>> developer interest in doing it.  All we need is a Windows MingW C
>> developer and an OSX/Obj-c developer that are willing to tackle the
>> challenge and finish the task.
>>
>> --Cecil
>>
>>
>>
>>
>>
>>
>

Re: [shoes] Proposal

From:
Steve Klabnik
Date:
2012-09-09 @ 19:51
The packager is supremely important. It is also incredibly difficult.
I have tried to deal with Red Shoe's packager twice and failed.

Any effort on packaging gets a major +1 from me, but I can't do it. I
feel defeated. :/

Re: [shoes] Proposal

From:
Hawley Waldman
Date:
2012-09-09 @ 22:27
I want to tell you all how relieved I am at the responses to my emailed 
proposal. I wasn't sure if it was going to start a flame war and I was 
halfway bracing myself to get majorly attacked. 

I hope that we can organize this enthusiasm and focus our attentions on  
writing some reasonable solutions to the problem.  

Somehow we need to figure out what our resources are and match them with 
our interests.   I use a Mac and so my top priority is to get something 
working that I can use. My understanding, from previous emails, is that 
green shoes will only package on windows and classic shoes will package 
things on a mac, you can get shoes to compile and make some changes in its
rake file. 

Could we start by creating an wiki page  where we could gather the actual 
state of affairs at this point (for all colors) ?

Sincerely,
Hawley

Re: [shoes] Proposal

From:
Peter Fitzgibbons
Date:
2012-09-09 @ 23:08
Just to clarify...  Are we specifically discussing packaging for 
Shoes3-MRI or Shoes4-Jruby, or both separately?

Sent from my iPad

On Sep 9, 2012, at 5:27 PM, Hawley Waldman <hawleyw@gmail.com> wrote:

> I want to tell you all how relieved I am at the responses to my emailed 
proposal. I wasn't sure if it was going to start a flame war and I was 
halfway bracing myself to get majorly attacked. 
> 
> I hope that we can organize this enthusiasm and focus our attentions on
writing some reasonable solutions to the problem.  
> 
> Somehow we need to figure out what our resources are and match them with
our interests.   I use a Mac and so my top priority is to get something 
working that I can use. My understanding, from previous emails, is that 
green shoes will only package on windows and classic shoes will package 
things on a mac, you can get shoes to compile and make some changes in its
rake file. 
> 
> Could we start by creating an wiki page  where we could gather the 
actual state of affairs at this point (for all colors) ?
> 
> Sincerely,
> Hawley

Re: [shoes] Proposal

From:
Eric Watson
Date:
2012-09-09 @ 23:41

On Sep 9, 2012, at 6:08 PM, Peter Fitzgibbons <peter.fitzgibbons@gmail.com> wrote:

> Are we specifically discussing packaging for Shoes3-MRI or Shoes4-Jruby,
or both separately?

I hear a nonpartisan call for a working Shoes that packages apps. 

Re: [shoes] Proposal

From:
Hawley Waldman
Date:
2012-09-09 @ 22:12
Steve, we will need you!

You are the person with the most experience re-working shoes and equally 
importantly if we don't at least learn from your efforts we will probably 
end up defeated too. 

I am hoping that we could at least get packaging for the system that shoes
is installed on working, even if we have to pull a sneaky hack. 

First step for me is to get shoes to compile on my Mac running 10.6.8. I 
tried the other day but Cairo failed to build and, not seeing anything 
obviously wrong I decided to take a break for a day. 

Hawley



On Sep 9, 2012, at 15:51, Steve Klabnik <steve@steveklabnik.com> wrote:

> The packager is supremely important. It is also incredibly difficult.
> I have tried to deal with Red Shoe's packager twice and failed.
> 
> Any effort on packaging gets a major +1 from me, but I can't do it. I
> feel defeated. :/

Re: [shoes] Proposal

From:
Eric Watson
Date:
2012-09-09 @ 23:06
I'm glad we are talking about this again ;) I agree that the packager is 
essential, and I have been sweating the fact that nobody is working out 
the details of packaging for Shoes 4. I have also been fiddling with a 
couple of options for Shoes 4, but without breakthrough success.

Please remember that while Shoes may be for beginners or for kids, is also
for rodents and for purveyors of fine leather goods, among others.

I have also put in a fair amount of time trying to get Shoes 3 packaging 
to work again, without success. I believe this is mostly to do with my own
poor C skills--certainly it is technically possible to pull off packaging,
as Jenna points out. One problem with our packaging system is that it has 
a bunch of moving parts (stubs, C code, Ruby code, URLs, web services, 
etc), and it's hard to keep them all in sync when you're not familiar with
the code. Another problem is that we are relying on some fairly tricky 
libraries like binject, which are also not maintained.

It's also worth noting that most of the efforts to get packaging working 
have been solo efforts. It is incredibly easy to get frustrated working on
this alone. Perhaps we would be more successful if we had a few of us 
working on it together. Also--lots of the packaging will probably be the 
same for Shoes 3 and Shoes 4 (wrapping code up in a .exe or .app, for 
instance), so this work is shareable.

So packaging is tough, but my biggest difficulty in hacking on Shoes is 
that it's so big and so complex that I am afraid to make changes, because 
I don't fully understand the system, and there are no tests to give me 
confidence that my changes haven't screwed something else up. That's why I
have been working on coding what is being called "Shoes 4", which is a 
frontend that runs in a regular Ruby, so it's easy to test, and which will
accept multiple backends (Swt, Qt, Gtk, etc), which also can run in a 
regular Ruby and be tested. This is a huge win for me, and I hope it makes
it easier for others to get involved.

+1 packaging wiki page, with instructions on how to compile like Hackety Hack.

Thanks everyone for your courage, honesty, insight, and kindness.

Eric

 
On Sep 9, 2012, at 6:37 AM, David Eastman wrote:

> I don't want to just pile on here, but am worried by the spurious 
"target audience is kids" thing.
> 
> You mean the target audience is beginners, many of whom are probably 
kids, right?
> 
> Or better yet, the target audience does not have a background in 
development, so presentation cannot assume knowledge of other platforms or
concepts. I hope no one is second guessing what kids do or don't need. 
Surely _why didn't. Maybe the thinking here is kids don't need packaging??

> 
> OK, rant off. But I'm as keen as Jenna seems to be to not allow strange 
motivations to stunt shoes. 
> 
> I can't work out if there is enough interest in Bloopsaphone to maintain
it as a library. Seen a flurry of chiptunes nostalgia things 2 years back.
I'm sure that moving code to ruby just makes sense; there will always be 
other ways to address performance issues. 
> 
> One thing Jenna said that caught my attention: "there really aren't that
many gems and libraries which are important for making a game or a little 
program" - I have found that to be strangely true. Apart from a json and 
json schema library, I can't think of any other gems I needed recently for
smaller/gaming apps. Might well be a thing worth surveying to help guide 
decisions.
> 
> 
> On Sun, Sep 9, 2012 at 11:19 AM, Peter Fitzgibbons 
<peter.fitzgibbons@gmail.com> wrote:
> So, given that Löve has binaries for all platforms, a few questions :
> 1. How is the build process.  Does that developer team have to build on 
that many different source-systems in order to get their builds?   Shoes 
was originally created to "cross-build"...  a Windows Shoes can build a 
Mac-compatible zip/install, and Linux -> WIndows, all the permutations.
> 2. What would your recommendation be for the most user-friendly 
cross-platform profile for Shoes?  Keep in mind that our target audience 
is Kids, so think beginners, age maybe 8+ (yes, yes, there are a few 
outliers who are devving video drivers at 6.  blah.  So are mine.)
> 3. Packaging issues aside, what should we do about the two other main 
issues with Redshoes : audio driver, layout manager?  Bloopsaphone is just
plain custom; should we go external a-la the video (VLC)? The group did do
some preliminary work to move some of the Shoes-C logic out of C into 
Ruby.  Though I'll bet that a lot of what's in C is performance related 
(even if by slices).  Remember that _why is a very shrewd analyst of the 
inner workings of many things.
> 
> Looking forward to your thoughts.
> Peter Fitzgibbons
> (847) 859-9550
> Email: peter.fitzgibbons@gmail.com
> IM GTalk: peter.fitzgibbons
> IM AOL: peter.fitzgibbons@gmail.com
> 
> 
> On Sun, Sep 9, 2012 at 4:37 AM, Jenna Fox <a@creativepony.com> wrote:
> I don't buy it. Löve 2D continues to have a functional cross platform 
packager. It's open source too! If Löve can do it, so can Shoes - them's 
the rules in this turing complete world of ours. Everything else is an 
excuse.
> 
> In the past two weeks a severe java vulnerability was publicised which 
oracle sat on for six months, allowing applets in webpages and other java 
apps to escalate privileges to arbitrary settings without user permission 
or deception. Oracle gave the security community the finger, and the 
security community gave them the finger back. Meanwhile this week an FBI 
agent had interesting files copied from their laptop via a java security 
vulnerability (AtomicArrayReference) which was then published online via 
bittorrent and the likes. Pretty hilarious ownage 
http://www.metafilter.com/119597/1-million-Apple-UUIDs-leaked-after-FBI-security-breach
> 
> I can't in good faith recommend anyone use Shoes, or the flawed and 
dangerous technologies it is increasingly being built on.
> 
> I'd love to see what would happen if Löve 2D met mruby. A Ruby Löve 
would be pretty outstanding. Till then, I observe the demise of shoes from
afar.
> 
> —
> Jenna
> 
> On Sunday, 9 September 2012 at 7:06 PM, Peter Fitzgibbons wrote:
> 
>> HI Cecil,
>> 
>> The reasons for abandoned support of RedShoes 3.x build is that OS 
versions have clobbered the cross-platform build process.
>> 
>> What this means;  Windows compilations have been shaky at best since 
WindowsVista/Windows7.  The expectation is that a single build and 
packaged binary can be created that will run WinXP AND Win7 (now also 
Win8).
>> On Mac, OSX Lion has solidified the 32bit -> 64bit upgrade, and with 
that taken away the ability for a single build and packaged binary to work
in both environments.  In fact we have not even been able to do 
cross-version builds at all.  A Lion build wont' work on SnowLeopard at 
all.
>> The Linux situation is a bit better but overall the same situation, 
32bit -> 64bit upgrade breaks the cross-platform build process.
>> 
>> So, recall that RedShoes was heavily dependent upon custom-C and 
external libraries, which are built cross-platform into a single 
monolithic, cross-platform compatible tarball (zip, installer, whatever).
_why created this in a masterful way, in the day when 32-bit was new-ish, 
Win95 was in full-steam, WinXP was on the horizon, most Linux distros were
just becoming pure 32bit, and OS 'X' was now solid (Tiger -> Leopard 
days).
>> 
>> Now we are on another bit-upgrade horizon, 32bit -> 64bit, and the 
build systems across the board are radically changing, for the better we 
hope.  The side-effect of this is that cross-platform compilation is not 
feasible.
>> 
>> The birth of Shoes4 / Jruby / SWT was a move to alleviate our packaging
woes by leveraging the vast Java community and their continuing work on 
cross-platform compatability.  While acknowledging that dependency on an 
external binary is a bit of a "risk" in some ways, the benefits and clear 
stable-base of the JVM community gives us the space to build (or use) a 
packager that works cross-platform and builds cross-platform.
>> 
>> Although we have been focused in the past 2-3 months on SWT, that work 
has been a proof that SWT has the tools and capability we need to produce 
in Shoes.  This email thread is quite coincidental as this week I had 
started my own thought process around when would be the best time to 
re-energize the packaging question.
>> 
>> Thank you all for your work and inspiration.  With some Java packaging 
mojo, we might even be able to release a Shoes4 Preview that the world 
could use and begin to play with.
>> 
>> Kindest Regards,
>> 
>> Peter Fitzgibbons
>> (847) 859-9550
>> Email: peter.fitzgibbons@gmail.com
>> IM GTalk: peter.fitzgibbons
>> IM AOL: peter.fitzgibbons@gmail.com
>> 
>> 
>> On Sat, Sep 8, 2012 at 9:13 PM, Cecil Coupe <ccoupe@cableone.net> wrote:
>>> On 09/08/2012 05:43 PM, Jenna Fox wrote:
>>> > I agree fully. I've long held the view that shoes is effectively dead if
>>> > packaging doesn't work.
>>> >
>>> > —
>>> > Jenna
>>> >
>>> 
>>> In the case of Red Shoes 3.x, I completely agree. Packaging has been
>>> half broken or half working for several years.  I know Ashbb has a
>>> windows shoes version that works well (on Windows) and I know Eric did
>>> some work on the OSX parts. I don't know that either of them made it to
>>> the website for initial user download and that they request the newer
>>> updated Shoes when packaging a script for either one.
>>> 
>>> I stopped beating the drum on the packaging issues of Red Shoes because
>>> maintenance of Red Shoes is a very low priority for the C level
>>> developers. Red Shoes is not being maintained or updated for lack of
>>> developer interest in doing it.  All we need is a Windows MingW C
>>> developer and an OSX/Obj-c developer that are willing to tackle the
>>> challenge and finish the task.
>>> 
>>> --Cecil
>>> 
>>> 
>>> 
>> 
> 
> 
> 

Re: [shoes] Proposal

From:
Jenna Fox
Date:
2012-09-09 @ 23:56
I really think shoes should take a page from Löve 2D here - their 
packaging works and is so simple you don't even really need a GUI for it 
(though it certainly doesn't hurt) - it completely solves the binject 
stuff and gives shoes access to code which is already well maintained by 
the game developer community. Binject is insane, and that thing which 
tries to create and modify DMG's cross platform is also insane - DMG is an
undocumented internal private apple format, which many indie mac 
developers and even apple themselves in some instances recommend against 
using for app distribution. Zips just work faster, better, easier, and are
a documented format. As I understand it, shy is currently a tarball 
format. Zip would be better for compression. Compression in many cases 
speeds up file loading, as computers tend to be faster at decompressing 
things than they are at loading things from hard drives, though SSDs may 
have changed that equation.  

Löve 2D is licensed under the zlib/libpng license, as shoes already comes 
with zlib and png support, so you aught to be able to use any code from 
their project in shoes.

Löve source code: https://bitbucket.org/rude/love/src - filesystem stuff 
is in 
https://bitbucket.org/rude/love/src/a66afb2d4fd0/src/modules/filesystem
PhysicsFS - the transparent filesystem doodad for games: 
http://icculus.org/physfs/ (Löve depends on it - it handles zip file 
access and real FS file access in a nice layered transparent way)
If MRI could be modified to use PhysicsFS for it's File and IO classes, 
and to load the shoes app from physicsfs too, that'd go a long way towards
packaging. I think in theory, then you just point shoes at it's own binary
and say "It's a zip!" and the physicsfs system goes and finds a zip inside
it - rather like when people embed zips and rars in to jpegs, pngs, and 
mp3s. JAR files are kind of already zips, so the same sort of zippy 
architecture is probably relevant (dump some java stuff inside a 
hypothetical zip-based shy format, and rename to .jar and hey presto? 
maybe)

Then maybe we can ceremonially burn binject and friends and send their 
husk-like corpses out to sea?


—
Jenna


On Monday, 10 September 2012 at 9:06 AM, Eric Watson wrote:

> I'm glad we are talking about this again ;) I agree that the packager is
essential, and I have been sweating the fact that nobody is working out 
the details of packaging for Shoes 4. I have also been fiddling with a 
couple of options for Shoes 4, but without breakthrough success.
>  
> Please remember that while Shoes may be for beginners or for kids, is 
also for rodents and for purveyors of fine leather goods, among others.
>  
> I have also put in a fair amount of time trying to get Shoes 3 packaging
to work again, without success. I believe this is mostly to do with my own
poor C skills--certainly it is technically possible to pull off packaging,
as Jenna points out. One problem with our packaging system is that it has 
a bunch of moving parts (stubs, C code, Ruby code, URLs, web services, 
etc), and it's hard to keep them all in sync when you're not familiar with
the code. Another problem is that we are relying on some fairly tricky 
libraries like binject, which are also not maintained.
>  
> It's also worth noting that most of the efforts to get packaging working
have been solo efforts. It is incredibly easy to get frustrated working on
this alone. Perhaps we would be more successful if we had a few of us 
working on it together. Also--lots of the packaging will probably be the 
same for Shoes 3 and Shoes 4 (wrapping code up in a .exe or .app, for 
instance), so this work is shareable.
>  
> So packaging is tough, but my biggest difficulty in hacking on Shoes is 
that it's so big and so complex that I am afraid to make changes, because 
I don't fully understand the system, and there are no tests to give me 
confidence that my changes haven't screwed something else up. That's why I
have been working on coding what is being called "Shoes 4", which is a 
frontend that runs in a regular Ruby, so it's easy to test, and which will
accept multiple backends (Swt, Qt, Gtk, etc), which also can run in a 
regular Ruby and be tested. This is a huge win for me, and I hope it makes
it easier for others to get involved.
>  
> +1 packaging wiki page, with instructions on how to compile like Hackety Hack.
>  
> Thanks everyone for your courage, honesty, insight, and kindness.
>  
> Eric
>  
> On Sep 9, 2012, at 6:37 AM, David Eastman wrote:
>  
> > I don't want to just pile on here, but am worried by the spurious 
"target audience is kids" thing.
> >  
> > You mean the target audience is beginners, many of whom are probably 
kids, right?
> >  
> > Or better yet, the target audience does not have a background in 
development, so presentation cannot assume knowledge of other platforms or
concepts. I hope no one is second guessing what kids do or don't need. 
Surely _why didn't. Maybe the thinking here is kids don't need packaging??

> >  
> > OK, rant off. But I'm as keen as Jenna seems to be to not allow 
strange motivations to stunt shoes.  
> >  
> > I can't work out if there is enough interest in Bloopsaphone to 
maintain it as a library. Seen a flurry of chiptunes nostalgia things 2 
years back. I'm sure that moving code to ruby just makes sense; there will
always be other ways to address performance issues.  
> >  
> > One thing Jenna said that caught my attention: "there really aren't 
that many gems and libraries which are important for making a game or a 
little program" - I have found that to be strangely true. Apart from a 
json and json schema library, I can't think of any other gems I needed 
recently for smaller/gaming apps. Might well be a thing worth surveying to
help guide decisions.
> >  
> >  
> > On Sun, Sep 9, 2012 at 11:19 AM, Peter Fitzgibbons 
<peter.fitzgibbons@gmail.com (mailto:peter.fitzgibbons@gmail.com)> wrote:
> > So, given that Löve has binaries for all platforms, a few questions :
> > 1. How is the build process. Does that developer team have to build on
that many different source-systems in order to get their builds? Shoes was
originally created to "cross-build"... a Windows Shoes can build a 
Mac-compatible zip/install, and Linux -> WIndows, all the permutations.
> > 2. What would your recommendation be for the most user-friendly 
cross-platform profile for Shoes? Keep in mind that our target audience is
Kids, so think beginners, age maybe 8+ (yes, yes, there are a few outliers
who are devving video drivers at 6. blah. So are mine.)
> > 3. Packaging issues aside, what should we do about the two other main 
issues with Redshoes : audio driver, layout manager? Bloopsaphone is just 
plain custom; should we go external a-la the video (VLC)? The group did do
some preliminary work to move some of the Shoes-C logic out of C into 
Ruby. Though I'll bet that a lot of what's in C is performance related 
(even if by slices). Remember that _why is a very shrewd analyst of the 
inner workings of many things.
> >  
> > Looking forward to your thoughts.
> > Peter Fitzgibbons
> > (847) 859-9550
> > Email: peter.fitzgibbons@gmail.com (mailto:peter.fitzgibbons@gmail.com)
> > IM GTalk: peter.fitzgibbons
> > IM AOL: peter.fitzgibbons@gmail.com (mailto:peter.fitzgibbons@gmail.com)
> >  
> >  
> > On Sun, Sep 9, 2012 at 4:37 AM, Jenna Fox <a@creativepony.com 
(mailto:a@creativepony.com)> wrote:
> > I don't buy it. Löve 2D continues to have a functional cross platform 
packager. It's open source too! If Löve can do it, so can Shoes - them's 
the rules in this turing complete world of ours. Everything else is an 
excuse.
> >  
> > In the past two weeks a severe java vulnerability was publicised which
oracle sat on for six months, allowing applets in webpages and other java 
apps to escalate privileges to arbitrary settings without user permission 
or deception. Oracle gave the security community the finger, and the 
security community gave them the finger back. Meanwhile this week an FBI 
agent had interesting files copied from their laptop via a java security 
vulnerability (AtomicArrayReference) which was then published online via 
bittorrent and the likes. Pretty hilarious ownage 
http://www.metafilter.com/119597/1-million-Apple-UUIDs-leaked-after-FBI-security-breach
> >  
> > I can't in good faith recommend anyone use Shoes, or the flawed and 
dangerous technologies it is increasingly being built on.
> >  
> > I'd love to see what would happen if Löve 2D met mruby. A Ruby Löve 
would be pretty outstanding. Till then, I observe the demise of shoes from
afar.
> >  
> > —
> > Jenna
> >  
> > On Sunday, 9 September 2012 at 7:06 PM, Peter Fitzgibbons wrote:
> >  
> > > HI Cecil,
> > >  
> > > The reasons for abandoned support of RedShoes 3.x build is that OS 
versions have clobbered the cross-platform build process.
> > >  
> > > What this means; Windows compilations have been shaky at best since 
WindowsVista/Windows7. The expectation is that a single build and packaged
binary can be created that will run WinXP AND Win7 (now also Win8).
> > > On Mac, OSX Lion has solidified the 32bit -> 64bit upgrade, and with
that taken away the ability for a single build and packaged binary to work
in both environments. In fact we have not even been able to do 
cross-version builds at all. A Lion build wont' work on SnowLeopard at 
all.
> > > The Linux situation is a bit better but overall the same situation, 
32bit -> 64bit upgrade breaks the cross-platform build process.
> > >  
> > > So, recall that RedShoes was heavily dependent upon custom-C and 
external libraries, which are built cross-platform into a single 
monolithic, cross-platform compatible tarball (zip, installer, whatever). 
_why created this in a masterful way, in the day when 32-bit was new-ish, 
Win95 was in full-steam, WinXP was on the horizon, most Linux distros were
just becoming pure 32bit, and OS 'X' was now solid (Tiger -> Leopard 
days).
> > >  
> > > Now we are on another bit-upgrade horizon, 32bit -> 64bit, and the 
build systems across the board are radically changing, for the better we 
hope. The side-effect of this is that cross-platform compilation is not 
feasible.
> > >  
> > > The birth of Shoes4 / Jruby / SWT was a move to alleviate our 
packaging woes by leveraging the vast Java community and their continuing 
work on cross-platform compatability. While acknowledging that dependency 
on an external binary is a bit of a "risk" in some ways, the benefits and 
clear stable-base of the JVM community gives us the space to build (or 
use) a packager that works cross-platform and builds cross-platform.
> > >  
> > > Although we have been focused in the past 2-3 months on SWT, that 
work has been a proof that SWT has the tools and capability we need to 
produce in Shoes. This email thread is quite coincidental as this week I 
had started my own thought process around when would be the best time to 
re-energize the packaging question.
> > >  
> > > Thank you all for your work and inspiration. With some Java 
packaging mojo, we might even be able to release a Shoes4 Preview that the
world could use and begin to play with.
> > >  
> > > Kindest Regards,
> > >  
> > > Peter Fitzgibbons
> > > (847) 859-9550
> > > Email: peter.fitzgibbons@gmail.com (mailto:peter.fitzgibbons@gmail.com)
> > > IM GTalk: peter.fitzgibbons
> > > IM AOL: peter.fitzgibbons@gmail.com (mailto:peter.fitzgibbons@gmail.com)
> > >  
> > >  
> > > On Sat, Sep 8, 2012 at 9:13 PM, Cecil Coupe <ccoupe@cableone.net 
(mailto:ccoupe@cableone.net)> wrote:
> > > > On 09/08/2012 05:43 PM, Jenna Fox wrote:
> > > > > I agree fully. I've long held the view that shoes is effectively dead if
> > > > > packaging doesn't work.
> > > > >  
> > > > > —
> > > > > Jenna
> > > > >  
> > > >  
> > > >  
> > > > In the case of Red Shoes 3.x, I completely agree. Packaging has been
> > > > half broken or half working for several years. I know Ashbb has a
> > > > windows shoes version that works well (on Windows) and I know Eric did
> > > > some work on the OSX parts. I don't know that either of them made it to
> > > > the website for initial user download and that they request the newer
> > > > updated Shoes when packaging a script for either one.
> > > >  
> > > > I stopped beating the drum on the packaging issues of Red Shoes because
> > > > maintenance of Red Shoes is a very low priority for the C level
> > > > developers. Red Shoes is not being maintained or updated for lack of
> > > > developer interest in doing it. All we need is a Windows MingW C
> > > > developer and an OSX/Obj-c developer that are willing to tackle the
> > > > challenge and finish the task.
> > > >  
> > > > --Cecil  

Re: [shoes] Proposal

From:
J. Kaiden
Date:
2012-09-10 @ 00:24
package!  oh yes, package!  couldn't agree more that this is a big (wicked
big) issue.

wish i could help more, will study up and try to do so...

everyone needs shoes,

  - j



On Sun, Sep 9, 2012 at 11:56 PM, Jenna Fox <a@creativepony.com> wrote:

>  I really think shoes should take a page from Löve 2D here - their
> packaging works and is so simple you don't even really need a GUI for it
> (though it certainly doesn't hurt) - it completely solves the binject stuff
> and gives shoes access to code which is already well maintained by the game
> developer community. Binject is insane, and that thing which tries to
> create and modify DMG's cross platform is also insane - DMG is an
> undocumented internal private apple format, which many indie mac developers
> and even apple themselves in some instances recommend against using for app
> distribution. Zips just work faster, better, easier, and are a documented
> format. As I understand it, shy is currently a tarball format. Zip would be
> better for compression. Compression in many cases speeds up file loading,
> as computers tend to be faster at decompressing things than they are at
> loading things from hard drives, though SSDs may have changed that
> equation.
>
> Löve 2D is licensed under the zlib/libpng license, as shoes already comes
> with zlib and png support, so you aught to be able to use any code from
> their project in shoes.
>
> Löve source code: https://bitbucket.org/rude/love/src - filesystem stuff
> is in
> https://bitbucket.org/rude/love/src/a66afb2d4fd0/src/modules/filesystem
> PhysicsFS - the transparent filesystem doodad for games:
> http://icculus.org/physfs/ (Löve depends on it - it handles zip file
> access and real FS file access in a nice layered transparent way)
> If MRI could be modified to use PhysicsFS for it's File and IO classes,
> and to load the shoes app from physicsfs too, that'd go a long way towards
> packaging. I think in theory, then you just point shoes at it's own binary
> and say "It's a zip!" and the physicsfs system goes and finds a zip inside
> it - rather like when people embed zips and rars in to jpegs, pngs, and
> mp3s. JAR files are kind of already zips, so the same sort of zippy
> architecture is probably relevant (dump some java stuff inside a
> hypothetical zip-based shy format, and rename to .jar and hey presto? maybe)
>
> Then maybe we can ceremonially burn binject and friends and send their
> husk-like corpses out to sea?
>
>
> —
> Jenna
>
> On Monday, 10 September 2012 at 9:06 AM, Eric Watson wrote:
>
> I'm glad we are talking about this again ;) I agree that the packager is
> essential, and I have been sweating the fact that nobody is working out the
> details of packaging for Shoes 4. I have also been fiddling with a couple
> of options for Shoes 4, but without breakthrough success.
>
> Please remember that while Shoes may be for beginners or for kids, is also
> for rodents and for purveyors of fine leather goods, among others.
>
> I have also put in a fair amount of time trying to get Shoes 3 packaging
> to work again, without success. I believe this is mostly to do with my own
> poor C skills--certainly it is technically possible to pull off packaging,
> as Jenna points out. One problem with our packaging system is that it has a
> bunch of moving parts (stubs, C code, Ruby code, URLs, web services, etc),
> and it's hard to keep them all in sync when you're not familiar with the
> code. Another problem is that we are relying on some fairly tricky
> libraries like binject, which are also not maintained.
>
> It's also worth noting that most of the efforts to get packaging working
> have been solo efforts. It is incredibly easy to get frustrated working on
> this alone. Perhaps we would be more successful if we had a few of us
> working on it together. Also--lots of the packaging will probably be the
> same for Shoes 3 and Shoes 4 (wrapping code up in a .exe or .app, for
> instance), so this work is shareable.
>
> So packaging is tough, but my biggest difficulty in hacking on Shoes is
> that it's so big and so complex that I am afraid to make changes, because I
> don't fully understand the system, and there are no tests to give me
> confidence that my changes haven't screwed something else up. That's why I
> have been working on coding what is being called "Shoes 4", which is a
> frontend that runs in a regular Ruby, so it's easy to test, and which will
> accept multiple backends (Swt, Qt, Gtk, etc), which also can run in a
> regular Ruby and be tested. This is a huge win for me, and I hope it makes
> it easier for others to get involved.
>
> +1 packaging wiki page, with instructions on how to compile like Hackety
> Hack.
>
> Thanks everyone for your courage, honesty, insight, and kindness.
>
> Eric
>
> On Sep 9, 2012, at 6:37 AM, David Eastman wrote:
>
> I don't want to just pile on here, but am worried by the spurious "target
> audience is kids" thing.
>
> You mean the target audience is beginners, many of whom are probably kids,
> right?
>
> Or better yet, the target audience does not have a background in
> development, so presentation cannot assume knowledge of other platforms or
> concepts. I hope no one is second guessing what kids do or don't need.
> Surely _why didn't. Maybe the thinking here is kids don't need packaging??
>
> OK, rant off. But I'm as keen as Jenna seems to be to not allow strange
> motivations to stunt shoes.
>
> I can't work out if there is enough interest in Bloopsaphone to maintain
> it as a library. Seen a flurry of chiptunes nostalgia things 2 years back.
> I'm sure that moving code to ruby just makes sense; there will always be
> other ways to address performance issues.
>
> One thing Jenna said that caught my attention: "there really aren't that
> many gems and libraries which are important for making a game or a little
> program" - I have found that to be strangely true. Apart from a json and
> json schema library, I can't think of any other gems I needed recently for
> smaller/gaming apps. Might well be a thing worth surveying to help guide
> decisions.
>
>
> On Sun, Sep 9, 2012 at 11:19 AM, Peter Fitzgibbons <
> peter.fitzgibbons@gmail.com> wrote:
> So, given that Löve has binaries for all platforms, a few questions :
> 1. How is the build process. Does that developer team have to build on
> that many different source-systems in order to get their builds? Shoes was
> originally created to "cross-build"... a Windows Shoes can build a
> Mac-compatible zip/install, and Linux -> WIndows, all the permutations.
> 2. What would your recommendation be for the most user-friendly
> cross-platform profile for Shoes? Keep in mind that our target audience is
> Kids, so think beginners, age maybe 8+ (yes, yes, there are a few outliers
> who are devving video drivers at 6. blah. So are mine.)
> 3. Packaging issues aside, what should we do about the two other main
> issues with Redshoes : audio driver, layout manager? Bloopsaphone is just
> plain custom; should we go external a-la the video (VLC)? The group did do
> some preliminary work to move some of the Shoes-C logic out of C into Ruby.
> Though I'll bet that a lot of what's in C is performance related (even if
> by slices). Remember that _why is a very shrewd analyst of the inner
> workings of many things.
>
> Looking forward to your thoughts.
> Peter Fitzgibbons
> (847) 859-9550
> Email: peter.fitzgibbons@gmail.com
> IM GTalk: peter.fitzgibbons
> IM AOL: peter.fitzgibbons@gmail.com
>
>
> On Sun, Sep 9, 2012 at 4:37 AM, Jenna Fox <a@creativepony.com> wrote:
> I don't buy it. Löve 2D continues to have a functional cross platform
> packager. It's open source too! If Löve can do it, so can Shoes - them's
> the rules in this turing complete world of ours. Everything else is an
> excuse.
>
> In the past two weeks a severe java vulnerability was publicised which
> oracle sat on for six months, allowing applets in webpages and other java
> apps to escalate privileges to arbitrary settings without user permission
> or deception. Oracle gave the security community the finger, and the
> security community gave them the finger back. Meanwhile this week an FBI
> agent had interesting files copied from their laptop via a java security
> vulnerability (AtomicArrayReference) which was then published online via
> bittorrent and the likes. Pretty hilarious ownage
> 
http://www.metafilter.com/119597/1-million-Apple-UUIDs-leaked-after-FBI-security-breach
>
> I can't in good faith recommend anyone use Shoes, or the flawed and
> dangerous technologies it is increasingly being built on.
>
> I'd love to see what would happen if Löve 2D met mruby. A Ruby Löve would
> be pretty outstanding. Till then, I observe the demise of shoes from afar.
>
> —
> Jenna
>
> On Sunday, 9 September 2012 at 7:06 PM, Peter Fitzgibbons wrote:
>
> HI Cecil,
>
> The reasons for abandoned support of RedShoes 3.x build is that OS
> versions have clobbered the cross-platform build process.
>
> What this means; Windows compilations have been shaky at best since
> WindowsVista/Windows7. The expectation is that a single build and packaged
> binary can be created that will run WinXP AND Win7 (now also Win8).
> On Mac, OSX Lion has solidified the 32bit -> 64bit upgrade, and with that
> taken away the ability for a single build and packaged binary to work in
> both environments. In fact we have not even been able to do cross-version
> builds at all. A Lion build wont' work on SnowLeopard at all.
> The Linux situation is a bit better but overall the same situation, 32bit
> -> 64bit upgrade breaks the cross-platform build process.
>
> So, recall that RedShoes was heavily dependent upon custom-C and external
> libraries, which are built cross-platform into a single monolithic,
> cross-platform compatible tarball (zip, installer, whatever). _why created
> this in a masterful way, in the day when 32-bit was new-ish, Win95 was in
> full-steam, WinXP was on the horizon, most Linux distros were just becoming
> pure 32bit, and OS 'X' was now solid (Tiger -> Leopard days).
>
> Now we are on another bit-upgrade horizon, 32bit -> 64bit, and the build
> systems across the board are radically changing, for the better we hope.
> The side-effect of this is that cross-platform compilation is not feasible.
>
> The birth of Shoes4 / Jruby / SWT was a move to alleviate our packaging
> woes by leveraging the vast Java community and their continuing work on
> cross-platform compatability. While acknowledging that dependency on an
> external binary is a bit of a "risk" in some ways, the benefits and clear
> stable-base of the JVM community gives us the space to build (or use) a
> packager that works cross-platform and builds cross-platform.
>
> Although we have been focused in the past 2-3 months on SWT, that work has
> been a proof that SWT has the tools and capability we need to produce in
> Shoes. This email thread is quite coincidental as this week I had started
> my own thought process around when would be the best time to re-energize
> the packaging question.
>
> Thank you all for your work and inspiration. With some Java packaging
> mojo, we might even be able to release a Shoes4 Preview that the world
> could use and begin to play with.
>
> Kindest Regards,
>
> Peter Fitzgibbons
> (847) 859-9550
> Email: peter.fitzgibbons@gmail.com
> IM GTalk: peter.fitzgibbons
> IM AOL: peter.fitzgibbons@gmail.com
>
>
> On Sat, Sep 8, 2012 at 9:13 PM, Cecil Coupe <ccoupe@cableone.net> wrote:
>
> On 09/08/2012 05:43 PM, Jenna Fox wrote:
>
> I agree fully. I've long held the view that shoes is effectively dead if
> packaging doesn't work.
>
> —
> Jenna
>
>
> In the case of Red Shoes 3.x, I completely agree. Packaging has been
> half broken or half working for several years. I know Ashbb has a
> windows shoes version that works well (on Windows) and I know Eric did
> some work on the OSX parts. I don't know that either of them made it to
> the website for initial user download and that they request the newer
> updated Shoes when packaging a script for either one.
>
> I stopped beating the drum on the packaging issues of Red Shoes because
> maintenance of Red Shoes is a very low priority for the C level
> developers. Red Shoes is not being maintained or updated for lack of
> developer interest in doing it. All we need is a Windows MingW C
> developer and an OSX/Obj-c developer that are willing to tackle the
> challenge and finish the task.
>
> --Cecil
>
>
>

Re: [shoes] Proposal

From:
Eric Watson
Date:
2012-09-10 @ 12:12
On Sep 9, 2012, at 6:56 PM, Jenna Fox wrote:

> I really think shoes should take a page from Löve 2D here - their 
packaging works and is so simple you don't even really need a GUI for it 
(though it certainly doesn't hurt) - it completely solves the binject 
stuff and gives shoes access to code which is already well maintained by 
the game developer community.

Let's look into this. First thing to note is that if we switch to a .zip 
based format, we should name it .roos 
(http://en.wikipedia.org/wiki/KangaRoos). I'm checking out Löve 2D (see 
packaging at https://love2d.org/wiki/Game_Distribution), and I think they 
have something to offer us. It doesn't appear to be *quite* as simple as 
you say :)

> 	• The end result will not be a single executable, you must also include
some DLLs in your zip-file.

So on Windows, you distribute a .zip that contains a .exe and some .dlls. 
That sounds not ideal. Windows users?

For Mac, you would copy your existing Shoes.app and twiddle some files. 
Sounds pretty easy. But they don't offer a gui for this. We could explore 
here.

Let's look into this, because it's true--the minitar lib that Shoes uses 
is a liability.

Eric

Re: [shoes] Proposal

From:
Jenna Fox
Date:
2012-09-09 @ 11:01
I'm no expert, but here's what I know of Löve's packaging system:  

1) They don't, so far as I know, have a GUI for cross-packaging, but it'd 
be a fairly simple addition.
1-a) Windows Packaging works by running copy /b love.exe+game.love 
game.exe on a windows machine - I was confused by that, but all it does is
append the game.love zip file to game.exe, just like...
1-b) Linux! For linux packaging, you simply append game.love to the end of
the love binary
1-c) For mac packaging, you drop the game.love zip file in 
love.app/Contents/Resources and change the icon if you like
1-d) and by the way a .love file is just a renamed zip with some lua files
and images and things inside. How awesome is that? All you need is a thing
to zip and a thing to append bytes!

Windows and Linux are so absurdly easy to package with Löve's system, they
need no discussion. Mac OS X packaging is easy to do cross platform - you 
just need a zip containing the Löve for Mac build, and a little ruby 
library for injecting files in to zips, which you'd need anyway to make 
the .love bundle automatically. By injecting the resource directly in to 
the zip you avoid the mess of unpacking unix executables in windows and 
possibly messing the executable bit on the binary inside. Nice and tidy!

2) Not sure what you mean by "cross-platform profile"? I don't really have
any strong views on particular technologies to get the job done, my view 
is only that for shoes to be really compelling, kids need to be able to 
make games and export them for Mac and Windows as a file which adds no 
more than ten-fifteen megabytes to the images and things they put in their
game. It must not need any installers or other things. It should be two 
zips, one with a windows .exe inside, another with a mac .app folder. 
Linux whatever goes who even knows?

The great thing in shoes isn't the rubygems or the stdlib or anything fat 
or complicated like that - it's the core ruby language, and the shoes api 
itself. Playing with RubyMotion has taught me that while it's nice to be 
able to grab whatever off rubygems, it isn't necessary, and there really 
aren't that many gems and libraries which are important for making a game 
or a little program. If it couldn't support rubygems for some reason who 
cares? And stdlib? to heck with it - most of it's crappy anyway.

3) If shoes is still being positioned primarily as a fun thing for kids, 
games are the main use case, and as such audio needs to revolve around 
latency. That means two things - you need a thing for playing background 
music, and a thing for playing low latency positional audio. The thing for
background music is the same thing you use for videos, I expect. For low 
latency positional audio, the very best you could do is OpenAL. It's a 
widely used cross platform library designed explicitly for playing sounds 
very precisely, and it'd be perfect for this job if not for Microsoft 
inventing their own thing in this space. This is how you make windows go: 
http://kcat.strangesoft.net/openal.html If you could have sound objects 
which can load from wavs music objects which load from mp3's, with play, 
pause, pitch, pan, volume controls on each, you would be doing very well 
for sound. OpenAL also opens the possibility of 3d sound and even as of a 
year ago quite compelling HRTF virtual 3d sound through headphones. For 
bonus points add a gadget so the sound effects can load from mp3's as 
well, by decoding them and handing the raw sound data to OpenAL Soft.

Layout manager? No idea. I don't even know what that is. It seems like 
this should be well trodden ground in web rendering engines - have people 
looked in to how they do it?

References:
Love's packaging system: http://love2d.org/wiki/Game_Distribution

—
Jenna


On Sunday, 9 September 2012 at 8:19 PM, Peter Fitzgibbons wrote:

> So, given that Löve has binaries for all platforms, a few questions :
> 1. How is the build process.  Does that developer team have to build on 
that many different source-systems in order to get their builds?   Shoes 
was originally created to "cross-build"...  a Windows Shoes can build a 
Mac-compatible zip/install, and Linux -> WIndows, all the permutations.
> 2. What would your recommendation be for the most user-friendly 
cross-platform profile for Shoes?  Keep in mind that our target audience 
is Kids, so think beginners, age maybe 8+ (yes, yes, there are a few 
outliers who are devving video drivers at 6.  blah.  So are mine.)
> 3. Packaging issues aside, what should we do about the two other main 
issues with Redshoes : audio driver, layout manager?  Bloopsaphone is just
plain custom; should we go external a-la the video (VLC)? The group did do
some preliminary work to move some of the Shoes-C logic out of C into 
Ruby.  Though I'll bet that a lot of what's in C is performance related 
(even if by slices).  Remember that _why is a very shrewd analyst of the 
inner workings of many things.
>  
> Looking forward to your thoughts.
> Peter Fitzgibbons
> (847) 859-9550
> Email: peter.fitzgibbons@gmail.com (mailto:peter.fitzgibbons@gmail.com)
> IM GTalk: peter.fitzgibbons
> IM AOL: peter.fitzgibbons@gmail.com (mailto:peter.fitzgibbons@gmail.com)
>  
>  
> On Sun, Sep 9, 2012 at 4:37 AM, Jenna Fox <a@creativepony.com 
(mailto:a@creativepony.com)> wrote:
> > I don't buy it. Löve 2D continues to have a functional cross platform 
packager. It's open source too! If Löve can do it, so can Shoes - them's 
the rules in this turing complete world of ours. Everything else is an 
excuse.  
> >  
> > In the past two weeks a severe java vulnerability was publicised which
oracle sat on for six months, allowing applets in webpages and other java 
apps to escalate privileges to arbitrary settings without user permission 
or deception. Oracle gave the security community the finger, and the 
security community gave them the finger back. Meanwhile this week an FBI 
agent had interesting files copied from their laptop via a java security 
vulnerability (AtomicArrayReference) which was then published online via 
bittorrent and the likes. Pretty hilarious ownage 
http://www.metafilter.com/119597/1-million-Apple-UUIDs-leaked-after-FBI-security-breach

> >  
> > I can't in good faith recommend anyone use Shoes, or the flawed and 
dangerous technologies it is increasingly being built on.
> >  
> > I'd love to see what would happen if Löve 2D met mruby. A Ruby Löve 
would be pretty outstanding. Till then, I observe the demise of shoes from
afar.  
> >  
> > —
> > Jenna
> >  
> >  
> > On Sunday, 9 September 2012 at 7:06 PM, Peter Fitzgibbons wrote:
> >  
> > > HI Cecil,
> > >  
> > > The reasons for abandoned support of RedShoes 3.x build is that OS 
versions have clobbered the cross-platform build process.
> > >  
> > > What this means;  Windows compilations have been shaky at best since
WindowsVista/Windows7.  The expectation is that a single build and 
packaged binary can be created that will run WinXP AND Win7 (now also 
Win8).  
> > > On Mac, OSX Lion has solidified the 32bit -> 64bit upgrade, and with
that taken away the ability for a single build and packaged binary to work
in both environments.  In fact we have not even been able to do 
cross-version builds at all.  A Lion build wont' work on SnowLeopard at 
all.
> > > The Linux situation is a bit better but overall the same situation, 
32bit -> 64bit upgrade breaks the cross-platform build process.
> > >  
> > > So, recall that RedShoes was heavily dependent upon custom-C and 
external libraries, which are built cross-platform into a single 
monolithic, cross-platform compatible tarball (zip, installer, whatever).
_why created this in a masterful way, in the day when 32-bit was new-ish, 
Win95 was in full-steam, WinXP was on the horizon, most Linux distros were
just becoming pure 32bit, and OS 'X' was now solid (Tiger -> Leopard 
days).  
> > >  
> > > Now we are on another bit-upgrade horizon, 32bit -> 64bit, and the 
build systems across the board are radically changing, for the better we 
hope.  The side-effect of this is that cross-platform compilation is not 
feasible.  
> > >  
> > > The birth of Shoes4 / Jruby / SWT was a move to alleviate our 
packaging woes by leveraging the vast Java community and their continuing 
work on cross-platform compatability.  While acknowledging that dependency
on an external binary is a bit of a "risk" in some ways, the benefits and 
clear stable-base of the JVM community gives us the space to build (or 
use) a packager that works cross-platform and builds cross-platform.  
> > >  
> > > Although we have been focused in the past 2-3 months on SWT, that 
work has been a proof that SWT has the tools and capability we need to 
produce in Shoes.  This email thread is quite coincidental as this week I 
had started my own thought process around when would be the best time to 
re-energize the packaging question.  
> > >  
> > > Thank you all for your work and inspiration.  With some Java 
packaging mojo, we might even be able to release a Shoes4 Preview that the
world could use and begin to play with.
> > >  
> > > Kindest Regards,
> > >  
> > > Peter Fitzgibbons
> > > (847) 859-9550 (tel:%28847%29%20859-9550)
> > > Email: peter.fitzgibbons@gmail.com (mailto:peter.fitzgibbons@gmail.com)
> > > IM GTalk: peter.fitzgibbons
> > > IM AOL: peter.fitzgibbons@gmail.com (mailto:peter.fitzgibbons@gmail.com)
> > >  
> > >  
> > > On Sat, Sep 8, 2012 at 9:13 PM, Cecil Coupe <ccoupe@cableone.net 
(mailto:ccoupe@cableone.net)> wrote:
> > > > On 09/08/2012 05:43 PM, Jenna Fox wrote:
> > > > > I agree fully. I've long held the view that shoes is effectively dead if
> > > > > packaging doesn't work.
> > > > >
> > > > > —
> > > > > Jenna
> > > > >
> > > >  
> > > > In the case of Red Shoes 3.x, I completely agree. Packaging has been
> > > > half broken or half working for several years.  I know Ashbb has a
> > > > windows shoes version that works well (on Windows) and I know Eric did
> > > > some work on the OSX parts. I don't know that either of them made it to
> > > > the website for initial user download and that they request the newer
> > > > updated Shoes when packaging a script for either one.
> > > >  
> > > > I stopped beating the drum on the packaging issues of Red Shoes because
> > > > maintenance of Red Shoes is a very low priority for the C level
> > > > developers. Red Shoes is not being maintained or updated for lack of
> > > > developer interest in doing it.  All we need is a Windows MingW C
> > > > developer and an OSX/Obj-c developer that are willing to tackle the
> > > > challenge and finish the task.
> > > >  
> > > > --Cecil
> > > >  
> > > >  
> > > >  
> > >  
> >  
>  

Re: [shoes] Proposal

From:
Cecil Coupe
Date:
2012-09-10 @ 04:16
Hawley, don't worry about a flame war. I've unleashed many of them about 
packaging. I even attempted to document packaging a year ago at

https://github.com/shoes/shoes/wiki/A-Developer%27s-Tour-Through-The-Magic-Packager

For those that want a wiki page to discuss it's faults, just get a 
github account associated with shoes/shoes and edit this at will:
https://github.com/shoes/shoes/wiki/Problems-with-Red-Shoes-Packaging

Edit away, wiki fans.

Peter, I'm well aware of the problems of red shoes and the shifting 
platforms and the hope that will all be solved by using jruby and java 
to handle all the platform "stuff". A worthy goal that I fully support. 
Until then, we have the problems that Hawley and others have enumerated.

Jenna, As far I know, Apple's dmg is not proprietary but it is not well 
documented unless you did deep into the Developers documentation. Kind 
of like MSFT's PEF. You can find the info if you look hard enough.

--Cecil

On 09/09/2012 03:06 AM, Peter Fitzgibbons wrote:
> HI Cecil,
>
> The reasons for abandoned support of RedShoes 3.x build is that OS
> versions have clobbered the cross-platform build process.
>
> What this means;  Windows compilations have been shaky at best since
> WindowsVista/Windows7.  The expectation is that a single build and
> packaged binary can be created that will run WinXP AND Win7 (now also Win8).
> On Mac, OSX Lion has solidified the 32bit -> 64bit upgrade, and with
> that taken away the ability for a single build and packaged binary to
> work in both environments.  In fact we have not even been able to do
> cross-version builds at all.  A Lion build wont' work on SnowLeopard at all.
> The Linux situation is a bit better but overall the same situation,
> 32bit -> 64bit upgrade breaks the cross-platform build process.
>
> So, recall that RedShoes was heavily dependent upon custom-C and
> external libraries, which are built cross-platform into a single
> monolithic, cross-platform compatible tarball (zip, installer,
> whatever).  _why created this in a masterful way, in the day when 32-bit
> was new-ish, Win95 was in full-steam, WinXP was on the horizon, most
> Linux distros were just becoming pure 32bit, and OS 'X' was now solid
> (Tiger -> Leopard days).
>
> Now we are on another bit-upgrade horizon, 32bit -> 64bit, and the build
> systems across the board are radically changing, for the better we hope.
>   The side-effect of this is that cross-platform compilation is not
> feasible.
>
> The birth of Shoes4 / Jruby / SWT was a move to alleviate our packaging
> woes by leveraging the vast Java community and their continuing work on
> cross-platform compatability.  While acknowledging that dependency on an
> external binary is a bit of a "risk" in some ways, the benefits and
> clear stable-base of the JVM community gives us the space to build (or
> use) a packager that works cross-platform and builds cross-platform.
>
> Although we have been focused in the past 2-3 months on SWT, that work
> has been a proof that SWT has the tools and capability we need to
> produce in Shoes.  This email thread is quite coincidental as this week
> I had started my own thought process around when would be the best time
> to re-energize the packaging question.
>
> Thank you all for your work and inspiration.  With some Java packaging
> mojo, we might even be able to release a Shoes4 Preview that the world
> could use and begin to play with.
>
> Kindest Regards,
>
> Peter Fitzgibbons
> (847) 859-9550
> Email: peter.fitzgibbons@gmail.com <mailto:peter.fitzgibbons@gmail.com>
> IM GTalk: peter.fitzgibbons
> IM AOL: peter.fitzgibbons@gmail.com <mailto:peter.fitzgibbons@gmail.com>
>
>
> On Sat, Sep 8, 2012 at 9:13 PM, Cecil Coupe <ccoupe@cableone.net
> <mailto:ccoupe@cableone.net>> wrote:
>
>     On 09/08/2012 05:43 PM, Jenna Fox wrote:
>      > I agree fully. I've long held the view that shoes is effectively
>     dead if
>      > packaging doesn't work.
>      >
>      > —
>      > Jenna
>      >
>
>     In the case of Red Shoes 3.x, I completely agree. Packaging has been
>     half broken or half working for several years.  I know Ashbb has a
>     windows shoes version that works well (on Windows) and I know Eric did
>     some work on the OSX parts. I don't know that either of them made it to
>     the website for initial user download and that they request the newer
>     updated Shoes when packaging a script for either one.
>
>     I stopped beating the drum on the packaging issues of Red Shoes because
>     maintenance of Red Shoes is a very low priority for the C level
>     developers. Red Shoes is not being maintained or updated for lack of
>     developer interest in doing it.  All we need is a Windows MingW C
>     developer and an OSX/Obj-c developer that are willing to tackle the
>     challenge and finish the task.
>
>     --Cecil
>
>
>
>

Re: [shoes] Proposal

From:
Jenna Fox
Date:
2012-09-10 @ 04:23
Wikipedia's article on DMG repeatedly states it is a proprietary format 
which has only been partially reverse engineered 
http://en.wikipedia.org/wiki/Apple_Disk_Image Regardless, it is no better 
than a zip and in many ways worse, so it shouldn't be a part of shoes 
packaging, seeing as zips are cross platform and well documented.  

—
Jenna


On Monday, 10 September 2012 at 2:16 PM, Cecil Coupe wrote:

> Hawley, don't worry about a flame war. I've unleashed many of them about  
> packaging. I even attempted to document packaging a year ago at
> 
https://github.com/shoes/shoes/wiki/A-Developer%27s-Tour-Through-The-Magic-Packager
>  
> For those that want a wiki page to discuss it's faults, just get a  
> github account associated with shoes/shoes and edit this at will:
> https://github.com/shoes/shoes/wiki/Problems-with-Red-Shoes-Packaging
>  
> Edit away, wiki fans.
>  
> Peter, I'm well aware of the problems of red shoes and the shifting  
> platforms and the hope that will all be solved by using jruby and java  
> to handle all the platform "stuff". A worthy goal that I fully support.  
> Until then, we have the problems that Hawley and others have enumerated.
>  
> Jenna, As far I know, Apple's dmg is not proprietary but it is not well  
> documented unless you did deep into the Developers documentation. Kind  
> of like MSFT's PEF. You can find the info if you look hard enough.
>  
> --Cecil
>  
> On 09/09/2012 03:06 AM, Peter Fitzgibbons wrote:
> > HI Cecil,
> >  
> > The reasons for abandoned support of RedShoes 3.x build is that OS
> > versions have clobbered the cross-platform build process.
> >  
> > What this means; Windows compilations have been shaky at best since
> > WindowsVista/Windows7. The expectation is that a single build and
> > packaged binary can be created that will run WinXP AND Win7 (now also Win8).
> > On Mac, OSX Lion has solidified the 32bit -> 64bit upgrade, and with
> > that taken away the ability for a single build and packaged binary to
> > work in both environments. In fact we have not even been able to do
> > cross-version builds at all. A Lion build wont' work on SnowLeopard at all.
> > The Linux situation is a bit better but overall the same situation,
> > 32bit -> 64bit upgrade breaks the cross-platform build process.
> >  
> > So, recall that RedShoes was heavily dependent upon custom-C and
> > external libraries, which are built cross-platform into a single
> > monolithic, cross-platform compatible tarball (zip, installer,
> > whatever). _why created this in a masterful way, in the day when 32-bit
> > was new-ish, Win95 was in full-steam, WinXP was on the horizon, most
> > Linux distros were just becoming pure 32bit, and OS 'X' was now solid
> > (Tiger -> Leopard days).
> >  
> > Now we are on another bit-upgrade horizon, 32bit -> 64bit, and the build
> > systems across the board are radically changing, for the better we hope.
> > The side-effect of this is that cross-platform compilation is not
> > feasible.
> >  
> > The birth of Shoes4 / Jruby / SWT was a move to alleviate our packaging
> > woes by leveraging the vast Java community and their continuing work on
> > cross-platform compatability. While acknowledging that dependency on an
> > external binary is a bit of a "risk" in some ways, the benefits and
> > clear stable-base of the JVM community gives us the space to build (or
> > use) a packager that works cross-platform and builds cross-platform.
> >  
> > Although we have been focused in the past 2-3 months on SWT, that work
> > has been a proof that SWT has the tools and capability we need to
> > produce in Shoes. This email thread is quite coincidental as this week
> > I had started my own thought process around when would be the best time
> > to re-energize the packaging question.
> >  
> > Thank you all for your work and inspiration. With some Java packaging
> > mojo, we might even be able to release a Shoes4 Preview that the world
> > could use and begin to play with.
> >  
> > Kindest Regards,
> >  
> > Peter Fitzgibbons
> > (847) 859-9550
> > Email: peter.fitzgibbons@gmail.com <mailto:peter.fitzgibbons@gmail.com>
> > IM GTalk: peter.fitzgibbons
> > IM AOL: peter.fitzgibbons@gmail.com <mailto:peter.fitzgibbons@gmail.com>
> >  
> >  
> > On Sat, Sep 8, 2012 at 9:13 PM, Cecil Coupe <ccoupe@cableone.net 
(mailto:ccoupe@cableone.net)
> > <mailto:ccoupe@cableone.net>> wrote:
> >  
> > On 09/08/2012 05:43 PM, Jenna Fox wrote:
> > > I agree fully. I've long held the view that shoes is effectively
> > dead if
> > > packaging doesn't work.
> > >
> > > —
> > > Jenna
> > >
> >  
> > In the case of Red Shoes 3.x, I completely agree. Packaging has been
> > half broken or half working for several years. I know Ashbb has a
> > windows shoes version that works well (on Windows) and I know Eric did
> > some work on the OSX parts. I don't know that either of them made it to
> > the website for initial user download and that they request the newer
> > updated Shoes when packaging a script for either one.
> >  
> > I stopped beating the drum on the packaging issues of Red Shoes because
> > maintenance of Red Shoes is a very low priority for the C level
> > developers. Red Shoes is not being maintained or updated for lack of
> > developer interest in doing it. All we need is a Windows MingW C
> > developer and an OSX/Obj-c developer that are willing to tackle the
> > challenge and finish the task.
> >  
> > --Cecil  

Re: [shoes] Proposal

From:
Cecil Coupe
Date:
2012-09-10 @ 04:34
Do these OSX zips you speak of run an system level installer program or 
do they just put the files on the disk and you have to navigate to that 
folder and double click the installer with an icon?  Do they ask for a 
password? Do they set the menus properly?

On 09/09/2012 10:23 PM, Jenna Fox wrote:
> Wikipedia's article on DMG repeatedly states it is a proprietary format
> which has only been partially reverse
> engineered http://en.wikipedia.org/wiki/Apple_Disk_Image Regardless, it
> is no better than a zip and in many ways worse, so it shouldn't be a
> part of shoes packaging, seeing as zips are cross platform and well
> documented.
>
> —
> Jenna
>

Re: [shoes] Proposal

From:
Jenna Fox
Date:
2012-09-10 @ 05:50
It sounds like you're a bit unfamiliar with OS X. Generally speaking OS X 
doesn't use installers. Installers are used for things like kernel 
extensions and system level frameworks. Regular apps are just a file you 
download. The system picks up on new, updated, and deleted .apps, indexing
their Info.plist settings and icons, making them available through the 
Spotlight search engine, adding them to databases of which apps can handle
various file extensions and URIs. This all happens in about half a second 
after the .app lands in a folder on your Mac - any folder. You can move it
around, drag a shortcut to it in to the Dock. No worries.

System apps on OS X are placed in the /Applications folder, but there 
really is no magic to that - that's just where they happen to be. With the
exception of Xcode, you can move those apps anywhere you like. Most older 
users like to put their own apps in there and certainly some third party 
developers encourage people to do so. The user can then drag the app to 
their dock to add it to the icons along the bottom of their screen, or 
drag it to the launchpad icon to add it to the Launchpad app launcher. 
They can drag it to /Applications in finder if they're a traditionalist 
(launchpad will pick it up there too), or they can launch it by clicking 
the Downloads stack (bottom right of screen) and selecting it there, or in
the downloads history list in their web browser. They can also open 
spotlight and type in 'Shoes' (or whatever) and press enter to run it 
regardless where it is.

Mac OS X automatically detects newly appearing apps on the filesystem and 
registers them to handle their file extensions and URIs (things like 
mailto: ), so there is no special action required to integrate the app. 
When the user wants to uninstall it, they do so by dragging it to their 
trash, and Mac OS X automatically deregisters it from handling those files
and URI prefixes.

DMGs were popularised back when internet app distribution first appeared, 
and were designed to resemble a floppy disk or CD ROM, which is why 
they're implemented as virtual disks. The idea was a developer could just 
image their CD to a compressed file and upload that to a site - that the 
CD ROM would always be the canonical format. They were also a way to work 
around the general internet not supporting resource forks, but use of 
these has largely gone out of fashion and modern apps don't make use of 
them. Since the demise of CD-based distribution DMGs have largely been 
considered too confusing. Many users forget to eject them, and many also 
leave apps inside these read-only virtual disks only to have trouble 
finding them after a reboot when the mounted disk has disappeared from 
their finder sidebar. The operating system is smart/dumb enough to let 
users drag a shortcut to an app in a DMG to their dock, which causes the 
OS to automatically mount the DMG if necessary to access the app, so many 
users leave apps in their DMGs indefinitely. Some apps don't work properly
when stored on read-only filesystems (I think Firefox is an example). DMG 
is thus largely an artefact of the 90s, still used by some for legacy 
reasons, or just out of habit. Slow, confusing, proprietary, legacy. When 
Red Shoes came out, the backlash against using DMGs was only beginning to 
develop, so it was reasonable to use them. The use of zips instead has 
been since popularised by indie mac studios as a superior alternative, 
many having won Apple Design awards for the ease of use and overall great 
design of their software, with zips now being used by Apple also in many 
instances. In fact the iOS App Store uses zips as the container for 
transporting apps to devices, and the Mac App Store likely works in 
exactly the same way. Where zips aren't used, often the 'self extracting 
dmg' is used - which is functionally identical to a zip, but proprietary.

Hope this info helps set the record straight on zips and break some 
harmful outdated packaging habits.

References:
Some apps off the top of my head which set the precedent for zip over dmg:
 - The multi-award winning Panic Software distribute Coda and Unison, 
their main Mac Apps via zip files.
 - The Chocolat text/code editor
 - The renowned TextMate code editor, probably the most used text editor 
among ruby programmers on OS X
 - Acqualia Software's Soulver - a really wonderful spreadsheet meets IRB 
way to do maths
 - The wonderful as always Löve 2D
 - Renowned Mac Developers "Rogue Amoeba" in their many apps old and new alike

I'm sure there are many more I'm forgetting, but those are just some of my
favourite apps and developers who happened to come to mind. :)

—
Jenna


On Monday, 10 September 2012 at 2:34 PM, Cecil Coupe wrote:

> Do these OSX zips you speak of run an system level installer program or  
> do they just put the files on the disk and you have to navigate to that  
> folder and double click the installer with an icon? Do they ask for a  
> password? Do they set the menus properly?
>  
> On 09/09/2012 10:23 PM, Jenna Fox wrote:
> > Wikipedia's article on DMG repeatedly states it is a proprietary format
> > which has only been partially reverse
> > engineered http://en.wikipedia.org/wiki/Apple_Disk_Image Regardless, it
> > is no better than a zip and in many ways worse, so it shouldn't be a
> > part of shoes packaging, seeing as zips are cross platform and well
> > documented.
> >  
> > —
> > Jenna
> >  
>  
>  
>  

Re: [shoes] Proposal

From:
Cecil Coupe
Date:
2012-09-10 @ 06:34
Good info to know and ponder. Thanks Jenna. I haven't used OSX since 
10.2.8. It sounds like OSX has invented their own Windows Registry 
nightmare. Ubuntu is (slowly) going that way too. Does the zip file have 
the OSX unique  folder hierarchy and nested plists and resource files 
(aka icon and stuff). If I double click a .zip how does OSX know its an 
app, a trusted (/Applications) app or a zip archive of some excel 
spreadsheets I sent to my brother in law?  If this is well documented 
then the rake files and stubs can be fixed. Assuming someone is willing 
to fix it.

To create the  OSX "special" Zips, Red Shoes would have to call a new 
Binject::OSXZip and pretty much stage/cache/load the files, plists, 
icons and other resources. Which is what binject::exe and binject::dmg 
do so adding binject::OSXZip isn't evil. It just lacks people to do the 
work.


On 09/09/2012 11:50 PM, Jenna Fox wrote:
> It sounds like you're a bit unfamiliar with OS X. Generally speaking OS
> X doesn't use installers. Installers are used for things like kernel
> extensions and system level frameworks. Regular apps are just a file you
> download. The system picks up on new, updated, and deleted .apps,
> indexing their Info.plist settings and icons, making them available
> through the Spotlight search engine, adding them to databases of which
> apps can handle various file extensions and URIs. This all happens in
> about half a second after the .app lands in a folder on your Mac - any
> folder. You can move it around, drag a shortcut to it in to the Dock. No
> worries.
>
> System apps on OS X are placed in the /Applications folder, but there
> really is no magic to that - that's just where they happen to be. With
> the exception of Xcode, you can move those apps anywhere you like. Most
> older users like to put their own apps in there and certainly some third
> party developers encourage people to do so. The user can then drag the
> app to their dock to add it to the icons along the bottom of their
> screen, or drag it to the launchpad icon to add it to the Launchpad app
> launcher. They can drag it to /Applications in finder if they're a
> traditionalist (launchpad will pick it up there too), or they can launch
> it by clicking the Downloads stack (bottom right of screen) and
> selecting it there, or in the downloads history list in their web
> browser. They can also open spotlight and type in 'Shoes' (or whatever)
> and press enter to run it regardless where it is.
>
> Mac OS X automatically detects newly appearing apps on the filesystem
> and registers them to handle their file extensions and URIs (things like
> mailto: ), so there is no special action required to integrate the app.
> When the user wants to uninstall it, they do so by dragging it to their
> trash, and Mac OS X automatically deregisters it from handling those
> files and URI prefixes.
>
> DMGs were popularised back when internet app distribution first
> appeared, and were designed to resemble a floppy disk or CD ROM, which
> is why they're implemented as virtual disks. The idea was a developer
> could just image their CD to a compressed file and upload that to a site
> - that the CD ROM would always be the canonical format. They were also a
> way to work around the general internet not supporting resource forks,
> but use of these has largely gone out of fashion and modern apps don't
> make use of them. Since the demise of CD-based distribution DMGs have
> largely been considered too confusing. Many users forget to eject them,
> and many also leave apps inside these read-only virtual disks only to
> have trouble finding them after a reboot when the mounted disk has
> disappeared from their finder sidebar. The operating system is
> smart/dumb enough to let users drag a shortcut to an app in a DMG to
> their dock, which causes the OS to automatically mount the DMG if
> necessary to access the app, so many users leave apps in their DMGs
> indefinitely. Some apps don't work properly when stored on read-only
> filesystems (I think Firefox is an example). DMG is thus largely an
> artefact of the 90s, still used by some for legacy reasons, or just out
> of habit. Slow, confusing, proprietary, legacy. When Red Shoes came out,
> the backlash against using DMGs was only beginning to develop, so it was
> reasonable to use them. The use of zips instead has been since
> popularised by indie mac studios as a superior alternative, many having
> won Apple Design awards for the ease of use and overall great design of
> their software, with zips now being used by Apple also in many
> instances. In fact the iOS App Store uses zips as the container for
> transporting apps to devices, and the Mac App Store likely works in
> exactly the same way. Where zips aren't used, often the 'self extracting
> dmg' is used - which is functionally identical to a zip, but proprietary.
>
> Hope this info helps set the record straight on zips and break some
> harmful outdated packaging habits.
>
> References:
> Some apps off the top of my head which set the precedent for zip over dmg:
>   - The multi-award winning Panic Software distribute Coda and Unison,
> their main Mac Apps via zip files.
>   - The Chocolat text/code editor
>   - The renowned TextMate code editor, probably the most used text
> editor among ruby programmers on OS X
>   - Acqualia Software's Soulver - a really wonderful spreadsheet meets
> IRB way to do maths
>   - The wonderful as always Löve 2D
>   - Renowned Mac Developers "Rogue Amoeba" in their many apps old and
> new alike
>
> I'm sure there are many more I'm forgetting, but those are just some of
> my favourite apps and developers who happened to come to mind. :)
>
> —
> Jenna
>
> On Monday, 10 September 2012 at 2:34 PM, Cecil Coupe wrote:
>
>> Do these OSX zips you speak of run an system level installer program or
>> do they just put the files on the disk and you have to navigate to that
>> folder and double click the installer with an icon? Do they ask for a
>> password? Do they set the menus properly?
>>
>> On 09/09/2012 10:23 PM, Jenna Fox wrote:
>>> Wikipedia's article on DMG repeatedly states it is a proprietary format
>>> which has only been partially reverse
>>> engineered http://en.wikipedia.org/wiki/Apple_Disk_Image Regardless, it
>>> is no better than a zip and in many ways worse, so it shouldn't be a
>>> part of shoes packaging, seeing as zips are cross platform and well
>>> documented.
>>>
>>> —
>>> Jenna
>

Re: [shoes] Proposal

From:
Jenna Fox
Date:
2012-09-10 @ 06:46
They aren't special. Mac OS unzips any zips you download automatically. If
the zip has a .app folder in it, then there'll be an unzipped .app folder 
in the downloads folder. Simple as that. No magic. The only trick to 
packaging for Mac OS if following the Löve playbook, is you ideally want a
library you can use to add a file to an existing zip. If you can do that, 
you can just poke a shy or whatever straight in to the same .app zip the 
shoes website hypothetically offers, and you're home free. On 
windows/linux you append your zip-style-shy to the end of the binary 
available on shoes website.  

You'd also want to rename the Shoes.app folder in the root of the zip to 
whatever string the user wanted, but you can structure the app so you 
don't need to fuss about with plists or any of that business. If you want 
to inject an icon things get a tad more complex. You can probably 
structure the Info.plist to reference a png icon inside the 
AppName.app/Contents/Resources folder and just not use Apple's icns format
- if that works, icon injection should be fairly easy, but it doesn't 
really solve icon injection in windows which seems like it'd need binject 
hackery, and really I think icons are not an important problem to solve, 
and should be left out side the scope of having a good robust packaging 
system. If someone gets icons working, that's bonus points really. Append 
A Zip comes at the cost of getting an icon injection mechanism for free on
windows, but it seems so much simpler in the long run. There are probably 
other apps people can use to change the icons on exe's anyway if they find
themselves so motivated.  

—
Jenna


On Monday, 10 September 2012 at 4:34 PM, Cecil Coupe wrote:

> Good info to know and ponder. Thanks Jenna. I haven't used OSX since  
> 10.2.8. It sounds like OSX has invented their own Windows Registry  
> nightmare. Ubuntu is (slowly) going that way too. Does the zip file have  
> the OSX unique folder hierarchy and nested plists and resource files  
> (aka icon and stuff). If I double click a .zip how does OSX know its an  
> app, a trusted (/Applications) app or a zip archive of some excel  
> spreadsheets I sent to my brother in law? If this is well documented  
> then the rake files and stubs can be fixed. Assuming someone is willing  
> to fix it.
>  
> To create the OSX "special" Zips, Red Shoes would have to call a new  
> Binject::OSXZip and pretty much stage/cache/load the files, plists,  
> icons and other resources. Which is what binject::exe and binject::dmg  
> do so adding binject::OSXZip isn't evil. It just lacks people to do the  
> work.
>  
>  
> On 09/09/2012 11:50 PM, Jenna Fox wrote:
> > It sounds like you're a bit unfamiliar with OS X. Generally speaking OS
> > X doesn't use installers. Installers are used for things like kernel
> > extensions and system level frameworks. Regular apps are just a file you
> > download. The system picks up on new, updated, and deleted .apps,
> > indexing their Info.plist settings and icons, making them available
> > through the Spotlight search engine, adding them to databases of which
> > apps can handle various file extensions and URIs. This all happens in
> > about half a second after the .app lands in a folder on your Mac - any
> > folder. You can move it around, drag a shortcut to it in to the Dock. No
> > worries.
> >  
> > System apps on OS X are placed in the /Applications folder, but there
> > really is no magic to that - that's just where they happen to be. With
> > the exception of Xcode, you can move those apps anywhere you like. Most
> > older users like to put their own apps in there and certainly some third
> > party developers encourage people to do so. The user can then drag the
> > app to their dock to add it to the icons along the bottom of their
> > screen, or drag it to the launchpad icon to add it to the Launchpad app
> > launcher. They can drag it to /Applications in finder if they're a
> > traditionalist (launchpad will pick it up there too), or they can launch
> > it by clicking the Downloads stack (bottom right of screen) and
> > selecting it there, or in the downloads history list in their web
> > browser. They can also open spotlight and type in 'Shoes' (or whatever)
> > and press enter to run it regardless where it is.
> >  
> > Mac OS X automatically detects newly appearing apps on the filesystem
> > and registers them to handle their file extensions and URIs (things like
> > mailto: ), so there is no special action required to integrate the app.
> > When the user wants to uninstall it, they do so by dragging it to their
> > trash, and Mac OS X automatically deregisters it from handling those
> > files and URI prefixes.
> >  
> > DMGs were popularised back when internet app distribution first
> > appeared, and were designed to resemble a floppy disk or CD ROM, which
> > is why they're implemented as virtual disks. The idea was a developer
> > could just image their CD to a compressed file and upload that to a site
> > - that the CD ROM would always be the canonical format. They were also a
> > way to work around the general internet not supporting resource forks,
> > but use of these has largely gone out of fashion and modern apps don't
> > make use of them. Since the demise of CD-based distribution DMGs have
> > largely been considered too confusing. Many users forget to eject them,
> > and many also leave apps inside these read-only virtual disks only to
> > have trouble finding them after a reboot when the mounted disk has
> > disappeared from their finder sidebar. The operating system is
> > smart/dumb enough to let users drag a shortcut to an app in a DMG to
> > their dock, which causes the OS to automatically mount the DMG if
> > necessary to access the app, so many users leave apps in their DMGs
> > indefinitely. Some apps don't work properly when stored on read-only
> > filesystems (I think Firefox is an example). DMG is thus largely an
> > artefact of the 90s, still used by some for legacy reasons, or just out
> > of habit. Slow, confusing, proprietary, legacy. When Red Shoes came out,
> > the backlash against using DMGs was only beginning to develop, so it was
> > reasonable to use them. The use of zips instead has been since
> > popularised by indie mac studios as a superior alternative, many having
> > won Apple Design awards for the ease of use and overall great design of
> > their software, with zips now being used by Apple also in many
> > instances. In fact the iOS App Store uses zips as the container for
> > transporting apps to devices, and the Mac App Store likely works in
> > exactly the same way. Where zips aren't used, often the 'self extracting
> > dmg' is used - which is functionally identical to a zip, but proprietary.
> >  
> > Hope this info helps set the record straight on zips and break some
> > harmful outdated packaging habits.
> >  
> > References:
> > Some apps off the top of my head which set the precedent for zip over dmg:
> > - The multi-award winning Panic Software distribute Coda and Unison,
> > their main Mac Apps via zip files.
> > - The Chocolat text/code editor
> > - The renowned TextMate code editor, probably the most used text
> > editor among ruby programmers on OS X
> > - Acqualia Software's Soulver - a really wonderful spreadsheet meets
> > IRB way to do maths
> > - The wonderful as always Löve 2D
> > - Renowned Mac Developers "Rogue Amoeba" in their many apps old and
> > new alike
> >  
> > I'm sure there are many more I'm forgetting, but those are just some of
> > my favourite apps and developers who happened to come to mind. :)
> >  
> > —
> > Jenna
> >  
> > On Monday, 10 September 2012 at 2:34 PM, Cecil Coupe wrote:
> >  
> > > Do these OSX zips you speak of run an system level installer program or
> > > do they just put the files on the disk and you have to navigate to that
> > > folder and double click the installer with an icon? Do they ask for a
> > > password? Do they set the menus properly?
> > >  
> > > On 09/09/2012 10:23 PM, Jenna Fox wrote:
> > > > Wikipedia's article on DMG repeatedly states it is a proprietary format
> > > > which has only been partially reverse
> > > > engineered http://en.wikipedia.org/wiki/Apple_Disk_Image Regardless, it
> > > > is no better than a zip and in many ways worse, so it shouldn't be a
> > > > part of shoes packaging, seeing as zips are cross platform and well
> > > > documented.
> > > >  
> > > > —
> > > > Jenna
> > > >  
> > >  
> > >  
> >  
> >  
>  
>  
>  

Re: [shoes] Proposal

From:
Eric Watson
Date:
2012-09-10 @ 11:25
Cecil,

Maybe a good way to think about the .dmg vs .zip issues is that it's a 
distribution format, not a packaging format. In either case, we would have
to create the same .app folder. The user then double-clicks the .dmg and 
gets a disk image containging the .app, or double-clicks the .zip and 
extracts the .app. Creating a .zip is definitely simpler.

Eric

On Sep 10, 2012, at 1:46 AM, Jenna Fox wrote:

> They aren't special. Mac OS unzips any zips you download automatically. 
If the zip has a .app folder in it, then there'll be an unzipped .app 
folder in the downloads folder. Simple as that. No magic. The only trick 
to packaging for Mac OS if following the Löve playbook, is you ideally 
want a library you can use to add a file to an existing zip. If you can do
that, you can just poke a shy or whatever straight in to the same .app zip
the shoes website hypothetically offers, and you're home free. On 
windows/linux you append your zip-style-shy to the end of the binary 
available on shoes website.
> 
> You'd also want to rename the Shoes.app folder in the root of the zip to
whatever string the user wanted, but you can structure the app so you 
don't need to fuss about with plists or any of that business. If you want 
to inject an icon things get a tad more complex. You can probably 
structure the Info.plist to reference a png icon inside the 
AppName.app/Contents/Resources folder and just not use Apple's icns format
- if that works, icon injection should be fairly easy, but it doesn't 
really solve icon injection in windows which seems like it'd need binject 
hackery, and really I think icons are not an important problem to solve, 
and should be left out side the scope of having a good robust packaging 
system. If someone gets icons working, that's bonus points really. Append 
A Zip comes at the cost of getting an icon injection mechanism for free on
windows, but it seems so much simpler in the long run. There are probably 
other apps people can use to change the icons on exe's anyway if they find
themselves so motivated.
> 
> —
> Jenna
> 
> On Monday, 10 September 2012 at 4:34 PM, Cecil Coupe wrote:
> 
>> Good info to know and ponder. Thanks Jenna. I haven't used OSX since
>> 10.2.8. It sounds like OSX has invented their own Windows Registry
>> nightmare. Ubuntu is (slowly) going that way too. Does the zip file have
>> the OSX unique folder hierarchy and nested plists and resource files
>> (aka icon and stuff). If I double click a .zip how does OSX know its an
>> app, a trusted (/Applications) app or a zip archive of some excel
>> spreadsheets I sent to my brother in law? If this is well documented
>> then the rake files and stubs can be fixed. Assuming someone is willing
>> to fix it.
>> 
>> To create the OSX "special" Zips, Red Shoes would have to call a new
>> Binject::OSXZip and pretty much stage/cache/load the files, plists,
>> icons and other resources. Which is what binject::exe and binject::dmg
>> do so adding binject::OSXZip isn't evil. It just lacks people to do the
>> work.
>> 
>> 
>> On 09/09/2012 11:50 PM, Jenna Fox wrote:
>>> It sounds like you're a bit unfamiliar with OS X. Generally speaking OS
>>> X doesn't use installers. Installers are used for things like kernel
>>> extensions and system level frameworks. Regular apps are just a file you
>>> download. The system picks up on new, updated, and deleted .apps,
>>> indexing their Info.plist settings and icons, making them available
>>> through the Spotlight search engine, adding them to databases of which
>>> apps can handle various file extensions and URIs. This all happens in
>>> about half a second after the .app lands in a folder on your Mac - any
>>> folder. You can move it around, drag a shortcut to it in to the Dock. No
>>> worries.
>>> 
>>> System apps on OS X are placed in the /Applications folder, but there
>>> really is no magic to that - that's just where they happen to be. With
>>> the exception of Xcode, you can move those apps anywhere you like. Most
>>> older users like to put their own apps in there and certainly some third
>>> party developers encourage people to do so. The user can then drag the
>>> app to their dock to add it to the icons along the bottom of their
>>> screen, or drag it to the launchpad icon to add it to the Launchpad app
>>> launcher. They can drag it to /Applications in finder if they're a
>>> traditionalist (launchpad will pick it up there too), or they can launch
>>> it by clicking the Downloads stack (bottom right of screen) and
>>> selecting it there, or in the downloads history list in their web
>>> browser. They can also open spotlight and type in 'Shoes' (or whatever)
>>> and press enter to run it regardless where it is.
>>> 
>>> Mac OS X automatically detects newly appearing apps on the filesystem
>>> and registers them to handle their file extensions and URIs (things like
>>> mailto: ), so there is no special action required to integrate the app.
>>> When the user wants to uninstall it, they do so by dragging it to their
>>> trash, and Mac OS X automatically deregisters it from handling those
>>> files and URI prefixes.
>>> 
>>> DMGs were popularised back when internet app distribution first
>>> appeared, and were designed to resemble a floppy disk or CD ROM, which
>>> is why they're implemented as virtual disks. The idea was a developer
>>> could just image their CD to a compressed file and upload that to a site
>>> - that the CD ROM would always be the canonical format. They were also a
>>> way to work around the general internet not supporting resource forks,
>>> but use of these has largely gone out of fashion and modern apps don't
>>> make use of them. Since the demise of CD-based distribution DMGs have
>>> largely been considered too confusing. Many users forget to eject them,
>>> and many also leave apps inside these read-only virtual disks only to
>>> have trouble finding them after a reboot when the mounted disk has
>>> disappeared from their finder sidebar. The operating system is
>>> smart/dumb enough to let users drag a shortcut to an app in a DMG to
>>> their dock, which causes the OS to automatically mount the DMG if
>>> necessary to access the app, so many users leave apps in their DMGs
>>> indefinitely. Some apps don't work properly when stored on read-only
>>> filesystems (I think Firefox is an example). DMG is thus largely an
>>> artefact of the 90s, still used by some for legacy reasons, or just out
>>> of habit. Slow, confusing, proprietary, legacy. When Red Shoes came out,
>>> the backlash against using DMGs was only beginning to develop, so it was
>>> reasonable to use them. The use of zips instead has been since
>>> popularised by indie mac studios as a superior alternative, many having
>>> won Apple Design awards for the ease of use and overall great design of
>>> their software, with zips now being used by Apple also in many
>>> instances. In fact the iOS App Store uses zips as the container for
>>> transporting apps to devices, and the Mac App Store likely works in
>>> exactly the same way. Where zips aren't used, often the 'self extracting
>>> dmg' is used - which is functionally identical to a zip, but proprietary.
>>> 
>>> Hope this info helps set the record straight on zips and break some
>>> harmful outdated packaging habits.
>>> 
>>> References:
>>> Some apps off the top of my head which set the precedent for zip over dmg:
>>> - The multi-award winning Panic Software distribute Coda and Unison,
>>> their main Mac Apps via zip files.
>>> - The Chocolat text/code editor
>>> - The renowned TextMate code editor, probably the most used text
>>> editor among ruby programmers on OS X
>>> - Acqualia Software's Soulver - a really wonderful spreadsheet meets
>>> IRB way to do maths
>>> - The wonderful as always Löve 2D
>>> - Renowned Mac Developers "Rogue Amoeba" in their many apps old and
>>> new alike
>>> 
>>> I'm sure there are many more I'm forgetting, but those are just some of
>>> my favourite apps and developers who happened to come to mind. :)
>>> 
>>> —
>>> Jenna
>>> 
>>> On Monday, 10 September 2012 at 2:34 PM, Cecil Coupe wrote:
>>> 
>>>> Do these OSX zips you speak of run an system level installer program or
>>>> do they just put the files on the disk and you have to navigate to that
>>>> folder and double click the installer with an icon? Do they ask for a
>>>> password? Do they set the menus properly?
>>>> 
>>>> On 09/09/2012 10:23 PM, Jenna Fox wrote:
>>>>> Wikipedia's article on DMG repeatedly states it is a proprietary format
>>>>> which has only been partially reverse
>>>>> engineered http://en.wikipedia.org/wiki/Apple_Disk_Image Regardless, it
>>>>> is no better than a zip and in many ways worse, so it shouldn't be a
>>>>> part of shoes packaging, seeing as zips are cross platform and well
>>>>> documented.
>>>>> 
>>>>> —
>>>>> Jenna
> 

Re: [shoes] Proposal

From:
Sebastjan Hribar
Date:
2012-09-10 @ 07:02
Here's my take on this as a newcomer to Shoes (well, and Ruby for that
matter, I've started only a few months back). I agree with Hawley that a
packager would help put Shoes to their rightful place in the world.

I share your experience. I've written some smaller apps/games for
learning purposes and some turned out to be quite useful. But when some
of my colleagues wanted to try them they lost interest because there
wasn't a simple freakin' .exe file to run (it seems horrific and
outdated to an average user to run something from console:). I have to
bounce from Ubuntu (home) to Win7 (work) and I had some difficulties
making it all work.

There was also some talk about targeting kids, that I don't quite get.
It seems to me everybody (should) benefits from Shoes.

I would like to help out, but as fas the technical stuff goes
unfortunately, I can't. If there is anything else, not strictly related
to programming, I would be glad to help.

Thank you all for your help so far.

regards
seba


Dne 08.09.2012 (sob) ob 16:53 -0400 je Hawley Waldman napisal(a):
> I would like to put forth the idea that we, as shoes enthusiasts, should
put much more emphasis on having a working packager then we are.
> 
> My controversial statement is: without a working packager shoes will 
remain in the domain of the esoteric.
> 
> A more nuanced and gentle way of putting it is: 
> 
> If, using shoes allowed you to easily create cool graphical apps which 
ran inside the shoes environment (which it does), and it also allowed you 
to easily create _free-standing_ applications, that ran  on osx, windows 
and linux without the necessity of downloading all kinds of support 
libraries (a feature it promises, but doesn't seem to deliver), we would 
see many, many, many, more people using shoes and, in all likelihood, that
would attract more attention from programmers to support the code/project.
> 
> If a young person, learning to program could put their program on a 
thumb drive and give it to all of their friends to play play with that 
would get them a lot more excited about programming.
> 
> If an amateur or hobbyist programmer could use ruby and shoes to create 
a program that their friends could run/use, it would create a lot of 
enthusiasm (and possibly more help with maintenance and support)
> 
> If professional programmers could use shoes to easily create good 
looking, commercially viable, desktop-ish applications they would get 
excited and jump on board, being much more likely to contribute to 
development and maintenance.
> 
> Our "product" is shoes, a tool that makes it easy for people to create 
programs with cool gui's, but people aren't going to buy in because _their
product is widget.app, or widget.exe and widget.<whatever> needs to be 
easy for _their customers to install and run.
> 
> We write the code for a program once, hoping in general that we are 
creating something that will be used again, and again. If we lose track of
that goal we are just spending our time in a kind of masturbatory world, 
and masturbation just ain't as fun in the long term as, well, you know 
what.
> 
> I don't think that shoes needs to become a bloated, swiss army knife of 
a toolkit, it can keep the slick, simple (and powerful) features that it 
has (although I'm thrilled with the talked about refinement of how listbox
will work in shoes4) and it will still be good enough to do many / most 
things. 
> 
> A good enough toolkit, that lets you create programs that you can easily
share and which might benefit others. That's what I would like to see 
shoes become.  An epitome of "appropriate laziness", what an former 
professor of mine described as an essential characteristic of a computer 
scientist.
> 
> 
> So, what do you say? Can we get some enthusiasm  and momentum going for 
fixing  our packager/application wrapper service, or creating a new one?  
Once that is done each of the groovy rewritten features for shoes4, or 
green_shoes, or <insert color here>_shoes, would have an immediate impact 
on the world.  We need one packager, but many, many features, how about 
getting the packager done so that we can use as many features as we choose
to write in the infinite future?
> 
> sincerely, respectfully and gently,
> Hawley

Re: [shoes] Proposal

From:
Peter Fitzgibbons
Date:
2012-09-10 @ 09:38
Jenna, et al,

Could you point me in the proper direction on the zipfile idea (which I
like btw, and now I have my feasibility hat on).  We're in our Ruby space
now (<3 ya Lua) so is the zipfile idea pointing at embedded ruby or
embedded JVM ?  I'm thinking embedded because those would be the
ultra-small,ultra-fast x-copy type profiles.

Your thoughts appreciated.
My Kindest Regards,
Peter Fitzgibbons
(847) 859-9550
Email: peter.fitzgibbons@gmail.com
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@gmail.com


On Mon, Sep 10, 2012 at 2:02 AM, Sebastjan Hribar <
sebastjan.hribar@gmail.com> wrote:

> Here's my take on this as a newcomer to Shoes (well, and Ruby for that
> matter, I've started only a few months back). I agree with Hawley that a
> packager would help put Shoes to their rightful place in the world.
>
> I share your experience. I've written some smaller apps/games for
> learning purposes and some turned out to be quite useful. But when some
> of my colleagues wanted to try them they lost interest because there
> wasn't a simple freakin' .exe file to run (it seems horrific and
> outdated to an average user to run something from console:). I have to
> bounce from Ubuntu (home) to Win7 (work) and I had some difficulties
> making it all work.
>
> There was also some talk about targeting kids, that I don't quite get.
> It seems to me everybody (should) benefits from Shoes.
>
> I would like to help out, but as fas the technical stuff goes
> unfortunately, I can't. If there is anything else, not strictly related
> to programming, I would be glad to help.
>
> Thank you all for your help so far.
>
> regards
> seba
>
>
> Dne 08.09.2012 (sob) ob 16:53 -0400 je Hawley Waldman napisal(a):
> > I would like to put forth the idea that we, as shoes enthusiasts, should
> put much more emphasis on having a working packager then we are.
> >
> > My controversial statement is: without a working packager shoes will
> remain in the domain of the esoteric.
> >
> > A more nuanced and gentle way of putting it is:
> >
> > If, using shoes allowed you to easily create cool graphical apps which
> ran inside the shoes environment (which it does), and it also allowed you
> to easily create _free-standing_ applications, that ran  on osx, windows
> and linux without the necessity of downloading all kinds of support
> libraries (a feature it promises, but doesn't seem to deliver), we would
> see many, many, many, more people using shoes and, in all likelihood, that
> would attract more attention from programmers to support the code/project.
> >
> > If a young person, learning to program could put their program on a
> thumb drive and give it to all of their friends to play play with that
> would get them a lot more excited about programming.
> >
> > If an amateur or hobbyist programmer could use ruby and shoes to create
> a program that their friends could run/use, it would create a lot of
> enthusiasm (and possibly more help with maintenance and support)
> >
> > If professional programmers could use shoes to easily create good
> looking, commercially viable, desktop-ish applications they would get
> excited and jump on board, being much more likely to contribute to
> development and maintenance.
> >
> > Our "product" is shoes, a tool that makes it easy for people to create
> programs with cool gui's, but people aren't going to buy in because _their
> product is widget.app, or widget.exe and widget.<whatever> needs to be easy
> for _their customers to install and run.
> >
> > We write the code for a program once, hoping in general that we are
> creating something that will be used again, and again. If we lose track of
> that goal we are just spending our time in a kind of masturbatory world,
> and masturbation just ain't as fun in the long term as, well, you know what.
> >
> > I don't think that shoes needs to become a bloated, swiss army knife of
> a toolkit, it can keep the slick, simple (and powerful) features that it
> has (although I'm thrilled with the talked about refinement of how listbox
> will work in shoes4) and it will still be good enough to do many / most
> things.
> >
> > A good enough toolkit, that lets you create programs that you can easily
> share and which might benefit others. That's what I would like to see shoes
> become.  An epitome of "appropriate laziness", what an former professor of
> mine described as an essential characteristic of a computer scientist.
> >
> >
> > So, what do you say? Can we get some enthusiasm  and momentum going for
> fixing  our packager/application wrapper service, or creating a new one?
>  Once that is done each of the groovy rewritten features for shoes4, or
> green_shoes, or <insert color here>_shoes, would have an immediate impact
> on the world.  We need one packager, but many, many features, how about
> getting the packager done so that we can use as many features as we choose
> to write in the infinite future?
> >
> > sincerely, respectfully and gently,
> > Hawley
>
>
>

Re: [shoes] Proposal

From:
James Gifford
Date:
2012-09-10 @ 13:55
+1 to the whole zip idea. We could potentially make that work for Linux as
well as Mac, since the .run format is pretty funky.

Peter, I think a embedded Ruby would be best, the idea of doing a JVM kind
of makes me uneasy, since we then

1. Make the download huge.
2. Have to try and keep it up-to-date.
3. Run into problems with 32 vs 64 bit, etc.

Cheers,
James Gifford
On Sep 10, 2012 9:48 AM, "Peter Fitzgibbons" <peter.fitzgibbons@gmail.com>
wrote:

> Jenna, et al,
>
> Could you point me in the proper direction on the zipfile idea (which I
> like btw, and now I have my feasibility hat on).  We're in our Ruby space
> now (<3 ya Lua) so is the zipfile idea pointing at embedded ruby or
> embedded JVM ?  I'm thinking embedded because those would be the
> ultra-small,ultra-fast x-copy type profiles.
>
> Your thoughts appreciated.
> My Kindest Regards,
> Peter Fitzgibbons
> (847) 859-9550
> Email: peter.fitzgibbons@gmail.com
> IM GTalk: peter.fitzgibbons
> IM AOL: peter.fitzgibbons@gmail.com
>
>
> On Mon, Sep 10, 2012 at 2:02 AM, Sebastjan Hribar <
> sebastjan.hribar@gmail.com> wrote:
>
>> Here's my take on this as a newcomer to Shoes (well, and Ruby for that
>> matter, I've started only a few months back). I agree with Hawley that a
>> packager would help put Shoes to their rightful place in the world.
>>
>> I share your experience. I've written some smaller apps/games for
>> learning purposes and some turned out to be quite useful. But when some
>> of my colleagues wanted to try them they lost interest because there
>> wasn't a simple freakin' .exe file to run (it seems horrific and
>> outdated to an average user to run something from console:). I have to
>> bounce from Ubuntu (home) to Win7 (work) and I had some difficulties
>> making it all work.
>>
>> There was also some talk about targeting kids, that I don't quite get.
>> It seems to me everybody (should) benefits from Shoes.
>>
>> I would like to help out, but as fas the technical stuff goes
>> unfortunately, I can't. If there is anything else, not strictly related
>> to programming, I would be glad to help.
>>
>> Thank you all for your help so far.
>>
>> regards
>> seba
>>
>>
>> Dne 08.09.2012 (sob) ob 16:53 -0400 je Hawley Waldman napisal(a):
>> > I would like to put forth the idea that we, as shoes enthusiasts,
>> should put much more emphasis on having a working packager then we are.
>> >
>> > My controversial statement is: without a working packager shoes will
>> remain in the domain of the esoteric.
>> >
>> > A more nuanced and gentle way of putting it is:
>> >
>> > If, using shoes allowed you to easily create cool graphical apps which
>> ran inside the shoes environment (which it does), and it also allowed you
>> to easily create _free-standing_ applications, that ran  on osx, windows
>> and linux without the necessity of downloading all kinds of support
>> libraries (a feature it promises, but doesn't seem to deliver), we would
>> see many, many, many, more people using shoes and, in all likelihood, that
>> would attract more attention from programmers to support the code/project.
>> >
>> > If a young person, learning to program could put their program on a
>> thumb drive and give it to all of their friends to play play with that
>> would get them a lot more excited about programming.
>> >
>> > If an amateur or hobbyist programmer could use ruby and shoes to create
>> a program that their friends could run/use, it would create a lot of
>> enthusiasm (and possibly more help with maintenance and support)
>> >
>> > If professional programmers could use shoes to easily create good
>> looking, commercially viable, desktop-ish applications they would get
>> excited and jump on board, being much more likely to contribute to
>> development and maintenance.
>> >
>> > Our "product" is shoes, a tool that makes it easy for people to create
>> programs with cool gui's, but people aren't going to buy in because _their
>> product is widget.app, or widget.exe and widget.<whatever> needs to be easy
>> for _their customers to install and run.
>> >
>> > We write the code for a program once, hoping in general that we are
>> creating something that will be used again, and again. If we lose track of
>> that goal we are just spending our time in a kind of masturbatory world,
>> and masturbation just ain't as fun in the long term as, well, you know what.
>> >
>> > I don't think that shoes needs to become a bloated, swiss army knife of
>> a toolkit, it can keep the slick, simple (and powerful) features that it
>> has (although I'm thrilled with the talked about refinement of how listbox
>> will work in shoes4) and it will still be good enough to do many / most
>> things.
>> >
>> > A good enough toolkit, that lets you create programs that you can
>> easily share and which might benefit others. That's what I would like to
>> see shoes become.  An epitome of "appropriate laziness", what an former
>> professor of mine described as an essential characteristic of a computer
>> scientist.
>> >
>> >
>> > So, what do you say? Can we get some enthusiasm  and momentum going for
>> fixing  our packager/application wrapper service, or creating a new one?
>>  Once that is done each of the groovy rewritten features for shoes4, or
>> green_shoes, or <insert color here>_shoes, would have an immediate impact
>> on the world.  We need one packager, but many, many features, how about
>> getting the packager done so that we can use as many features as we choose
>> to write in the infinite future?
>> >
>> > sincerely, respectfully and gently,
>> > Hawley
>>
>>
>>
>

Re: [shoes] Proposal

From:
Peter Fitzgibbons
Date:
2012-09-10 @ 10:04
HI Folks,

Read here : https://love2d.org/wiki/Game_Distribution

I think I like the : $ *zip -r ../${PWD##*/}.shoes **
I This seems to assume that a .shy has been placed at the root of the shoes
app directory.  The Windows instructions simply reference the .exe from
wherever it lies.
An installer is still a requirement for all Love2D exes on all platforms.

Lets start discussing again what the *feasible* target installation profile
should be for Shoes.
Can we build installers (zips) for each platform and then make it a basic
pre-req that to run any .shy you need Shoes ?   (Not what _why
accomplished).

Thoughts?

Peter Fitzgibbons
(847) 859-9550
Email: peter.fitzgibbons@gmail.com
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@gmail.com


On Mon, Sep 10, 2012 at 4:38 AM, Peter Fitzgibbons <
peter.fitzgibbons@gmail.com> wrote:

> Jenna, et al,
>
> Could you point me in the proper direction on the zipfile idea (which I
> like btw, and now I have my feasibility hat on).  We're in our Ruby space
> now (<3 ya Lua) so is the zipfile idea pointing at embedded ruby or
> embedded JVM ?  I'm thinking embedded because those would be the
> ultra-small,ultra-fast x-copy type profiles.
>
> Your thoughts appreciated.
> My Kindest Regards,
>
> Peter Fitzgibbons
> (847) 859-9550
> Email: peter.fitzgibbons@gmail.com
> IM GTalk: peter.fitzgibbons
> IM AOL: peter.fitzgibbons@gmail.com
>
>
> On Mon, Sep 10, 2012 at 2:02 AM, Sebastjan Hribar <
> sebastjan.hribar@gmail.com> wrote:
>
>> Here's my take on this as a newcomer to Shoes (well, and Ruby for that
>> matter, I've started only a few months back). I agree with Hawley that a
>> packager would help put Shoes to their rightful place in the world.
>>
>> I share your experience. I've written some smaller apps/games for
>> learning purposes and some turned out to be quite useful. But when some
>> of my colleagues wanted to try them they lost interest because there
>> wasn't a simple freakin' .exe file to run (it seems horrific and
>> outdated to an average user to run something from console:). I have to
>> bounce from Ubuntu (home) to Win7 (work) and I had some difficulties
>> making it all work.
>>
>> There was also some talk about targeting kids, that I don't quite get.
>> It seems to me everybody (should) benefits from Shoes.
>>
>> I would like to help out, but as fas the technical stuff goes
>> unfortunately, I can't. If there is anything else, not strictly related
>> to programming, I would be glad to help.
>>
>> Thank you all for your help so far.
>>
>> regards
>> seba
>>
>>
>> Dne 08.09.2012 (sob) ob 16:53 -0400 je Hawley Waldman napisal(a):
>> > I would like to put forth the idea that we, as shoes enthusiasts,
>> should put much more emphasis on having a working packager then we are.
>> >
>> > My controversial statement is: without a working packager shoes will
>> remain in the domain of the esoteric.
>> >
>> > A more nuanced and gentle way of putting it is:
>> >
>> > If, using shoes allowed you to easily create cool graphical apps which
>> ran inside the shoes environment (which it does), and it also allowed you
>> to easily create _free-standing_ applications, that ran  on osx, windows
>> and linux without the necessity of downloading all kinds of support
>> libraries (a feature it promises, but doesn't seem to deliver), we would
>> see many, many, many, more people using shoes and, in all likelihood, that
>> would attract more attention from programmers to support the code/project.
>> >
>> > If a young person, learning to program could put their program on a
>> thumb drive and give it to all of their friends to play play with that
>> would get them a lot more excited about programming.
>> >
>> > If an amateur or hobbyist programmer could use ruby and shoes to create
>> a program that their friends could run/use, it would create a lot of
>> enthusiasm (and possibly more help with maintenance and support)
>> >
>> > If professional programmers could use shoes to easily create good
>> looking, commercially viable, desktop-ish applications they would get
>> excited and jump on board, being much more likely to contribute to
>> development and maintenance.
>> >
>> > Our "product" is shoes, a tool that makes it easy for people to create
>> programs with cool gui's, but people aren't going to buy in because _their
>> product is widget.app, or widget.exe and widget.<whatever> needs to be easy
>> for _their customers to install and run.
>> >
>> > We write the code for a program once, hoping in general that we are
>> creating something that will be used again, and again. If we lose track of
>> that goal we are just spending our time in a kind of masturbatory world,
>> and masturbation just ain't as fun in the long term as, well, you know what.
>> >
>> > I don't think that shoes needs to become a bloated, swiss army knife of
>> a toolkit, it can keep the slick, simple (and powerful) features that it
>> has (although I'm thrilled with the talked about refinement of how listbox
>> will work in shoes4) and it will still be good enough to do many / most
>> things.
>> >
>> > A good enough toolkit, that lets you create programs that you can
>> easily share and which might benefit others. That's what I would like to
>> see shoes become.  An epitome of "appropriate laziness", what an former
>> professor of mine described as an essential characteristic of a computer
>> scientist.
>> >
>> >
>> > So, what do you say? Can we get some enthusiasm  and momentum going for
>> fixing  our packager/application wrapper service, or creating a new one?
>>  Once that is done each of the groovy rewritten features for shoes4, or
>> green_shoes, or <insert color here>_shoes, would have an immediate impact
>> on the world.  We need one packager, but many, many features, how about
>> getting the packager done so that we can use as many features as we choose
>> to write in the infinite future?
>> >
>> > sincerely, respectfully and gently,
>> > Hawley
>>
>>
>>
>

Re: [shoes] Proposal

From:
Eric Watson
Date:
2012-09-10 @ 15:17
On Sep 10, 2012, at 5:04 AM, Peter Fitzgibbons wrote:

> Lets start discussing again what the feasible target installation 
profile should be for Shoes.
> Can we build installers (zips) for each platform and then make it a 
basic pre-req that to run any .shy you need Shoes ?   (Not what _why 
accomplished).

Packaging is complicated (see 
https://github.com/shoes/shoes/wiki/A-Developer%27s-Tour-Through-The-Magic-Packager).
We are talking about a few overlapping ideas, and this causes confusion. 
Maybe we can name them.

1. Shoes app archive

- a Shoes app (and any assets), compressed into a single file
- currently, this kind of package is a .shy file, but we could also create
a .zip-based format
- does not include Shoes
- requires an existing Shoes install


2. Shoes app standalone executable

- a standalone Shoes app
- .exe, .app, .run
- can be distributed as-is, or compressed as a .zip (or .dmg)
- includes Shoes
- does not require an existing Shoes install


3. Shoes app net-install executable

- a standalone Shoes app
- .exe, .app, .run
- can be distributed as-is, or compressed as a .zip (or .dmg)
- does not include Shoes
- downloads and installs Shoes if necessary. Uses installed Shoes if present.

I would say that archives and standalone executables are necessary. I do 
not think it would be good enough to only offer archives, and require a 
Shoes install to run packaged apps, or even to offer archives zipped up 
with a Shoes install.

Net-install executables are nice to have, but not essential. They offer 
reduced app size in exchange for a *ton* of complexity.

What do you all think?

Eric

Re: [shoes] Proposal

From:
Hawley Waldman
Date:
2012-09-10 @ 15:31
I would like to start with the aim of a packager that creates an 
standalone app. Extra downloads or installs of dependencies are just an 
annoyance for the end user and run the risk that an update to the 
dependencies would not be compatible with the app itself.

To simplify things/leverage the group's knowledge and skills, the first 
thing that I'd like to see is the capability of shoes being run on a mac 
being able to create a stand alone mac app, and shoes run on windows being
able to create a stand alone windows app.  This seems to me to be an 
acceptably simplified, yet still very useful first step.

(there was some mention earlier about gui vs command line and I think that
should be semi-irrelavent. Once we have a functional app maker it should 
be easy enough to wrap it up in a gui, that's the point of shoes, right?)

-hawley

> On Sep 10, 2012, at 5:04 AM, Peter Fitzgibbons wrote:
> 
>> Lets start discussing again what the feasible target installation 
profile should be for Shoes.
>> Can we build installers (zips) for each platform and then make it a 
basic pre-req that to run any .shy you need Shoes ?   (Not what _why 
accomplished).
> 
> Packaging is complicated (see 
https://github.com/shoes/shoes/wiki/A-Developer%27s-Tour-Through-The-Magic-Packager).
We are talking about a few overlapping ideas, and this causes confusion. 
Maybe we can name them.
> 
> 1. Shoes app archive
> 
> - a Shoes app (and any assets), compressed into a single file
> - currently, this kind of package is a .shy file, but we could also 
create a .zip-based format
> - does not include Shoes
> - requires an existing Shoes install
> 
> 
> 2. Shoes app standalone executable
> 
> - a standalone Shoes app
> - .exe, .app, .run
> - can be distributed as-is, or compressed as a .zip (or .dmg)
> - includes Shoes
> - does not require an existing Shoes install
> 
> 
> 3. Shoes app net-install executable
> 
> - a standalone Shoes app
> - .exe, .app, .run
> - can be distributed as-is, or compressed as a .zip (or .dmg)
> - does not include Shoes
> - downloads and installs Shoes if necessary. Uses installed Shoes if present.
> 
> I would say that archives and standalone executables are necessary. I do
not think it would be good enough to only offer archives, and require a 
Shoes install to run packaged apps, or even to offer archives zipped up 
with a Shoes install.
> 
> Net-install executables are nice to have, but not essential. They offer 
reduced app size in exchange for a *ton* of complexity.
> 
> What do you all think?
> 
> Eric

Re: [shoes] Proposal

From:
Peter Fitzgibbons
Date:
2012-09-10 @ 16:09
Shoes GUI to run/install Shoes app.  Sounds like the self-bootstrap story
like Mono Project (when it first self-compiled).

Is it possible to have a .bat/.sh "wrapper" that can self-detect existing
shoes and then install if necessary?  Isn't this what the Net-Install of
RedShoes did?

I'm +1 for 1. Shoes archive .zip (.shy) and 2. Shoes executable.

I think maybe the majority of the complexity in this discussion is based
upon 3. Net-Install.  IF that is the case, then we may have a fairly easy
path into 1. and 2. and gettting a Shoes4-Preview available.

Thoughts?

Peter Fitzgibbons
(847) 859-9550
Email: peter.fitzgibbons@gmail.com
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@gmail.com


On Mon, Sep 10, 2012 at 10:31 AM, Hawley Waldman <hawleyw@gmail.com> wrote:

> I would like to start with the aim of a packager that creates an
> standalone app. Extra downloads or installs of dependencies are just an
> annoyance for the end user and run the risk that an update to the
> dependencies would not be compatible with the app itself.
>
> To simplify things/leverage the group's knowledge and skills, the first
> thing that I'd like to see is the capability of shoes being run on a mac
> being able to create a stand alone mac app, and shoes run on windows being
> able to create a stand alone windows app.  This seems to me to be an
> acceptably simplified, yet still very useful first step.
>
> (there was some mention earlier about gui vs command line and I think that
> should be semi-irrelavent. Once we have a functional app maker it should be
> easy enough to wrap it up in a gui, that's the point of shoes, right?)
>
> -hawley
>
> > On Sep 10, 2012, at 5:04 AM, Peter Fitzgibbons wrote:
> >
> >> Lets start discussing again what the feasible target installation
> profile should be for Shoes.
> >> Can we build installers (zips) for each platform and then make it a
> basic pre-req that to run any .shy you need Shoes ?   (Not what _why
> accomplished).
> >
> > Packaging is complicated (see
> 
https://github.com/shoes/shoes/wiki/A-Developer%27s-Tour-Through-The-Magic-Packager).
> We are talking about a few overlapping ideas, and this causes confusion.
> Maybe we can name them.
> >
> > 1. Shoes app archive
> >
> > - a Shoes app (and any assets), compressed into a single file
> > - currently, this kind of package is a .shy file, but we could also
> create a .zip-based format
> > - does not include Shoes
> > - requires an existing Shoes install
> >
> >
> > 2. Shoes app standalone executable
> >
> > - a standalone Shoes app
> > - .exe, .app, .run
> > - can be distributed as-is, or compressed as a .zip (or .dmg)
> > - includes Shoes
> > - does not require an existing Shoes install
> >
> >
> > 3. Shoes app net-install executable
> >
> > - a standalone Shoes app
> > - .exe, .app, .run
> > - can be distributed as-is, or compressed as a .zip (or .dmg)
> > - does not include Shoes
> > - downloads and installs Shoes if necessary. Uses installed Shoes if
> present.
> >
> > I would say that archives and standalone executables are necessary. I do
> not think it would be good enough to only offer archives, and require a
> Shoes install to run packaged apps, or even to offer archives zipped up
> with a Shoes install.
> >
> > Net-install executables are nice to have, but not essential. They offer
> reduced app size in exchange for a *ton* of complexity.
> >
> > What do you all think?
> >
> > Eric
>

Re: [shoes] Proposal

From:
Steve Klabnik
Date:
2012-09-10 @ 19:44
Peter and I just had an excellent real-life discussion about this. Yay
Chicago!

We've done two things in this thread:

1. Establish we all feel a packager is a most important feature (possibly
most of all!!!)
2. Establish we don't know up from down when it comes to making this
actually WORK.

So I'd like for this discussion to be a bit more focused around strategies
for getting a ruby + shoes + deps done. Doesn't matter HOW; running code
beats all.

Requirements:

1. Mac and Windows. Linux would be nice.
2. You can only download one thing. This is super crucial. One file.
3. No prerequisites. We can't assume people have compilers. Or libraries.

I personally am super world traveller for the next few weeks, so I will be
able to put zero effort into this, other than email answers. But those are
the parameters. Make sense?

Re: [shoes] Proposal

From:
Eric Watson
Date:
2012-09-10 @ 20:06

On Sep 10, 2012, at 2:44 PM, Steve Klabnik <steve@steveklabnik.com> wrote:

> 1. Mac and Windows. Linux would be nice.
> 2. You can only download one thing. This is super crucial. One file.
> 3. No prerequisites. We can't assume people have compilers. Or libraries.

+1

To me, this means, that a Java-based stack bundles Java along with Ruby, 
Shoes, and the app. An executable .jar doesn't cut it, because that 
requires the user to have Java installed. 

Re: [shoes] Proposal

From:
Tobias Pfeiffer
Date:
2012-09-11 @ 04:46
On 10.09.2012 22:06, Eric Watson wrote:
> To me, this means, that a Java-based stack bundles Java along with Ruby,
Shoes, and the app. An executable .jar doesn't cut it, because that 
requires the user to have Java installed.
I agree, but I'd like it though if the packager would also support 
packaging without including the JRE - just due to the size of the package.

Re: [shoes] Proposal

From:
ashbb
Date:
2012-09-11 @ 13:44
Does the `Shoes app standalone executable` include Ruby (or JRuby)?

ashbb

Re: [shoes] Proposal

From:
David Eastman
Date:
2012-09-11 @ 15:14
(this thread will probably migrate to an Issues thread on github)

Yes, it must - standalone means the packager has wrapped enough for
the installer to need nothing more.

This implies that a specific ruby is associated with that shoes
version, and one assumes the original dev environment.



-- Sent from my HP Pre3

On 11 Sep 2012 14:45, ashbb <ashbbb@gmail.com> wrote:

Does the `Shoes app standalone executable` include Ruby (or JRuby)?

ashbb

Re: [shoes] Proposal

From:
Peter Fitzgibbons
Date:
2012-09-11 @ 15:22
Please folks,
Use the following issue henceforth

ALL,

Issue 90 <https://github.com/shoes/shoes4/issues/90> Implement packager for
Shoes.{exe,app,sh}
Per the wiki Tour the Magic

Packager<https://github.com/shoes/shoes/wiki/A-Developer%27s-Tour-Through-The-Magic-Packager>,
this is the Packager, not the Installer.  That is, this mod will be used to
"create" the Shoes.{exe,app,sh}.  For now, the only installation option
will be (at-least) x-copy install.   We'll work on Installer (Install4J,
DMG, etc) next.

Issue 124 <https://github.com/shoes/shoes4/issues/124> Implement packager
for Shoes "apps" (.shy named zip-installs)
This is the "app" packager... I expect this mod to be code within the Shoes
codebase to zip (and unzip) .shy files.

Issue 125 <https://github.com/shoes/shoes4/issues/125> Implement Installer
for Shoes.{exe,app,sh}


Please continue relevant discussions within the Issues list.

Shoes On!

Peter Fitzgibbons
(847) 859-9550
Email: peter.fitzgibbons@gmail.com
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@gmail.com

Re: [shoes] Proposal

From:
Peter Fitzgibbons
Date:
2012-09-10 @ 20:08
ALL,

Issue 90 <https://github.com/shoes/shoes4/issues/90> Implement packager for
Shoes.{exe,app,sh}
Per the wiki Tour the Magic

Packager<https://github.com/shoes/shoes/wiki/A-Developer%27s-Tour-Through-The-Magic-Packager>,
this is the Packager, not the Installer.  That is, this mod will be used to
"create" the Shoes.{exe,app,sh}.  For now, the only installation option
will be (at-least) x-copy install.   We'll work on Installer (Install4J,
DMG, etc) next.

Issue 124 <https://github.com/shoes/shoes4/issues/124> Implement packager
for Shoes "apps" (.shy named zip-installs)
This is the "app" packager... I expect this mod to be code within the Shoes
codebase to zip (and unzip) .shy files.

Issue 125 <https://github.com/shoes/shoes4/issues/125> Implement Installer
for Shoes.{exe,app,sh}


Please continue relevant discussions within the Issues list.

Shoes On!

Peter Fitzgibbons
(847) 859-9550
Email: peter.fitzgibbons@gmail.com
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@gmail.com


On Mon, Sep 10, 2012 at 2:44 PM, Steve Klabnik <steve@steveklabnik.com>wrote:

> Peter and I just had an excellent real-life discussion about this. Yay
> Chicago!
>
> We've done two things in this thread:
>
> 1. Establish we all feel a packager is a most important feature (possibly
> most of all!!!)
> 2. Establish we don't know up from down when it comes to making this
> actually WORK.
>
> So I'd like for this discussion to be a bit more focused around strategies
> for getting a ruby + shoes + deps done. Doesn't matter HOW; running code
> beats all.
>
> Requirements:
>
> 1. Mac and Windows. Linux would be nice.
> 2. You can only download one thing. This is super crucial. One file.
> 3. No prerequisites. We can't assume people have compilers. Or libraries.
>
> I personally am super world traveller for the next few weeks, so I will be
> able to put zero effort into this, other than email answers. But those are
> the parameters. Make sense?

Re: [shoes] Proposal

From:
Tobias Pfeiffer
Date:
2012-09-10 @ 08:55
Hi all,

I agree that packaging is vastly important. However attempts to fix the 
red shoes packager have failed and have left severe scars on our brave 
heroes who tried to defeat it.

As for shoes4, I stand by my point that development hasn't advanced far 
enough, I mean a few months back we nearly switched to QT due to some 
inabilities of SWT. I think when we're closer to feature complete, we 
can start looking at the packager. I dunno when the optimal point for 
this is though :-)

However if someone's all enthusiastic about figuring out the packager 
now, please go ahead and do it.

Shoes on!
Tobi

On 08.09.2012 22:53, Hawley Waldman wrote:
> I would like to put forth the idea that we, as shoes enthusiasts, should
put much more emphasis on having a working packager then we are.
>
> My controversial statement is: without a working packager shoes will 
remain in the domain of the esoteric.
>
> A more nuanced and gentle way of putting it is:
>
> If, using shoes allowed you to easily create cool graphical apps which 
ran inside the shoes environment (which it does), and it also allowed you 
to easily create _free-standing_ applications, that ran  on osx, windows 
and linux without the necessity of downloading all kinds of support 
libraries (a feature it promises, but doesn't seem to deliver), we would 
see many, many, many, more people using shoes and, in all likelihood, that
would attract more attention from programmers to support the code/project.
>
> If a young person, learning to program could put their program on a 
thumb drive and give it to all of their friends to play play with that 
would get them a lot more excited about programming.
>
> If an amateur or hobbyist programmer could use ruby and shoes to create 
a program that their friends could run/use, it would create a lot of 
enthusiasm (and possibly more help with maintenance and support)
>
> If professional programmers could use shoes to easily create good 
looking, commercially viable, desktop-ish applications they would get 
excited and jump on board, being much more likely to contribute to 
development and maintenance.
>
> Our "product" is shoes, a tool that makes it easy for people to create 
programs with cool gui's, but people aren't going to buy in because _their
product is widget.app, or widget.exe and widget.<whatever> needs to be 
easy for _their customers to install and run.
>
> We write the code for a program once, hoping in general that we are 
creating something that will be used again, and again. If we lose track of
that goal we are just spending our time in a kind of masturbatory world, 
and masturbation just ain't as fun in the long term as, well, you know 
what.
>
> I don't think that shoes needs to become a bloated, swiss army knife of 
a toolkit, it can keep the slick, simple (and powerful) features that it 
has (although I'm thrilled with the talked about refinement of how listbox
will work in shoes4) and it will still be good enough to do many / most 
things.
>
> A good enough toolkit, that lets you create programs that you can easily
share and which might benefit others. That's what I would like to see 
shoes become.  An epitome of "appropriate laziness", what an former 
professor of mine described as an essential characteristic of a computer 
scientist.
>
>
> So, what do you say? Can we get some enthusiasm  and momentum going for 
fixing  our packager/application wrapper service, or creating a new one?  
Once that is done each of the groovy rewritten features for shoes4, or 
green_shoes, or <insert color here>_shoes, would have an immediate impact 
on the world.  We need one packager, but many, many features, how about 
getting the packager done so that we can use as many features as we choose
to write in the infinite future?
>
> sincerely, respectfully and gently,
> Hawley

Re: [shoes] Proposal

From:
Eric Watson
Date:
2012-09-10 @ 13:33

On Sep 10, 2012, at 3:55 AM, Tobias Pfeiffer 
<tobias.pfeiffer@student.hpi.uni-potsdam.de> wrote:

> As for shoes4, I stand by my point that development hasn't advanced far 
> enough, I mean a few months back we nearly switched to QT due to some 
> inabilities of SWT. I think when we're closer to feature complete, we 
> can start looking at the packager.

On the other hand, if packaging is a high priority, we should at least 
prove to ourselves that we can achieve it with our proposed setup. What's 
the sense in developing a complete Shoes 4 and then getting hung up on the
packaging again?

In software engineering terminology, packaging is "high risk". We should 
try to expose problems with packaging our chosen stack as fast as we can.

Re: [shoes] Proposal

From:
Tobias Pfeiffer
Date:
2012-09-10 @ 14:07
On 10.09.2012 15:33, Eric Watson wrote:
> On the other hand, if packaging is a high priority, we should at least 
prove to ourselves that we can achieve it with our proposed setup. What's 
the sense in developing a complete Shoes 4 and then getting hung up on the
packaging again?
>
> In software engineering terminology, packaging is "high risk". We should
try to expose problems with packaging our chosen stack as fast as we can.
Yup I totally understand what you mean.
Maybe I'm too optimistic in the sense that I 100% believe packaging is 
possible with JRuby/SWT. With MRI + QT I'd be more cautious and would 
totally be on the "try it as soon as possible site".
On the other hand, a working packager with a non working shoes doesn't 
help us much either. In addition I'm a bit afraid that it keeps us from 
doing big overhaul changes since they might break the packager.
Plus, at least in open source I'm a bit more cautious. I don't want 
anyone to spend huge amounts of work on the packager and then make it 
obsolete or something.

Just a personal preference, but I fully see your point :-)

Cheers!
Tobi

Re: [shoes] Proposal

From:
Hawley Waldman
Date:
2012-09-10 @ 14:24
> On 10.09.2012 15:33, Eric Watson wrote:
>> On the other hand, if packaging is a high priority, we should at least 
prove to ourselves that we can achieve it with our proposed setup. What's 
the sense in developing a complete Shoes 4 and then getting hung up on the
packaging again?
>> 
>> In software engineering terminology, packaging is "high risk". We 
should try to expose problems with packaging our chosen stack as fast as 
we can.
> Yup I totally understand what you mean.
> Maybe I'm too optimistic in the sense that I 100% believe packaging is 
> possible with JRuby/SWT. With MRI + QT I'd be more cautious and would 
> totally be on the "try it as soon as possible site".
> On the other hand, a working packager with a non working shoes doesn't 
> help us much either. In addition I'm a bit afraid that it keeps us from 
> doing big overhaul changes since they might break the packager.
> Plus, at least in open source I'm a bit more cautious. I don't want 
> anyone to spend huge amounts of work on the packager and then make it 
> obsolete or something.
> 
> Just a personal preference, but I fully see your point :-)
> 
> Cheers!
> Tobi

With a packager in place, people can create applications utilizing 
whatever features are working; many simple apps need minimal features, 
many of which may be working long before the full toolkit is finished.

With a reasonable design, and since shoes 4 is committed to tdd, anything 
that 'breaks' the packager will be known right away and the issue can be 
addressed, either by modifying the new code, or modifying the packager.  
If the shoes4's code, as downloaded from github came properly set up for 
the packager to run, no new code would be added to break things, where as 
if many features are written, by multiple people and then we try to make 
all of that work with a packager we will likely be stuck chasing a 
gazillion details when we try to tack a packager on at the end.

Additionally, as pointed out earlier in the thread, it is likely that a 
successful packaging solution is likely to be portable to all colors of 
shoes, at least its' design, if not its code.

sincerely,
Hawley