How Do You Do Business Apps? (Squeak/Pro Proposal)

Stefan Matthias Aust sma at 3plus4.de
Sat Feb 26 10:51:21 UTC 2000


Paul,

>Thanks for the great followup.

You're welcome ;-)

>Excellent suggestion. I hinted at something like this in my suggestion
>(relating to being sued), but you put it much better.  We need a widget
>system (like Widgets/V or the later WindowBuilder/Pro from ObjectShare
>pre PPD) where the widgets work like Delphi or Visual Basic type
>widgets. You detail the needs very well in your untitled post to the
>list of 3:34PM today.

Yes, this is what I called pluggable widgets.  Self-contained entities, aka
parts, which can be composed, contructed and then connected with a model.
I think, both Delphi and VB don't feature the latter requirement.  The real
power of VisualWorks or Dolphin which have that connection feature is the
speed you achieve when creating non-trivial UIs.

I want not less than the same for Squeak.

I'd like to discuss these ideas with anybody who's interested.
Unfortunately I forgot to set a subject for that initial text when I copied
it into my email tool.  I'm sorry.

>I also have some ideas related to adapters with dynamic dependency paths
>which make it easy to connect GUI widgets to business logic. I developed
>(with some help from others) some fancy adapters for a big insurance
>company for VisualWorks, but I don't own the rights to it or even have a
>copy. So I'd have to reinvent something like that or get them to let me
>use that code, or find something similar somewhere.

I did something like this twice for different customers so I've a pretty
detailed understanding of how I'd do it a third time :-)

>> Installation is pretty easy and could be even easier if we'd use tools like
>> InstallShield (or similar quasi-standard tools for other platforms) or have
>> a self-installing Squeak eventually.
>
>Self installing? Neat idea! This might need a compressed image somehow. 

I think Andrew C Green was working on something like this.  A couple of
months ago, I did some experiments and at least on Windows, creating a VM
with an attached image that will be automatically extracted, uncompressed
and run was promising.  Actually, you could add any number of files to my
SQAR (squeak archive) format.  But it was just a throw-away prototype.

>> Deployment, I agree, is still very difficult and it borders to magic (a
>> saying that at least in German makes sense) to strip an image in an optimal
>> way.
>
>That might be easier if we built up and didn't need an image stripper.
>Also, I'm assuming you would always ship the compiler.

I think we eventually need both.  It's already a big advantage if you can
leave out whole packages for development as this omits the danger of
refering to functionality that might be unavailable later.  So if you can
compose your development image from packages, this is an advantage.

Still, even packages might be too big and parts of that packages aren't
needed for your application.  Delphi, I think, is able to include only the
used methods of pascal units, removing all unneeded code.  Because of the
dynamic aspects of Smalltalk, you cannot as easily remove Smalltalk
methods, but with some careful planning and hints from the developer, an
image stripper can do amaizing things.   

The image should be however written in a way that there're only a few
global references.

>But, I think command line / scripting Squeak needs a smaller image that
>loads extra functionality on demand, like Python. I think both could
>work together -- especially if there was a good export facility.

Yepp.  Perhaps the on-demand-loading of ImageSegments is the answer here...

>Still, I'd be happy to discuss collaboration further, especially if we
>could turn this into a two month project instead of four months, or add
>key missing pieces like database support.

So the question is, would anybody want to pay for development on Squeak?
What's about companies like RedHat that probably swim in money like that
uncle of Donald Duck (Dagobert he's call in Germany)?  Are there other
companies willing to invest into promising open source projects?

I actually talked with my boss about that issue and provided that we (that
is www.baltic-online.de) have the time and could affort it (unfortunately,
we couldn't work for $5000 per month) could put in up to for Smalltalk
developers. So if anybody want's to spend a million or two, just call us ;-)

>> I'd prefer if I could use MS TTF fonts on Windows.  I *hate* the poor
>> quality of X fonts (at least as configured as at work).  Loading of other
>> TTFs would be nice as I'm a fontaholic.
>
>OK. I'm not sure what it would take. Also, there may be a legal issue
>with importing fonts into an image and then saving that image.

I hope that eventually the graphics operations are abstracted in way that
would allow a primitive to directly display true type (or other host fonts)
as a fast and good looking alternative to Squeak's own fonts.

In the meantime, it might be possible to use the free TeX fonts.  I didn't
had the time to look at them yet so I can't comment but at least the legal
problems seems to be solved here.

Aa alternative would of course be to ask a font designer, for example Ray
Larabie who's very creative and who offers already more than 200 free
fonts, to create a clean and easy to read Squeak font.

>OK. It is just I'd feel safer distributing an image I was planning on
>supporting if I knew everything that was in it -- because I could look
>at the textual representation used to generate the image.

Hm, so simple file out all classes and you also got that textual
description ;-)  Okay, okay, of course you'd have to do a lot of more if
you want to load that source code again.

>> I'd change maybe to definitely.  At least things like #resize should be
>> passed to the Squeak system so that you don't need to manually call
>> "restore screen".
>
>Good point on the #resize. I was thinking more of mouse / button events.
>But you raise a larger issue of general windows event handling.

Yes, system-level events (like resizes, color changes, etc) and
application-level events (like mouse clicks and keyboard)

Once, you're event driven, I hope it's only a small step towards multiple
Squeak screens which could then play the role of host windows or - thinking
about collaborate environments - distributed to different computers.

>ODBC or other database support sure would be nice, I agree. Perhaps it
>is even essential. (See your thread on database support -- did you get
>MySQL going with Squeak?) It's just a question of time. Some form of

Yes, I got it.  But I never tried so far and just looked at the code.  At
the moment I'm still lobbying for our (that is www.baltic-online.de) first
Squeak project.  This this, I was collecting the needed technologies and
tried to figure out whether it would be possible to use them at all.  As
our main reason for Squeak is application size (compared to a complete Java
installation) and development speed, we need to be sure (if you could at
all) that we will reach our requirements.


bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf.





More information about the Squeak-dev mailing list