[ Skimmer's note: look for bulleted section at the bottom. ]




Now that I have time to be a squeaker again I've begun to re-write all 
the AI stuff I lost to my old HD back in the spring...

I'll cover the simpler subject first...

On a whim I had the idea of seeing wheather using a set of libraries, 
"ggi" and "gii" would work better than the current framebuffer driver 
which only yields 8-bit color (!).

OK...

I went and looked at the existing framebuffer drivers and found that 
while the author definitely knows more C than I do, he also thinks that 
I know more C than I do. For example, what does C do when you simply 
declare a struct without specifying its contents? eg:

struct foo;

Being baffled by these I found the header for the display (something 
like SqVMDisplay.h in the ./vm part of the platform source..)

What I found was a file with exactly three lines of comments. Those 
lines did nothing more than denote sub-parts of a structure declaration.

While I can probably guess the purpose of many of the functions listed 
there, I don't know what the "gotchyas" are... For example, does a 
certain function have to synchronize with something else in the VM? Must 
it have/must it avoid certain side-effects? What are the limits on the 
parameters and return values?

This is doubly irksome to me beacuse I probably just got done failing my 
first course in software engineering, in part, because the professor 
GAVE ME A ZERO FOR NON-DOCUMENTATION DESPITE A 3K README FILE!!!


I won't press that any further, The other subject I wanted to mention 
was the structure of Projects, Worlds, and PasteUpMorphs.

One of my biggest areas of frustration last spring was trying to figure 
out how to make a mini, and strongly isolated, project or something for 
my AI to play with and to facilitate my interaction with it. The 
methodology I was using at the time was to use inspector/explorer to 
attempt to discover the structure of a world and then to find a way to 
construct a customized version.

That effort pretty much failed...

This time around it dawned on me that I should be trying to discover how 
it is first initialized and work forward. Success!

I found that the key to the whole shebang is "Project". That to create a 
new project. I then tried this code on a paste-up morph:

#
self beWorldForProject: (Project newMorphicOn: self)
#

-- And royally messed up my desktop.

There are at least two things happening here, the first being that the 
new world is also a member of a seperate world causing conflicts and 
race conditions. The second, being a bunch of what I perceive to be 
design issues with the factoring of the whole mess...


# 1 # PasteUpMorph has a serious case of multiple personality disorder. 
At first it seems to be your usual abstract morph class... However, two 
variants are advertised in the "Object Catalog" as "Playfield" and 
"Holder", under two very seperate categories. The difference in the case 
of holder being that it has a table layout, it is set to shrink-to-fit, 
and it has a different color and border. It's other personality is to be 
the workhorse class for Morpic desktops. Although it appears to support 
an implementation of Morphic, it is only a small part of a functoning 
Morphic world. (proposal below)

# 2 # Project has a similar case of multiple personality disorder. It 
seems to do two very distinct things _AND_ attempts to suppport two very 
different UI paradigms (MVC and Morphic). It's other role being that of 
creating a partially isolated project with respect to certain system 
services such as changesets, transcript reporting, and file-in/file-out.

Firstly, it seems that the responsibility of setting up a project should 
be seperate from seting up an MVC or Morphic world. I propose isolating 
the functionality for a morphic world in a new class "MorphicWorld" 
(although I would immagine most squeakers who post to this list would 
rather pick a word at random from the dictionary because actually 
calling it what it is would make Squeak too easy.)

In this case you can have Morpic worlds within a single project.

# 3 # There are too many assumptions about how a morphic world will be 
used. In my case, I want to create a nested world for isolating my AI so 
that it would have to work doubly hard to mess up the rest of my image. 
Another use for this would be in colaboration, that a single world will 
be shared between users but still allow the user simultanious access to 
his own desktop in a semi-secure fassion.

The current implementation (which is spread among at least three classes 
that I have been able to identify), assumes that the current paradigm of 
making new worlds children of the current one. Every method I've looked 
at assumes that the current world will be the topmost thing on the 
desktop, attached not just to any Form but Display specificly (BAD BAD 
BAD!!!)

I beleive that a refactoring of this can help Morphic support the 
paradigm bending which seems to be my vice. ;)

As a final note, I must point out that I am still a raw newbie when it 
comes to GUI programming and I have much to figure out.