Editor Problems

With all the activity, I thought it may be appropriate to list editor “features” that I find troublesome and sometimes silly. I have not had a chance to check out 3.5 beta, so they might already been addressed, and for some, I don’t know if they appear in other architectures. I’m using windows 10.

Again, I’m only talking about GUI behavior here and not how they affect the model.

  1. Maps. If I “add a map” to my module and scroll down to select “include toolbar button to show/hide?”, I am not allowed to enter in the button text, icon, or hotkey. It wants me to save and exit; then start the editor again, at which point I can enter the button information. Now there is a trick to get around this. Add a new map and check the “include toolbar button.” Next copy and paste this map window. If I now edit the copy, I CAN enter the button text, et. al. This fits in the silly category because there seems to be no reason why I can’t enter the button fields, especially if I can do it to a copy.

  2. Grid numbering. I create a rectangular grid, and then I add grid numbering. If the grid’s cell height is around 250 pixels or more (not unreasonable), then the grid numbering window will have the “ok/cancel/help” buttons, which are at the bottom, disappeared off the bottom of my screen. I have to grab the window’s top edge, drag it down, and then pull up the window to expose the buttons.

  3. Send to Location trait. This window has a “advanced options” checkbox. If I check it, it opens an in-place sub-window where I can specify additional offsets. (Note that for some reason, the “additional X offset” is blank while the others are set to zero.)

The massively annoying thing about this checkbox is the editor does not remember its state, so if I re-open this window later, the checkbox is unchecked. It is ALWAYS unchecked. One might think that this trait has no advanced options with an unchecked box, and one would be wrong. This has no business being a checkbox. If it’s going to operate this way, it should be a button.

But even more so, why is there a checkbox? Ditch the checkbox and simply put the “advanced” options inline where everyone can see them. The code has to be simpler than adding all this checkbox and sub-window nonsense. As you might guess, this one bugs the hell out of me. (I think there may be other “advanced” checkboxes elsewhere, and I think they should vanish too.)

  1. Game piece layers. It’s a bit annoying that there are two “layer” elements, game piece layers and piece layers, but I’m not complaining about that. Suppose I define 3 layers: top, middle, and bottom. You would think they would be listed in vertical order as you would picture them: top, middle, bottom. But nooo. The window lists them upside down: bottom, middle, top. This one falls into the goofy category.

  2. Trigger trait. In this window, there are scrollable lists for “watch keystrokes” and “perform keystrokes.” Each list has an “add” button, which adds a new blank line to the bottom of the list. This is harder to explain, but you can see a problem if you have 6 or more keystrokes in a list. The add button is in the scrollable region, so when you add enough lines, the add button scrolls off the top of the list. What I have to do then to add a keystroke then is I must scroll up to show the button, press it, and then scroll down to get to the new line, which was scrolled off the bottom. Really tedious. And if I want to insert a keystroke in the list, it’s too bad. I have to rebuild the list almost from scratch. I wish these lists used an un-goofy versions of the game piece layers component (see #4).

  3. Coordinate systems. Most components define pixel location (0,0) at the center of the piece or region, but there are a couple that put it in the top left corner, and ± may mean different directions. (I don’t remember which components behave this way, but I’ve run into them.) I’m not talking much about this one because I don’t think it’s easy to fix and keep backward compatibility.

The 3.5 Editor UI has been substantially redesigned and already resolves several of these issues.

  • Dialogs will generally use more space where it is available, but will move or display scroll bars when necessary to ensure they remain on screen, especially on smaller screens.
  • Configuring Lists of items (key strokes, Strings, Key commands) will be standardised and will provide add/remove and re-position functionality on all items.
    -I agree with you on point 3 also and have removed the ‘Advanced options’ checkbox.

This is a Work in Progress, beta 1 contains the first stage.

Nice list, let’s add to it :slight_smile:

  1. Map Boards. Please update the “Select Default Board setup” to display the saved configurations of multiple boards (rows and columns). Currently there is no clue at all from the editor of the actual configuration of boards which in in use and to change anything one has to restart from scratch each time.

  2. Allow copy/cut and pasting between different modules.

  3. Add an UNDO functionality.

I noticed the “moved fixed distance” trait also has the “advanced” thing.

I probably should have written this with respect to 3.5-beta, but I can’t find the link to it. Where is it again?
Never mind. I found it.

Good Thread! This is how we Make Progress! :slight_smile:

When you come across places where the coordinate system is using “an Unusual Origin”, that would be a GREAT thing to mark clearly in the documentation. And/or even begin to make a comprehensive list of them somewhere like the “tips and tricks” section of the wiki.

And I think you’ll like a lot of what’s coming in 3.5! It’s a very UX-oriented release.

Brian