23 Mar, 2009, elanthis wrote in the 1st comment:
Votes: 0
Quick summary of what I envision the clickable text stuff doing, before trying to define how to do it.

The clickable text is just a way of adding "markup" to output noting that it has a context menu (possibly a default click behavior too). Clicking one of the options just sends a signal back to the server (possibly just a regular ol' line of user input, sent either as a plain TELNET input line or using zmp.input/subwindow.input).

For example, player names might have click menues for Look, Follow, and Attack. Mobs might have Look, Attack. Items might have Look, Get, Use. etc. Clicking on Player->Look might just send the text "look elanthis" to the server.

Questions:

1) Should there only be context-menu style clicks or also allow clicks without a menu? Would be useful for making those clickable subwindow texts like MUSHclient supports, iirc.

2) Should it always just send the line verbatim, or should there be an optional way of specifying that clicking the text just puts the text into the input area, e.g. so you could have a Whisper action on the player context menu that just fills "whisper elanthis " into the input area with the cursor at the end of the input?

3) Is just using the standard input mechanisms acceptable, or is there some need to communicate even more information back for these clicks, necessitating yet another set of input commands (that will need to deal with subwindows, no less).

4) How should we deal with nested marked? If the command for example includes the clickable text as an argument, then you can't obviously include a color command on the text as well. If the clickable text is an argument, we also nee dto think about whether ANSI escape codes have to be supported or not. Alternatively, we have a pair of commands e.g. click.begin-text and click.end-text which gives more of an HTML/MXP style approach. basically, are we sending (in XML-ish pseudocode) <click text="some text" actions="blah" /> or are we sending <click actions="blah">some text</click> ?

Anything else I'm not considering?
23 Mar, 2009, David Haley wrote in the 2nd comment:
Votes: 0
(1) Menu-less clicks: yes. I don't view sending a list of pairs as that different from a single "click action" datum. If you get a list of pairs, make a context menu. If you get a single datum, make it a click-link.

(2) Sending vs. input-box filling. I'd rather keep it simple for now, I kind of view that as an appropriate place for dialogs. E.g., Elanthis->Whisper pops up a box saying "whisper what?", the text from which is then appended to "whisper elanthis" and sent back.

(3) Input mechanisms. What other input mechanisms did you have in mind? I'm inclined to think that plain old lines are fine for the vast majority of commands; unless someone has a pressing use-case for something else we might want to just stick with that.

(4) Nesting. Eh, although I dislike the begin/end tags from principle, they really make a lot of things simpler here. It is conceivable after all that somebody would want to send even more ZMP during the link, although of course some commands would be nonsensical embedded inside the tags. I think we can punt and leave the responsibility for being sane to the person writing the sequence of commands.


I'll think about this some more and see if I come up with anything else.
02 Apr, 2009, elanthis wrote in the 3rd comment:
Votes: 0
*bump* any more input on what people want out of such a package, or comments from client authors about implementing these features?
02 Apr, 2009, quixadhal wrote in the 4th comment:
Votes: 0
I could see clicking an object popping up a menu (either via curses/layers or a seperate window… or even a snazzy popup/radial menu I guess). In the first case, the natural behavior (using a mouse) would be to have a second click to select an option. In the latter cases, you'd expect to hold the button down and drag to the choice, releasing to select it.

In either case, you might have an additional layer of menu pop up as a result.

I know that's the GUI side, but I would probably expect the protocol to be prepared to support those kind of actions, IE: sending additional menu data if the current "choice" isn't an answer.

In many ways, this is very much like the HTML forms interface, and seeing the difference between a full graphical browser's handling vs. lynx is probaby a good mindset to be in while planning it. :)
02 Apr, 2009, elanthis wrote in the 5th comment:
Votes: 0
How would the protocol represent submenues, and how useful are those really? Maybe some examples of what you're envisioning would help.
02 Apr, 2009, quixadhal wrote in the 6th comment:
Votes: 0
I'm thinking along the lines of some of the MMO or RPG interfaces I've seen in graphical games.

For example, one had a radial menu that opened when you right-clicked a character. One of the command options was "talk", which simply put "/tell character-name" in the chat window. Another was "attack", which started combat. A third, however, was "steal", which then opened a submenu of the items you could attempt to pick-pocket.

So, one might expect that clicking a character would send back a menu for the client to display in whatever manner it sees fit, but the "steal" option would actually be another menu. The question is… do you have to send the entire possible menu tree on the initial click, or would selecting "steal" then prompt the server to send another menu with the list of choices available?

How useful that is… I guess that depends on what you're using it for. I could see it being a bit special-case for most player-game interactions. I could see it being very handy for builders though, as they could pick "edit", get a list of things they can change, pick "room flags" and get a set of flags, which would then have "toggle" as an action.
02 Apr, 2009, elanthis wrote in the 7th comment:
Votes: 0
Ah gotcha.

We had talked about a separate gui package for things like dialogs, inventory windows, etc. I'd imagine that there'd just be a menu option for steal that would and the server would respond with the gui package request, separate from the clickable text. If the server sees that the client does not support the gui package, it would leave that option out of the menu or just autofill the steal thing.

I hav eto disagree with David here and say that having autofill is both useful (for the very reason above) and easy to implement.
07 Apr, 2009, David Haley wrote in the 8th comment:
Votes: 0
There's no question that auto-fill can be useful, however there are some issues like focus (if you're clicking on the main window, does the input box get focus for commands typed in?), and everything useful about auto-fill, and more, can be achieved with dialogs. But, this is a weak opinion and I don't terribly care either way.

Representing submenus is an interesting question but one that needs to be answered IMO. There are tons of use cases for submenus. OLC is a very good example. Other examples are things like: casting spells, using a social, quick group commands (attack, defend, …), and so forth.
08 Apr, 2009, elanthis wrote in the 9th comment:
Votes: 0
I personally dislike having excessive dialogs. They block the main game window, for one, which is annoying. There's a reason browsers and many other desktop apps are moving to those little alert bars that show up in the top part of the main content area instead of using dialog popups. Dialogs have their place, but that place isn't "everywhere." :)

So far as submenues, is it something that needs to be part of the clickable text functionality or could it be a part of another package? I think that might depend on how the menues should look… if we're thinking fly-out or zoomable radial menues, you kind of need the context of the whole menu tree, so doing a separate command would be a pain (much less a separate package).

I could potentially run this past a designer or two and see what they think.
08 Apr, 2009, David Haley wrote in the 10th comment:
Votes: 0
I was thinking a plain old menu with submenus; the radial stuff is another question entirely. Getting the whole menu at once can be a problem, and it could also be a problem to have to delay while waiting for a reply from the server for how to populate the menu. (In fact, I'm not sure how easy it is to populate submenus on the fly in some GUI toolkits.)
08 Apr, 2009, elanthis wrote in the 11th comment:
Votes: 0
Most toolkits allow you to just have a callback to fill in the submenu. That's really problematic in a network protocol design, though, because that means blocking (even the protocol makes asynchronously looking up submenu data easy, most toolkits cannot be threaded and most menu APIs I've seen are not asynchronous).
08 Apr, 2009, David Haley wrote in the 12th comment:
Votes: 0
Ya, that's what I meant about it being a problem having to wait. In fact, by "problem", I'm tempted to mean "unacceptable problem".

On the other hand, sending a whole list of every possible thing you could do every time you wanted to make a menu might not be acceptable either.

I guess some kind of macro system would be in order for that. Macro subpackage anybody? :wink:
11 Apr, 2009, Les wrote in the 13th comment:
Votes: 0
FWIW, GTK+ menus don't block processing in the background (though user interaction is restricted to the menu while it is up). I would be utterly shocked if this wasn't the case in QT as well. That covers probably 99% of all open source clients that use a gui (the rest using motif, or tcl/tk, or some other abomination).

It probably would be better to just send the whole menu at once and not worry about being clever with dynamically loading submenus. Anything that's going to have more options than are convenient for a menu is using the wrong ui element anyway, those should be in a list or tree or whatever.
12 Apr, 2009, David Haley wrote in the 14th comment:
Votes: 0
It's not so much that the whole program gets blocked (that would be terrible), it's that the GUI would "stutter" as menus are queried for and obtained.
12 Apr, 2009, elanthis wrote in the 15th comment:
Votes: 0
So we had a couple small examples of submenues, but I'm not sure they're really that useful given how much of a pita that is. For example, "steal" might be better done by popping up a listview (or graphical inventory view) of the target character instead of a submenu with 30+ items in it. For OLC, I think a dedicated OLC interface would be far better, too. A full navigatable tree-view of the game world that could display forms for each item. Not particularly complex, but definitely way better than menues with Toggle actions (which breaks the Human-Interface Guidelines of every major OS/toolkit, I believe).

I think just leaving submenues out entirely is probably the better bet here. The idea for clickable text isn't to build some kind of full-scale menu bar toolkit, it's just to pop up a handful of important or frequently-used context-sensitive actions for a specific entity.
12 Apr, 2009, David Haley wrote in the 16th comment:
Votes: 0
I think that it's a lot easier and more immediate to get submenus working for simple OLC tasks than it is to start worrying about dedicated OLC interfaces with tree views etc. For OLC, it would be acceptable to have some delay (if indeed there would be any) while the menus are loading, given that the audience is builders and not players who need real-time responsiveness.
18 May, 2009, Wodan wrote in the 17th comment:
Votes: 0
this seems to have died a bit, so ehm, how about:

menu.simple itemname action1 action2 action3 etc

You don't really need more than that for a simple object menu. We can always add more complex stuff later, but I'd love to not need mxp for menus like that :)
28 May, 2009, elanthis wrote in the 18th comment:
Votes: 0
I dislike any protocol that forces blocking behavior, because a protocol error thus causes the client to lock up, unless a lot of tricky programming is done.

An event-based setup is far safer, albeit harder to design for specific use cases.

I think going with a simpler setup is probably best. With very simple clickable text without any submenu you can do a lot, even for OLC. Especially coupled with sub-windows. Create an OLC subwindow, and menu actions for items in the main display can cause information (with clickable actrions) to be displayed in the subwindow. I guess that's a case of "one bird with two stones" instead of "one bird with an automatic rifle." ;)

Maybe I'm just a UNIX beard, but small tools that do one thing well and which can be combined together to make a more powerful whole are far more appealing to me than trying to make just as many highly-specialized and complex tools that seem more flexible on the surface but can't be easily adapted when need be. I could imagine even a submenu system ending up being inadequate for a lot of uses (people may want toggle items, and making those not look like crap requires adding protocol support for them so clients know to use the toolkit support for togglable menu items) so we'd just end up with a more complex tool that isn't complex enough. Get people to use the subwindow stuff though and then you can do a lot with very little.
28 May, 2009, David Haley wrote in the 19th comment:
Votes: 0
The many-small-tools-combined approach works well if you are aware of all the tools, how they all work, and how to combine them. There's a reason why some tasks are solved with integrated approaches; you sometimes require just too much coordination, and keeping things separate can make things clunky. Of course, you are entirely correct that integrated approaches are harder to adapt and extend, but I'm not convinced that combined small tools are always just as good.

In this case, using sub-windows to act as "submenus" is a good way to get a lot without a lot of work, so I agree it's a good approach here. But I'm not sure the same reasoning holds for the general case. :wink:
21 Jun, 2009, elanthis wrote in the 20th comment:
Votes: 0
Ack, so damn busy.

So, yeah, integrated approaches are useful when you need ease of use for a specific, well-defined set of features that can be developed into a unified whole. I think the problem here is that we have no idea what features people need though, so we can't ship out a ready-to-go package that has all the features people want and no unnecessary bloat.

So, if I were to do a simple clickable text package, it might look something like (very informally written):

text-click.begin-action

Denotes that the following text region can be clicked. A single argument, action, is given. When the text is clicked, the action is sent to the server via zmp.input as if the player had typed in the action text. All text following this command until the first text-click.end-action command is considered part of the clickable action. Clients are encouraged to render the clickable text region with an underline, reversed colors, or other clear visual marker of the region's clickable state.

text-click.end-action

Marks the end of any clickable text region defined by a prior text-click.begin-action command.

text-click.begin-menu

Denotes that the following text region is clickable and creates a menu when clicked. Pairs of arguments are passed to this command. The first argument in each pair is user-visible text and the second argument in each pair is the action text. When the clickable text region denoted by text-click.begin-menu is clicked, a menu should be displayed showing the user-visible text in the same order defined by this command. If any of the items are clicked, the corresponding action text should be sent to the server via zmp.input as if the user had typed in the text. All text following this command until the first text-click.end-menu command is considered part of the clickable action. Clients are encouraged to render the clickable text region with an underline, reversed colors, or other clear visual marker of the text's clickable state.

text-click.end-menu

Marks the end of any clickable text region defined by a prior text-click.begin-menu command.

Additional Implementation Notes

Nested clickable text regions make little sense, and there is no need to support it. If a second text-click.begin-action or text-click.begin-menu command is received before a prior clickable text region has been terminated, the clickable text region may be implicitly terminated.

It is highly discouraged for server authors to expect clickable text regions to span across explicit line terminations (but it is fully reasonable to expect themt to span across implicit line terminations created by client-side word-wrapping). Clients may implicitly terminate any clickable text region upon receipt of an explicit line terminator from the server.

Clients may also implicitly terminate any clickable text region upon receipt of any other command that directly conflicts with the clickable text functionality, including any commands from other package that create clickable text, change target output windows, or otherwise severely disrupt the possibility of continuing the text region. Text formatting such as color changes, font changes, image insertion, or similar behavior should not terminate clickable text regions if at all possible. Server authors should none the less avoid using any complex commands within a clickable text region to avoid potential client compatibility issues.

my thoughts

- Should these be two separate packages to make detecting support easier, or is relying on individual command detection enough?
- Should commands within clickable text regions just be disallowed entirely for simplicitly's sake?
- If the prior is "yes," then should the command just include the clickable text as an argument and rid us of the end-* commands?
- Can we get rid of the action version by just stating that a menu with a single item with an empty user-visible text portion should just send the action immediately upon clicking wtih no menu display?
- Do menues or clickable text actions need an associated id to help protect against stale action links, or should the MUD just deal with that itself by what information it puts into the action text?

All in all, I think the above is worth running with, assuming we have a client author who's interesting in getting it up and running.
0.0/24