My gut feeling is that paper dolls and the like are not subwindows, they are entirely different "widgets." The kind of thing the server doesn't even ask the client to layout. THe server just says "hey I need the paper doll widget turned out, here's the vector outline" and the client slaps it into the sidebar or a new window or whatever the client wants to do.

I don't really like the idea of the server giving layout anyway. The client is the UI, it's the client's job to figure out where stuff goes in a logical, consistent manner. subwindows are a bit of a special case because they're general purpose reusable text containers that the client has no real knowledge of. We could add "use case" markers to subwindows (this is a chat window, this is an inventory window, this is a map window) but we'll inevitably leave a few out.

Essentially though I see subwindows as just a way of specifying an alternate text output region separate from the main output. Anything getting into heavy graphics or highly-specialized behavior is not a subwindow, it's something else (I'll use the term widget collectively for now, although each widget may well be a separate package and not part of a single hueg widget package). Essentially subwindows are something that even a console-only client can implement (using split windows) where as paperdolls and the like probably require a real GUI toolkit or at least graphical drawing capabilities.

I can buy all that. If the intention is to make the subwindows text-only, then sure, it makes lots of sense to only use characters. I was thinking that they were more general subwindows, hence my remark above.

The thing is that using "size" now means future packages regarding paper dolls or whatever that makes sense to talk in pixels will make things confusing. It might be a good idea to think about pixel vs characters and their representation and terminology early on. But maybe not :P

Maybe the subwindow spec should just use the terms "rows" and "columns" to be less confusing, then.

For other kinds of subwindows, I really don't think it's even necessary for the server to give size, because it's up to the client to draw the stuff. The client might have a tiny little compact compass or it might have a big honking huge one. I do not believe the server should be in the business of telling the client how to draw graphics, because at that point we're no longer talking about a text game and a rich text client – we're talking about a graphical MMO using an ad-hoc and under-powered rendering protocol. Might as well just replace the MUD client with a stripped down X server and just make the MUD server render using Cairo-over-GLX.

This sounds totally l33t. :tongue:




This was definitely my initial position. Alot of back and forth with David and others later and my position has changed to one that providing layout hinting doesn't do any harm so long as paying attention to it is not required for a fully conforming spec implementation.

Leio brought up a good point that such hinting has a lot of inherent ambiguity in it when dealing with frames vs. windows. Specifying hinting behavior in the spec itself is probably counter-productive unless it is the position of the spec to dictate client capabilities to a larger extant than what the existing zmp specs have done.

Better to let the client authors figure it out imo.



This is logical of course but it would also be easy enough to add a type parameter that signified text or graphics for that window. My thoughts here is that a 'graphical subwindow' and a 'text subwindow' are just the nougat of the subwindow candy bar :tongue: Both would share the same layout, position saving, title information, identifier stuff, etc, just the widget they display might be different depending on implementation.

I agree that more thought could be put into a vector graphics protocol (anyone else remember RIP graphics?) but that seems, to me, to be a side issue.

Just to clarify my position, I think this is pretty much the only to go. One thing that strikes me about graphics of the sort that a mud might use is that there are pretty well defined areas where such a thing would be used. A compass. A tactical map. A paper doll/avatar thing, etc.

To my eye, it appears that such things would be better served by an explicit package. A client could provide theming for the compass and the server doesn't care at all how the client draws it (a terminal client could just print it out even). A tactical map or paper doll could be concerned with tilesets or pieces of armor rather than low level vector drawing. These packages could include a mechanism for downloading the graphics data over http or ftp like the zmp.sound package provides.

This just seems better to me.

I have been and continue to be of the opinion that the MUD should (to whatever extent is reasonable) provide semantic information to the client that the client chooses to render as it sees fit. So for the 'paper doll' stuff, frankly, I wouldn't even see the server telling the client to draw pixels xxx…yyy, I would see it just saying what the current state of the player is.

The thing is that this kind of system requires a lot of intelligence on the client's part to interpret the server's semantics, whereas a simple drawing system requires nothing more than the ability to draw pixels.

Late night rambling, apologies…

There is unfortunately a middle ground that has to be met. With paper dolls, for example, the specifics can be highly game specifics. Games with aliens or fantasy races might need non-humanoid body shapes. Some MUDs might just want to show damage on limbs while others might break them down into things like shoulder, arm, wrist, and hand. Some games might want to show damage/status for vehicles, especially (space)ships or rovers.

One could just define a humanoid paper dolls with specific damage points and force MUDs to fall into that mold. I would not be directly opposed to that. But it might be nice to allow the MUD to send outlines and define points in a very, very, very simplistic vector graphic format (or perhaps a well-defined subset of SVG) and then the spec can include a link to some "reference implementations" for common shapes. Maybe even just a male and female human outline, or perhaps a few other common fantasy race shapes and a few vehicles. The nice thing is that if those are in SVG, game artists can use them as a basis for their unique races.

That is honestly though the only packages that I personally can think of that really has a strong case for letting the server tell the client what to draw. Things like a compass should really just be a list of exits, and the client can render that however it wants – a clickable graphical compass, a simple sorted list, a status line, whatever. There may well be some other examples though that I just haven't thought of.

I created an unofficial zmp.subwindow command in gnome-mud recently when I was playing with some stuff.

zmp.subwindow set-scroll <ident> <boolean>

Just toggles the scrollbar off and on. Useful for windows that shouldn't scroll. A subwindow.clear command might be useful as well, with perhaps some 'SHOULD' semantics included in the spec for clear. (Ie, if the window doesn't scroll the client SHOULD simply clear the text in it however the client wants to do it, if if it does scroll the client SHOULD clear it with blank lines)