mit-scheme-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MIT-Scheme-devel] Splitting screen into <screen> and <tty-screen>.


From: Matt Birkholz
Subject: [MIT-Scheme-devel] Splitting screen into <screen> and <tty-screen>.
Date: Tue, 28 Jul 2009 04:41:39 -0700

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? :-)

Attachment: patch-Gtk-Screen-1.diff.bz2
Description: Edwin support for Gtk-Screen.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]