Making Squeak more accessible and used - reversing the trend

I haven't looked at your GUI code, but are you using Magritte?  If so, you
are closer to running in Morphic then you think. :)


_________________________________________________________________
Laugh, share and connect with Windows Live Messenger
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline

It has a great ORM (Glorp), it just needs drivers to some of these
databases.

_________________________________________________________________
FREE online classifieds from Windows Live Expo – buy and sell with people
you know
http://clk.atdmt.com/MSN/go/msnnkwex0010000001msn/direct/01/?href=http://expo.live.com?s_cid=Hotmail_tagline_12/06

I don't use magritte, I think I will try to switch to magritte for the
editors, but I'm not sure it would be suited for the rest of the app.

Yann

J J wrote:

I have been thinking about this stuff as well.

Vista is out, and the places I read think Microsoft may have opened the door
for some competition (due to trying to force DRM down everyone's throats,
etc.).  If Steve Jobs goes for it, Micheal Dell said he is interested in
shipping Dells with Mac OS on them.  Some people are even saying Linux may
gain some big market share.

So what this means to me is, people will be looking for an easy way to make
GUI applications on these platforms.  I know nearly nothing about the MAC
world, but in Linux the only RAD tool I am aware of is a code generator for
GTK.

Now in Smalltalk we always say (and I believe) that we can be much more
productive then other languages.  So I think it may be time to prove it.

I don't know how many of you have used Dolphin, but it is an amazing system.
  It only works on windows, but the GUI is wonderful and looks just like a
normal windows app.  And what is more, after you build an application, it
has tools to automatically package up the application you write and turn it
into a MSI kind of package.  This includes turning certain parts into DLL's
so that if you write multiple applications they can share libraries, etc.,
etc..

And I think Dolphin is currently the perfect system for building native
windows apps.  You get as much, or more speed then a VB environment but
vastly more power.

What would be nice, is if Squeak had something like this.  A great GUI
builder (maybe it has already) and some way that we could use some system to
turn an application we write into a native Linux/Mac OS package.  Well,
native looking.  If you check what Dolphin installs you would find a
smalltalk interpreter in there.  The payback with the installer is, we can
then submit "binaries" to distributions like Debian for any applications we
make.  The end user doesn't need to know it is Smalltalk.  If we end up
becoming a big player in the Linux and/or MAC world, people will be
*begging* us to share how we are doing it.

With a rapid GUI development tool bound with the productivity of the
Smalltalk language and the platform independence of Squeak we could have
quite an advantage in the native UI space.  And I understand the concerns
about making apps that do things that already exist, but what we have to
remember is that all applications change all the time.  What a Word
processor looked like 5 years ago is a little different then what they look
like today and will be still more different in another 5.  Not drastically,
but new features are being added.  All we have to do is keep up with the
features they have and add our own here and there.  To take a page from Paul
Graham's book, when ever a "competitor" adds a feature, we can have it the
next day.

Think about Mozilla for example.  They are pretty advanced, but it is an
enormous code base in C.  They can't add new core features quickly.

I still believe the web will play an even larger roll in the future then
now, but we will always have to have *some* native apps (a browser if
nothing else).  And if MAC gets a bigger percentage of the desktop market
share (and maybe even Linux), this could open up an opportunity that wasn't
there before.  And I don't think anyone can move to cover that gap as quick
as Smalltalk can.

>From: Brad Fuller <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: [hidden email]
>Subject: Making Squeak more accessible and used - reversing the trend
>Date: Tue, 30 Jan 2007 18:05:01 -0800
>
>All,
><sniped>

_________________________________________________________________
>From predictions to trailers, check out the MSN Entertainment Guide to the
Academy Awards®
http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline1

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.

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.

(I used the word "application" in my original msg because I didn't know
what else to use. Using the word "object" is ok, but doesn't convey the
idea of an object that is feature-rich to satisfy a particular higher
order need (like a web browser does.))

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



J J wrote:

--
brad fuller
www.bradfuller.com

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

Which would only certainly happen if we had a large base, or potentially
large base, of users craving for Squeak.

hmmm.. back to the original problem...


--
brad fuller
www.bradfuller.com

Hello all,

I continue to think the community is really missing the point on a few
fundamental topics.  Some think the only route to success is to get
developers to use Squeak to churn out native-widget apps for end users;
others fire back with things like there should be no OS, no difference
between users and developers, and other idealistic beliefs.  All are
bickering, to the detriment of Squeak.

Our goal should be to collaborate on making both approaches, and others,
possible!  Personally, I would be thrilled with some slight pluggable
control of Morphic's appearance, combined with a LOT of attention to
making it feel the way they typical end user would be willing to
tolerate.  As I have said many times, the "out of the box" look of
Squeak has been improving from some time, but the feel is going to tank
Squeak for anything but niche use right now - sorry, but it's true.
Since many Squeakers appear to like the feel, fine, make that
configurable.  We do not have to shoot each other in the foot to have
what we each want.

I recently talked to a really bright recent CS graduate.  Brace
yourself: he had never heard of Alan.  He has now of course :)   I blame
academia for this outrage, not the student.  The reality is that
Smalltalk does not get a particularly fair shake, and probably will not
for some time.  From one perspective, we can use that to our respective
personal advantages: crush the competition by having an edge.  We all
individually found Smalltalk, so others can too.

The best source of new developers will be those who already "get it" -
aka current Smalltalkers.  For them, ANSI compatibility is probably the
best thing we can strive to provide.  Squeak's read streams should catch
up with exception handling; reading off the end of a stream should
default to an error, with #nextOrNil and #nextAvailable: signaling a
willingness to accept less than the requested amount of data.  Squeak
should stop electively grumbling about underscores (it really is getting
to be elective at this point).  Want single-key assignment?  Fine, make
it an optional feature of the editor.

The modularization effort provides a wonderful opportunity to give
Squeak a frame-up restoration for 3.10 and  beyond.   I continue to hope
that we will take a collective deep breath and clean up the modules as
they go into the next image; now is the time.  3.9 could have some tools
to check/correct old code for export to newer releases, perhaps using
the RB to attempt to automate fixes.  As the governator might say, no
pain, no gain.

J.J., FWIW, the few end user apps I have seen written in Squeak all use
SystemWindow for their top-level window.  The result is one main window
with a Squeak-generated title bar inside the VM's main window - that's
wrong from a user's perspective.  To them, the Squeak/VM window will be
"the window" and so the client area (to borrow from MS) should be an
alignment morph or something covering the current world.  From that
perspective, and with the pluggable look and corrected feel I mention
above, I doubt you or your potential users would much miss the latest
and greatest native widgets.  That would be all the more true if your
hint of an exodus from Windows occurs.

Happy Smalltalking,

Bill





Brad Fuller brad at bradfuller.com
Sat Feb 3 23:45:14 UTC 2007:
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.

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.

(I used the word "application" in my original msg because I didn't know
what else to use. Using the word "object" is ok, but doesn't convey the
idea of an object that is feature-rich to satisfy a particular higher
order need (like a web browser does.))

What we need is to convince Mr. Dell to sell computers with Squeak on it

and nothing else. That would be the ultimate.



J J wrote:
> I have been thinking about this stuff as well.
>
> Vista is out, and the places I read think Microsoft may have opened
the
> door for some competition (due to trying to force DRM down everyone's
> throats, etc.).  If Steve Jobs goes for it, Micheal Dell said he is
> interested in shipping Dells with Mac OS on them.  Some people are
even
> saying Linux may gain some big market share.
>
> So what this means to me is, people will be looking for an easy way to

> make GUI applications on these platforms.  I know nearly nothing about

> the MAC world, but in Linux the only RAD tool I am aware of is a code
> generator for GTK.
>
> Now in Smalltalk we always say (and I believe) that we can be much
more
> productive then other languages.  So I think it may be time to prove
it.
>
> I don't know how many of you have used Dolphin, but it is an amazing
> system.  It only works on windows, but the GUI is wonderful and looks
> just like a normal windows app.  And what is more, after you build an
> application, it has tools to automatically package up the application
> you write and turn it into a MSI kind of package.  This includes
turning
> certain parts into DLL's so that if you write multiple applications
they
> can share libraries, etc., etc..
>
> And I think Dolphin is currently the perfect system for building
native
> windows apps.  You get as much, or more speed then a VB environment
but
> vastly more power.
>
> What would be nice, is if Squeak had something like this.  A great GUI

> builder (maybe it has already) and some way that we could use some
> system to turn an application we write into a native Linux/Mac OS
> package.  Well, native looking.  If you check what Dolphin installs
you
> would find a smalltalk interpreter in there.  The payback with the
> installer is, we can then submit "binaries" to distributions like
Debian
> for any applications we make.  The end user doesn't need to know it is

> Smalltalk.  If we end up becoming a big player in the Linux and/or MAC

> world, people will be *begging* us to share how we are doing it.
>
> With a rapid GUI development tool bound with the productivity of the
> Smalltalk language and the platform independence of Squeak we could
have
> quite an advantage in the native UI space.  And I understand the
> concerns about making apps that do things that already exist, but what

> we have to remember is that all applications change all the time.
What
> a Word processor looked like 5 years ago is a little different then
what
> they look like today and will be still more different in another 5.
Not
> drastically, but new features are being added.  All we have to do is
> keep up with the features they have and add our own here and there.
To
> take a page from Paul Graham's book, when ever a "competitor" adds a
> feature, we can have it the next day.
>
> Think about Mozilla for example.  They are pretty advanced, but it is
an
> enormous code base in C.  They can't add new core features quickly.
>
> I still believe the web will play an even larger roll in the future
then
> now, but we will always have to have *some* native apps (a browser if
> nothing else).  And if MAC gets a bigger percentage of the desktop
> market share (and maybe even Linux), this could open up an opportunity

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

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

Bill Schwab wrote:
> Hello all,
>
> I continue to think the community is really missing the point on a few
> fundamental topics.  Some think the only route to success is to get
> developers to use Squeak to churn out native-widget apps for end users;
> others fire back with things like there should be no OS, no difference
> between users and developers, and other idealistic beliefs.  All are
> bickering, to the detriment of Squeak.

Gee... I haven't seen any bickering. I think the arguments have been
fruitful and interesting.

>
> Our goal should be to collaborate on making both approaches, and others,
> possible!

Why would one want to continue to perpetuate the development of vertical
applications - of which it is difficult to communicate between (except
w/o even more vertical methods of communicating)? I see only one
advantage of developing OS-native apps in Squeak and that's Smalltalk's
prototyping ability. A capability that you can also get with other
languages. Unfortunately, the user misses the true power of the
Smalltalk environment.

<text removed>

> The modularization effort provides a wonderful opportunity to give
> Squeak a frame-up restoration for 3.10 and  beyond.   I continue to hope
> that we will take a collective deep breath and clean up the modules as
> they go into the next image; now is the time.  

Amen


--
brad fuller
www.bradfuller.com

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.

_________________________________________________________________
Laugh, share and connect with Windows Live Messenger
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline

Because we want to lower the cost of entry into smalltalk without losing any
of the power.  Of course, if we deploy 3 or 4 different native apps they
wouldn't be able to talk to each other via normal message sends, but on the
other hand it will be trivial for them to talk over the network which lets
them take advantage of the dual cores.

At this point, it isn't clear whether the implicit threading of Concurrent
Haskell, Transactional memory, or the 0 sharing/message passing of Erlang is
going to win out as the strategy for multi-threading.  If it happens to be
the Erlang solution, then Squeak isn't so far behind actually but we will
need to expand on this "vertical methods of communicating".

>I  see only one advantage of developing OS-native apps in Squeak and that's
>Smalltalk's prototyping ability. A capability that you can also get with
>other languages. Unfortunately, the user misses the true power of the
>Smalltalk environment.

Yes, they miss the complete true power of Smalltalk.  But right now they are
missing *all* of the power.  It seems to me that people don't come look at
your world until you beat them in their own.

_________________________________________________________________
Talk now to your Hotmail contacts with Windows Live Messenger.
http://get.live.com/messenger/overview

I agree 100% that we should have all the approaches possible, and I thought
that was part of my message.  In the world I envision, my image would have
all the applications I have ever written or loaded.  But when I update one
of the applications I support, I can click a button to package it up for
deployment.  We could even put plug-ins to let the tool completely build
Debian, RPM, whatever packages completely so there is only one step,
speeding our "time to market" up even more.

And as far as look-and-feel.  I agree, I don't have a problem with how
Squeak looks, but I would want to release my apps so that they look native
where ever they run.  I think Squeak can already do this, but it sounds like
a little work is needed here as well to support it easier (e.g. don't spend
cycles building up the Squeak window if it isn't going to be used).

>From one perspective, we can use that to our respective
>personal advantages: crush the competition by having an edge.  We all
>individually found Smalltalk, so others can too.

Sure, that is very true.  It is funny reading what people like Paul Graham
and the PS2 game company "Raw Dog" did with Lisp.  The companies that
acquired them didn't want to use the language, so now they are vulnerable to
the same thing occurring again.

>J.J., FWIW, the few end user apps I have seen written in Squeak all use
>SystemWindow for their top-level window.  The result is one main window
>with a Squeak-generated title bar inside the VM's main window - that's
>wrong from a user's perspective.

I wasn't suggesting that the application look like Squeak now.  I was
pointing to Dolphin as my example.  But if we make this configurable, as you
say, then we can have it anyway we want it.  We could even automate it so
that the build stage selects a GUI appropriate for the target system.

For example, we could use Magritte to build the GUI, and at package build
time, the package builder selects the Magritte for that platform (e.g.
Magritte-Morph, Magritte-MacOSX, etc.).  Since there is no dependency on the
other Magritte GUI generators (e.g. Magritte-Seaside) they get stripped out
of the final image.

>That would be all the more true if your
>hint of an exodus from Windows occurs.

Well, I don't know that I would say Exodus.  I don't expect windows desktops
drop to 0 overnight.  I would be happy if Mac and Linux picked up another 5
or 10% a piece.

But I just mean there is a chance, and if the desktop market ever does open
up I think we stand the best chance to get in that space before everyone
else comes.  The Windows RAD tool space is utterly saturated.  But Linux is
very low hanging fruit, with (for now at least) a low application market
share.  I can't say much about Mac but I would expect it to be less
saturated then Windows at least and higher application market share then
Linux.

_________________________________________________________________
Turn searches into helpful donations. Make your search count.
http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_donation&FORM=WLMTAG

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: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

Brad,

I want to "perpetuate" vertical apps because my users need them and
therefore I need to create them.  Communicating between them can be as
simple as using sockets.  Given that I have apps (vertical or otherwise)
on geographically separated machines, that's pretty much a wash anyway.
BTW, I get more than prototyping: I get the ability to
profile/refactor/iterate until I have something that frequently
out-performs a mainstream effort, and I get an OO system that can "tell
me where it hurts" any time an error occurs.  That's a lot of bang for
the user's buck.

In summary, I want to use Smalltalk, and like it or not, I will run on
top of things like Windows, Mac OS or Linux for a long time to come.
The question is whether or not Squeak is a candidate development
platform.

We seem to agree (to put it mildly<g>) about the level of cleanup that
should occur in moving to 3.10.  That's a start.

Bill



Brad Fuller brad at bradfuller.com
Sun Feb 4 02:09:16 UTC 2007

> I continue to think the community is really missing the point on a few
> fundamental topics.  Some think the only route to success is to get
> developers to use Squeak to churn out native-widget apps for end
users;
> others fire back with things like there should be no OS, no difference
> between users and developers, and other idealistic beliefs.  All are
> bickering, to the detriment of Squeak.

Gee... I haven't seen any bickering. I think the arguments have been
fruitful and interesting.

>
> Our goal should be to collaborate on making both approaches, and
others,
> possible!

Why would one want to continue to perpetuate the development of vertical

applications - of which it is difficult to communicate between (except
w/o even more vertical methods of communicating)? I see only one
advantage of developing OS-native apps in Squeak and that's Smalltalk's
prototyping ability. A capability that you can also get with other
languages. Unfortunately, the user misses the true power of the
Smalltalk environment.

<text removed>

> The modularization effort provides a wonderful opportunity to give
> Squeak a frame-up restoration for 3.10 and  beyond.   I continue to
hope
> that we will take a collective deep breath and clean up the modules as
> they go into the next image; now is the time.  

Amen




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

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

JJ,

We have a small process-synchronization problem: we're writing emails at
the same time :)  Your recent message would likely alter my recent
message.  Please consider that as you read, if only retroactively.

My experience is that users will gladly tolerate some unfamiliar
appearance (aka deviation from platform standards) as long as software
does what they want, quickly, intuitively, and robustly.  One more pass
on the broken record: they care about feel far more than they care about
look.

We seem to want many of the same things for and from Squeak.  I would
simply urge you to prioritize some of the other items I have mentioned
(ANSI/underscore, end of stream errors, morphic feel) over native look
and packaging.  Between native look and packaging, look is probably the
more important topic for the community.  The packaging side is something
that a single developer can do, and your recent message referencing RPM
etc. shows that you already have ideas on how to do it.  The result
would easily be distributed as one or more items on SM.

Happy Smalltalking!

Bill



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

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

I'm not as concerned about how it happens (native widgets, working directly
in Morphic), as being able to do it.  And we are probably fairly close now.

>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.

I agree.  The MVP framework in Dolphin is nice.  I didn't mean to sound like
I would close the door to anything.  I don't know enough about Morphic to
say it can or can't do all these things.

>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.

Well, I wasn't even thinking about windows honestly.  I think Squeak could
make a big impact much faster on the other two platforms.  But I think
making it a plug-in architecture would be the best route.  Then people can
put in what ever installer they want.

>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.

That's true.  I didn't think anything I suggested couldn't be done today.  
Just most of it could be made easier.  People can and do deploy stand alone
applications now, but it is a totally manual process.  And it is also a very
automatable process.

>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.

Well, if you are developing a health care, bank or similar app, then of
course you couldn't use such a feature.  But I think there are applications
that this would be viable, and you can stick a warning on about "sending
this bug report WILL send everything your doing for debugging purposes", so
the user can decide what to do.  They can also go away from their online
bank account and look at some other site that triggers the problem.

I know we can't do this all the time (and maybe we can't *most* of the
time), but the times it can be used will make debugging very fast.

>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!!!

Those are all tough problems.  But that lets us charge more for software in
those domains. :)

_________________________________________________________________
FREE online classifieds from Windows Live Expo – buy and sell with people
you know
http://clk.atdmt.com/MSN/go/msnnkwex0010000001msn/direct/01/?href=http://expo.live.com?s_cid=Hotmail_tagline_12/06

Hello all,
I feel compelled to add my point of view due to recent discussions on this
list; I have kept quiet for a long time as I'm not a professional programmer
and haven't contributed code so my point of view doesn't hold much weight
but I hope to be expressing a wish that other silent readers have - if not,
I'll quietly go away and see what other solutions can do for me.
First, some background: I was first introduced to computers as a child, on
Apple ][ machines at my father's work, on which I learned to program in
basic, making little games. I then progressed to a ZX81 at home and then a
spectrum, all of which there was an easy route into programming. I then
spent around 15 years without a computer and when I finally got a PC was
horrified - I had a computer which (out of the box) I couldn't use to
compute!
I have since dirtied my hands with all sorts of programming languages and it
took a long time before I stumbled over squeak. Squeak has been an amazing
and enlightening adventure for me but I have never really used it. The thing
that has kept me interested even though I don't use squeak (except to
explore squeak itself) is Alan Kay's dynabook vision. This is how I'd like
to use my computer (or even better, my pda.)
Now in the next part of this mail I'm going to say all sorts of things that
I'm sure many squeak developers will disagree with. I'm aware that squeak is
being pulled in several directions simultaneously and everyone has their
good reasons for doing so but I have to put my viewpoint across and deal
with the flames. If any of this sounds blunt or naive, I'm sorry.
There are many RAD ways of building native applications - wxPython, wxRuby,
wxPerl... You get the idea. I'm sure wxGNUSmalltalk would be possible. For
me, the beauty and the power of squeak is in the direct manipulation of
objects.
I would love to see Tweak in the main image. There is a lot of talk about
cleaning up morphic and the huge effort it would require. Would it not be a
better idea to spend that effort getting Tweak functional in the main image?
I'm sure there are many ways that the etoys environment and tile scripting
could be expanded upon to create more advanced programming possibilities for
the non-expert like myself.
One way in which this type of environment could be useful to the layperson
(and I have many more ideas which I'll save for a later date) would be the
types of things that people generally use (and abuse) spreadsheets for.
For example, if we had a list that we could pull from a flap and then could
produce a tile that sums all the elements or have a 'collect' tile that
could be used to make a little script to add 15% to the values and populate
a new list... These morphs (or tweaks) could be embedded into a bookmorph
(booktweak?) and easily presented in an attractive manner. One could even
use the animation capabilities that etoys already has to create motivational
aids - a small drawing of an athlete who will reach the finishing line at
the other side of the screen if the numbers add up right (those numbers
could be your weight, the money you've earned, the amount of cigarettes
you've smoked..)
Anyway, I'm sure a lot of you have thought about the dynabook and about
adult etoys and fantasised about what it could do. I just worry, maybe
unjustly so that squeak is being developed by such competent programmers
that the needs or wants of people like me who aren't programmers or maybe
have it as a hobby gets overlooked. I think that an adult etoys environment
would be the killer app (environment or whatever you would call it) for
squeak.
Many thanks to all of you for such an amazing piece of software,
James

Hello all,
I feel compelled to add my point of view due to recent discussions on this
list; I have kept quiet for a long time as I'm not a professional programmer
and haven't contributed code so my point of view doesn't hold much weight
but I hope to be expressing a wish that other silent readers have - if not,
I'll quietly go away and see what other solutions can do for me.
First, some background: I was first introduced to computers as a child, on
Apple ][ machines at my father's work, on which I learned to program in
basic, making little games. I then progressed to a ZX81 at home and then a
spectrum, all of which there was an easy route into programming. I then
spent around 15 years without a computer and when I finally got a PC was
horrified - I had a computer which (out of the box) I couldn't use to
compute!
I have since dirtied my hands with all sorts of programming languages and it
took a long time before I stumbled over squeak. Squeak has been an amazing
and enlightening adventure for me but I have never really used it. The thing
that has kept me interested even though I don't use squeak (except to
explore squeak itself) is Alan Kay's dynabook vision. This is how I'd like
to use my computer (or even better, my pda.)
Now in the next part of this mail I'm going to say all sorts of things that
I'm sure many squeak developers will disagree with. I'm aware that squeak is
being pulled in several directions simultaneously and everyone has their
good reasons for doing so but I have to put my viewpoint across and deal
with the flames. If any of this sounds blunt or naive, I'm sorry.
There are many RAD ways of building native applications - wxPython, wxRuby,
wxPerl... You get the idea. I'm sure wxGNUSmalltalk would be possible. For
me, the beauty and the power of squeak is in the direct manipulation of
objects.
I would love to see Tweak in the main image. There is a lot of talk about
cleaning up morphic and the huge effort it would require. Would it not be a
better idea to spend that effort getting Tweak functional in the main image?
I'm sure there are many ways that the etoys environment and tile scripting
could be expanded upon to create more advanced programming possibilities for
the non-expert like myself.
One way in which this type of environment could be useful to the layperson
(and I have many more ideas which I'll save for a later date) would be the
types of things that people generally use (and abuse) spreadsheets for.
For example, if we had a list that we could pull from a flap and then could
produce a tile that sums all the elements or have a 'collect' tile that
could be used to make a little script to add 15% to the values and populate
a new list... These morphs (or tweaks) could be embedded into a bookmorph
(booktweak?) and easily presented in an attractive manner. One could even
use the animation capabilities that etoys already has to create motivational
aids - a small drawing of an athlete who will reach the finishing line at
the other side of the screen if the numbers add up right (those numbers
could be your weight, the money you've earned, the amount of cigarettes
you've smoked..)
Anyway, I'm sure a lot of you have thought about the dynabook and about
adult etoys and fantasised about what it could do. I just worry, maybe
unjustly so that squeak is being developed by such competent programmers
that the needs or wants of people like me who aren't programmers or maybe
have it as a hobby gets overlooked. I think that an adult etoys environment
would be the killer app (environment or whatever you would call it) for
squeak.
Many thanks to all of you for such an amazing piece of software,
James

Hehe, that happens sometimes.

Well, is there any place where we have a list of priorities of the
community?  If so, maybe we should give it a look and see if it still
reflects reality and what things we can knock off the list.

_________________________________________________________________
Invite your Hotmail contacts to join your friends list with Windows Live
Spaces
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

Hi all,

I disagree with native windows. One of the features of Squeak is get an image
and load it on any OS without changes with a proper vm. And I love this as
much as I love the Smalltalk/Squeak way to develop.

The thing could be change with the windows feel. More like a normal window but
with the squeak features.

As I said one day:
http://weeklysqueak.wordpress.com/2006/10/18/squeak-toy-or-instrument/

I'm founding my company, and talking with my girlfriend, I told her about make
my projects on smalltalk. She told me:

 "all the benefits if you use squeak are very good but, what happen with the
end-user? The end-user have fear about changes. You can make a ERP with
Squeak?" Yes I told it. "And looks like other apps?" No "Then will be very
difficult to sell"

I told her about XProgramming, OO benefits, blablabla all very beautiful but
as She saids,

"If you give an app to an end-user and this app don't looks like a normal app,
this end-user doesn't want it. He will not use the app because look strange."

I have the same opinion I expressed on October 2006. Is good if Squeak have a
different look, for the actual look exists SqueakLand with her own image. I
don't talk about gray apps (as Diego calls it). But a lot of widgets inside
the image, with a business look could be interesting.

Develop over squeak is fun, and this is important, but, the end-user doesn't
understand about develop fun. "He" wants work, not develop, and "he" don't
want "coloured windows" because disconcern it. I pay my bills thanks to the
app's I develop. If I can't sell my app's, then I can't pay my bills. I don't
like this way, but is the reality. The end-user is the boss, and you must do
your work as "he" wants, because "he" pay.

If you offer an app in Squeak, and other company offer the same app, but
developed over VB, .NET, Java etc.., he will choose the VB,.NET,Java project
because the other is strange and doesn't look an app.

Now, some people will be answer with "Komanche+Seaside=Web Interface" but, as
I said, (I think) the web interface is not the solution, not all the
end-users likes web interface to work (a point of sale on a supermarket for
example), and remember, "he" pay.

Is sad. All is around money, yes, but is the reality and, I think, all of us,
wants work with Squeak using it on commercial projects for our own benefit,
and not use it only on home to invest.

There are "solutions" (¿solution?) like wxSqueak, but seems not continued.

IMHO, If Squeak change the look&feel, could be the Smalltalk flavour thath
make shadow to VisualWorks. And we, the developers (and users), don't need a
pink debug window to fun developing.

Well, this is only my pesonal opinion (not the solution) about this (again).
My 2 cents.

El Sábado, 3 de Febrero de 2007 22:00, J J escribió:
--

Giuseppe Luigi Punzi - Consultor

       :: ZYO Consulting ::
 email: [hidden email]
  tlfno: +34 675 145 912
   web: http://www.zyoconsulting.com

Yep, if you want to move beyond the status quo and provide tools that
seem odd at first blush to users, it's going to be a tad tougher sell.
as always:

"It must be considered that there is nothing more difficult to carry
out, nor more doubtful of success, nor dangerous to handle, than to
initiate a new order of things. For the reformer has enemies in all
those who profit by the old order, and only lukewarm defenders in all
those who would profit by the new order, this lukewarmness arising
partly from fear of their adversaries, who have the laws in their favor;
and partly from the incredulity of mankind, who do not truly believe in
anything new until they have had actual experiences of it. Thus, it
arises that on every opportunity for attacking the reformer, his
opponents do so with the zeal of partisans, the others only defend him
half-heartedly, so that between them he runs great danger."

1513 AD Machiavelli


Giuseppe Luigi Punzi wrote:

--
brad fuller
www.bradfuller.com