[SUG][EDITOR] Rename "To Front" / "To Back"

[namida]

Quoting this from another topic sums it up best:

What I've never understood, both in Old and New Formats, is that the "to front" / "to back" feature works the other way round for objects as it does for terrain. Meaning: If you want an object in the very background (in this case: the updraft), you actually have to click "to front".

The issue here is perhaps that "back" and "front" aren't the best terms, and instead, "start" / "end" (of the piece list) would be more accurate. Pieces are drawn starting with the first piece in the list, then the 2nd, and so on. An "eraser" piece thus erases what's been drawn up to that point (but not anything drawn after it), and a "no overwrite" piece will be drawn behind (instead of in front of) all existing pieces - however, crucially, this doesn't change when the piece is drawn, just how it's drawn. Thus, a No Overwrite piece at the end of the list, will be drawn behind everything else (because the only thing that could get drawn behind that is another No Overwrite piece even later in the list).

Now, combine that with that objects generally have "No Overwrite" selected by default, and you see why these buttons seem to work backwards for objects - but they're actually doing exactly what they're meant to do, they just have a poor choice of name. And that's probably something that we should discuss fixing.

The question is, what would be better terms here, that are still short enough to fit on a clickable button?

[ccexplore]

The closest I can come up with is maybe "draw last"/"draw first".

One other possibility is to leave the current names, but actually reverse the sense of those commands just for things that have no-overwrite set, but then it would confuse the people who already grasped the actual draw first/last behavior and got used to it.

[Simon]

Keep the good names and reverse the sense, yes.

Consider to reword no-overwrite as a positive option, overwrite terrain and gadgets (obscure terrain) >_> But it's really an issue of no-overwrite behaving almost like a re-ordering. No rewording can make that intuitive.

Front/back can look at the overwriting flag and reverse sense exactly if no-overwrite.

-- Simon

[ccexplore]

Actually, I guess even selectively reversing sense of commands wouldn't always work.  While "draw last" for no-overwrite would definitely put it visually behind existing stuff, "draw first" has no guarantees of anything, since it always depends on the no-overwrite statuses on all the remaining overlapping graphics.  Heck, even "to back" for normal rendering doesn't necessarily guarantee it'd always visually go to back--not if all other overlapping graphics are all no-overwrite.

So really, I guess the only possible accurate way to talk about them is "draw last"/"draw first".

[IchoTolot]

Simply reversing the names is not the general solution here. No Overwrite reverses the meaning, but it still holds true in the standard case.

I would vote for ccexplore's suggestion "draw last"/"draw first".

[namida]

Front/back can look at the overwriting flag and reverse sense exactly if no-overwrite.

I recall you explaining to a user why the naive implementation of No Overwrite (draw all no overwrite pieces in reverse, then all normal pieces in normal order) doesn't work. For the same reason, this proposal doesn't really work either - I already considered this idea before making the topic.

[Simon]

Front/back can look at the overwriting flag and reverse sense exactly if no-overwrite.

For the same reason, this proposal doesn't really work either

Right, this relies on nearly every other gadget to be set to no-overwrite. I had supposed that most gadgets are no-overwrite.

If that's not enough still, then you need more abstract wording: Draw earlier, To front of list, ...

-- Simon

[namida]

For the next update, I've changed "To Back", "Back", "Forward" and "To Front"; to "Draw First" , "Draw Sooner", "Draw Later" and "Draw Last" respectively.