Quote:
This sounds fantastic in theory, but in practice I cannot think of a way of making a GUI application "page" its output. I tried for a while and failed, with MUSHclient.
Well, strictly speaking the behavior of the functions to handle data in the buffer is the biggest issue. Stuff has, otherwise, done paging in GUIs since as far back as the first copy of Word for Windows. I do think that, should someone ever work out what the rules need to be under such a system, along with the text positioning, that a flag be added, which designates *if* the behavior is in effect, and if so, how commands related to the buffer, line retrieval, etc. actually work. Some things, like triggers wouldn't change much, since they already "post process" after a new line. One just needs to treat any "position change" that moves up or down a line as a "new line". I.e., ten characters get displayed on a line, then text position in moved up one line, then "the prior line" is obviously "complete" at that point, whether or not a newline itself was received. Figuring out "which" line you last received has to be more direct though, which I always thought worked wacky in the client as is, since obviously the last line "received" is not longer the last line in the buffer, its which ever line was changed prior to the last time the cursor moved. The same *new line* could appear on the same existing buffer line 50 times, as something like animation runs, and its never going to be the "last line in the buffer", unless it just happens to be the last line in the buffer those 50 changes are made on.
Oh, and the other distinct issue with paging, once you have *paged* the cursor can't move back up the buffer, into lines that are "not on the page", even if only 5 lines have been received for the page, but some twit asked it to move up 10.
It wouldn't be easy, but certainly not impossible, and the biggest issue is getting the rules of "how" it has to work and what therefor appears in the buffer space, and why, are defined. The only quirk is, in most of them I have used that support scrolled buffers and logs, the "log" contains a complete copy of everything that happened, including position changes, not just the final lines for that "page". It has to, since you can't keep buffering thousands of lines, until a page, before writing the output. You have to limit how much is on screen before its "assumed" that you have reached the end of the page, then write anything above the current "top" line (many would do that, since there was a fixed 25-30 lines on the screen), or you have to write is as it happens, and how they have some way to "replay" the logged data. Obviously, for all practical purposes, Mushclient would have to use the former, and assume that anything that would logically have scrolled "off" the page is "gone", and therefor safe to write to the log.
Again, its only a matter of how you define the rules of how to handle this, and most logging clients with scripts have used roughly the same rules for ages. And the paging itself, has been done quite often in many programs, as far back as GUIs.
Its just not going to be me that does it. lol At the least I still don't have the spare change to buy something with fracking MFC libraries in it to try. :p |
![[Go to top]](/images/gototop.gif){kind=small}
top