Telopt support in tintin is dealt with at the lowest input level and keeps track of the input length, but the internal scripting language itself is entirely string based, and like your average mud server, pretty much every string based routine relies on the NUL byte being solely used as the string terminator.

Sorry, I missed this the first time around. My reasons are basically the same as Vassi's. I don't fully trust something designed by Zugg, to be very frank, especially given the history of him introducing weirdnesses into his own client's handling of the protocol, making people who are actually standards-compliant appear to have bugs.


My pipe dream is that the MUD sends a semantically rich description of what is going on, and the client renders it as text, images, whatever. Of course this is probably all but impossible in practice if you want to keep it general; it could be done for one game at a time I think.

Note that in the examples I showed, the MUD isn't actually sending rendering instructions; it is sending information that MUSHclient plug-ins render in some interesting way (in this case, by creating and populating a "mini-window"). I suppose it would be possible to send actual rendering commands, using some kind of vector art format so that window size doesn't screw up the result too much.


Frankly? Not going to happen, even though it would be cool. It'd be reinventing the wheel, except that instead of a wheel it'd be like reinventing the steam engine, the combustion engine, all the parts of the car ……


Much more likely, and we can always refactor specialized packages into common packages if we see the gain.

The nice thing about clients with very rich plugin capabilities like MUSHclient is that the onus isn't on the client author to support all this stuff. If the plugins are sufficiently capable, the MUD author can write the plugins him/herself.

I don't think it's really all that complicated is it? I mean, most of these things, like the compass, can be accomplished with fairly simple models. It's trivial to allow MUD owners to skin them, so long as they know the dimensions of the image you can tell the client to pull the skin from any arbitrary URL (i.e. their mud server) That is the way our Moon phases and Character art and status icons work, since we want to be able to change them at any time without forcing a client update.

Now paper dolls and paper-doll like inventories I can see as being more complex, since you can't guarantee which body parts the MUD will be using or even if they have humanoid PCs, however you could go for a more generic drag-drop interface if you wanted to, with squares next to icons for different body parts which - again - can be skinned very easily.

The basic case isn't that complicated. It's when you want to start talking about generic widgets that scroll, drag-and-drop, etc. that things get complicated.

Grossly speaking, you could show a quest journal in two ways:

- tell the client what the quests are, and have it display them somehow
- tell the client to create a list widget, populating the list with elements x_1…x_n.

The latter is more general because you don't need client-side support for new windows. If you decide to implement a list of places you've visited, you can just use the same list display widget (which could optionally be skinned by the MUD etc.) instead of needing new client-side support for displaying the list of places using the same widget.

Note that even a half-intelligent client would have some kind of generic display widget that it could recycle, but you'd still need to support it. Moving the basic set of widgets to the protocol level allows you to easily describe new interfaces without touching the client at all.

Just explode the ZMP sub request into an array of strings before passing it to the scripting language. That's the main intent of using the NUL bytes – you can easily split the sub request into an array of strings without needing to copy the strings (in C) and without needing an escaping mechanism for "valid string" delimiters.

Most non-toy scripting languages I have seen do not rely on the NUL byte. That's one of the oft-touted advances of almost every language over C. Python, Ruby, Perl, PHP, etc. all allow full binary data inside of strings. Some of them have separate "binary strings" versus Unicode strings these days, but dealing with them is fairly straight forward, and the TELNET buffers would have to be binary strings in those environments anyway as bytes like IAC and so on are invalid UTF8 data (and languages that use UTF16 force the use of a byte array anyway since TELNET is 7-bit/8-bit).

Ah, gotcha. Well, I don't want to send any rendering commands. For a compass, it would be up to the client to determine how to render it. The package would specify a list of standard directions.

The problem with sending any images for GUI controls is that it can and will quickly result in some quite ugly GUI controls, due to a combination of low-quality artwork that will inevitably be used by most MUDs and the fact that the MUD's graphics style will not be the same as the client's graphics style. I could see at most a vector graphics system used for geometric MUDs and maybe for the paper doll system. And then background images and photos and the like (which I don't expect most MUDs to use).

In general, I would stick with a generic widget-baed system for the main stuff but make it relatively simple. We don't need advanced layout, IMO. I'm sure we could come up with a small list of very specific widgets that cover a very wide variety of uses.

For example, a table/list widget that lets you specify a few columns of data and some buttons for each, along with a simple dialog widget, could be used for stores, player creation, inventory, dialog trees, etc.

We could try to make nicer widget that result in a better UI (no popup/overlay dialogs for item details, for example), but then we start getting to more specific use cases that are harder to implement, harder to reuse, etc. A "better" inventory window might show a list of item names in a big font with smaller item details (type, cost) in a small font underneath, with a pane on the right-hand side showing full details for the selected item. I can think of a few other uses for such a widget, but not a lot. One would then still need another widget for dialog trees and the like.

Of course, it's entirely possible to have a base GUI package and then some more specialized GUI packages. The servers have to go through the trouble of checking for which package (if either) is available before trying to use them first, of course.

There's a very fine line between "too simplistic to be useful" and "too complicated to be implementable." Trying to stay on that line is never easy. :/

I can't really come up with a truly powerful GUI library that doesn't require at least some kind of XML->widget layout engine in the client combined with a standardized scripting language (e.g., JavaScript). It either comes down to highly specialized widgets with one or two uses each or very generic widgets that will result in relatively mediocre (but still quite usable and understandable) GUIs.

How about we start hashing out some simpler packages first? Say, a chat or subwindow package. A subwindow package might look like (in informal language):

subwindow.create

Defines a new subwindow. Receives two arguments. The first argument is a unique ID for the window used in other commands, which MUST be alphanumeric. The second argument is the user-visible title for the window, which MUST be UTF8.

If subwindow.create specifies the ID of a window that is already open, the command updates the window's title but has no further effect.

The window ID can be any alphanumeric string, but it MUST NOT be empty and it MUST NOT be equal to the string "main."

subwindow.close

Closes a specific subwindow. Receives a single argument, the unique ID of the window to close.

The window ID MUST NOT be equal to the string "main." If the window specified does not exist, this command has no effect.

subwindow.select

Selects which window output will be sent to. Receives a single argument, the unique ID of the window to select.

If the argument is equal to the string "main" then the original client window is selected for output.

If the specified window does not exist, the original client window MUST be selected.

Usage

The subwindow package allows for the simple definition of alternate output windows for MUD output. Each output window should behave similarly to the main output window. The package allows for the creation and removal of subwindows, but it does not allow for the main output window to be removed or altered.

Example usage for an OOC chat subwindow might look like the following:

server: ZMP "subwindow.define" "oocchat" "OOC Chat"
server: ZMP "subwindow.select" "oocchat"
server: Welcome to OOC Chat!\r\n
server: ZMP "subwindow.select" "main"
server: login/gameplay/etc.
server: ZMP "subwindow.select" "oocchat"
server: Zach: hey guys, anyone around?\r\n
server: ZMP "subwindow.select" "main"
server: more gameplay
server: ZMP "subwindow.select" "oocchat"
server: Thomas: hey Zach, just me right now, wazzup?
server: ZMP "subwindow.select" "main"
server: more gameplay

Open Discussion

1) Should subwindows be allowed to have dedicated input lines? That would require a client->server, subwindow-specific zmp.input type command, e.g. subwindow.input, that takes two arguments: the target subwindow and the line of input.

2) Should the server get notified if a user explicitly closes a subwindow? Maybe a client->server subwindow.closed command.

3) Should the server have extra flags it can set for a window, to for example turn on/turn off dedicated input, disable the ability for users to close the window, etc.?

4) Should there be layout hints from the server, giving the client an idea of where it should put the window? e.g., "top", "right", "left", "bottom" ?

5) Is there a need to more clearly define "output," to make it clear that things like color commands, image embedding, etc. should all be directed to the selected subwindow, or is that obvious enough?

Might be an idea to use tintin's format for describing an exit:

{n}= {1}
 {e}= {2}
{ne}= {3}
 {s}= {4}
{se}= {6}
 {w}= {8}
{nw}= {9}
{sw}= {12}
 {u}= {16}
 {d}= {32}

The advantage is that it's easy to extract the x y z direction of the exit that way, allows weird exits like nue, and is pretty compact. 0 logically indicates a no exit room.

Agreed. Really, there aren't that many general widgets. Off the top of my head, I can think of:

- Dialog boxes. Yes/No; multiple selection; maybe input box. Maybe bulk-text input, for things like descriptions. (Why not use the client to edit big blocks, instead of clunky line-mode editors in the MUD?)
- Tabular data. A list is a special case where there's just one column.

… which are the same you gave. The concepts can be taken far, if you allow other commands to create interesting output. For example, you could specify a hyperlink using other commands, and use that to create "buttons". You could specify some kind of image, and use that to implement a grid-like inventory using a table.

Things like paper doll displays get more complicated, though.


I think so, yes, for a few reasons (but my real answer is no – see below). For one, it allows you to contextualize input. If you're in a chat window, just typing something could send your message to that channel. Same thing if you had a subwindow for tells, for example. One could imagine a subwindow for doing some kind of OLC work, in which case it is understood that commands typed there refer to the OLC context. Etc. Second, it means you're looking at what you're typing in the context of where you're typing.

However, this places a considerable onus on client authors to be using some kind of intelligent windowing system on their end beyond a canvas that gets drawn on. MUSHclient's miniwindows can't handle this, for example, because they're just plain canvases. So maybe this isn't such a good idea. The point of subwindows is mostly to provide clicking and the like, so let intelligent input happen with clicking – which could construct an appropriate command string to send to the MUD normally.


Well, if the client closes the inventory window, presumably something has to happen so that either the server stops selecting the inventory window, or the client discards future output to that window. But the client might not want to completely lose that input. On the other hand, I'm not sure windows should be closeable in the first place. It would probably be easier for both server and client to have MUD-side preferences that specify which windows to create, than to handle opening and closing fully dynamically outside of the MUD's instructions to do so.


I think the option should be left open, at least. Maybe as a separate command: subwindow.create followed by subwindow.setflags, or something like that.


I think so, although I think it would be nice to say that the client can rely on window names carrying some semantic value. For example, the server might say "put inventory in the upper right", but the client might decide they want the window in the lower right. So, they need to be able to reliably recognize the inventory window.

Size hints might be nice, although I would recommend that size be specified in character width/height (e.g. 20x10 characters) as opposed to pixels. This way, if the minimap displays the surrounding x rooms, you can make the window of the appropriate size.


Don't really understand the question: isn't the whole idea of selecting a window that all future output commands go there?

—————

One thing I would add is the command subwindow.clear, which instructs the client to clear that subwindow. You probably don't need a scrolling inventory list, for example; it would suffice to clear it before redrawing it. Same thing for a mini-map, for example: clear the map, draw the new one.

It might be interesting to do something like:
Display this picture, and create these hotspots that correspond to sending these commands.

A compass is then implemented by creating a window, drawing the image, and creating hotspots that send n/s/e/w etc.

While tempting, primarily for OLC like David said, I don't think dedicated input would be that valuable in a sub-window. One potentially good use for it would be in a MUD where your characters regularly control vehicles or mechs or something and you'd want one window to show whats going on 'outside' and the other to walk around inside. That way any input you type in one box would be used to control the vehicle, the other would control the player. Again, pretty edge case. With that said, I don't think it would be so very hard to implement anyway.



Depends on how we're qualifying a sub-window now. If, and this is the way I understood it, subwindows are simply for text then I would say no. Simply have the client route any output to the main window if the specified window is not open. I absolutely detest MUD clients (BatMud, I'm looking at you) that have windows floating everywhere. It's distracting, ugly, and information overload. I prefer to split a window in two panes and just use that, with the ability to hide the second pane.

Anyway, the point is the first thing I would want to do is close all your little sub-windows except maybe for one. In fact, I'd like to be able to route text to whichever window I wanted it, so if the game tells me theres a chat, guild, thought, and main channel I would want to be able to create my own windows\panes and route to my hearts desire.



I agree with David on this.



Ascii maps make me cry, but I still agree with David on this.



I think it should be pretty self explanatory, if nothing else you'd quickly figure out what the problem was while testing your mud.



I don't know if this would complicate things or not, but I would think that most of that should happen in a different kind of window. A subwindow, for instance, might more accurately be a textwindow, and we could have a different kind for drawing operations (and as the base for widgets).

I'm assuming you were referring to the image bit and not the clear bit (please correct me if that's incorrect). I agree that it probably makes sense to separate the simple text window from a more complex window that can have graphics. In that case I would suggest renaming "subwindow" above to "textwindow", "subtextwindow" or something like that.


:tongue:
I agree, but an ASCII map is a good first go at putting up a map before you have nifty graphics etc.

I'm assuming for the moment that we are still using ANSI escape routines, so the standard methods of clearing the window would still work for subwindows.

If we want to totally supplant ANSI (I don't see a huge value for this – even the color package I have exists only due to wanting slightly more extensive behavior than ANSI allows, and not because I just wanted to replace ANSI color codes with an equivalent ZMPish mechanism), then it would probably be best to just add a couple ZMP cursor control and screen/line clearing commands. zmp.goxy, zmp.clear, zmp.clearline, whatever.

So far as input, I would think that we would have it be a "use it if you want and don't use it if you don't want," although I suppose some MUDs may come to depend on it. For things like inventory windows I see zero purpose behind giving it an inventory line. I really only see a use for it for chat windows. I figure we could make a totally separate chat package (which would imply giving clients a standard "create channel" button and the like), but if the subwindow can do everything the chat package would -really- need, why not go for it? A client without the ability to render input lines in a subwindow could still support the feature by having a drop-down, select button, or even a special command syntax for selecting input window.

[ Main |^] [_whatever_I'm_typing_________] // drop-down to select 'input' window
[_/window_occ_whatever_I'm_typing______] // special client command for sending input to a specific window

Not sure if that would be annoying or not. Depends on how much the MUD depends on subwindow input.

I am unsure as to whether or not different types of windows should be their own packages or just "type flags" for the subwindow package. If you have both textwindow and subwindow packages, then you potentially have to duplicate all the practically identical commands (subwindow.close, textwindow.close, subwindow.select, textwindow.select), and then have to figure out semantics for what happens if you try to create a textwindow and a subwindow with the same window ID… does the second replace the former, or are the IDs in separate namespaces, or what? We could just add another parameter to subwindow.create that indicates the type of window, e.g. text, chat, info, etc. Define a standard list and specify their purpose and special behavior. Or just define a set of flags that can be used to build those specific behaviors, e.g. a chat window might be "text,input,noclose."

I see David's point about disallowing the closing of a subwindow, especially if the client can't tell the server about it. If the server is expecting to be able to dump out a "clear screen, draw inventory list" series of commands to an inventory window, but the user closed the window, then either the main output window will keep getting cleared and draw over (as my example was written above) or we have to make closed windows just route nowhere… which ends up being equivalent to just hiding the window. Any good client will probably have a menu or something for hiding and unhiding all windows.

Window sizing is something that needs a bit more thought too, I think. If the client pops up individual OS-level windows (or simulates them), then you probably want to specify sizing. If you aim more for what Vassi (and I) are thinking of, you would just have a split pane that is going to have the same width (or maybe same height) as the main window. In particular, can TELNET NAWS reasonably interact with subwindows? I think we may now need a ZMP command for communicating the size of specific subwindows back to the server, either because the client refused to create a window the size requested or because the user resized the window. Do we then need to specify minimum/maximum sizes, or just expect the MUD to deal as gracefully as it can (same as they have to with TELNET clients already) ?

Not a bad idea. Could easily toss in and out in there too, which is nice if you want to say that "the se exit is the 'out' exit." It does imply that graphical compasses need to be ready to support a 3D representation, though – how else would you deal with a room that had both neu and ned exits (which some MUDs certainly make possible) ?

What I've had in mind was just a standard 8-directional compass with two sets of buttons on either side (for in/out and up/down), and the compass just highlights the exits available to the current room, and makes highlighted exits clickable. Is that about what other people are thinking of, or is there something more wanted out of a compass?

ANSI is annoying (can you tell I hate parsing yet?) but I agree that it doesn't make sense to supplant a perfectly good set of control codes.



My player base is probably not a shining example of average MUDDers but most of them have played WoW or some other MMO at some point and would be very comfortable with the second form, I.E. "/chat Hi!" One issue with that, though, is that some MUDs might want to use '/' commands. I know I was kind of thinking of making my staff commands or other 'menu-y' commands start with slash. It becomes moot simply by allowing players to edit the prefix, though.

The dropdown, I think, would be annoying after a while but it probably would depend on how the other window is being used. If you need to work in only one window at a time, for extended periods, it wouldn't be so bad - the more common scenario would probably involve a lot of switching back and forth though. Worrying about it is probably not really our job though, if the protocol calls for inline editing it's up to the author of the client to decide how to handle it if he or she can't comply.



I think type works very well, it's mostly only a difference between whether your main control will be a text control or a canvas control, the rest of the goo doesn't need to change.



I get where you're coming from with the dump and clear, but I would probably approach it from the point where I would ignore 'meta' commands on windows that don't exist, but route text to the main window. To take the inventory and map example again, closing the windows means that I want it to show in-line instead of separately. The server will try to keep it neat by clearing the window, but since I have chosen to close I am implying that I don't really care about that, so ignoring the .clear command would not be an issue. The alternative would be to notify the server that the window is closed, and then the server would have to keep some flag, and every time I type inventory, or my inventory is updated, the server would have to check a condition to see if it was going to send it to the main window or the inventory window. It seems cleaner to let the client handle it, and I can't think of a situation where it would be an issue at the moment.



I think we should probably require a width and height, along with a no-resize flag. It would be a good idea, if especially someone wanted to do something like what David suggested where you send an image and hotspots and you have an insta-widget. Allowing the players to resize that window would just result in ugliness since you probably don't want to stretch images around. Windows of type text should probably use NAWS, or some mechanism like it, to give the MUD a chance to do some formatting if they care to. I guess a question here would be how much we do want to mix ZMP packages with other Telnet options? By which I mean, if we have sub-windows we're reasonably guaranteed that there is strong ZMP support, but that says nothing about NAWS being implemented.

One thing I'd be willing to support is a good local editing protocol. After negotiation the server would send:

IAC SB ZMP "zmp.edit" NUL "filename" NUL "string" NUL IAC SE

The purpose of the filename is mainly to get the file extension right so the text editor can highlight stuff, the default filename should probably be temp.txt The client can save the string to file, and open it with an editor. When done editing it should be send back with something like:

IAC SB ZMP "zmp.edit" NUL "filename" NUL "string" NUL IAC SE

The server should probably have saved the editing state and deal with the return string in whatever way it sees fit. I'm not sure if further functionality would be required.

I apologize, I have to be somewhat brief here.

- Using ANSI codes is a big minus for me. It means that the thing on the other end has to parse/understand them. In MUSHclient's case, for instance, again, the canvas is really just a dumb canvas. There is no interpreting of codes etc. – you would have to do it all yourself. This is not an argument for the general case, but it would be a big problem for me. Furthermore, ANSI codes feels like mixing protocols to me. We're talking about the ZMP protocol here, not ANSI. Sure, clients are likely to understand ANSI if they're implementing ZMP. But, for things that are meaningful to ZMP, just use ZMP, no? As long as we're parsing ZMP stuff, we might as well have just that parser. I don't see much point in forcing people to also interpret ANSI codes. (Recall that we're sending color with ZMP too, ne?)

- I don't see too much point in standardizing exits that much, considering that you fall on your face when it comes to the truly interesting exits like "door", "portal", etc. I think that that kind of exit is far more common than the relatively exotic "northeast and up" vs. "northeast and down".


Unfortunately I cannot agree with this, although it would make life a lot easier if it were the case. The whole point of a map to display tactical information is that you want information in almost real-time, or in any case with very frequent updates. The idea would be that the MUD tells you what the new tactical situation is every time it changes, or once a second, or whatever. If I want to hide that window for some reason, I reallyreallyreally don't want all that stuff going to my main output window – I want it gone. The whole point of hiding information is to hide that information.

Now, we could make this a window flag, which would probably address both my use case and what Vassi described, without either of us stepping on the other's toes. Something like: alternative-output vs. standalone-output.

Feel more than free to define a terminal package for basic output control and the like if you want. :)



Almost all pure-text clients already have some kind of "client command" escape. Some make it editable. Almost all just allow you double up, so that e.g. //command would send /command to the server.



That could have disastrous results. Imagine if it were an ASCII map window that tried to be smart and only update the portion of the map that changed…

Either the window output needs to be routed nowhere, the server needs to know when a window has been closed, or window just needs to remain open. You could always add an option to your client to merge any subwindow with the main window output, if you know it's safe to do so. The client can be really intelligent in so very many ways.

I think what I wrote in the example spec above about just routing to main is bad. It should either route nowhere or notify the server to stop sending the output. The easiest solution by far is to just route nowhere (requires no extra code for a client, really) and then to not let subwindows be closed, only hidden. From a user perspective, it's the same thing, except that if the window are just "hidden" then the user can unhide the window without having to get the server to send a new subwindow.open command.



I think the intent is that the inventory subwindow would just update in real time and allows show the current state of your inventory. The goal being that you never actually need to expressively ask for your inventory again. If you did type in inventory though it would make sense (IMO) to just dump the inventory list to the main window, even if the subwindow is open.

The server already has to check for realtime inventory updates because the client may not support the subwindow package… or even ZMP.



Makes some sense, but I'm not sure graphical clickable stuff really belongs in subwindows. Among other things, the size of the window would be specified in character cells and not pixels (I really think it'd be a bad idea to say "text subwindows use cells and graphics subwindows use , the size of a character cell is completely unknown – it can even change at any time by changing client font settings. Making hotspot-graphic windows is probably best saved for a GUI/dialog package, and we can just leave subwindows as a way of organized "regular" MUD output.



NAWS really can't work with subwindows anyway, as NAWS does not in any way communicate which subwindow it is referring to. There's no way to say "the following NAWS TELNET stuff is for subwindow foo." We could add a command for that, but as the only use I can think of is for NAWS, it would make more sense to just add a command for notifying the server of window size changes.


I think it might be worth sketching out some ideas of how we expect this to be used. In my ideal client, "subwindows" would only be panes. The server could request a specific size but almost certainly would be limited to the dimensions of the main window. A sidepanel would then house a number of specialized graphical windows (status bars, paper doll, round timer, compass, etc.). Transient dialogs (things that the user interacts with once or twice and then disappear) would be then popups or overlays. MUSHclient as I understand just opens everything into a whole new window. It has more far more freedom in what the server can ask the client to do (no restrictions on window sizes). I'm all good with people writing and using clients like that, but those kinds of apps tend to drive me nuts. :) Point is, the package needs to be able to gracefully deal with both types of clients. I don't want to make a package that can't be used with a "limited" paned client, but I don't want to make a package that assumes panes are there, either. Mostly I think that just means being careful about what we expect from window sizing, but maybe there's something else I'm missing?



Would be quite nice. I'd add a file id (could be just the filename), MIME type (more reliable, handles encoding), and title (more descriptive) parameters, though. e.g.

IAC SB ZMP "zmp.edit" NUL "945236" NUL "onenter.lua" NUL "text/x-lua; charset=ISO-8859-1" NUL "onEnter event for GoblinArcher" NUL "script data blah blah blah" NUL IAC SE

The only problem is that the spec as written does not mandate any minimum buffer size… some clients or servers might only accept to 1K worth of subrequest data, for example. Tyche recommended long ago that I should either make the spec require a minimum buffer size or add negotiation for buffer sizes in; should've listened to him. I may add in at least a recommendation to the spec for a minimum 8K or 16K buffer size. (A good sized script could still exceed those limits, of course.)

Hmm. Well, assuming you guys do want a terminal control package, what exactly would it need besides the existing color stuff and screen clearing? Is cursor position or line clearing at all useful once you have subwindows, graphical widgets, dedicated prompt display areas, etc.?

How do you control intelligent update if you have just a side pane? That is, wouldn't you have to redraw the whole pane every time from the MUD? Using cursor control sounds like quite a bit of work, because then you need to know where everything belongs.

Note that MUSHclient's approach can be applied to what you want: just arrange your miniwindows in a line on the side. Boom, a "pane". :smile: Note that they're not actual MCI windows.


I don't think so. You could maybe use it to intelligently update a tactical map, but that would probably be more trouble than it's worth on client/server side anyhow. Easier to just dump the new 5x5 (or whatever) map.

I still think that you can use normal ZMP colors in subwindows, so no need for a package and/or command there, and textwindow.clear seems like a very natural thing to have for a text window. It's not really terminal control.

Not sure what you mean? If you have panes, rather than separate windows, it doesn't make it any harder to draw or redraw, at least "not in my language"(TM). Each panel is still a separate control, the difference is purely in the layout. Being able to arrange a bunch of tiny windows might make them feel like panes, but it still gives the effect of being cobbled together. I'm not sure how to describe it better, but obviously it's simply a matter of preference.

It seems to me that we're still kind of mixing talk about two different kind of subwindow concepts.



I guess I'm confused. I thought the text subwindows were primarily for chat stuff, especially since you're saying that we should have different types (and more so now that you mentioned having a separate kind of window in a GUI toolkit). In the cases you presented I absolutely see your point and even feel a little sheepish, but in the original concept where you're just filtering out other chat output then I still don't see the harm in it. I would really like to draw the line on what kind of windows\panes do what, and the naming scheme should probably match the intention.

I again agree with NAWS, and essentially the notion that we should probably take care of ZMP problems with ZMP solutions for consistency.

The kind of information display I'd like to get would be something like a status display. (Think the bottom pane on your client, for instance, showing hp/mana/etc., map, time, …) Such a thing does not scroll, and therefore it is not appropriate to use a normal text output window that you add lines to.

Since we're talking about a text window that you direct output to, if you are going to "redraw" it, you need some form of cursor control or clearing and redrawing all. The problem with either of those solutions for a full side pane is that you don't know how big the pane is, either horizontally or vertically: it depends on the client window size. (Presumably you could force a horizontal size for a side pane, and vertical size for a top/bottom pane.)


Did you check out the miniwindows link I posted to Nick Gammon's work? That's the kind of stuff I'm going for, although without graphics for now in the "textwindow" concept. We're talking things like maps, inventory lists, current character status, …

This might address your above concern (about not understanding my problem with how to redraw the pane) due to the nature of information being displayed.