a friend requested me a screenshot of syxgtk, it's the first one here:
http://code.google.com/p/syx/wiki/ScreenShots.
I would like to explain how the 'asd.st' script works:
1) Create the window, and connect buttons with something like button when:
#clicked send: self -> #onClicked
2) Gtk main
2.1) This forks a process that calls a primitive
2.1.1) The primitive create a thread in which gtk_main() will run
2.2) Semaphore new wait (won't never be signaled this semaphore, it's used
just to keep the process suspended so keeping Syx up if no other process
is running)
3) Suspend the current process. This because the console actually is in
blocking mode, so we need to suspend the process. There's a way to let the
console be asyncronous, already tested using Semaphores, but won't work
with readline (any suggestion here?)
Now, we connected signals to a special syxgtk marshaller, which does the
following:
- transform GValue to SyxOop
- obtain the callback to call
- create a new process
- wait that process for being terminated (remember the callback is called within a OS thread)
These i think are pure Syx callbacks, really very easy to implement for
any other external loop.
How it differs from my old SqueakGtk? Just read:
- each C call had one more redirection than in Syx, because in C calls using SWIG automatically handles self pointers by accessing instance variables
- main loop had to be implemented in a Squeak-side method by doing the iteration manually
- the marshaller had to forward its function to Squeak, because we can't convert from GValues to Squeak objects since we can't lookup classes
- we save all that GValues in a special C-side stack
- set the jump for future longjmp and call the interpreter
- the main loop checks for callbacks, then obtain the list of arguments from that list of GValues and does its job
- once returned from all callbacks, it's time to do the longjmp to return from the C callback
It was a pain, slow and moreover wasn't so safe to use setjmp/longjmp and a
stack of callbacks.
Bye.
