Suggestions

[Balerion300]

Just a thread for any suggestions people may have for mush-portal development!

Right now, the things that come to mind are:

1) Better mobile support. On my Android phone, it works okay in landscape mode, but portrait mode gets a broken drop down menu (there's always a gray bar where the menu is supposed to drop) and the settings menu (and perhaps others) are cut off rather than conforming to the width of the view portal. I'm not sure if this is stuff that can easily be fixed via the CSS rules or not, but in any case, the easier this would be to use on mobile, the better I think it'd be for adoption. As it stands, currently I think our users who use your websocket client on mobile (and we have a few, because most seem to find the Android/iOS MUD clients rather annoying) will stick to it.

2) I do not know how feasible it would be to make the app as customizable as possible via the local.js settings. For example, I don't know that our +mail system (which is Mike/Talvo's system built in emulation of ElendorMUSH) will ever be able to make use of the mail functionality, so it'd be nice to just be able to drop that icon without having to make a custom build. Like "useMailModule = false" or something, if that makes sense.

That said, if I ever figure out why I can't build (do you think its outdated react-scripts from what I posted earlier), I suppose it doesn't matter too much provided it's fairly straightforward to drop the icon and functionality from the source.

3) Some basic color presets or perhaps just substituting words for the current ANSI-37/ANSI-40 type codes (e.g. black, white) could help people make use of it more easily.

4) This works very well in Chrome (both PC and Android) and Opera (PC), but it seems to not work on Firefox (PC) and Safari (iOS). I'm not sure if that can be addressed.

[grapenut]

1. I agree, but this one is a doozy. I tried to make it mobile-friendly from the start but it is a real challenge to make it work well for both in one package. I decided it would probably be easier to make a separate mobile version, perhaps using react-native to make it a proper mobile app. Trying to run it in the mobile browser is less than optimal with how restrictive the UI is, but a dedicated native app wouldn't have those same restrictions. Definitely in the works for the future, but I may need to enlist some outside help.

2. This one should be easy and is probably next on the pipeline. I think rather than providing options for each button, I'll just move the code that adds the buttons to local.js. The only tricky part would be getting the icons loaded dynamically, but they are SVG so shouldn't be too hard. That said, there's no reason why you couldn't modify the JSON`MAIL* attributes on the event handler to use the data from the +mail system instead of the @mail functions.

3. I'm going to make a color selector widget. Click the button to open a menu with color swatches that you can click to choose.

4. I develop on Chrome so the support there should be 100%, but I've tested it with Firefox, IE/Edge, and Safari. There were occasionally some things that didn't work as expected (like SSL), but overall should still be usable. Do you know anything specific that doesn't work?

[Balerion300]

Re: 4,

On Firefox, I just get a gray screen (the same gray color used in menus). The HTML is loaded, but nothing is happening. Same on iOS Safari.

Maybe it's some caching issue on our side. We use Varnish and such. But the HTML looks right, anyways.

[Balerion300]

The color selector works great. That said, I realized that if you want black text on white, ansi highlight breaks -- can you do some sort of ansi inversion for colors, so that highlight becomes unhighlighted (more of a grey color)?

[Balerion300]

Just for reference, this is what MUSHclient does with ANSI color options.

[grapenut]

I added a toggle that swaps the color mappings for black and white, and inverts the normal/highlight for white to achieve what you're looking for. It's probably not the most elegant permanent solution, but it will work in the interim. Making an interface to customize the color mappings is probably far down the line, but I could perhaps make it a little more accessible. It currently loads a file (public/inverse.css) that redefines the CSS rules for those colors. I was thinking about putting that into a popup text box so you could edit the CSS overrides directly and then load/unload it.

[grapenut]

The issues with Firefox and Safari have been fixed.

[Balerion300]

I see a config.theme with a hex code in local.js. I decided to try and change it, but that doesn't seem to be implented yet. Or, if it is, it doesn't quite work?

It'd be nice to have a second theming color option, for the icons and MUSH Portal text so that one can set the color of those as well as the main banner color.

[grapenut]

That parameter is only for the popup window title bar color. I'm experimenting with ways to provide dynamic theme changes.

[grapenut]

Ok, I've added the ability to change the theme from local.js. I've also fixed the default build to use a relative path "." for the root url, so you can just copy mush-portal/build/ to htmlroot/BoD/Portal without needing to rebuild. Next on the list will be control over the taskbar commands from local.js

[grapenut]

All of the taskbar buttons are now added from local.js so you can customize or add new ones. But I will edit the event handler to extract information from the +mail system if it's there, or fall back to @mail/Myrddin's if not.

[Balerion300]

Very cool. We need to figure out the SSL issue -- we don't own the server and need our server admin to help sort it out -- but then will start messing around with the latest build. :)

[grapenut]

I would suggest setting up SSL on the MUSH if you can. The easiest way is to use https://letsencrypt.org/.

In the mean time you can use the proxy at leaf.grapenut.org:443 as the host:port for the webclient, with serverSSL=true. It will handle the decryption of SSL traffic and relay it to bod.westeros.org:3000. All of the traffic will be coming from the same IP, so individual sitelocks won’t work. This is only a temporary fix.

On Nov 17, 2018, at 2:06 AM, Balerion300 notifications@github.com wrote:

Very cool. We need to figure out the SSL issue -- we don't own the server and need our server admin to help sort it out -- but then will start messing around with the latest build. :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[grapenut]

So I managed to make everything pretty mobile friendly. I still need to do some work with the popup windows, but I think everything should be at least useable. On mobile we render a sidebar toggle icon, the mush name, three vertical dots to open the windows/commands menu, and the normal three stacked lines to open the task menu. On desktop the three vertical dots are replace by the windows and command buttons themselves, while the sidebar toggle buttons are removed.

I've also added custom macros, triggers, css overrides, and a user-defined onLoad script. There is a form for custom keys and timers but those are not yet implemented. You can access the customizer with the wrench icon in the task menu (three lines).

Using the css overrides it's possible to completely customize ansi.css and inverse.css on the local client so you can set your own custom colors. Eventually I'll make this have a clicky color selection popup, but for now you can manually set the css tags. You can always delete and reset from the source files if you make a mistake.

Macros match a pattern on user input while triggers match patterns on game output. The matching pattern can be a wildcard pattern "command =", or a regular expression "command (.)=(.)". You can execute either mushcode or an arbitrary bit of javascript when the string is matched. You can use %-tokens in the action string to be replaced by the arg strings. The token %0 contains the entire matched string, with %1-%99 being the individually matched args. Use %% or \% put a literal %. Matched triggers can choose to suppress the output of text that they match.

[Balerion300]

Very awesome on the mobile front.

Here's one thing that would be cool if possible: have it automatically HTMLify any urls so they can be clicked and sent into new windows/tabs. Alternatively, I guess using Pueblo-type markup is possible?

Is the event handler code updated to see if it works with Mike's +mail system?

[grapenut]

The link replacer has been fixed and reenabled. I wasn't able to make much headway in figuring out the structure of Mike's +mail code, and he wasn't much help with it either. If you know how to extract messages from the sql I can show you how to build your own json from that.

[grapenut]

Also I've added spawn windows. You can add a trigger that listens for and puts them in a separate window. Create a trigger with any name you like. Switch it to execute Javascript. Use a wildcard match for <> . Turn on suppress output to keep it from also showing up in the main terminal. Set the action text to Window("Channels").append("%0"). Now whenever you get any chatter it will forward it into a window called Channels. If you want each channel to get their own window then you change the action to Window("%1").append("%2")

[Balerion300]

I'm not expert on Mike's system, so I think we'll have to let that fall by the wayside. No big deal.

Have updated at http://www.westeros.org/BoD/build but for some reason it keeps pointing to your development server, despite local.js having been edited. I see you changed some variable names but pretty sure I understood how to edit it correctly.

[Balerion300]

After searching again, I see that the "main" js file appears to have node.grapenut.org as the default address, rather than taking it from the local.js. So when I try to connect, it goes there first. I see from settings I can direct it to an entirely new address. If it could take the default address from local.js and use that instead, that would be great.

Also, having the option to remove the manual address input would be nice, for those who just want their instance of the client used to connect to a specific game. Possibly that's already in local.js though.

[grapenut]

You cloned in-between commits apparently. The server address in local.js is now set on client.defaultSettings, and then the user override client.settings are loaded from localStorage. Get the updated local.js.

[Balerion300]

Tried again, I don't seem to have the local.js edits right. I have to use it in http mode until we get stuff sorted out on the server. Right now local.js looks like this:

` var urlAddress = window.location.search.substring(1); var urlSSL = false;

var defaultAddress = "bod.westeros.org"; var defaultPort = "3000";

client.defaultSettings.serverSSL = urlSSL; client.defaultSettings.serverAddress = urlAddress ? urlAddress.split(":")[0] : defaultAddress; client.defaultSettings.serverPort = urlAddress ? urlAddress.split(":")[1] : defaultPort; client.loadSettings();

client.connect(); `

[grapenut]

I committed the changes to source, but hadn't made a build. There is now a ton of new mobile layout updates and other fixes in the latest nightly build, along with some more comments to help explain connection options in local.js. If you want to disallow changing the server in the settings menu, change allowServerChange to false. You must also remove the if (urlAddress) block to prevent changing the server address via the URL.

[grapenut]

A new nightly build is posted. There are fixes included for all of the bugs that I currently know about and several substantial improvements to the mobile layout.

The sidebar has been revamped and the overlapping lists have been properly separated.

Problems with unicode characters inserted by IOS have been resolved.

There are example templates for triggers and macros that you can load and save/edit. There are basic things that I think would be useful like redirecting channels into spawn windows. These will serve as a guide for how you can construct your own until I finish the user guide with more details.

[Balerion300]

Cloned and tried again, and now just getting a grey screen for no obvious reason. Local.js looks like this right now:

// allow users to override the default address // www.mysite.com/app?address:port var urlAddress = window.location.search.substring(1);

// check for HTTPS and switch to SSL var urlSSL = window.location.protocol === "https:";

// if true, connect using SSL. make sure the port is updated as well. client.defaultSettings.serverSSL = urlSSL;

// the default server hostname client.defaultSettings.serverAddress = "bod.westeros.org";

// the default server port, accounting for SSL client.defaultSettings.serverPort = urlSSL ? '3001' : '3000';

// reload user settings client.loadSettings();

// allow the server connection info to be changed in settings? client.settings.allowServerChange = true;

// override the saved address with an address from the URL // www.mysite.com/app?address:port if (urlAddress) { client.settings.serverSSL = urlSSL; client.settings.serverAddress = urlAddress.split(":")[0]; client.settings.serverPort = urlAddress.split(":")[1]; }

// initiate the connection, now that we have established the server info client.connect();

[grapenut]

You pick the worst times to reclone :)

I did an update on the dependencies earlier today while configuring nightly automatic builds, and the new version of the syntax highlighting editor had some issues that I still need to sort out. It'll be worked out tonight.

[grapenut]

Ok it's resolved now.

[Balerion300]

All right, got it working! Amazing work so far. This is far more full-featured a web-based client than any that I've seen before.

[grapenut]

Significant mobile improvements in tonight's build. We have fully customizable taskbar buttons, saved command history with recall foreward/backward buttons, additional icons from game-icons.net and a ton of other stuff.

I plan to only have a few more minor builds before official release. I'll be finishing up the BBoard window to match the look and functionality of the Mailbox and then implementing the timers/keys. These are secondary items and all of the main functionality for the first release is in. Please keep the bug reports coming in!

[Balerion300]

Just upgraded. Fantastic stuff.

The spawning windows reminds me that there really needs to be some way to have those notify when there's activity in those windows, though. Whether it's blinking the window, providing a new lines count somewhere on the window bar icon, or a sound or something (if that's possible).

[grapenut]

The spawning windows reminds me that there really needs to be some way to have those notify when there's activity in those windows, though. Whether it's blinking the window, providing a new lines count somewhere on the window bar icon, or a sound or something (if that's possible).

They have an activity badge on the taskbar icon whenever they are minimized. Are you talking about when the windows are open?

[grapenut]

I've added a little notification popup that shows the last line received in any spawn window (update your triggers with the new template). It auto closes in 5 seconds, or when you interact with anything. Clicking on the notification itself brings up the spawn window. You can swap whether it shows on top or bottom (the default is bottom on desktop and top on mobile).

[grapenut]

I've hit a release point so I'm closing this for now. Reopen, or open a new one for future suggestions.