17 Mar, 2009, elanthis wrote in the 21st comment:
Votes: 0
Look, I think we can all agree TELNET sucks. We can all agree that it is no longer commonly used on the Internet for remote shell access. But it's what we use for MUDs, and changing that is not something I forsee happening anytime soon, for two large reasons: all existing MUD software supports TELNET and TELNET only; and despite TELNET's quirks it still works and gets the job done for what we need here in 2009 so long as you add in MCP/MXP/Pueblo/ZMP.

It is not ZMP's job to dictate changes in the TELNET protocol, only to dictate the meaning and interpretation of the data sent inside the RFC854-compliant ZMP subnegotiation command. If you want to come up with MUDNET or something, please do, I support such an effort. I really want feedback on this particular topic though so please hash out your new protocol in a different thread plzkthxbai.
17 Mar, 2009, David Haley wrote in the 22nd comment:
Votes: 0
For the sake of repetition, I would suggest adopting the same line-ending convention that telnet does. I think the telnet line-ending convention, while not orthogonal to ZMP's convention, is not so tightly related, however, it's less confusing to just use the same one and call it even.
18 Mar, 2009, elanthis wrote in the 23rd comment:
Votes: 0
Meh, probably confusing enough to just not be worth mentioning in the spec at all, beyond perhaps a "be aware some apps might use one or the other."

On a half-related note (there's enough ZMP threads as is) the subwindow package is now online.

http://zmp.sourcemud.org/pkg-subwindow.s...
18 Mar, 2009, David Haley wrote in the 24th comment:
Votes: 0
Is that still a "draft" or a published spec? (just curious)
18 Mar, 2009, Vassi wrote in the 25th comment:
Votes: 0
The example for subwindow.open reads:

Quote
An example use of this command may look like: IAC SB ZMP subwindow.size NUL 80 NUL 25 NUL IAC SE


Just thought that might be confusing if left as is.
18 Mar, 2009, Les wrote in the 26th comment:
Votes: 0
Gnome-mud supports the subwindow spec as of now. No servers support it so it's sort of a wash though. :) If you have a server capable of sending zmp commands (I use http://code.google.com/p/soiled/source/b... which lets me send arbitrary zmp commands for testing stuff out) then you can play around with it a bit if you checkout the current source from our svn repo.

The potential is there for it to be pretty neat. On mud clients that support creating subwindows and putting text into them I always like to move channels to their own subwindow so the spam doesn't clog up the main one. If the server can do this for me, all the better!
19 Mar, 2009, elanthis wrote in the 27th comment:
Votes: 0
It's not considered a draft and is therefor complete, save for any minor clarifications or typo fixes.

Fixed the example command, thanks Vassi. (btw, is the formatting showing up for you? should be quotes around the command arguments. might have to refresh if you have an old copy of the css file cached)
19 Mar, 2009, Les wrote in the 28th comment:
Votes: 0
elanthis said:
Fixed the example command, thanks Vassi.


Cleared my browser cache and even fetched the page with wget and the example still reads subwindow.size. You're fired elanthis :wink:
19 Mar, 2009, elanthis wrote in the 29th comment:
Votes: 0
Doh. I deserve to be fired. :/ That example was written for size and I ended up moving it. didn't even notice. I dumb. Fixed for realz yo.
19 Mar, 2009, David Haley wrote in the 30th comment:
Votes: 0
Hmm. I sort of thought we were going for that whole iterative development process where we try it out, hammer out problems, revise the spec if necessary, and so forth. :wink:
19 Mar, 2009, elanthis wrote in the 31st comment:
Votes: 0
It seemed simple enough to just go with it. Hopefully I didn't make a bad call, but you're right, I should've labeled it as a working copy.
19 Mar, 2009, David Haley wrote in the 32nd comment:
Votes: 0
I think it's not too late to relabel it, probably the only people who know about it really are those present.

But yeah, it's probably ok. But it's hard to tell until we actually do some stuff with it.
19 Mar, 2009, Les wrote in the 33rd comment:
Votes: 0
Well as probably the only guy who's implemented the thing in a client so far I'm curious what you think is needed or missing. With the spec as is we get:

The ability to open as many subwindows as necessary or wanted on the client from the server.
The ability to optionally accept input from those subwindows. (Though to be honest it's not clear to me why the server would care which window the input came from (see subwindow.input), but I'm a client guy so that's not surprising)
The ability to request size of the subwindow and respond to size changes from the client.
And probably most importantly, the ability to put text into a specific subwindow.

I know you're a Mushclient guy David and this all seems pretty easily done from that (maybe with the addition of stripping out color information? I know mushclient doesnt' support that in it's subwindows without manual parsing).

I'm just curious what concerns you have or what you would like to see added. :)
20 Mar, 2009, David Haley wrote in the 34th comment:
Votes: 0
To be very perfectly honest, I don't know yet – I don't think I will know until I start playing with it from the client end, and also from the server end for that matter.
22 Mar, 2009, Tyche wrote in the 35th comment:
Votes: 0
IRT subwindows…
Any thoughts on subwindow.open providing a suggested layout parameter?
I was thinking of something akin to Java's north, south, east, west, center.

IAC SB ZMP subwindow.open NUL inv_wind NUL Inventory NUL 30 NUL 25 NUL north east NUL IAC SE
IAC SB ZMP subwindow.open NUL stat_wind NUL Stats NUL 30 NUL 10 NUL center east NUL IAC SE
IAC SB ZMP subwindow.open NUL map_wind NUL Map NUL 30 NUL 10 NUL south east NUL IAC SE
22 Mar, 2009, Les wrote in the 36th comment:
Votes: 0
Tyche said:
IRT subwindows…
Any thoughts on subwindow.open providing a suggested layout parameter?
I was thinking of something akin to Java's north, south, east, west, center.

IAC SB ZMP subwindow.open NUL inv_wind NUL Inventory NUL 30 NUL 25 NUL north east NUL IAC SE
IAC SB ZMP subwindow.open NUL stat_wind NUL Stats NUL 30 NUL 10 NUL center east NUL IAC SE
IAC SB ZMP subwindow.open NUL map_wind NUL Map NUL 30 NUL 10 NUL south east NUL IAC SE


I thought about this alot actually. It adds some complexity to the implementation but that's not my real problem with it. The problem I have with it is two fold.

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.

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).

It just doesn't seem to me to be the job of the server to figure out where these windows should go. The user places them, then the client can remember where the user placed them and place them there again on the next connection.

That's how I think it should work at any rate :tongue: Maybe I'm just full of crap, you tell me.
22 Mar, 2009, David Haley wrote in the 37th comment:
Votes: 0
It makes tons of sense for the server to create windows and indicate where they should be, if that arrangement is deemed to be a sensible arrangement for how the information should be presented. Note that the "OS window manager" isn't necessarily the thing placing these windows, and even if it is! it has no idea where things should belong and might as well just lay things out in some kind of tiled layout forcing users to replace things at every window creation.

If the server is putting up, say, a minimap, why not just let it say "hey, this should go in the lower-right corner". If the server can say this, the player could even configure his/her settings on the game to have it put the window somewhere else.
22 Mar, 2009, Les wrote in the 38th comment:
Votes: 0
David Haley said:
It makes tons of sense for the server to create windows and indicate where they should be, if that arrangement is deemed to be a sensible arrangement for how the information should be presented.


Sensible by the server coder perhaps, what if the user has different ideas about sensibility?

David Haley said:
Note that the "OS window manager" isn't necessarily the thing placing these windows, and even if it is! it has no idea where things should belong and might as well just lay things out in some kind of tiled layout forcing users to replace things at every window creation.


This ties back in to what I said before, it makes a lot more sense for the client to simply remember where the user placed the windows. It's not as if the server is going to change their identifiers very often, if ever. The ooc channel once and forevermore, etc.

David Haley said:
If the server is putting up, say, a minimap, why not just let it say "hey, this should go in the lower-right corner". If the server can say this, the player could even configure his/her settings on the game to have it put the window somewhere else.


Or the user can just put the thing where she wants once and be done with it. It seems to be alot of work for very little benefit. Its easy to store an x/y coordinate and place a window there, it's harder dealing with the visibility and other issues I brought up in my previous post.

I am a fan of ZMP and would like to see it broadly used. By adding alot of complexity to the implementation though it's going to really hamper it. I mean, look, it's acceptance is already somewhat hampered because many clients and servers don't handle telnet properly in the slightest. The complexity of a telnet state machine is pretty low on the scale.
22 Mar, 2009, David Haley wrote in the 39th comment:
Votes: 0
Les said:
Sensible by the server coder perhaps, what if the user has different ideas about sensibility?

Applications do this all the time. How is this any different whatsoever from any application deciding where its GUI components go?

I agree that unnecessary complexity is bad, however this particular question is of no complexity at all. It's not exactly hard to throw in a hint system based on the four corners, or the four edge middle points. In fact it's kind of trivial, isn't it? I'd argue that it's even simpler than remembering where the user placed the window; in that case, the application has to store state, etc.
22 Mar, 2009, Les wrote in the 40th comment:
Votes: 0
David Haley said:
Applications do this all the time. How is this any different whatsoever from any application deciding where its GUI components go?

Yeah but those gui components are generally a standard set per application. In Photoshop you're always going to have the tool palette, photoshop doesn't have to worry about some server suddenly deciding you need a palette for 3d rendering appearing. 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. A mud server just sort of has to guess and hope that the client places the window the right spot if this is implemented.

David Haley said:
I agree that unnecessary complexity is bad, however this particular question is of no complexity at all. It's not exactly hard to throw in a hint system based on the four corners, or the four edge middle points. In fact it's kind of trivial, isn't it? I'd argue that it's even simpler than remembering where the user placed the window; in that case, the application has to store state, etc.


Well if a client can't store state then there's no preferences so it'd be a pretty basic client. And I agree with you that it's not that complex to place a window at a frame border. I do strongly disagree that it's difficult to store a window coordinate though. And I certainly disagree that it's simpler to programmatically determine if a window is in view and move it elsewhere if not than simply letting the user place it and remember that.
20.0/54