22 Mar, 2009, Tyche wrote in the 41st comment:
Votes: 0
Les said:
One, the user is going to set up the windows how the user wants to do so anyway so why add a lot of complexity so the server can choose a layout. Depending on how such an addition would work then also the implementation needs to remember if any particular window has been moved by the user so it knows to ignore the gravity argument if the window gets closed and then later reopened.


Would this be an issue with size as well, if the user resizes the windows?

Les said:
Secondly, it really is the window manager's job (or the win32 window subsystem, or the Finder, or whatever) to place windows. If the user has the client up against the right side of the screen and a window with gravity center-east rolls in what happens? Well ideally I wouldn't place the window off the screen so now I have to figure out where it will fit. Multiply that 7 more times for each gravity point and I'm wondering why I'm not just using the system already written to handle this sort of nonsense for me (ie, the window manager).


Sure some clients would use the desktop window manager because they are using separate disconnected windows, but some would place windows inside their own application window, no? I would consider size and layout parameters to be suggestions to the client.
22 Mar, 2009, Les wrote in the 42nd comment:
Votes: 0
Tyche said:
Would this be an issue with size as well, if the user resizes the windows?


Yeah it would. The spec is pretty quiet on this. In my implementation I made the assumption that the server has the best of intentions in specifying a particular size and therefore resize the window on the servers command even if the user had resized it. As an example, there might be a small room based minimap that gets much bigger as the user moves to an overland map. So the server tells me to resize the window so it can show this new larger map, etc.

Tyche said:
Sure some clients would use the desktop window manager because they are using separate disconnected windows, but some would place windows inside their own application window, no? I would consider size and layout parameters to be suggestions to the client.


If it's just a hint and not required to do as part of the spec then I have no problem with it. It would be extremly useful for that situation.
22 Mar, 2009, David Haley wrote in the 43rd comment:
Votes: 0
Les said:
My point is because they're a standard set a designer can make useful decisions about placement based on the needs of the user and app.

Sorry, I don't understand why the MUD can't put up a useful set of standard widgets in subwindows for that game and it wouldn't be deemed reasonable that the MUD can make useful decisions about those just like Photoshop does.

Les said:
If it's just a hint

We've been using the word "hint" from the beginning, here… :wink:
22 Mar, 2009, elanthis wrote in the 44th comment:
Votes: 0
Sorry I've been unresponsive. Busy few days. (Got acceptance letter to DigiPen, been partying…)

I remarked subwindow as a draft. I also updated formatting again slightly for all the ZMP pages to make them more readable.

I have no opposition to an optional placement parameter. I would probably go with top, bottom, left, right personally, but the north/east stuff is fine too.

Any ideas on how I should clarify the sizing portion? The intent I thought was clear: the client makes no guarantees about window sizes, and it may allow resizing (and it should send subwindow.size commands whenever a subwindow is resized).

I imagine that clients come in only two varieties, but maybe I'm wrong: those that just create new top-level (or MDI) windows for each subwindow, and those that use a split-window view. Clients that have panes would likely be focusing on graphical widgets in the side panes and not chunks of arbitrary text. Maybe I'm expecting too much.
22 Mar, 2009, Les wrote in the 45th comment:
Votes: 0
elanthis said:
(Got acceptance letter to DigiPen, been partying…)


Congratulations! I'll look forward to your DSi/Wii games :)

elanthis said:
Any ideas on how I should clarify the sizing portion? The intent I thought was clear: the client makes no guarantees about window sizes, and it may allow resizing (and it should send subwindow.size commands whenever a subwindow is resized).


When the server sends subwindow.open a second time it is required that the title of the window be updated if changed. If the client supports resizing the windows is it required to resize the window if the server sends different width/height parameters?

elanthis said:
I imagine that clients come in only two varieties, but maybe I'm wrong: those that just create new top-level (or MDI) windows for each subwindow, and those that use a split-window view. Clients that have panes would likely be focusing on graphical widgets in the side panes and not chunks of arbitrary text. Maybe I'm expecting too much.


Clients could also do both. MXP requires the ability to make frames and floating windows for example.

22 Mar, 2009, David Haley wrote in the 46th comment:
Votes: 0
Les said:
If the client supports resizing the windows is it required to resize the window if the server sends different width/height parameters?

I would think that would be sensible behavior. I wouldn't say it's a strict requirement, but it should be a very strong "SHOULD". If the server expects to be able to resize, it would be for things like sending a bigger map for instance, which would have bad results if the client doesn't fix the window on their end.
22 Mar, 2009, elanthis wrote in the 47th comment:
Votes: 0
Les said:
Congratulations! I'll look forward to your DSi/Wii games :)


Thanks! Though to be honest, by the time I graduate, the DS and Wii will already have been replaced. ;) I have over 140 credits to my name between community college and the University of Michigan, but DigiPen takes no transfer credits… so I need to do the full 147 credit hours the program requires. My existing knowledge and transfers basically just let me skip all the classes I know and replace them with electives. Kinda sucks because if I'd have just hunkered down and finished my degree at UofM, I'd be entering into a Masters program at DigiPen instead of as an undergrad. :/

Quote
When the server sends subwindow.open a second time it is required that the title of the window be updated if changed. If the client supports resizing the windows is it required to resize the window if the server sends different width/height parameters?


From the spec:
Servers may send the subwindow.open command with the same subwindow identifier as a previous command. Clients should attempt to resize the subwindow to the new dimensions, and must update the subwindow label to the new value.

So yeah, the client should attempt a resize.

Quote
Clients could also do both. MXP requires the ability to make frames and floating windows for example.


Good to know.
22 Mar, 2009, elanthis wrote in the 48th comment:
Votes: 0
David Haley said:
Les said:
If the client supports resizing the windows is it required to resize the window if the server sends different width/height parameters?

I would think that would be sensible behavior. I wouldn't say it's a strict requirement, but it should be a very strong "SHOULD". If the server expects to be able to resize, it would be for things like sending a bigger map for instance, which would have bad results if the client doesn't fix the window on their end.


This is already in the spec and has been since I first published it. :) The server sends a second subwindow.open for an existing window, the client takes the new parameters. This can be used to change the window title or to (ask for a) resize.

Although I did just realize a potential snafu with that. What if a server wants to change the window title but doesn't care about changing the size? Huh, I guess the server could in that case remember the values the client sent it with the subwindow.size command (it's going to remember them anyway I imagine) and send those sizes instead of the "default" size. Not a problem, them.</braindump>
23 Mar, 2009, leio wrote in the 49th comment:
Votes: 0
elanthis said:
This is already in the spec and has been since I first published it. :) The server sends a second subwindow.open for an existing window, the client takes the new parameters. This can be used to change the window title or to (ask for a) resize.

Although I did just realize a potential snafu with that. What if a server wants to change the window title but doesn't care about changing the size? Huh, I guess the server could in that case remember the values the client sent it with the subwindow.size command (it's going to remember them anyway I imagine) and send those sizes instead of the "default" size. Not a problem, them.</braindump>

It could be a problem if the client then will just resize to that "size", but the user had resized it so that there's actually some pixels less than required for the font face width extra. Harder to workaround the possible few pixels size change, because sizes are count of characters in the grid as far as subwindow cares, but in a GUI it gets translated to pixels.
Of course a "grid" is relative once changing of font faces and font sizes comes into play, either by some ZMP package or existing MXP methods possibly embedded into the stream.
23 Mar, 2009, leio wrote in the 50th comment:
Votes: 0
Ok, some comments on the subwindow ZMP package draft specification current state from the perspective of a MUD client maintainer that already implements support for MXP frames:

Comments on existing specification:
  • Should suggest MUD server coders to keep identifiers persistent over time as much as possible for user benefits as clients could try to retain the positioning (and sizing?) choices of the user based on it

  • subwindow.close from server-side can in some cases have data loss effects. Don't call it from server for things uninitiated by the user with a MUD command? (don't close my OOC channel subwindow out of the blue losing the history)

  • subwindow.size is currently about character width/height. The term "size" is quite ambiguous and suggests pixel sizes in GUI clients, which could be useful knowledge for the server for inline images usages in the future (or through MXP) or some such.
    • Size in character grid terms can also be a very relative thing once it's possible to use different font faces and sizes, which could already be done if embedding MXP into the subwindow

  • How do ANSI colors and other similar commands interact with the subwindow in the stream in regards to subwindow.select? Most likely each subwindow will have their own ECMA-048 CSI state tracker and also for other such things. Basically like a separate server connection with its own states as far as the output window is concerned about - e.g a \eHow do ANSI colors and other similar commands interact with the subwindow in the stream in regards to subwindow.select? Most likely each subwindow will have their own ECMA-048 CSI state tracker and also for other such things. Basically like a separate server connection with its own states as far as the output window is concerned about - e.g a \e[0m while a subwindow is selected shouldn't reset the color used last in the main window or other subwindows, etc. All output going to the subwindow including escape sequences is already stated in the spec, but maybe it could be more explicit to define the interaction better so that servers could rely on it.[/li]
    [li]subwindow.set-input => This allows a server to reliably detect if the input feature is supposed by the client. => s/supposed/supported[/li]
    [li]subwindow.set-input and subwindow.input seem related and support checks should return identical values to those two.[/li]
    [/ul]

    Other notes and addition suggestions:

    [ul]
    [li]Should have a way to suggest default location until repositioned (or if client doesn't save it). This is also about corners - for example if one subwindow is top right and another subwindow is bottom right, then it would be a pane in the right with the height being divided amongst those windows. Or it could also be four things on the right. With corners an advanced client could also implement small docked windows (e.g automap ones) so that they make the main or some bigger subwindow non-rectangular with the text wrapping around that smaller subwindow.
    [ul]
    [li]Also think of docked vs floating windows and hinting of that preference as in MXP. [/li]
    [li]Also how to express a certain order for two things in the same corner or side, so that it's defined which comes before (left or top one) and otherwise relativity to other windows in the same corner or location. I don't think a simple "top/bottom/left/right" works. How do you express which one is the top-most on [url=http://wxmud.sourceforge.net/screenshots... screenshot[/url] - the banner of the tell subwindow? What if you want the automap to be docked left of the stats subwindow. Some weight variable? Some docking libraries state saving codes have some thoughts on this[/li][/ul][/li]
    [li]Hint for subwindow to be scrollable or not (have a scrollbar or not)? Useful for automaps kind of subwindows perhaps. Related to that I note that there are two types of clear screens - one is like coreutils "clear" command in linux and the actual VT102 command for that - Clearing the screen but the history just basically moves up; and complete clear. The latter might need ZMP methods and be useful for auto-maps to not needlessly have lots of content in that subwindow that is supposed to only represent current state[/li]
    [li]Would be useful to have a way to signal to the server to perhaps close a subwindow completely. Stop sending important channel messages to a hidden window and let them go to the main window instead. - MUD flips the choice of that channels output going to main window or a subwindow automatically for the user instead of the user having to send a MUD command like "channel set ooc -subwindow"[/li]
    [li]Logging output to file gets interesting to MUD client authors with subwindows involved :thinking:[/li]
    [/ul]

    I think a mailing list might be better for fleshing out official ZMP package specs. I at least can't follow a forum constantly for this that has many other topics going on as well, but a mailing list I can just handle together with the rest of my mail. Here in the forum I don't even see an option to send a mail on replies :(
    I do have some new package thoughts to implement in wxMUD and also in the MUD server I somehow ended up being a coder for recently. There are also some interesting things already done in a non-spec'ed way already based on MXP or a custom telnet option protocol, but I want to get those converted to generalized ZMP specs instead.
    Hopefully the notes were coherent enough as written at 4am :smile:
23 Mar, 2009, David Haley wrote in the 51st comment:
Votes: 0
Good suggestions, after an admittedly brief read I don't really have objections other than the assumption that putting two windows on the right means creating a pane and splitting it.

I'd rather not move this to a mailing list, however it would be nice if there were a ZMP section in the forums here. I guess since it's Elanthis's protocol it would be up to him to decide where the "development home" is. I'm incentivized to keep it here because this is the place I frequent most :wink:

Note however that you can 'subscribe' to forum threads to get emails when a reply is posted. The link is at the bottom of the thread. You can also subscribe to an entire subsection, which would be nice if we had a ZMP forum. Finally, you could also use an RSS reader to get notifications if you already use RSS.
23 Mar, 2009, elanthis wrote in the 52nd comment:
Votes: 0
The ANSI colors is (i thought) spelled out in the spec. Once a subwindow.select is received, the subwindow receives all output generating/altering commands, regular output, and ANSI sequences.

I'm open to having a location parameter. Need to figure out exactly what options that should entail.

If we move ZMP discussion, it'll probably be to a Google Group, which gives both email and web-based accessed. I'm fine with it staying here too though. I don't use email often at all.
23 Mar, 2009, elanthis wrote in the 53rd comment:
Votes: 0
So what positional parameters should we use?

I could see either adding a single parameter to window.open with north, northeast, east, etc. like the Java-method Tyche mentioned. Or two parameters with top, middle, bottom and a second with left, center, right like CSS uses. Either way works for me. Client authors, you're the guys in charge with this stuff, since you're the ones that have to code all the logic to deal with it. :)

Also, forgot to comment on leio's size concerns. Quite simply, pixels suck as a measurement tool. They're meaningless for anything other than bitmap image data. Especially in the case of variable-width fonts where the server has no idea what font size I have the client set to, what resolution/DPI my monitor is, etc. I'm not particularly a fan of mixing font faces in a MUD anyhow. It just makes it hard to read, same as mixing colors haphazardly. Look at a real book and they very rarely use a mix of font faces; usually just technical manuals and the like that use a few extra fonts to differentiate between code/output and the main text, or some kinds of biographies that put narrated passages in a different font than the main text. Neither is particularly suitable to a MUD, which is more like a novel. So what I'm saying is that I don't really see a problem with assuming fixed-width uni-size fonts. Even for inline images, I'd be inclined to suggest that MUDs specify the image be scaled to a certain number of character cells, and/or allow the client a way to communicate character cell dimensions back to the server so it can figure out any sizing on its own.

Even if you do have a strong use case for pixels (you might, I could be wrong, totally possible) that doesn't change the fact that many MUDs _need_ cell-based sizing because that's how they work. They assume fixed-width monospace fonts and do a bunch of drawing and such based on those sizes and monospace font properties. The only way I can think of to coordinate the two would be to specify units, so a server might send a size of 600px by 400px or it might say 80cc by 25cc. The client then would need to rememeber which unit the server is interested in working in and respond in kind. Which seems like a pain, honestly, but maybe it's worth it?
23 Mar, 2009, David Haley wrote in the 54th comment:
Votes: 0
(New thread maybe? This is subwindowing now, not general best practices)

elanthis said:
The only way I can think of to coordinate the two would be to specify units, so a server might send a size of 600px by 400px or it might say 80cc by 25cc. The client then would need to rememeber which unit the server is interested in working in and respond in kind. Which seems like a pain, honestly, but maybe it's worth it?

It should probably be a parameter/flag on the window, instead of making people remember. I guess this is not that different from what you said.

But I can very well imagine needing pixel sizes. Paper dolls are a simple example of when you'd need to send an image that's shaped in pixels, not in characters.
40.0/54