Discussion:
Ship it with Squeak
(too old to reply)
Alan Kay
2012-01-28 09:59:46 UTC
Permalink
Henrik --
Alan Kay>> Most of the next billion machines are not going to be
either Macs or PCs
..... but will certainly be connected to Internet.
I also hope that convergence/ubiquitous computing etc. really will happen,
and throw everything over as the personal computers did--but I see many
reasons why this won't happen; too many I think.
I wasn't thinking of convergence, except as below ...
At least not for a long
time--the PDAs and friends are still not nearly useful enough, for example.
What timeframe do you expect this to happen in? A billion computers implies
a rather long time.
Not really. Many of the next generation of mobile phones will have
StrongARM or equivalent chips, reasonable displays, and will be
connectable to the net. Settop boxes, PDAs, etc. This is all going to
happen in a rush, in the next few years. What convergence there is
will exist at the phone and TCP/IP levels (and, of course, there is
Squeak that can run on all)...
Well, Squeak is a client for its own media -- and this is what I'm
most interested in -- you may have noticed that we can now "publish"
whole projects, which can serve as a more active and media basis for
representing ideas than simplistic html pages. We will release a
bunch of these by the end of the summer.
Given these ambitions, I am surprised that there appear to be no ambitions
to addressing the usability of the stuff inside Squeak, and make it
accessible for 'real people', as in accessible to those without a major in
Smalltalk.
"Appearences can be deceiving". The route we are taking may seem odd,
but there are reasons (many of them rational) for taking a more
hacker's route, not the least is that we need serious wide & deep
functionality to hang our eventual UIs on (I think many people on the
list realize that the present UI (er, UIs) is just a placeholder for
a near future more uniform and richer scheme for the "omniuser").

Cheers,

Alan
Stefan Matthias Aust
2012-01-28 10:00:21 UTC
Permalink
Post by Alan Kay
Henrik --
Alan Kay>> Most of the next billion machines are not going to be either
Macs or PCs
..... but will certainly be connected to Internet.
Actually, I'd be more pessimistic and say that if Microsoft doesn't make
big mistakes, Windows will continue to stay for a long time. And there're
millions of PCs out there.

Of course perhaps even more new non-Windows-PC computers will hit the
market but targeting only them, is like ignoring the present and hoping for
the future.

IMHO, Squeak shouldn't ignore current, conventional machines and, I think
this was where this argument came from, therefore needs a conventional UI, too.
Post by Alan Kay
Not really. Many of the next generation of mobile phones will have
StrongARM or equivalent chips, reasonable displays, and will be
connectable to the net. Settop boxes, PDAs, etc.
And they all will run Java ;-) And Windows CE, oder PalmOS - replacing one
monopol with another doesn't help...
Post by Alan Kay
eventual UIs on (I think many people on the list realize that the present
UI (er, UIs) is just a placeholder for a near future more uniform and
richer scheme for the "omniuser").
Do you have more details on that new near future UI?

bye
--
Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf
Tim Rowledge
2012-01-28 10:47:17 UTC
Permalink
Post by Stefan Matthias Aust
Post by Alan Kay
Not really. Many of the next generation of mobile phones will have
StrongARM or equivalent chips, reasonable displays, and will be
connectable to the net. Settop boxes, PDAs, etc.
And they all will run Java ;-) And Windows CE, oder PalmOS - replacing one
monopol with another doesn't help...
Actually there is a good chance that a high proportion of them will run
EPOC32, and many ofthe rest NintendoOS/SegaOS/PlatstationOS/whatever.
--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: IML: Invoke Murphy's Laws
Lex Spoon
2012-01-28 10:00:27 UTC
Permalink
Does this sound like the beginnings of an approach that would produce a
stable version of Squeak for commercial apps and utilities, with no
money changing hands, and without posing a big threat to the beautiful
thing that is the Squeak community?
A fork is likely to happen at some point. However, several things on
your list are *not* going to be done soon by Squeak Central, but could
be done without forking:

1. Making more standard widgits, including better layout widgits.

2. Making a GUI builder based on them.

3. Working out platform-issues with deployment. It only needs to be
done once for each platform, and then everyone can benefit. It's also
not an incredibly big task.

4. Replacing the fonts. Again not a big task--can someone download one
of these free fonts sometime and make a changeset that installs them?
This issue is ridiculous!


Incidentally, image stripping doesn't necesasrily require any fancy
tools or system-wide rewrites. All it really takes is people updating
the various remove* methods, plus occassionaly removing any dependencies
between "modules" that shouldn't be there. The Linux kernel might be
used an as example here: it has well over 100 "modules", but the
dividing lines aren't on any sort of module system. Each removable
module is just written carefully so that the kernel will still build
with any reasonable group of settings. (Obviously, removing networking
and then trying to build TCP/IP support is not going to work very well).


Anyway, this is a wonderful post, Paul! It really gets to the issues
without being silly.



-Lex
Alan Kay
2012-01-28 10:00:30 UTC
Permalink
Hi Jon --

We REALLY NEED THIS!

Please let me know if I need to talk to anyone from the former
Interval to clear this ....

It actually should be public domain by now anyway.

What do you think, Tim?

Cheers,

Alan

------
On Wed, 28 Jun 2000 18:50:58 -0400 (EDT), Bijan Parsia
http://www.huv.com/smalltalk/browser.html
*Now*! :)
Coming... :-)
Tim, what was the status of the software when you left Interval? Is the
browser code PD for sure?
Later,
Jon
--------------------------------------------------------------
Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
http://www.huv.com
Jecel Assumpcao Jr
2012-01-28 10:11:58 UTC
Permalink
One thing I'd like to do is start up a discussion about what direction we
should go with this. I assume it would be nice to use Morphs to represent
the actual page layout elements. Does anyone have any great (or
not-so-great) thoughts on this subject?
My favorite web browser is the quick and dirty one David Ungar wrote in
Self using morphs back in 1995. As you might imagine from that date, it
doesn't have tables, frames, background images and so on. It used
morphic buttons for links, for example. I really liked the way the page
would grow as the html was read in - IE has since added this feature
and it is the thing I miss most in Netscape.

Unfortunately this doesn't run in the Mac version of Self, but if you
have a Sparc I would suggest you take a look at this.

-- Jecel
Jon Hylands
2012-01-28 10:25:25 UTC
Permalink
Post by Alan Kay
Hi Jon --
We REALLY NEED THIS!
Okay, Alan, you're convincing me :-)

While we're waiting to hear from Tim, I can talk about some of the stuff in
the browser...

It handles tables, and images, although of course it doesn't do a perfect
job or anything. It doesn't do JavaScript, or frames, although I suspect
adding frames would be fairly simple. It has an internal PlugIn
architecture, so external viewers and such can be configured for it. If I
remember correctly, internal images (JPEG & GIF) are also handled using
PlugIns.

One of the nastiest things in the whole browser is the
"parse-tree-fixer-upper". The people who wrote Netscape and IE should be
taken out against a wall and shot, for allowing such bad HTML to work okay
:-)

Something like 75% of my effort in writing this browser was figuring out
clever ways to fix the parse tree to form "correct" HTML, so it could
actually lay out pages properly.

It also loads images in background tasks, and can suspect loading all those
images when you click on another link. It does not use any sub-views in the
window to display anything -- everything is layed out on a singe graphical
view.

One warning -- this sucker is big... 500 K of source code right now. I've
started working on the port to Squeak 2.7, and have the HTML parser and all
the parse nodes ported (which of course was the easy part).

It would definitely be cool to see this as a big group effort, to make a
better browser.

One thing I'd like to do is start up a discussion about what direction we
should go with this. I assume it would be nice to use Morphs to represent
the actual page layout elements. Does anyone have any great (or
not-so-great) thoughts on this subject?

Do we have JPEG file readers available? We used (at Interval) a custom
image library that was added to the VM, and handled JPEG, GIF, and MPEG
(yes, there's a video plug-in...)

The link to the screenshots (which I took over 2 years ago) is at
http://www.huv.com/smalltalk , for those who missed the first posting.

Later,
Jon

--------------------------------------------------------------
Jon Hylands ***@huv.com http://www.huv.com/jon

Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
http://www.huv.com
Henrik Gedenryd
2012-01-28 10:01:03 UTC
Permalink
* Making Squeak event driven at the VM level to eliminate those
occasional weird mouse drags
Working on it. It's a _lot_ more than VM level work. Many bits of code
use messages like anyButtonPressed or shiftDown etc which are really
un-event driven ideas.
But they are really, really needed to make a good interface, so they must be
provided. Actually, it is up to the user event handler whether to poll the
hardware or look at the state of the last received event. But it must also
be possible to look for things that don't generate events, like whether
shift is down, or a regular key is down. It is particularly necessary to use
regular keys as modifiers since the usual modifier keys are taken by mouse
button emulation.

What I would like to see, if you are already digging there ;-), is that all
the input-related messages were tied to the HandMorph, eg. anyButtonPressed
and friends, including keyboard messages. This will have obvious benefits
also for remote Morphic.

Henrik
Tim Rowledge
2012-01-28 10:01:10 UTC
Permalink
Tim, what was the status of the software when you left Interval? Is the
browser code PD for sure?
The IP commitee gave us the ok to share anything except that directly
related to the proprietary details of the AvioDigital MediaWire stuff.
Since the webbrowser is quite unrelated to any such details I can't see
it being restricted in any way. Besides, Jon is going to rewrite the
display stuff to use morphic, will want to replace most of the layout
code to take advantage of hindsight and so it won't really have much to
do with interval anyway, will it?

tim
--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Fractured Idiom:- MONAGE A TROIS - I am three years old
Paul Fernhout
2012-01-28 10:01:29 UTC
Permalink
Andrew-

I appreciate your comments on experience with Python/TK vs. Squeak
(especially on the Mac).

I think the issues you raise in regards to cross-platform GUI are right
on, and a major reasaons I am interested in Squeak over Python. Squeak
has a better philosophy -- just put up a bitmap and let Squeak do
whatever it wants with it -- whereas Python tries to interface with
native widgets or widgets produced by TK or wxWindows or whatever other
library. I agree that Python lacks a cross-platform GUI (although
wxWindows is nice) -- although I do think that for purposes of text
processing, file manipulation, and simple internet utilities Python is
often a good cross-platform choice.

However, I think it is possible the internals of TCL event loop
implementation could perhaps be "borrowed" without having to pull in the
other problematical features. We're only talking a few hundred lines of
C code here at most I think. I believe it likely that many of the issues
you raise have more to do with TK cross-platform problems or issues with
the Python/TK interface than issues with TCL event handling itself. It
is my understanding that raw TCL on the Mac is pretty stable, even if TK
support is rough.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com
Right you are. The Tk/Tcl event model is nicely done, and cross platform
as well. The code is freely available under a BSD license. Even if you
don't "steal" it, it certainly serves as a good source of inspiration.
It seems to me that Tk/Tcl style events could readily be adapted to Squeak,
serving as a fairly general external event system and making things like
AsyncFile unnecessary.
Its been a little over a year, maybe two, since I worked in
Python/Tkinter, and I can freely say that it was nothing less than
squirrelly on MacOS. There was almost no uniformity from platform to
platform, and performance was abysmal. I had a serious application I
was trying to press through in Python for several months, with only
nominal success. (Frequent memory leaks -- periodic random crashes
-- undebuggable freezes -- the works -- all in a putative OODL!)
Indeed, that was when I met Squeak at a Hacker's conference -- Ted
Kaehler demoed it, and I had the entire app (a multimedia game)
within three weeks, running pixel for pixel identically across MacOS,
Unix and Windows. (I wrote it in Windows at my office, but delivered
it on my wife's iMac for her birthday).
The process was flawless, debugging information amazing, and I fell in love.
You can have Python/Tkinter -- I trust it got much better since the
mess with which I was working -- but the Smalltalk environment was
just fine for my purposes.
Admittedly, the expectations of UI uniformity for games are
substantially less than for other systems, but I was nothing less
than thrilled with the flexibility of Squeak for simultaneous
on-the-metal and abstract-from-the-universe coding.
--
V.P. Eng., R&D, 813.885.2779 (office)
Netwolves Corporation 813.885.2380 (facsimile)
www.netwolves.com
Alan Kay
2012-01-28 10:02:16 UTC
Permalink
Just a suggestion ...

Forget about the Mac or the PC, and concentrate on an Internet
Interface. These have to be universal, and the current (mostly) html
ones are pretty rudimentary. This is fresh ground for new ideas. Most
of the next billion machines are not going to be either Macs or PCs
.... but will certainly be connected to Internet.

Cheers,

Alan

-----
G'day,
I have a lot of trouble thinking about the idea of a business
interface for squeak.
I use Macs and when people talk about business applications and
computers for business, they mean pc's (at least here in Australia).
I can tell you from experience that people using machines on one
platform will not accept an application running on their machine
that looks and runs like an other platform (Mac, Unix, pc, whatever).
This is my understanding of why VisualWorks never really took off in
the business area (that and the high costs to purchase) - they came
very close to emulating, for example, the Mac ui, but not acceptably
close enough.
- Do you succumb to a particular platform and just make it for that
one, shutting out all the others, like Dolphin and VisualSmalltalk?
- Do you try to be everything for everybody, doing nothing
perfectly, like VisualWorks?
***
The thing that I'm starting to understand about Squeak is that its
real advantage is in that it doesn't look like anything else! You
can't complain that it's too Mac like or too windows like if it
looks like neither!
I have a suspicion that building a standard UI for Squeak might be
the death of it.
***
The only thing that I can think that might work would be to specify
an interface/protocol simple enough to be usable across all the
currently deployed platforms and then build a native UI for each
platform, just like happens with FileDirectory now.
For example, you could have an abstract text entry field with a
specific protocol that could then be implemented across the
different platforms. The actual widgets could even be rendered
natively.
The trouble would be in handling specific platform requirements,
like the single menu bar on the Mac.
...
Karl
Henrik Gedenryd
2012-01-28 10:05:27 UTC
Permalink
I don't have any fonts. I know there was a discussion of Public Domain
fonts on the list a long while back. To my knowledge, at least some of
the fonts in Squeak are still the original Apple ones. Can anyone who
knows confirm this? What the story on the true-type fonts in Morphic?
According to (at least American) copyright law, bitmap fonts are
"renderings" (I'm not a lawyer) and are therefore _not_ copyrightable. I
think the Apple lawyers were a little bit "optimistic" when they claimed
copyright to those bitmaps. If you want to switch, eg. MS provides some
rather good "free" screen fonts (Verdana et al, but read the legal
fineprint). There are loads of free ones on the net, but they are pretty bad
to 99%.

As far as antialiased fonts go, the patent-free version of FreeType is still
pending. However, it is only needed for _creating_ the bitmaps--these can be
used entirely without the FreeType plugin. Hence the answers to these two
are "no" and "no need to worry"--it's all in the image, and you, the
developer, put it there.
Are they loaded from the OS? Can I assume people have them?
See the Swiki for a preliminary version and some fonts done with that (the
version there doesn't work in 2.8 after all the various reworking done by
Andreas, but I have a fix myself).

BTW, deploying multimedia with Squeak is a great idea since it makes the
"native look & feel" issue moot (if done with a little care).

Henrik
Stefan Matthias Aust
2012-01-28 10:08:50 UTC
Permalink
Any hope of making these X11 fonts part of the standard 2.8 release and
completely replacing the Apple fonts?
Not for 2.8 as it's feature-frozen (I hope). There might be a change for
2.9 - I can't decide this. I know however that SqC already mentioned that
they're looking for some way to replace the apple fonts.

BTW, as I understand the license of Microsoft's core web fonts (Arial,
Verdana, etc) which are freely available, you're not even allowed to supply
the bitmap. You could however let every user generate automatically his
own strike font from the installed fonts and request the user to install
these fonts. As truetype fonts are kind of standard and should work on
Mac/Unix (at least with a decent font server)/Windows, a few FFI calls per
platform might be enough.

This would be the way I'd go. On platforms which natively support TTF
(Mac/Windows), there're absolutely no problems by using that support. If
the Linux user wants to use freetype to have a ttf font server isn't my
problem.

bye
--
Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf
Alan Kay
2012-01-28 10:09:39 UTC
Permalink
Marcel --
Post by Alan Kay
Just a suggestion ...
Forget about the Mac or the PC, and concentrate on an Internet
Interface. These have to be universal, and the current (mostly) html
ones are pretty rudimentary. This is fresh ground for new ideas. Most
of the next billion machines are not going to be either Macs or PCs
..... but will certainly be connected to Internet.
I am not sure how this helps. Either you have xml/html/style
interfaces and rely on the 'universal client'. This is an
interesting area because it allows mixing of documents and multiple
presentations of an underlying data-source. However, forget about
morphic. Interaction, if possible at all, will only be through
standardized mechanisms such as event/scripting enabled SVG/XHTML,
which essentially means JavaScript.
The other option is downloading your own client and executing there.
Apart from the fact that I don't necessarily find this desirable,
you will have the same problem as before, that each platform will
have local interface conventions that you need to follow if you are
executing locally.
What am I missing?
Well, Squeak is a client for its own media -- and this is what I'm
most interested in -- you may have noticed that we can now "publish"
whole projects, which can serve as a more active and media basis for
representing ideas than simplistic html pages. We will release a
bunch of these by the end of the summer. I think Squeak is a little
more powerful than JavaScript ... Also, Squeak always has "authoring
turned on" so it opens vistas of "SuperSwikis" of active media that
can be added to, etc.

... and there are a variety of ways to deal with the existing web conventions.

I think the basic difference in point of view is that I don't see the
existing OS's and web as being anything more than bad defacto
standards that positively invite us to produce better alternatives
... I certainly don't see them as anything that has to be catered to
...

Cheers,

Alan
Giovanni Giorgi
2012-01-28 10:20:20 UTC
Permalink
[...]
Well, Squeak is a client for its own media -- and this is what I'm
most interested in -- you may have noticed that we can now "publish"
whole projects, which can serve as a more active and media basis for
representing ideas than simplistic html pages. We will release a
bunch of these by the end of the summer. I think Squeak is a little
more powerful than JavaScript ... Also, Squeak always has "authoring
turned on" so it opens vistas of "SuperSwikis" of active media that
can be added to, etc.
... and there are a variety of ways to deal with the existing web conventions.
I think the basic difference in point of view is that I don't see the
existing OS's and web as being anything more than bad defacto
standards that positively invite us to produce better alternatives
... I certainly don't see them as anything that has to be catered to
A look to the future (I will try to..."invent" it...:-)
In few years, we will have Nintendo GameBoy and Playstations connecting to the
Internet, and your powerful boring PC alone in the home (ok, the Mac will be on
the center of the table but powered off:-)
Or we will use a GSM telephone with a powerful Internet Access.

So we need of stronger infrastructure on the Internet.
XML is good, but it carry only passive data (for the moment).
Squeak is a lot nicer, think: you can setup a Image with a Swiki Server running
on it,
you can browse the swiki pages, create swiki section on fly using some Squeak
programs, download code updates and so on.
Then you can download and convert emails in swiki web pages and doing some
strict data integration.
Lotus domino do a similar thing, but Squeak has the power to do it and more.
And...no a single line of C code you will see (ok, you will generate some
pluging in C language.:).
This is fantastic, and you are using ONLY Smalltalk!!!
A simple, plain image with a lot of ***protocol*** glued together.
Are the Protocol Interfaces the key? Or must we look for something else?
We must look at a language? Java?
I have used Java for some time, and I do not know if with Java all the things I
can do in Squeak would be easier and so integrated...what do you think?
--
// Giovanni "Daitan" Giorgi
// Assibit S.r.l.
// http://www.geocities.com/~giorgi_g/
//mailto: ***@geocities.com GSM: +39-(0)347-30-76-419
Georg Gollmann
2012-01-28 10:11:26 UTC
Permalink
2) Deployment onto limited-memory computers. I'm still aware of
organisations where 32Mbyte P200s are unusually high-spec. They're
typically not going to want to sit 100 Mbytes of Squeak app on those
desktops, especially as Squeak's locality of reference and hence its paging
behaviour is typically poor.
Really ?
I find the Squeak GC is quite virtual memory friendly. Running a 1 GB
image on a P100 Linux box was no problem at all. Naturally if your
application constantly walks the whole dataset you are in trouble.
But then any system will be slow.

Of course there are situations where Squeak is not adequate, but I
see a tendency to shoot with cannons at sparrows. And then we have
discussions about code bloat...

Keep It Simple
Georg
--
----
Dipl.Ing. Georg Gollmann TU-Wien, Zentraler Informatikdienst
Wiedner Hauptstr. 8-10
phon:(+43-1) 58801 - 42022 A-1040 Wien
fax: (+43-1) 58801 - 42099
mail:***@zid.tuwien.ac.at
http://macos.tuwien.ac.at/Gollmann.html
Lex Spoon
2012-01-28 10:12:10 UTC
Permalink
Post by Henrik Gedenryd
But they are really, really needed to make a good interface, so they must be
provided. Actually, it is up to the user event handler whether to poll the
hardware or look at the state of the last received event. But it must also
be possible to look for things that don't generate events, like whether
shift is down, or a regular key is down. It is particularly necessary to use
regular keys as modifiers since the usual modifier keys are taken by mouse
button emulation.
MorphicEvents contain a bitmap of what modifiers were pressed during the
event. But like Tim said, a lot of existing code queries Sensor
directly instead of looking at the Event object.



-Lex
Stephan Rudlof
2012-01-28 10:13:04 UTC
Permalink
Hmm, one problem here - this matches the sqfixes archive procmail regex
^Subject: \[.*(FIX|ENH|ADD|ANN|GOOD|HACK).*\]
Any idea on improving this reg ex? It must, for example, match
"[BUG][FIX]" but not "Re: [FIX]".
-- Bert
- I don't understand the joke here.
It was no joke.
- If there is no joke: Don't you already have the searched reg ex?
The above is the current regex. It unfortunately matches a [CANNOT]
tag. It should only match [ANN] or [ANNOUNCE]. I could of course remove
the ANN. But there are other problems as well, like the
"[BUG] Re: [FIX]" case. I'm not exactly a regex buff.
So my question is: Can anybody come up with a regular expression that
matches all of
Subject: [ANN] ...
Subject: [BUG] [ANN] ....
but none of
Subject: Re: [ANN] ...
Subject: [BUG] Re: [ANN] ....
Subject: [CANNOT] ...
were ANN should also allow any of FIX, ENH, ADD, ANN, GOOD, HACK
to allow [FIX], [ENHANCEMENT], [ADDON], [ADD-ON], [GOODIE] ...
-- Bert
A first idea (not tested, and there are som variants of reg ex'es):
grep
with
^Subject: (\[BUG\])?(\[(FIX|ENH|ADD|ANN|GOOD|HACK|ADDON|ADD-ON)\])+
and then
grep --revertMatch
with
[RE:|Re:|re]
.

Greetings,

Stephan
--
Stephan Rudlof (***@evolgo.de)
"Genius doesn't work on an assembly line basis.
You can't simply say, 'Today I will be brilliant.'"
-- Kirk, "The Ultimate Computer", stardate 4731.3
Stephane Ducasse
2012-01-28 10:13:54 UTC
Permalink
Hi jon

your browser looks really great. I really hope that we will be able to
play with it soon.

I was wondering if you could tell us what were the motivations
of writing it in Squeak for Interval. Were people
thinking to make money with it? What were the plans?
This is always interesting to see what other people dream
in using squeak.

Stef
Post by Alan Kay
Hi Jon --
We REALLY NEED THIS!
Okay, Alan, you're convincing me :-)
While we're waiting to hear from Tim, I can talk about some of the stuff in
the browser...
It handles tables, and images, although of course it doesn't do a perfect
job or anything. It doesn't do JavaScript, or frames, although I suspect
adding frames would be fairly simple. It has an internal PlugIn
architecture, so external viewers and such can be configured for it. If I
remember correctly, internal images (JPEG & GIF) are also handled using
PlugIns.
One of the nastiest things in the whole browser is the
"parse-tree-fixer-upper". The people who wrote Netscape and IE should be
taken out against a wall and shot, for allowing such bad HTML to work okay
:-)
Something like 75% of my effort in writing this browser was figuring out
clever ways to fix the parse tree to form "correct" HTML, so it could
actually lay out pages properly.
It also loads images in background tasks, and can suspect loading all those
images when you click on another link. It does not use any sub-views in the
window to display anything -- everything is layed out on a singe graphical
view.
One warning -- this sucker is big... 500 K of source code right now. I've
started working on the port to Squeak 2.7, and have the HTML parser and all
the parse nodes ported (which of course was the easy part).
It would definitely be cool to see this as a big group effort, to make a
better browser.
One thing I'd like to do is start up a discussion about what direction we
should go with this. I assume it would be nice to use Morphs to represent
the actual page layout elements. Does anyone have any great (or
not-so-great) thoughts on this subject?
Do we have JPEG file readers available? We used (at Interval) a custom
image library that was added to the VM, and handled JPEG, GIF, and MPEG
(yes, there's a video plug-in...)
The link to the screenshots (which I took over 2 years ago) is at
http://www.huv.com/smalltalk , for those who missed the first posting.
Later,
Jon
--------------------------------------------------------------
Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
http://www.huv.com
Stephane DUCASSE (***@iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/
"if you knew today was your last day on earth, what would you do
different? ... especially if, by doing something different, today
might not be your last day on earth" Calvin&Hobbes

University of Bern, Institut fuer informatik and Mathematik
IAM-SCG, 10 neubruckstrasse, CH-3012 Bern, Switzerland.
Stephan Rudlof
2012-01-28 10:16:18 UTC
Permalink
For completness sake we also need the [CANTOO] tag as well, with
the obvious results above ...
;-)
I think it's time for a new message tag. If everyone who asserted
that "Squeak cannot ..." would add the tag "[CANNOT]" to their message
subject, we could have fun tallying up the hits and misses. ;-)
Hmm, one problem here - this matches the sqfixes archive procmail regex
^Subject: \[.*(FIX|ENH|ADD|ANN|GOOD|HACK).*\]
Any idea on improving this reg ex? It must, for example, match
"[BUG][FIX]" but not "Re: [FIX]".
-- Bert
- I don't understand the joke here.
- If there is no joke: Don't you already have the searched reg ex?

Greetings,

Stephan
--
Stephan Rudlof (***@evolgo.de)
"Genius doesn't work on an assembly line basis.
You can't simply say, 'Today I will be brilliant.'"
-- Kirk, "The Ultimate Computer", stardate 4731.3
Marcel Weiher
2012-01-28 10:18:07 UTC
Permalink
To make real progress, everyone should be thinking much longer, on
a much
higher level. HTML (and everything else about the web) is/will be
the MS-DOS
of the next two decades--it will dominate, will not be abandoned
so that
huge efforts will be spent on compatibility backwards, it will
represent the
worst possible solution to the problems it addresses, and hold
back progress
to an immense degree. XML (et al)? Jeez, it's just one of the
first hacks to
remedy these things, within the original boundaries.
Sorry, I disagree vehemently with this rant, er, analysis. HTML is
an *excellent* solution to the problem it address, because it is so
simple that it actually works (put that last clause in bold, italic,
caps, with three underlines and exclamation marks). Mind you, it is
not a good solution for some of the things people are forcing it to
do, like precise layout -> ouch!

XML is the only hope for reprieve from the tyranny of proprietary,
opaque and fragile data formats. It also makes heterogenous
interoperability a real possibility, by making it *easy*.
Furthermore, it combines the worlds of UNIX (everything is a text
file) and objects (everything is an object). Each world brings with
it a very powerful and composable abstractions, but so far they've
had a heck of time dealing with each other. It also has the power to
free us from the grip of (relational) databases for structured data,
by both being a viable alternative and interoperable.
Post by Alan Kay
I think Squeak is a little
more powerful than JavaScript ... Also, Squeak always has "authoring
turned on" so it opens vistas of "SuperSwikis" of active media that
can be added to, etc.
There is no doubt (at least in my mind) that Squeak is more powerful
than JavaScript. However, that becomes irrelevant if the
specification says JavaScript. A Squeak script that won't be
executed is of limited usefulness. Of course, I personally think
JavaScript is a curse, because most of the things it 'dynamicizes' do
not gain by being dynamic. Most information does just fine in a
static representation, and I don't need dancing paper-clips to cheer
me up...
Post by Alan Kay
.... and there are a variety of ways to deal with the existing web
conventions.
HTML, XML, JavaScript, DHTML, BLAHABLAHATML, yadda yadda yadda.
The best way
to predict the future is to ignore them :)
Ignore HTML and especially XML only at your own peril!
The advent of the web and these dinosaur technologies is a disaster.
It is a democratic upheaval with some blood-letting.
Ten years ago we were using our computers to do productive work.
Now we're back to making them work again.
Sorry, the only difference I see is that nowadays designers think
they want to know what all that is, because it is "cool".
Then, courses would teach people Quark XPress and
then about kerning, typefaces, point sizes, ligatures, and so on--real
useful skills and knowledge for graphic designers.
Quark XPress is not a useful skill. I consider Quark a part of the
problem set, not the solution. Proprietary file-format, vendor
lock-in, monolithic, buggy apps, silly "plug-in" architectures that
are just another mechanism for vendor lock-in etc.

Now if there were a vendor-independent, usable language for
specifying layout, typography and design...and no, neither TeX nor
Postscript fit the bill. Maybe you could even create an XML-based
language for that purpose, though I don't think the FO-part of XSL is
really what's needed either. Of course, if it is XML-based, you'd
probably want an equivalent more human-accessible version as well.
Today they're having to
teach them Unix file system syntax and image representation
formats so that
people can put images in their documents, which used to be done by
cut &
paste back then.
What's stopping them from using GUI HTML builders with cut-paste
image placement for their HTML work? Why didn't they hand-code
Postscript before? Answer: because hand-coding Postscript is so much
more difficult than hand-coding HTML that they never would have
dared. You're comparing apples with oranges.
It's essentially a counterrevolution of the techies.
Partly. Geeky/techie things have suddenly become "cool", so "cool"
people try to do stuff that they really have no clue about when there
are better ways to accomplish the same thing (for example letting a
real techie do it in 1/10th the time).
Notice that Linux, the great "new" thing formerly known as Unix,
is 30+ years old,

Yes, I am also somewhat underwhelmed by Linux, though if that's what
it takes to spread an at least partially decent OS, oh well...
HTML is a much poorer version of the 35 years old SGML,
This is actually incorrect. HTML is an application of SGML, not a
"poorer version", exactly the sort of thing SGML was invented for.
To make real progress the existing stuff needs to be abandoned--so this
won't happen. Backward compatibility is the best way to hinder genuine
progress.
Numb-minded backwards compatiblity, yes. Standards are a way of
achieving *compatibility* instead of *backwards compatibility*.
Open, extensible standards like XML (and many of the languages that
have been defined with XML) allow you to use the standard for those
90% of things that don't require more, and still do what you want by
extending where necessary, in a controlled fashion.

This is vastly different from closed backwards compatibility
enforced by MS-DOS or Java "industry standards". These typically
preclude innovation.
Watching the tape of what Engelbart had on a real, working system
in '68,
makes you cry a few tears, seeing things that won't be in real use
in the
next 10 or 20 years, easily.
Well, let's get to work on it, although I have to admit that I
myself am closer to Sketchpad...

Marcel
Bert Freudenberg
2012-01-28 10:19:14 UTC
Permalink
Post by Stephan Rudlof
grep
with
^Subject: (\[BUG\])?(\[(FIX|ENH|ADD|ANN|GOOD|HACK|ADDON|ADD-ON)\])+
This looks good and ...
Post by Stephan Rudlof
and then
grep --revertMatch
with
[RE:|Re:|re]
.
makes this one unnecessary. I don't care if a re: is in the line, a
"[FIX] Re: [BUG]" should be accepted, but "Re: [FIX]" not.

I'll try this one:
^Subject: (\[BUG\])?\[(FIX|ENH|ADD|ANN|GOOD|HACK).*\]

which requires either of FIX|ENH|ADD|ANN|GOOD|HACK to be first on the
line, optionally preceded by [BUG].

Thanks!

-- Bert
Bob Arning
2012-01-28 10:21:38 UTC
Permalink
Hi Paul,
* Having reliable VMs for Linux (which?), Windows (NT, 2000, 95, 98),
and Mac (PPC, Which OS Revs?)
As far as the Mac goes, I haven't seen a difference here or on the list between any of the recent OS versions.
* Replacing the fonts (to meet license obligations)
Fonts are simple bitmaps. If you have others that you feel free to use, the changes are not significant.
I think Squeak would need significant work to get it into shape for
shipping "shrink-wrap" quality applications. I would like to do this
without forking Squeak, but I don't know if this is possible. I think it
would require maintaining a seperate line of development for a while.
I'm not sure the notion of forking Squeak is a necessary one. For a projct of the timescale (4 months) you have mentioned, I would envision this approach:

1. Select a reasonably stable starting point (release 2.8 if you were to do it today, e.g.). You would be unlikely to change compilers or libraries in the midst of such a short project. Consider Squeak in the same light.
2. Develop a list of things in 2.8 that you don't want or need and build something to remove those (ala #majorShrink).
3. Develop basic enhancements (a different GUI, e.g.) that you want and build those.
4. Develop your application based on items 1 through 3.
5. Monitor the updates to the general release of Squeak for anything that might be useful. Much of this could be ignored if you have ditched the pertinent part of the system or if the improvement would not measurably affect your product. If you find something useful, fold it into step 3.
* Possibly jettisoning much of Morphic and maybe also MVC and having a
hybrid GUI framework perhaps with parts of both useful for typical
commercial GUI type tasks (text box, combo box, button, image, etc.).
This GUI might have a "game-like" look. This is probably the most
controversial part, and I could reconsider this if another approach
using Morphic somehow was less work and looked nice and was stable for
an application. I like what Morphic wants to be; I just think the first
try needs to be refactored or redone for simplicity and stability in an
application. This GUI part is the highest risk part of the effort (after
ensuring reliable VMs on multiple platforms).
It would be interesting in seeing some specific examples of what's hard to do with Morphic. Granted, there's a lot there, but much of it simply does not come into play unless you want it to.
* Am I out of my mind to think of using Squeak at this point to make a
GUI-based application for sale?
I don't think so.
* Am I wildly underestimating the work involved?
Other than the 4 months to port your application from Delphi, I haven't seen an estimate. Or, if 4 months is the whole magilla, it will depend on how demanding you are in the removal of the last (million, thousand, dozen) bytes of unnecessary code. It will also depend on how exacting you are in other requirements.
* What am I forgetting?
If I were to hazard a guess, it would be which parts of Squeak could be jettisoned from the perspective of potential participants. Some would want MVC to go and Morphic retained. Some might want just the opposite. Others would want yet a different combination.
* Is it likely this fork would just get ignored even if I maintained it
in the face of continual evolution along a main line?
I'm tempted to say, "Build it and they will come", but I won't.
* If this is a good idea, what sort of cooperative framework makes sense
to maintain a deployable version of Squeak for multiple platforms?
* Would people on this list be upset if this effort used this mailing
list for coordination, posting of fixes, etc. given that they would
pertain to an essentially forked version?
Some would and some wouldn't. If your messages only improved the rendering of plants in 3D, I suspect you'd hear some howls. If they helped 3D rendering in general, your contributions might be well received.
* Would others contribute substantially to this deployment platform --
since its needs might differ from the mainline of Squeak development?
I suspect that would vary from item to item. There are those who might help remove dependencies on Morphic without being inherently interested in your total package. Others, similarly, might help with the deployment issue or improving the handling of mouse events.
* By coordinating such an effort, we might gain a commercial advantage
over others in publicity, which would be valuable in gaining consulting
contracts helping others transition their applications to Squeak. This
has the potential to create conflicts (hopefully friendly rivalries).
I guess those are conflicts we should be so lucky to have!
Does this sound like the beginnings of an approach that would produce a
stable version of Squeak for commercial apps and utilities, with no
money changing hands, and without posing a big threat to the beautiful
thing that is the Squeak community?
Yes.

Cheers,
Bob
Karl Goiser
2012-01-28 10:24:11 UTC
Permalink
G'day,

I have a lot of trouble thinking about the idea of a business
interface for squeak.

I use Macs and when people talk about business applications and
computers for business, they mean pc's (at least here in Australia).
I can tell you from experience that people using machines on one
platform will not accept an application running on their machine that
looks and runs like an other platform (Mac, Unix, pc, whatever).

This is my understanding of why VisualWorks never really took off in
the business area (that and the high costs to purchase) - they came
very close to emulating, for example, the Mac ui, but not acceptably
close enough.

The questions about a user interface are:

- Do you succumb to a particular platform and just make it for that
one, shutting out all the others, like Dolphin and VisualSmalltalk?

- Do you try to be everything for everybody, doing nothing perfectly,
like VisualWorks?


***
The thing that I'm starting to understand about Squeak is that its
real advantage is in that it doesn't look like anything else! You
can't complain that it's too Mac like or too windows like if it looks
like neither!

I have a suspicion that building a standard UI for Squeak might be
the death of it.
***


The only thing that I can think that might work would be to specify
an interface/protocol simple enough to be usable across all the
currently deployed platforms and then build a native UI for each
platform, just like happens with FileDirectory now.

For example, you could have an abstract text entry field with a
specific protocol that could then be implemented across the different
platforms. The actual widgets could even be rendered natively.

The trouble would be in handling specific platform requirements, like
the single menu bar on the Mac.

...


Karl
Stefan Matthias Aust
2012-01-28 10:24:51 UTC
Permalink
product (see winetech.com). We currently have software written in a
combination of Visual Basic, C++, and the Microsoft Jet Engine for the
Access database. Squeak initially looked promising as a platform for the
future, but I am gradually and sadly reaching the conclusion that it is
may never be usable for software like ours.
Why don't you, assuming the project is large enough, allocate 10% of its
time to create the extensions needed? That will might also be a nice
payback to the community ;-) And I'm pretty sure that you can still be
faster that with C++ (VB is probably nearly as nice as Smalltalk).

For example, today we spend 3 hours with a customer to test, debug and fine
tune an application written in Squeak. With other languages like C++, we
coudn't have done that at all and probably would have spent two additional
days development.
2. No stable GUI that provides critical tools for manipulating large slabs
of data (particularly Grids that show multiple records and Rich Text boxes
that display and edit text while using multiple fonts and colors).
That's unfortunately true and not that easy to change if you want to
achieve the quality (yes really) Microsoft provides with VB or Access. For
a simple grid morph one could derive the TableMorph which was already
mentioned on this list. Adding some in-place editing capabilities and
finished up the stuff might take less than 1 week. Squeaks normal text
input field can already show colors (even working hyperlinks) and one
custom font but one would need to work on this to support multiple fonts,
different indentation, list bullets, paragraphs with different line
heights. To allow text input one probably would need an editor morph
similar to Microsoft's wordpad. As I don't know much about the edit
control, I'd guess about 1-3 weeks of work - including the wordpad editor.
3. No database ( We currently have about 50,000 records across two
databases, taking up about 100 megabytes). We need fast access from a
variety of different indexes.
Depending on what you need, it might be sufficient to keep the data in your
image. The application mentioned above simply keeps 50MB of data which,
after one
Smalltalk collectGarbage
which moves all global data into the old space doesn't affect performance
at all. And it's know pretty easy to use Smalltalk's #select: and
#collect: messages to access the data.
4. Not even an obvious ability to store 100 megabytes on BTrieve-like files.
Even 100 MB woudn't be a problem on a 256MB+ PC ;-)
5. Poor documentation.
Well, here you need to look at example, browse the web and ask question on
this list. This can definitely be improved.

bye
--
Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf
Bruce ONeel
2012-01-28 10:26:17 UTC
Permalink
For completness sake we also need the [CANTOO] tag as well, with
the obvious results above ...

;-)
Hmm. This isn't quite true. You can use muliple fonts, colors, styles,
etc. right now in a Workspace (or even a code pane). Or you could use
Scamper for static display (which would let you reuse html).
Hmm. This isn't quite true either. Can you really show multiple fonts in
multiple sizes in one workspace? I think, all lines need the same size and
one one font is possible.
I'm staring at a workspace with four different font, in three different
colours all on one line. I am getting very slee.....
I think it's time for a new message tag. If everyone who asserted that "Squeak cannot ..." would add the tag "[CANNOT]" to their message subject, we could have fun tallying up the hits and misses. ;-)
Cheers,
Bob
Bruce ONeel
2012-01-28 10:33:39 UTC
Permalink
Hi,
As someone who spent time with tcl/tk and especially Tcl/Tk on the
mac, I mostly agree. Tcl/Tk on the mac (and win32) is a great try
but you end up shoving a unix/X model into someplace it doesn't fit.
Digging down into the Mac specific code showed how ugly it was
at times. In the end it was a lot of work to get Tk to work well
though the most recent versions do work well on the Mac.

In some senses a cross platform GUI framework has been a bit of
a holy grail. It seems like you should be able to make it work, but
as you get into it all kinds of things turn out to be quite difficult
to really get to work well. Tcl/Tk seems to make it work, at the
expense of speed.

Anyway, I like th fact the Squeak looks the same regardless of the
system I use it on.

cheers

bruce
G'day,
I have a lot of trouble thinking about the idea of a business
interface for squeak.
I use Macs and when people talk about business applications and
computers for business, they mean pc's (at least here in Australia).
I can tell you from experience that people using machines on one
platform will not accept an application running on their machine that
looks and runs like an other platform (Mac, Unix, pc, whatever).
This is my understanding of why VisualWorks never really took off in
the business area (that and the high costs to purchase) - they came
very close to emulating, for example, the Mac ui, but not acceptably
close enough.
- Do you succumb to a particular platform and just make it for that
one, shutting out all the others, like Dolphin and VisualSmalltalk?
- Do you try to be everything for everybody, doing nothing perfectly,
like VisualWorks?
***
The thing that I'm starting to understand about Squeak is that its
real advantage is in that it doesn't look like anything else! You
can't complain that it's too Mac like or too windows like if it looks
like neither!
I have a suspicion that building a standard UI for Squeak might be
the death of it.
***
The only thing that I can think that might work would be to specify
an interface/protocol simple enough to be usable across all the
currently deployed platforms and then build a native UI for each
platform, just like happens with FileDirectory now.
For example, you could have an abstract text entry field with a
specific protocol that could then be implemented across the different
platforms. The actual widgets could even be rendered natively.
The trouble would be in handling specific platform requirements, like
the single menu bar on the Mac.
...
Karl
Daniel Vainsencher
2012-01-28 10:36:25 UTC
Permalink
4. Not even an obvious ability to store 100 megabytes on BTrieve-like files.
Well, my Celeste message file is 77MB, and works quite fine, thanks to a
pretty simple index file. Don't know what you mean precisely by
"BTrieve-like files" (Squeakhas neither BTrieve compatible classes nor
an emulation, AFAIK). What are your requirements?

Do you need a simple data store or do you need a database (multiple
users, security, transactions, recovery...)?

Just curious.
If your dataset is so small simply put everything into the image. Why
mess around with external files if Squeak can handle 4 GB ?
Maybe he wants the image to finish loading in his life time... ;-)
Nice idea though...

Daniel
douglas at winetech.com ()
2012-01-28 10:36:28 UTC
Permalink
Pauls missive has inspired me to put down some thoughts that have been
percolating for a while:

I have been watching this Squeak list for about 6 months, and was hoping to
see real evidence that we could consider Squeak for our next generation
product (see winetech.com). We currently have software written in a
combination of Visual Basic, C++, and the Microsoft Jet Engine for the
Access database. Squeak initially looked promising as a platform for the
future, but I am gradually and sadly reaching the conclusion that it is
may never be usable for software like ours. Here are the issues:

1. No current orientation toward application deployment at Squeak Central.
2. No stable GUI that provides critical tools for manipulating large slabs
of data (particularly Grids that show multiple records and Rich Text boxes
that display and edit text while using multiple fonts and
colors). Although I realize that many on this mailing list regard these as
old-fashioned and boring, they are still necessary for many purposes. We
would like to use Squeak's wonderful capabilities in addition to these
tools, but we cannot start development without them.
3. No database ( We currently have about 50,000 records across two
databases, taking up about 100 megabytes). We need fast access from a
variety of different indexes.
4. Not even an obvious ability to store 100 megabytes on BTrieve-like files.
5. Poor documentation.

While it looks like Squeak has tremendous pluses (Innovative, open source,
great functionality, machine independence) , these seem to primarily
benefit teaching and research, and not actual application developers like
ourselves.

I admire Paul's effort to develop a deployable Squeak application, and
would consider any success he has as great evidence that we may be able to
use Squeak also.

Sincerely
Douglas Flower
***@winetech.com


==========================
(From Paul Fernhout)
All-
I am trying to determine the extent to which it is feasible to
create and maintain an application deployment kit for Squeak, and how
much others would be willing to cooperate in doing so.
While we're not committing to anything yet, here is a note to sound out
interest.
At the moment we (my wife and I) are seriously considering making
version 2.0 of our PlantStudio (Botanical Illustration Software that
produces 3D models of plants) product in Squeak so we can also have Mac
and Linux versions. I personally would do the bulk of the conversion
work from Delphi. The effort might possibly start in a couple of months.
We would expect that project to take four months or so.
However, I think Squeak as it is needs several changes before it can be
used to deploy a "commercial" application to an internet audience (in
this case, of graphic professionals). I'm trying to decide if these can
be fixed with a reasonable amount of effort that still lets me finish
the application in four months.
* Making Squeak event driven at the VM level to eliminate those
occasional weird mouse drags
* Creating a "lockable" GUI w/ common data entry widgets
* Producing a small footprint image with all "clutter" removed
* Doing odds and ends related to stability and testing
* Having reliable VMs for Linux (which?), Windows (NT, 2000, 95, 98),
and Mac (PPC, Which OS Revs?)
* Developing an install process for all platforms (might be platform
specific; maybe could live with ZIP file install)
* Replacing the fonts (to meet license obligations)
* Single EXE
* Namespaces
* Image buildable from scratch
* Consistent exception handling
* GUI builder
* One-click deployment building
Things I don't need for my application (but others might want, or I
* Printing
* Sound
* Reliable sockets
* HTML viewing
* Reentrancy
* Better development tools and version control
I haven't done much with 2.8 so it may be improving in these areas. It
certainly sounds like pluggable primitives have come a long way.
I think Squeak would need significant work to get it into shape for
shipping "shrink-wrap" quality applications. I would like to do this
without forking Squeak, but I don't know if this is possible. I think it
would require maintaining a seperate line of development for a while.
This isn't specifically a dig at SqueakC (well maybe a little :-) , but
I think supporting a version of Squeak intended for shipping (ANSI)
Smalltalk apps in a boring but predictable GUI is a fairly different
activity and set of priorities than supporting a version for
experimenting (Pink vs. Blue planes). SqueakC may want a Pink (Blue?)
version or not, but it is clear (to me) that that a version of Squeak to
support applications is not where their priority is right now. I don't
fault them for this. But I do see a void which has remained since the
first OOPSLA '97 Squeak BOF where half the people in the room wanted an
experimental version and half wanted a stable version. The reality as I
see it is that the half wanting a stable version of Squeak for apps or
utilities mostly don't stick with Squeak. (Obviously there are some
noteable exceptions.) But the reality (for me) is that even when a
client doesn't care if I use Squeak for a simple utility, I know Python
or C++ or Java gives them what they want faster. I'd like to change that
situation.
My last posts about this issue to the Squeak list were in February 2000
(just before the NASDAQ meltdown) when I proposed a Squeak/Pro of
"SqueakHat". Several people wrote to me saying they or their company
had considered something similar or might consider participating in this
somehow. Some offered the possibility of funding; some offered to work
for pay or as partners. I decided not to pursue that proposal at the
time in part because of a concern of tearing either the community or my
relationship to it apart. The Squeak list is a precious resource and
things can often get ugly when money changes hands.
So here is something I am thinking about (but not yet committing to)
which I hope will fit well with the Squeak community and open source
* Putting up a forked version of Squeak which is specifically for
deploying utilities and applications for the PC, Linux, and Mac.
This might be done on SourceForge.
* Coordinating the minimal changes (mostly removals!) required to make
this a stable deployment platform from a "make it reliable for the end
user" point of view.
* Possibly jettisoning much of Morphic and maybe also MVC and having a
hybrid GUI framework perhaps with parts of both useful for typical
commercial GUI type tasks (text box, combo box, button, image, etc.).
This GUI might have a "game-like" look. This is probably the most
controversial part, and I could reconsider this if another approach
using Morphic somehow was less work and looked nice and was stable for
an application. I like what Morphic wants to be; I just think the first
try needs to be refactored or redone for simplicity and stability in an
application. This GUI part is the highest risk part of the effort (after
ensuring reliable VMs on multiple platforms).
* Putting all this under the Squeak license (or similar compatible open
source licenses for add-ons determined by their contributor).
* I as a tool-kit user would build on top of this deployment kit for
applications for sale.
* Am I out of my mind to think of using Squeak at this point to make a
GUI-based application for sale?
* Am I wildly underestimating the work involved?
* What am I forgetting?
* Is it likely this fork would just get ignored even if I maintained it
in the face of continual evolution along a main line?
* If this is a good idea, what sort of cooperative framework makes sense
to maintain a deployable version of Squeak for multiple platforms?
* Would people on this list be upset if this effort used this mailing
list for coordination, posting of fixes, etc. given that they would
pertain to an essentially forked version?
* Would others contribute substantially to this deployment platform --
since its needs might differ from the mainline of Squeak development?
The last is most important to me because I don't have the current Mac or
Linux set-up to support these platforms without a big investment in
time and new software and equipment. Maintaining the image and codebase
on one system is easy; testing VMs on multiple platforms and
configurations is hard. It is not clear to me that the current VMs would
be appropriate for deployment. At the very least changes to make them
even driven would be needed.
* We're not asking for help developing the application, and the
application would itself most likely not be open source, and that
creates a bit of a conflict between where the deployment kit stops and
our application begins (e.g. is our 3D turtle part of the kit?)
* We have no funds to pay anyone for their contributions or their time.
* We have no interest in selling Smalltalk development tools or the
deployment kit.
* We might release other applications on top of this framework -- like
our two other products, and perhaps later something related to an email
client, news reader, web client, and knowledgebase.
* By coordinating such an effort, we might gain a commercial advantage
over others in publicity, which would be valuable in gaining consulting
contracts helping others transition their applications to Squeak. This
has the potential to create conflicts (hopefully friendly rivalries).
* We probably won't make any money from this unless PlantStudio ships
and people like it enough to register it (i.e. "tip" us), or consulting
comes along related to helping others deploy apps with the Squeak
toolkit.
Does this sound like the beginnings of an approach that would produce a
stable version of Squeak for commercial apps and utilities, with no
money changing hands, and without posing a big threat to the beautiful
thing that is the Squeak community?
I'd also appreciate frank and informed commentary on why what I propose
won't work (for technical, effort, or social reasons) if that is your
belief. Alternate suggestions or pointers to work in progress
(especially on a VM with events) would be appreciated. Replies to the
list would generally be preferred so all may comment on them.
-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com
Tim Rowledge
2012-01-28 10:40:16 UTC
Permalink
3. No database ( We currently have about 50,000 records across two
databases, taking up about 100 megabytes). We need fast access from
a variety of different indexes.
4. Not even an obvious ability to store 100 megabytes on BTrieve-like files.
If your dataset is so small simply put everything into the image. Why
mess around with external files if Squeak can handle 4 GB ?
I'd assume that Douglas might be concerned with things like security,
sharability and so on. Why not take a look at MinneStore? Didn't that
appear to be promising?

tim
Georg Gollmann
2012-01-28 10:45:17 UTC
Permalink
3. No database ( We currently have about 50,000 records across two
databases, taking up about 100 megabytes). We need fast access from
a variety of different indexes.
4. Not even an obvious ability to store 100 megabytes on BTrieve-like files.
If your dataset is so small simply put everything into the image. Why
mess around with external files if Squeak can handle 4 GB ?

Georg
--
----
Dipl.Ing. Georg Gollmann TU-Wien, Zentraler Informatikdienst
Wiedner Hauptstr. 8-10
phon:(+43-1) 58801 - 42022 A-1040 Wien
fax: (+43-1) 58801 - 42099
mail:***@zid.tuwien.ac.at
http://macos.tuwien.ac.at/Gollmann.html
Jon Hylands
2012-01-28 10:36:56 UTC
Permalink
On Wed, 28 Jun 2000 18:50:58 -0400 (EDT), Bijan Parsia
http://www.huv.com/smalltalk/browser.html
*Now*! :)
Coming... :-)

Tim, what was the status of the software when you left Interval? Is the
browser code PD for sure?

Later,
Jon

--------------------------------------------------------------
Jon Hylands ***@huv.com http://www.huv.com/jon

Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
http://www.huv.com
Giovanni Giorgi
2012-01-28 10:37:18 UTC
Permalink
Thanks for the great comments. Just what I want to hear!
(Not that I'd not want to hear disagreements.)
Nothing.

I'd like to promise I can help you about your idea, but
I have no much time in this moment, and so I cannot :(

But If we find some pepole interested in doing a Developement o deployment kit
for Squeak, I will try to help you in my free weekends!!
I think a stable subset of Squeak library would help a lot "newbie" too.

[...]
More than anything, a deployment kit would create some
additional clarity in Squeak by trying to modularize parts of it.
[...]
Stephan Rudlof had a similar one in his strategy for
basing less stable libraries only on more stable ones. As he points out,
we also need to differentiate between the interface stability and the
implementation stability.
This is an hard point.
VisualWorks has a "parcel" concept which is not so simple and with a bit of
problems.
The parcels can used for deploy new code into a running image, but
conflits can arise easily: if two parcels re-define the same
object or method in different ways, you will have a problem when do you want
"unistall" one of them in different order and so on.

****I think the modularisation must be resolved in conjunction with the
NameSpace problem. If we draw a good NameSpace environment, we can use it for
supporting
modules.
Namespace and interfaces are important for a collaborative developement as
Squeak is.
And interface are best used with a bit of NameSpace***
For example, I do not know how mucch Morphic is stable and usable for a true
commercial product.
* internal APIs
* implementation within those APIS.
Would people who know for 2.8 have any comments?
If I write Morphic widgets, is it likely they will run on next year's
Morphic?
This is a big question.
Morphic structure is a little safe because a lot of the interface is exposed in
the Morphic Base object.

Only a crazy man will modify that interface, destroying all the widget working
now.
[...]
Problem is if I say six months, my wife (& business partner) probably
won't let me do it. It's a stretch as it is. It's really got to fit in
four or less -- even if that means cutting stuff.
The question is, what can I cut and what can't I cut? And what can I
leverage for a Squeak deployment toolkit that others are working on or
willing to support?
I think you can use the basic Morphic engine, and try to use only the widget
provided. If you are carefully you can speed up your porting.

If you need of a new widget, design it carefully so it is open, and can be
robust.
Read <http://coweb.cc.gatech.edu/squeakbook/21> about extreme programming in
Squeak: you will need it.

[...]
I will not be upset, but a SourceForge project with a different mailing list is
the best idea :)
Good point. My major concerns are that the SourceForge project would
start with zero traffic and then people would have to check two lists.
And also, much of the (deployment) issues will be relevant to the main
distribution. But it makes sense not to clutter the list with details on
deployment in general if there is a lot of traffic about it.
Isn't there already a Squeak SourceForge project by the way?
Yes, it's SqueakNOS.
I think you can solve legal problems in Squeak for a commercial product.
Squeak is a open-source-like project (it is not GNU, but open source is good
enough).

[snip about my fews difficulties....]
Could you detail those difficulties?
What would make it easier?
(I ask to the squeak-list to comment my idea here, thank you!!)

First, tutorials and documentation should be a lot more.
The book of Mark Guzdial,
"Squeak: Object-Oriented Design with Multimedia Applications"
(http://coweb.cc.gatech.edu/cs2340/8) is a dream, but it is not sufficient.

Second, Squeak has not a stable library in all its parts.
I take for example a my small application.
When Squeak 2.7 came out, I must fix some small problems I do not have in
Squeak 2.6
I use an instance variable called "array" (a bad name, I apologize myself) in a
my class.
In Squeak 2.8 someone add a instance variable array in a superclass, and so my
code cannot be filed-in for a "redefinition" error.
It was easy to fix but if you develop a big application for Squeak 2.6 it
will likely not work in Squeak 3.0...too differences!!

If we can mantain old interfaces for compatibility (using for example namespace
and so on) I think we will have less problems.

Third, we do not have javadoc-like system: altrough it will be easy to add it
because of the hypertext documentation system (very good, a dream!!).
I have builded a small application called AutoDoc which will generate the
documentation of a set of class, but not the comments for every method and so
on (only comment class, hyperlink to superlcasses and so on).

I think I forget a lot of things, but one is not-missed: Smalltalk ide, Browser
and method finder are a fantastic resource for debugging and developing (and
the new private methods are a good evolution of Smalltalk towards information
hiding!!)
If I will have (dream!) a semi-professional kit, a lot of my bugs will be
discoveredy early!!
I'd like that too.
[...]
I realized that "professional development" and "deployment" are two
different issues.
[...]
I'd love to have professional development tools for Squeak (better
version control, better native code compiler, refactoring browser, good
documentation, etc.).
But I'm realizing what I can't live without as a commercial developer is
deployment -- and related stability.
This is true.
We need of a more "BSD-like" idea of Squeak image, with a focus on young
developer, who know only Java and (uh!) VisualBasic.

About multiplatform developement. network and filesystem differences must be
tested across the three major platform (Unix, Win,Mac).
You can have the same problem in Java, in my experience.

[...]
By now many people practically think Java originated the virtual
machine, the cross-platform GUI, garbage collection, and maybe MVC too
given Swing. This is true in much the same way many people now think
Bill Gates invented personal computing (instead of Doug Engelbart, Alan
Kay, J.R. Licklider, and others).
I agree with you.
I think in the next five years someone will "discover" the code-block-as-object
in Smalltalk, the iterator as a language extension (Java has a similar thing
already).
And finally, someone will say "dynamic languages are slower than statically
typed languages, but are simpler and less error prone..."
I like your Squeak buzzwords though. It would be amusing to see a glitzy
marketing web page for Squeak that used terms like that.
We must only choos the "right words" and the right logos: Smalltalk can be the
future and must be free.
--
// Giovanni "Daitan" Giorgi
// Assibit S.r.l.
// http://www.geocities.com/~giorgi_g/
//mailto: ***@geocities.com GSM: +39-(0)347-30-76-419
David T. Lewis
2012-01-28 10:37:51 UTC
Permalink
The same could probably not be said for socket events which might need
quicker response (or need "select" to operate well). File events and
semaphores might also need better support.
The TCL event loop might be a good model here. I had a TCL expert spend
twenty minutes once extolling to me the virtues of TCL's event loop as a
key cross-platform feature (in contrast to Python's lack of an event
loop).
Any TCL internals experts on the list? Could we "steal" (legally under
the TCL license) the TCL cross-platform event loop code? Would it help
at the VM level?
Right you are. The Tk/Tcl event model is nicely done, and cross platform
as well. The code is freely available under a BSD license. Even if you
don't "steal" it, it certainly serves as a good source of inspiration.

It seems to me that Tk/Tcl style events could readily be adapted to Squeak,
serving as a fairly general external event system and making things like
AsyncFile unnecessary.

Dave
Craig Latta
2012-01-28 10:42:59 UTC
Permalink
Hi--

Here's another poll for interest in a Squeak gathering, in conjunction
with Camp Smalltalk 2 (17-20 July 2000 in Annapolis, Maryland, USA). We
could have a BOF-style thing during that event, or perhaps a weekend
thing like the SqueakEnd earlier this year, if some kind Squeaker in the
area could host it.

If you're interested, please send email to me.


thanks,

-C

--
Craig Latta
composer and computer scientist
***@netjam.org
www.netjam.org
***@watson.ibm.com
Smalltalkers do: [:it | All with: Class, (And love: it)]
Bijan Parsia
2012-01-28 10:41:35 UTC
Permalink
On Mon, 26 Jun 2000 ***@winetech.com wrote:

[snip]
Post by douglas at winetech.com ()
I have been watching this Squeak list for about 6 months, and was hoping to
see real evidence that we could consider Squeak for our next generation
product (see winetech.com). We currently have software written in a
combination of Visual Basic, C++, and the Microsoft Jet Engine for the
Access database.
I would have been surprised if Squeak were drop in replaceable for that
combo. (But I might suggest, if you're ok staying on windows only, Dolphin
Smalltalk.)
Post by douglas at winetech.com ()
Squeak initially looked promising as a platform for the
future, but I am gradually and sadly reaching the conclusion that it is
may never be usable for software like ours.
Well it *may* as well :) I'll point out that Squeak the evolving system
and Squeak the deployment platform are not necessarily identical. Keeping
the two distinct and yet separable is a challenge not yet met but one that
will be met sooner if there's an active "deployment group".

I would say that one should expect some "pain" in such a
situation--it's not going to be a one time job. For example, I can see how
to puttogether a simple parceling mechanism out of reference streams, or
image segmants, or FileDictionaries...but the simplest hack that will work
will need (probably) to change when environments are settled. New
features, new simplifications...these will require change. No matter
*what*. The only way to assure "stability" is to fork...which is a
reasonable option in my book :)
Post by douglas at winetech.com ()
1. No current orientation toward application deployment at Squeak Central.
True, but if Paul gets the Deployment Fetishists Association (;)) rolling,
that may be a bit moot.
Post by douglas at winetech.com ()
2. No stable GUI that provides critical tools for manipulating large slabs
of data (particularly Grids that show multiple records and Rich Text boxes
that display and edit text while using multiple fonts and
colors).
Hmm. This isn't quite true. You can use muliple fonts, colors, styles,
etc. right now in a Workspace (or even a code pane). Or you could use
Scamper for static display (which would let you reuse html).

And there are some tools for sound display, editing, an manipulation. That
might count as large data sets. There is the TableMorph. And
Listboxes. The latter, of course, are not optimized for large data sets
(as lex has pointed out wrt celeste), but might well becomes so, or
at least such an improvement would be welcome and adopted (again, for
both, because of Celeste).
Post by douglas at winetech.com ()
Although I realize that many on this mailing list regard these as
old-fashioned and boring, they are still necessary for many purposes.
No, I think we all want them. I'm interested in hearing what's missing
from pluggable text boxes wrt rich text, and it's merely a matter of no
one following up (yet) on the other.
Post by douglas at winetech.com ()
We
would like to use Squeak's wonderful capabilities in addition to these
tools, but we cannot start development without them.
Sensible. It might make some sense, however, to try implementing one of
them, as a development test case. Any such work would be welcome, and
you'd get a hands on assessment of the difficulties of filling gaps in
Squeak.
Post by douglas at winetech.com ()
3. No database ( We currently have about 50,000 records across two
databases, taking up about 100 megabytes). We need fast access from a
variety of different indexes.
There is a MySQL driver (which I may get to test out today! yay!), and
several of us are groaning about other drivers and OBDC access. There is
MinneStore. I certainly have no notion of how difficult it would be to
write a set of primatives for Access..er...access :)
Post by douglas at winetech.com ()
4. Not even an obvious ability to store 100 megabytes on BTrieve-like files.
Well, this wasn't obvious to me :) But again, I'm not sure how "big" a gap
this is to cross. It certainly seems that there are "packages" for this
sort of thing. How difficult it is to make them Squeak "active" is unknown
to me. But it's certainly *possible* that the "cost" of adding this is
"made up" in other areas.
Post by douglas at winetech.com ()
5. Poor documentation.
Some is poor, some is scattered, some is just incomplete, and some is
quite nice, and much is getting better. But you can't yet just sit down
with a single reference and read through everything there is know about
squeak :)
Post by douglas at winetech.com ()
While it looks like Squeak has tremendous pluses (Innovative, open source,
great functionality, machine independence) , these seem to primarily
benefit teaching and research, and not actual application developers like
ourselves.
Depends *strongly* on the application.
Post by douglas at winetech.com ()
I admire Paul's effort to develop a deployable Squeak application, and
would consider any success he has as great evidence that we may be able to
use Squeak also.
Note that nothing I say is intended to support the proposition "Squeak is
a prime time classic RAD system". It isn't. Dolphin is much closer, though
it isn't cross platform. I think some of use need to start actually
distributing "clunky" apps before we're going to really get "smooth" apps
*out* (forgive the pun) Squeak.

Pauls distinction between Squeak as OS (or "system" as I like to put
it) and Squeak as Application is far better, in my mind, to the research
vs. production one, and one I shall have to think about more.

Cheers,
Bijan Parsia.
Bob Arning
2012-01-28 10:44:26 UTC
Permalink
Hmm. This isn't quite true. You can use muliple fonts, colors, styles,
etc. right now in a Workspace (or even a code pane). Or you could use
Scamper for static display (which would let you reuse html).
Hmm. This isn't quite true either. Can you really show multiple fonts in
multiple sizes in one workspace? I think, all lines need the same size and
one one font is possible.
I'm staring at a workspace with four different font, in three different
colours all on one line. I am getting very slee.....
I think it's time for a new message tag. If everyone who asserted that "Squeak cannot ..." would add the tag "[CANNOT]" to their message subject, we could have fun tallying up the hits and misses. ;-)

Cheers,
Bob
Paul Fernhout
2012-01-28 10:47:02 UTC
Permalink
Tim -

You're quite right.

I looked into events a bit back when I was working towards
a Squeak->Netwon port since the Newt is totally event driven at the user
application level. You can't ask the Newt where the stylus is on the
screen -- in fact it really wants to give you entire gestures (with
multiple segments) at once.

The biggest single issue was in MVC. IIRC (from 1.16), the MVC code for
many apps does some internal tight polling looking for mouse changes
that locks up the system, especially when waiting on a mouse up. If
these loops are still in the code they wouldn't be that hard to fix --
just tedious. Morphic does not have this problem -- just others related
to complexity and size :-) -- except that Morphic still is expecting
this non-event
mouse primitive at the bottom of everything, but I think that can be
changed in one place.

I don't think actually passing in basic mouse events through the VM
would be that hard. My approach for the Newt was planned to be a short
circular queue of mouse events maintained by the VM that the Smalltalk
could check by a new primitive and dispatch itself. This matched the
Newt's desire to produce gesture paths. There is also problem that the
logic for storing modifier keys in a global would have to be changed -
it would have to reflect what current point was being retrieved from the
stroke point buffer.
[The Newt had several other event-related issues (detailed on the Squeak
list on 27 Oct. 1997) which I won't go into.]

Other events like window close etc. might require more cleverness
related to allocating event objects and such. In general though, it
might be klunky but acceptable to poll for most external window events
(close, resize) as Squeak mainly spends time with its own windows.

The same could probably not be said for socket events which might need
quicker response (or need "select" to operate well). File events and
semaphores might also need better support.

The TCL event loop might be a good model here. I had a TCL expert spend
twenty minutes once extolling to me the virtues of TCL's event loop as a
key cross-platform feature (in contrast to Python's lack of an event
loop).
Any TCL internals experts on the list? Could we "steal" (legally under
the TCL license) the TCL cross-platform event loop code? Would it help
at the VM level?

One big issue here is that the Squeak VM is not reentrant so one needs
to tread carefully. I guess in the end, for completeness, one might
just have to either generalize the event system to allocate Smalltalk
objects and poll in the VM, or generalize a primitive to request events
from the OS and modify all the Smalltalk code to use it.

Part of the problem stems from Squeak not making up it's mind about
whether it's an application or an OS. If you are putting Squeak on the
metal in a single thread it is probably easiest to implement if it does
poll (and maybe sleep). Then the current MVC handling of polling is a
good thing. If you think of Squeak as an application with another OS
thread serving it with events, then polling is probably a bad thing.

Anyway, that is how I see it.

How far have you got? What is your approach?
Which platforms are you looking at?
I hope your changes make it into the main distribution.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com
* Making Squeak event driven at the VM level to eliminate those
occasional weird mouse drags
Working on it. It's a _lot_ more than VM level work. Many bits of code
use messages like anyButtonPressed or shiftDown etc which are really
un-event driven ideas.
Even the nearest-to-event parts make assumptions about checking the
mouse and then the keyboard; not surprising when they are working of the
current mouse-state plus keyboard-queue system.
tim
Henrik Gedenryd
2012-01-28 10:47:50 UTC
Permalink
Post by Alan Kay
I am not sure how this helps. Either you have xml/html/style
interfaces and rely on the 'universal client'. This is an
interesting area because it allows mixing of documents and multiple
presentations of an underlying data-source. However, forget about
morphic. Interaction, if possible at all, will only be through
standardized mechanisms such as event/scripting enabled SVG/XHTML,
which essentially means JavaScript.
...
Post by Alan Kay
What am I missing?
To make real progress, everyone should be thinking much longer, on a much
higher level. HTML (and everything else about the web) is/will be the MS-DOS
of the next two decades--it will dominate, will not be abandoned so that
huge efforts will be spent on compatibility backwards, it will represent the
worst possible solution to the problems it addresses, and hold back progress
to an immense degree. XML (et al)? Jeez, it's just one of the first hacks to
remedy these things, within the original boundaries.
Post by Alan Kay
I think Squeak is a little
more powerful than JavaScript ... Also, Squeak always has "authoring
turned on" so it opens vistas of "SuperSwikis" of active media that
can be added to, etc.
.... and there are a variety of ways to deal with the existing web
conventions.
HTML, XML, JavaScript, DHTML, BLAHABLAHATML, yadda yadda yadda. The best way
to predict the future is to ignore them :)

The advent of the web and these dinosaur technologies is a disaster. Ten
years ago we were using our computers to do productive work. Now we're back
to making them work again. Then, courses would teach people Quark XPress and
then about kerning, typefaces, point sizes, ligatures, and so on--real
useful skills and knowledge for graphic designers. Today they're having to
teach them Unix file system syntax and image representation formats so that
people can put images in their documents, which used to be done by cut &
paste back then. It's essentially a counterrevolution of the techies. Notice
that Linux, the great "new" thing formerly known as Unix, is 30+ years old,
HTML is a much poorer version of the 35 years old SGML, etc. etc. And the
advocates of this complain that Smalltalk, at a mere 25, is too old?
Post by Alan Kay
I think the basic difference in point of view is that I don't see the
existing OS's and web as being anything more than bad defacto
standards that positively invite us to produce better alternatives
I obviously agree, but no one does who is willing to pay for it.
Essentially, everything being capitalized on the net today was invented as
part of the effort of going to the moon (via ARPA)! But hopefully the
situation will improve again, if the current indications of an e-commerce
reality check and so on are signs that people are beginning to switch on
their brains again.
Post by Alan Kay
.... I certainly don't see them as anything that has to be catered to
....
To make real progress the existing stuff needs to be abandoned--so this
won't happen. Backward compatibility is the best way to hinder genuine
progress.

Watching the tape of what Engelbart had on a real, working system in '68,
makes you cry a few tears, seeing things that won't be in real use in the
next 10 or 20 years, easily.
Post by Alan Kay
Most of the next billion machines are not going to be either Macs or PCs
..... but will certainly be connected to Internet.
I also hope that convergence/ubiquitous computing etc. really will happen,
and throw everything over as the personal computers did--but I see many
reasons why this won't happen; too many I think. At least not for a long
time--the PDAs and friends are still not nearly useful enough, for example.
What timeframe do you expect this to happen in? A billion computers implies
a rather long time.
Post by Alan Kay
Well, Squeak is a client for its own media -- and this is what I'm
most interested in -- you may have noticed that we can now "publish"
whole projects, which can serve as a more active and media basis for
representing ideas than simplistic html pages. We will release a
bunch of these by the end of the summer.
Given these ambitions, I am surprised that there appear to be no ambitions
to addressing the usability of the stuff inside Squeak, and make it
accessible for 'real people', as in accessible to those without a major in
Smalltalk.

Henrik
Lawson English
2012-01-28 09:59:55 UTC
Permalink
So please let me repeat my question: Can you show one word
written in font Comic12 and another word in font NewYork12
in the same workspace in the same size? Looking at the
"Welcome to..." window, there should be a way, but AFAIK, you can't.
It's quite possible - all you need is to classify all the fonts in the same
text style. Not a good way to do it since some of the information that is
supposedly the same for a text style are different in the fonts but
possible. More generally, I'd like to see some of the information that is
currently in the text style to be in the font itself so that all you need to
fully specify the layout of some string is defined in the font. Then, you
basically don't need any text style any longer (and besides - specifying the
fonts through an index in the font array of a text style rather than an
explicit point size and the appropriate attributes is pretty dangerous if
you change the style these days).
Check out the GXTypography GXLayout shape-object from GX graphics for an
example of how to "do this right."
So, I *believe*, I sincerely *hope*, that it is now
established that there *is* a sufficently *rich* Rich Text Widget
for, at least, *some* purposes. I cannot say that it answers
to *all* purposes, but it's also pretty clear that *building* ones,
using a variety of techniques, is non-burdensome to various degreeds.
Hm ... just wondering. Why is it that so many people cry for a Rich Text
Widget?! Wouldn't a HTML spec serve the same purpose?! And we do have the
formatter for it right in the system.
How is it for reading and writing RTF? And does HTML allow arbitrary point
sizes? What's the space consideration for RTF vs HTML storage?
- Andreas
PS. Since we're talking about text here - the three things we really need
for good text layout are a) fractional widths b) left/right side bearings
and advance widths (for overhang and underhang characters) and c) kerning
pairs (and possibly automatic detection of common ligatures). Anyone up to
it?!
Again, check out the GXTypography GXLayout shape. Even avoiding
right-to-left, vertical, bidirectional, etc., issues, there's a lot more
needed for good, modern text-layout handling than what you've mentioned.


--
YOU have the right to select the Reform Party Presidential Nominee, which
doesn't have to be Pat Buchanan. Request a ballot BY Midnight, June 30.
<http://www.reasontovote.com>
Send your ballot-request via: FAX 515-472-2011 -mail won't get there in time
Oops. Too late.
--
Stefan Matthias Aust
2012-01-28 10:02:27 UTC
Permalink
Hm ... just wondering. Why is it that so many people cry for a Rich Text
Widget?!
I think, when talking about a Rich Text Widget, people thinking about a
text input facitily that allows one to define different text alignment,
fonts (font families), styles (like bold or italics), colors, bullet lists
and perhaps even images and tables. At last I don't think about
Microsoft's RTF file format here.
Wouldn't a HTML spec serve the same purpose?! And we do have the
formatter for it right in the system.
In the above sense, no. HTML spec is a file format but there's also no
interactive HTML editor. Scamper can render a subset of HTML but that not
enough to qualify as an rich text widget. It's close to that definition
though.

bye
--
Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf
Marcel Weiher
2012-01-28 10:06:15 UTC
Permalink
[ skins -> C vs. Scheme semantics ]

Where did I say anything about bridging incompatible semantics? How
would this be useful? Please, that's just a complete straw man. I
mean, I say I have a perfectly fine car and you say it doesn't fly
you to the moon. Well, flying to the moon has never been in the
requirements for a perfectly fine car.

Once again, I was talking about "skins", like the different skins
for Squeak-Smalltalk now showing. An XML-based encoding
(marshalling) of parse-trees could serve as a skin-neutral storage
format. And could probably be easily translated into (some) other OO
languages as well.
Anyway, look at SOAP for an example of *easy* interoperability. You
can write SOAP commands using any old text editor, or even via
direct telnet connection. That's very low overhead for trying
something out and doing things in an ad-hoc way.
Doing this has no support for any kind of input-side validity.
Exactly! The point is that extremely light-weight or ad-hoc access
is possible without all that overhead, while at the same time fully
validated access is just as easy (or easier) than with the
heavy-weight equivalents.

[more of same snipped]
Try the same with a
CORBA ORB!!
Why? I can do the same kind of thing from bsh or Tcl or Python
when I want
to play around with CORBA interfaces. The responsibility for
validity is
split between client and server.
Compare the overhead of the two solutions:

On the client side, a simple text editor or even just telnet, both
of which are simply available vs. a whole programming language plus
an integrated ORB, which has to implement IDL-parsing, IIOP
parsing/generation and all the other services, none of which leverage
common technologies but have to implemented just for CORBA!

On the server side, you can hook up one of the many, many XML
parsers available off the shelf and then just read out the DOM (or
handle the SAX events), again compared to a full CORBA ORB with all
the trappings and no common components.

The point here is that the barriers to entry are just incredibly
low. If you want to do something very simple, you can do so with
very simple means. If you want to do something complex or highly
secure, you need to spend more. But the people who want to do
something simple should not be penalized because some people want to
do something complex, and it would be good if both could use the same
basic protocol, and they can.
As for interoperability, the format is easy to
parse/generate with just about any language/OS I can think of.
It's only easy to generate if you don't care about correctness and
robustness. String manipulation is a truly awful basis for the core of
http://www.cert.org/advisories/CA-2000-02.html
XML parsers and generators are commonly available and easy to write.
If you think XML-parsing should be done by regex-matching or
strcmp(), you get what you deserve. The CERT advisory clearly only
talks about incorrect servers, and you will note that my scenarious
have been about easy, ad-hoc *client* access. Furthermore, the
problem in the CERT advisory is really the insecurity of having
script access enabled. If you have that turned on, you're wide open
to attacks anyhow, the only difference with being that the audience
you're wide open to has increased.

Still I'll wager with you that a SOAP server requires a fraction of
the code of a fully functioning CORBA ORB. (Not that I am a SOAP
fan, but the general idea of encoding messages as XML has a lot of
appeal and SOAP is one spec I am aware of).
Deeply, the problem is that generating HTML or XML is *not* about
concatenating strings together.
Of course not, whowever said that it is? For programmatic access,
you should build the (simple) libs that do it properly. However, you
*can* reasonably build or edit a simple XML file in a text editor,
which you can't reasonably do with various binary formats, and you
can also *examine* XML files in a text editor.
Generating HTML or XML is about building
trees of elements and then marshalling them into ASCII.
Yes of course. Where did I say anything different? I always groan
when I see code that concatenates HTML/XML tags to strings in an
ad-hoc fashion.

My own XML-framework (for Objective-C) both has a proper parser and
a generator, with the generator being a type of EncodingFilter.
OK, so maybe this is a straw man.
Exactly!
You probably agree with me that real XML
and SOAP applications need a library or set of classes to
generate/parse/validate their data, since it's not strings.
My point from the start is that it is *both* trees of semantically
rich objects *and* strings, though one has to take care, because it
is not simple strings.
But once you
have that library and code to it, the particular advantages of
SOAP over
(say) CORBA doesn't look so one-sided.
Yes it does. You get to leverage common components, the overall
complexity is much lower, you get a human-readable (and debuggable),
standardized interchange format/wire protocol, you get easy ad-hoc
usage, etc.
Some of the magic binary bits are well-known and documented via
OLE storage.

AFAIK, the whole word file format is now documented (somewhere).
That doesn't change the fact that writing custom binary-format
parsers is going to be a lot more complex than (a) just opening the
XML file in a text-editor and *looking* at it and/or (b) using one
of dozens/hundreds of off-the-shelf XML tools with it.
Yes, I agree, with a qualification: XML files *can* have
self-describing
syntax. But you still have to understand what that syntax means.
Yes, if the semantics are inherently complex or intentionally
obscured, XML won't solve that, because, as I've explained before,
that's outside of the domain of problems it is trying to solve.

However, with XML you at least have a good chance of understanding
what is there, assuming that the creator of the schema is not an
adversary trying to confuse you.

<Quantity>1</Quantity> vs (hex) fc00000001 or was that fc01000000?
Post by Marcel Weiher
Furthermore, it combines the worlds of UNIX (everything is a text
file)
This is a strawman (I hope). If everything is a text file,
why aren't
vi+pipelines the only applications I use to edit and view things?
I think you misunderstood: the "everything is a text file" is an
assumption that most of the UNIX tools are built around. It makes
many powerful things possible, especially for *ad hoc* processing.
However, it loses out on richer structures, for example those typical
in OO systems. XML is a way of combining the two worlds.
Again, only if you're willing to give up correctness, or do a lot
more work
to try to patch around end cases. The right way to process
objects is as
objects.
The "right" way depends on your application and on the economics of
the situation. For example, say you have two databases and you need
to dump the contents of one into the other, once. They have schemas
that are principally compatible but differ slightly.

Now, you could (and it seems you argue one should) build complete
class hierarchies modelling the schemas of the two databases,
routines reading correct object-graphs out of one database
(potentially running out of memory), transforming the object-graphs
in memory (running out again) and then writing the resulting object
graph to the other database.

Or you could dump one DB out to XML-format (with an off-the-shelf
tool), use an off-the-shelf generic XML-transformation tool that
remaps the file purely syntactically (with your knowledge of the
semantics controlling the syntactic transformations) and import the
resulting XML-file into database two.

Notice that I didn't say "use sed", because that won't work.
Purely syntactic queries are limited to identity queries, which aren't
terribly useful.
Where do you get that idea? With an XML-aware tool, I could
certainly do more, based on structure, context and values. The user
of the tools can have knowledge (or make assumptions) about the
semantics.
You can move up to queries based on string operations (is
this attribute value in the canonical Unicode sort order between
"Carlson"
and "Weiher"?) but that's not much better.
What would prevent me from doing queries based on structural or
numerical relationships? Structural queries are even in the base
XPointer, XML query languages such as Quilt support rich queries
expanding on those available in SQL. ( see
http://www.almaden.ibm.com/cs/people/chamberlin/quilt_euro.html)
o A not-so-awful generic syntax
o self describing, human readable, editable, robust
o that has a framework for discussing, documenting, and
standardizing the
semantics, and
o is usable *without* a machine encoded semantics
o thus providing a low barrier to entry, just like HTML/HTTP
o but scales to higher demands just as well
o A political atmosphere where information and service providers are
expected to do so.
XML hype is *good* as long as it's a tool to accomplish that last
goal. But
we shouldn't forget that it's just one of many possible vehicles to get
this, and even with full documentation of formats there is a vast
amount of
work in creating interoperation, which often starts with
standardization on
models.
Yes, in many cases that is the case, and it is happening. Just
watch www.oasis.org to see industries scrambling to get their common
vocabularies defined. But once again, it is possible to do partial,
but correct, processing of files even when you don't know what half
(or more) of it means.

Marcel
Bijan Parsia
2012-01-28 10:06:59 UTC
Permalink
Well, for Squeak---and the typesetting world---they're different
fonts.
Really? Then I'm sorry and I have so say that I wanted to talk about font
*families*. Everything else seems very strange for me. I would never
expect that a larger font has completely different glyphs.
Eh...there are a lot of confusing overlapping terms that get screwed up in
a variety of ways. I was thinking of "font" as "collection of
glyphs" or as "StrikeFont". My main point being that the extant Squeak
layout manager can handle, to some degree, various fonts in a single
paragraph. This was sufficently shown, to my mind, by the various NewYork
"sizes", as those are distinct StrikeFonts. Yadda yadda.
I'm glad you posted a gif to prove that you're right.
Well, me too. It did clear things up :)
I'm also very glad
that you take it personal to defend Squeak (even it I didn't attack it or
challenge you) ;-)
Oh well, 6:30 am, pre-stimulants, late night. :)
Your argument, however, isn't fair.
Me? concerned with *fairness*! MuhwAHAHAHAHAHA!
As Squeak is turning-complete, it can
do everything (perhaps with the exception of washing cars), if programmed
correctly. The system that comes right of the box however can't show
multiple forms if you don't reprogram (which includes manipulating
textstyle objects) it.
Hmm. Acutally, I don't think *this* is fair. I *thought* that the original
issue was whether there was a "rich text widget" type thing. The
workspace, as it stands, is one...albeit that without tweaking, it
displays a single fontfamily, alignment, etc., though it does do multiple
sizes, styles, etc.

But is the workspace a "widget"? It seems to me to be a *tool* supporting
a certain range of activities. Now you may argue that if it's going to
do multi-size, it might as well do multi-family. I probably agree, and I
think that the single family default is a legacy issue.

However, presumably it would be a defect of a rt widget if you *couldn't*,
if desired, turn *off* some flexibility. If you wanted to use somethign
Workspacey for end-user data entry, wouldn't you want to reprogram the
menus *anyway*?
So let's settle that argumentation by agreeing that we're both correct.
Ok, so long as, to paraphrase Orwell, "some animals are more correct than
others" :)
P.P.P.P.S. But since we feature-whining...what I'm *dying* for is a Squeak
port of Lucene (a java VTwin full text search
clone): http://lucene.sourceforge.net/ Any java literate folks up to
taking it on? For *meeeeeeeeeeeeeeeeeeeee*? <blink/> <flutter/> <blink/>
[snip]
Well, then go forward with a good example and port it... :-)
Well, I *am* java illiterate :) I was kinda hoping that a super-Java-dude
would come and save the day.

I will attempt ransacker (http://ransacker.sourceforge.net/) if I get some
time.

(Still drooling over the thought of Lucened swiki searches...or, heck, we
could get rid of the "searching method source will take several
minutes" :))

Cheers,
Bijan Parsia.
Stefan Matthias Aust
2012-01-28 10:10:59 UTC
Permalink
Hi Stefan
thanks for all your work.
You're welcome.
Are you selling application in Squeak?
Yes. Well, not me personally but the company I'm working for.
can you say more?
It's a solution for a customer who wants to sell customized weather reports
to ship captains. We used Squeak to implement a server that automatically
processes weather report requests and that creates the responses calculated
from some 50 MB of weather data.

Smalltalk turned out to be really helpful as we're still tweaking and fine
tuning the application while feeding it with test data with no compile time
interruptions or other turn-around-time lost.

Squeak is a little bit slow but with a fast PC it's sufficient and still
cheaper than a professional Smalltalk system. So as I didn't want to use
Java I convinced my boss to try out Squeak ;-)

The main obstacle was Squeaks poorly implemented file io. They're very
slow (but one can fortunately do this
s := (FileStream fileNamed: 'foobar') contentsOfEntireFile readStream
work around) and we lost time because of that really stupid behavior of
opening requestors if a file doesn't exist or whether it should be
overwritten. I cursed the author of that design multiple times. IMHO,
there should be two different level: core and UI.

We also tried to provide a small administration UI but failed because that
would have taken too much time compared to a solution in Java or another
language. Interestingly, the customer wouldn't have cared about Squeak's
look (MVC, with my newlook extensions)

bye
--
Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf
Dan Ingalls
2012-01-28 10:15:00 UTC
Permalink
So please let me repeat my question: Can you show one word written in font
Comic12 and another word in font NewYork12 in the same workspace in the
same size? Looking at the "Welcome to..." window, there should be a way,
but AFAIK, you can't.
Oh really, of course you can. Add some more fonts to the textstyle.
There's nothing there that makes it impossible or even hard to mix
fonts. Included is a tiny gif to illustrate.
| t comic |
t _ 'hello, world' asText.
comic _ TextStyle named: #ComicBold.
t addAttribute: (TextFontReference toFont: (comic fontOfSize: 24)) from: 8 to: 12.
StringHolder new textContents: t; openLabel: 'x'.
It would be easy to add attributes of TextFontReference to selected text in much the same manner that sizes and colors are done today.
I too was surprised that no one knew about TextFontReference. Adding the interface which you suggest would certainly simplify access to this capability.

Also, we could add an extended 'copy with actual font references' command to the text editor. This would convert relative font references (font1, font2, etc) in the copied text to absolute font refereces determined from the textStyle of the source paragraph. Then if the selection were pasted elsewhere, it would retain its original fonts.

- Dan
Bijan Parsia
2012-01-28 10:20:10 UTC
Permalink
Hmm. This isn't quite true either. Can you really show multiple fonts in
multiple sizes in one workspace?
Yes. Try "set font" in the "more..." yellow menu of a workspace. I just
did NewYork14. I have pasted in other fonted text..
Please let us define "different font" first.
Well, ok, so long as we do it correct.
For me, NewYork12 and
NewYork24 aren't different fonts but just the same font in different
sizes.
Well, for Squeak---and the typesetting world---they're different
fonts. NewYork12 and NewYork24 can have completely different glyph
sets. Er...they *do* have completely different glyph sets.
And changing the font size is all you can do with the "set
font..." menu option.
Well, you didn't *say* through the "set font..." menu option...though it
turns out with *minimal* tweaking, you can make that work too.
So please let me repeat my question: Can you show one word written in font
Comic12 and another word in font NewYork12 in the same workspace in the
same size? Looking at the "Welcome to..." window, there should be a way,
but AFAIK, you can't.
Well, at this point, I'm no longer *confident* that I can satisfy your
concerns with more words that may not answer to your understanding. But
perhaps a picture will do the job:

Loading Image...

I would show the menu which now has Ypatia14 as a font option...but I
can't remember where I put the delay code for the screenshot that Bob did
up for me, and don't feel like it :)

The simplest way to add *more* fonts (not that there's just one at the
moment) to the set font...menu is to inpsect DefaultTextStyle, and
evaluate (something like):
self fontAt: 5 put: (ComicBold fontAt: 3)

Then open a new workspace.

The UI studly with time on their hands can work up a new font menu that
collects various vaguely related "fonts" into "families" under a heading
in the menu with submenus for the "font sizes".

So, I *believe*, I sincerely *hope*, that it is now established that there
*is* a sufficently *rich* Rich Text Widget for, at least, *some*
purposes. I cannot say that it answers to *all* purposes, but it's also
pretty clear that *building* ones, using a variety of techniques, is
non-burdensome to various degreeds.

Cheers,
Bijan Parsia.

P.S. Well, *yes*, I'm feeling a touch snippy...what's it to you? ;)
P.P.S. To be fair, I think mine is a *reactive* snippiness. I do tend to
get snippy when the number of "this what squeak needs before I'll deign to
use it" posts outweigh the "here's something cool to play with",
espeically when the former start talking about "most" or "many" people,
etc. etc.
P.P.P.S. Not that your concerns aren't valid, well-phrased, interesting
yadda yadda yadda. But I'd like to see a few more, "Well, here's one way I
can use squeak as is." type posts. Or "here's a small thing that would
help me, anyone up for it?"
P.P.P.P.S. But since we feature-whining...what I'm *dying* for is a Squeak
port of Lucene (a java VTwin full text search
clone): http://lucene.sourceforge.net/ Any java literate folks up to
taking it on? For *meeeeeeeeeeeeeeeeeeeee*? <blink/> <flutter/> <blink/>
P.P.P.P.P.S. (Different "blink" tag...don't be fooled.)
Bob Arning
2012-01-28 10:20:24 UTC
Permalink
It would be easy to add attributes of TextFontReference to selected text in much the same manner that sizes and colors are done today.
Well, here it is. It changes ParagraphEditor>>offerFontMenu (cmd-k) so that all availbale fonts are shown.

Cheers,
Bob

===== code follows =====
'From Squeak2.9alpha of 13 June 2000 [latest update: #2440] on 1 July 2000 at 2:36:34 pm'!
"Change Set: manyFonts
Date: 1 July 2000
Author: Bob Arning

Changes ParagraphEditor>>offerFontMenu to offer all known fonts as options for changing the font of the current selection."!


!ParagraphEditor methodsFor: 'editing keys' stamp: 'RAA 7/1/2000 14:33'!
offerFontMenu
"Present a menu of available fonts/sizes, and if one is chosen,
apply it to the current selection.
Use ALL Fonts!! "

| reply niceNames realFonts |

niceNames _ OrderedCollection new.
realFonts _ OrderedCollection new.
StrikeFont familyNames do: [ :fam |
(TextStyle named: fam) fontArray do: [ :sf |
niceNames add: sf name withoutTrailingDigits, ' ', sf pointSize printString.
realFonts add: sf.
]
].
reply _ (SelectionMenu labelList: niceNames selections: realFonts) startUp ifNil: [^self].
self replaceSelectionWith: (
Text
string: self selection asString
attribute: (TextFontReference toFont: reply)
) ! !
Stefan Matthias Aust
2012-01-28 10:20:28 UTC
Permalink
As usual, there is a pretty big difference between what you can do in code
and in the UI. Although my knowledge is no complete here, my impression is
that there is a limit to one TextStyle per paragraph. Now a TextStyle
contains an arbitrary array of StrikeFonts--in the vanilla image these just
contain different sizes of the same 'font'. The terminology is difficult
here, but a StrikeFont is essentially a bitmap with the different
characters. So AFAI understand it (and I've tried it) you can just place
SF's with different 'fonts' in the same TS and off you go. This is of course
not an ideal situation today, but as usual I think the problem is that it's
far from bad enough that someone will take the effort to improve it, so to
speak. I'd guess the problem is that the TextScanner needs some fast
primitives, and passing on a bunch of different TS's might be a problem in
this respect.
This was the information I was looking for and even I'd call it a big hack
it's a clever way of working around the current limitations. Thank you.
Dunno. But don't let the interface fool you :)
This reminds me on a way I think the UI task force (or whatever they call
themselves) of the Gnome project goes. If somebody reports a missing
feature which is actually already available, then it's a bug in UI. Hidden
features are of no value. So let's consider this as a bug report ;-)


bye
--
Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf
Stefan Matthias Aust
2012-01-28 10:23:31 UTC
Permalink
Well, for Squeak---and the typesetting world---they're different
fonts.
Really? Then I'm sorry and I have so say that I wanted to talk about font
*families*. Everything else seems very strange for me. I would never
expect that a larger font has completely different glyphs.

I'm glad you posted a gif to prove that you're right. I'm also very glad
that you take it personal to defend Squeak (even it I didn't attack it or
challenge you) ;-)

Your argument, however, isn't fair. As Squeak is turning-complete, it can
do everything (perhaps with the exception of washing cars), if programmed
correctly. The system that comes right of the box however can't show
multiple forms if you don't reprogram (which includes manipulating
textstyle objects) it.

So let's settle that argumentation by agreeing that we're both correct.
P.P.P.P.S. But since we feature-whining...what I'm *dying* for is a Squeak
port of Lucene (a java VTwin full text search
clone): http://lucene.sourceforge.net/ Any java literate folks up to
taking it on? For *meeeeeeeeeeeeeeeeeeeee*? <blink/> <flutter/> <blink/>
P.P.P.P.P.S. (Different "blink" tag...don't be fooled.)
Well, then go forward with a good example and port it... :-)

bye
--
Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf
Tim Rowledge
2012-01-28 10:25:46 UTC
Permalink
So please let me repeat my question: Can you show one word written in font
Comic12 and another word in font NewYork12 in the same workspace in the
same size? Looking at the "Welcome to..." window, there should be a way,
but AFAIK, you can't.
Oh really, of course you can. Add some more fonts to the textstyle.
There's nothing there that makes it impossible or even hard to mix
fonts. Included is a tiny gif to illustrate.

tim
--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: XA: Execute Address field
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multifont.gif
Type: image/gif
Size: 4838 bytes
Desc: not available
Url : Loading Image...
Raab, Andreas
2012-01-28 10:27:07 UTC
Permalink
So please let me repeat my question: Can you show one word
written in font Comic12 and another word in font NewYork12
in the same workspace in the same size? Looking at the
"Welcome to..." window, there should be a way, but AFAIK, you can't.
It's quite possible - all you need is to classify all the fonts in the same
text style. Not a good way to do it since some of the information that is
supposedly the same for a text style are different in the fonts but
possible. More generally, I'd like to see some of the information that is
currently in the text style to be in the font itself so that all you need to
fully specify the layout of some string is defined in the font. Then, you
basically don't need any text style any longer (and besides - specifying the
fonts through an index in the font array of a text style rather than an
explicit point size and the appropriate attributes is pretty dangerous if
you change the style these days).
So, I *believe*, I sincerely *hope*, that it is now
established that there *is* a sufficently *rich* Rich Text Widget
for, at least, *some* purposes. I cannot say that it answers
to *all* purposes, but it's also pretty clear that *building* ones,
using a variety of techniques, is non-burdensome to various degreeds.
Hm ... just wondering. Why is it that so many people cry for a Rich Text
Widget?! Wouldn't a HTML spec serve the same purpose?! And we do have the
formatter for it right in the system.

- Andreas

PS. Since we're talking about text here - the three things we really need
for good text layout are a) fractional widths b) left/right side bearings
and advance widths (for overhang and underhang characters) and c) kerning
pairs (and possibly automatic detection of common ligatures). Anyone up to
it?!

Continue reading on narkive:
Loading...