1 files changed, 55 insertions, 0 deletions
diff --git a/doc/window_ui.ideas b/doc/window_ui.ideas
new file mode 100644
index 0000000..789f230
--- /dev/null
+++ b/doc/window_ui.ideas
@@ -0,0 +1,55 @@
+so assume the client can be made small enough to run with RAMTOP
+set to 40K or less...
+
+for windowing to be useful, we have to have at least 4 of them,
+preferably more.
+
+scrollback would be a nice feature. it's a tradeoff of course,
+more scrollback per window = fewer windows.
+
+suppose we can manage to set RAMTOP to 36K ($9000).
+
+we need 1K for a font. for one thing, we want { } ~ ` glyphs (and
+maybe some chunk of latin-1 based on the XL intl set). for another,
+we want the font to be in screen order, so putting $41 in screen RAM
+actually show a capital A, etc. this will speed things up, and also
+allow for nick tab-completion to search backwards through screen
+memory (so we won't have to keep a separate list).
+
+we *don't* need a regular GR.0 screen. all display will be done with
+the windowing UI.
+
+we *do* need a GR.0-like display list, with an LMS for every line.
+probably it'll be 23 lines of channel/query text, and 2 lines for the
+input/status area (and a blank line between them). this will be ~80
+bytes, and the different screens can share it (the LMS addresses get
+updated when switching windows).
+
+a GR0 line is 40 bytes. we have, say, 12200 bytes. that's 300 lines.
+the inputbox is shared between all the windows. that gives us 13
+23-line screens, if we don't do scrollback. if we allocate 60 lines
+per screen (23 of which are visible at any given time), that gives us
+5 scrollable windows. not really enough of them: one for each channel
+or query, and one "everything else" (server messages and PMs that
+aren't queries).
+
+if it's 50 lines per window, we get 6 of them.
+
+how about they aren't all the same height?
+
+the 'everything else' window and the primary channel can have more lines.
+say, they get 59 lines each, and we have 4 more windows at 46 lines.
+that puts us a bit over (12080 bytes) but I think it's doable. that still
+only gives us 6 windows though. not worth doing.
+
+what about a non-scrollable server window, then 6 46-line scrollable
+windows, one of which is "msgs" (all non-query PMs). that gets us 5
+channel/query windows, plus the msgs window will be more convenient
+than having the msgs mixed with server text.
+
+what if we want 8 windows? they'd only be 37 lines each (not even a
+whole screen of scrollback).
+
+maybe we can scrunch the client down so it fits under 32K... maybe
+that can include the font too, so we have 16K for window lines. that
+would give us 8 51-line windows or 7 58-line ones.