I have a patchset (attached) that replaces Edwin's screen struct with SOS classes <screen> and <tty-screen>... and it works! Edwin seems fine even though (selected-screen) might be #[instance 42 of <tty-screen>]. A <gtk-screen> class will follow shortly (ha!).
I kept just a handful of slots in the general <screen> class: root-window, visibility, x/y-size and debug-trace. The rest, like the "state" slot, went to the <tty-screen> class -- the character-cell, output optimizing type of screen. Putting the state slot in <tty-screen> would normally change its default accessor from "screen-state" to "tty-screen-state", but this disturbs several files: bios.scm, os2term.scm, tterm.scm, win32.scm and xterm.scm. As an exception, I specified the accessor name "screen-state". The rest of the slot accessors did get renamed. E.g. the original screen-move-cursor procedure now uses the tty-screen-new-matrix slot accessor. Obviously tty-screen-specific, it was renamed "tty-screen-move-cursor". Thus many old procedures were noted as tty-screen-specific. Others were genericized -- extended to handle non-tty-screens. And some were turned into full-blown generic procedures: screen-beep, set-screen-size!, update-screen!,... I have just begun to imagine converting all of the old window classes to SOS, starting from vanilla-window. I expect <buffer-window> will be an abstract class with specializations <tty-buffer-window> and <gtk-buffer-window>. The outline struct hackery goes in <tty-buffer-window>, and my <scm-layout> hackery goes in <gtk-buffer-window>. But perhaps there are other ideas kicking around. At this point I am still asking: Is this The Right Thing? Are there any obvious pitfalls to converting from Edwin's old class system to the new, spiffy SOS? Has anyone else attempted (or just thought about) this? Are there any objections? (Should it be spelled <terminal-screen> or <console-screen> or something? :-)
patch-Gtk-Screen-1.diff.bz2
Description: Edwin support for Gtk-Screen.
_______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
