JJ,

It does seem as though while you are not asking for native code, you are
asking for native widgets.  There are times when it would be useful
(appropriate is probably a better word), but I am more concerned about
having emulated widgets with a robust (with respect to end users) feel.

I can summarize as follows: I do not disagree with your goal of having
access to native widgets.  I am saying that I think it is less important
than getting morphic right.  Rob's wxSqueak has promise, but more than
the widgets themselves, I want to have the MVP framework for Squeak.

You mention "native package tools of the host operating systems" - does
that include MSI?  There was a time when I was _convinced_ I was going
to switch to it.  Object Arts had done so, and I found the Automation
wrapper for it.  Within a few hours, the cracks started to appear, and
after a few days, I wanted my money back from Bill Gates :)  IMHO, it is
so complicated as to be truly dangerous, largely because they sent a
relational database to do a serializer's job.  Pretty pathetic in total.
 It is also, for now at least, completely avoidable.  InnoSetup does a
fine job.

The Redhat package manager looks like it might be worth a look.  I have
never searched for a Windows implementation, but IIRC, the license does
not prevent it.  Of course, there is no harm in having hooks for
whatever binary packager a developer might want to us, including the
ultimate workhorse: zip files.

I think you are low-balling Squeak's ability to deploy images.  One can
package something that starts up with "the app" running.  Your users
could simply unzip that, or run an Inno based installer, and get going
in a real hurry.  If your users are developers, you can send them an
image with the stuff already loaded.  Squeak's license does not stop
you.

One thing, your idea of zipping up the user's image for a bug report is
not possible in general.  People will not knowingly send you financial
data, and if you target health care as I do, it becomes criminal in
addition to being unwise.  What you can do is log call stacks for errors
and a little more on crashes.  I don't care for Squeak's tendency to
overwrite vs. append to these logs, but that is easy to fix.  Then a
user could be directed to the log for cleaning if necessary, and
forwarding to you.  Health care presents some additional problems: what
is in the crash log, and where does it live?  Shared drives are becoming
common for avoiding such concerns, but if the failure is due to loss of
same, OUCH!!!

Bill




>From: Brad Fuller <brad at bradfuller.com>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: Making Squeak more accessible and used - reversing the
trend
>Date: Sat, 03 Feb 2007 15:45:14 -0800
>
>One of smalltalk's wonderful features is it's prototyping ability,
that's 
>true. I think what you are proposing is to create native apps with
Squeak 
>to get developers excited about the development possibilities of
Squeak.

Yes.  That and proving to others how good Squeak/Smalltalk is by
constantly 
being ahead of them.  I should also mention, I don't mean native as in 
"compiles to machine code".  It will still be the same system, just with

unused components stripped out of the package.

>But, I think we would go down the wrong road, and do a real disservice,
if 
>we encouraged building native OS applications. Squeak moves beyond the
OS 
>and vertical applications (or, never been there) into a world not 
>necessarily requiring an operating system - on into a personal
environment 
>where user's can manipulate objects for their own needs on any
hardware.

But having the ability to generate native looking doesn't mean we can't 
still build in Squeak in this way.  In fact, we still have to *develop*
this 
way.  It is just that when we make a new "application" or update an
older 
one, we press a "deploy" button and now we have a package that we can
use 
with all the native package tools of the different operating systems.

In other words, we can be on a high horse and say "no compromise!  This
is 
the future and you must take the whole or you can have nothing!" and 
everyone will continue to choose their less capable languages (except
for 
web programming where we don't have this issue).  Or we can reach out
just a 
little and prove what we can do.

I am not talking about something radical like getting source files.  Not

having source files is a big part of what gives Smalltalk it's advantage
and 
I would never want to see that changed just to look more familiar.  I
would 
never want to change Smalltalk in any way just to look familiar.

But I do care about playing well with others where it makes sense.  And
to 
me, an ability like this makes sense.  Right now, if I made some cool 
application in Squeak what does the average user have to do to see it? 
They 
use their native app installer to get squeak, then they have to learn
the 
Squeak interface to be able to use *our* app installer to finally get
it.  
That puts us at a rather large disadvantage.

Right now, people are doing this kind of packaging for stand alone 
applications anyway.  Look at Sophie for example.  And what about
commercial 
apps?  We want to support those right?  If a vendor releases something
for 
the desktop, it will be a stand alone app.

But if we make the stand alone application generator, we can do anything
we 
want.  For example, we can have the default error handler to pop up a
window 
to the user, much like MS windows does now, and give them an option to
send 
a "bug report".  The "bug report" would actually zip up the image, right

where it is and mail it to the developer so when he runs it in his own 
image, he has the full debugger et al. to rapidly find and fix the
problem.  
We can have the built in auto-update system just load a change set. 
Using 
the power of Smalltalk, our application can update itself while running.
 No 
application restarts for updates.

>What we need is to convince Mr. Dell to sell computers with Squeak on
it 
>and nothing else. That would be the ultimate.

Squeak isn't ready to fit that roll, even if there was interest



Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bills at anest4.anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029