[FIX] UI Bitrot

[Todd Fleming]

I'm really impressed with Timmy's reverse-engineering work.  He came
really close to finding Bug 2 as evidenced by the following quotes:

 > Since "constructors:" is plural, I added the curly braces
 > there but it seems weird that the list would always have only one
 > element in it.

and

 > The whole right column of (osWindow blah) is unused.


This patch fixes several UI bugs; it runs again.

Note: Do *not* apply to patch that Timmy posted today; it is based on
an unfortunate misunderstanding caused by Bug 2.

Bug 1
=====
src/ui/graphics.slate is in AutoLoad, which broke the instructions
in src/ui/README.  "load: 'src/ui/graphics.slate'" caused the file to
load twice.  This is why #parents: misbehaved and the call to #text:
failed.

Bug 2
=====
Fortunately I keep old sources around to compare with.  Unfortunately
someone made wholesale cosmetic changes to
plugins/sdl-windows/windows.slate which made it difficult to compare.
One of those cosmetic changes introduced a bug.

Someone changed:
   Windows eventTable add:
       (each key) ->
       (Windows EventTableEntry
           newPrototype: (events atSlotNamed: (each value at: 0))
           constructors: (each value at: 1))].

To:
   Windows eventTable at: each key put:
     (Windows EventTableEntry
        newPrototype: (events atSlotNamed: each value first)
        constructors: each value first)].

This should be:
   Windows eventTable at: each key put:
     (Windows EventTableEntry
        newPrototype: (events atSlotNamed: each value first)
        constructors: each value second)].

This caused constructors to be initialized with a (wrong) symbol
instead of a list.

Bug 3
=====
Added "lobby" in several places.


Now, to fix misconceptions caused by Bug 2:

 > Brian: As it is, I'll bet  that "entry constructors" should be
 > {#theSymbol} rather than just #theSymbol.

"entry constructors" is a list of symbols.  ex:
#(osWindow mouseButtonPosition) or #(osWindow mouseMotionPosition).
This list tells "entry@(Windows EventTableEntry traits) construct"
what needs to be initialized for a particular type of message.

 > Timmy: Since "constructors:" is plural, I added the curly braces
 > there but it seems weird that the list would always have only one
 > element in it.

Actually, it normally has 2 elements in it.  In the future it will
have more.  Ex: I planned to add modifier key state to mouse
messages but never got around to it.

 > Timmy: It looks like prototype is just the name of the class to copy
 > for the event and constructors are a list of symbols that are
 > applied after it is copied through the 'construct:' message.

Almost correct; prototype isn't just a name of a something to copy;
it's an actual prototype.
"newPrototype: (events atSlotNamed: each value first)" grabs the
prototype from the events namespace.

 > Timmy: I'm guessing if you had a move event, suppose you would fill
 > the moveEvent's slots with the x position and y position. If the
 > ExternalLib interface to get the x and y coordinate required two
 > calls, you could have each call in a separate construct: message.
 > You could mix and match depending on what slots the object has.
 > At least that's what I'm guessing.

Bingo!

 > Timmy: The whole right column of (osWindow blah) is unused.

Bug #2.  It's now used again.

 > Timmy: Also it looks like there is a case issue. They use
 > #(MouseLeaveEvent ...) up there but then in the methods there is:
 >
 > event@(Event traits) construct: _@#mouseMotionPosition [...]
 >
 > I can't find a _ at mouseLeaveEvent or _ at MouseLeaveEvent though.

#MouseLeaveEvent refers to a prototype in the events namespace.
The right column contains the symbols used for
"event@(Event traits) construct: _@#blah".  They aren't
capitalized because they are not prototypes.

Todd

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ui_bitrot_fix.gz
Type: application/x-gzip
Size: 6504 bytes
Desc: not available
Url : /archives/slate/attachments/20060411/301e3df4/ui_bitrot_fix-0001.bin