This commit was made to change the default font from MoebiusXBIN's TOPAZ 437 to regular Moebius' IBM VGA. However, the change to the "Reset to default font" feature to accommodate this was accidentally reverted by the commit made to make the character list pick the character for the character brush. As a result, choosing to "Reset to default font" will load TOPAZ 437 instead of IBM VGA.

All versions of Moebius, including the original, will simply not open any BIN file without SAUCE info. If you feed it an ANS file without SAUCE, it will at least open the file as an 80-character-width picture, even if that's not correct. If you feed it a BIN file without SAUCE, it will sit on a blank drawing window, with a visible side bar but no canvas or preview.

This is notable alongside the issue of being unable to save a file without SAUCE because there is at least one application where it would be useful to be able to save and load BIN files without SAUCE: creating a replacement for Doom's ENDOOM lump, the textmode screen that appears when you quit the game, which is a full text mode video memory block of 80x25 characters, and thus must be exactly 4,000 bytes in size. That means there can not be any SAUCE info inside of it, only the raw text color and character data. When I went to render my ancient ENDOOM lumps as out-of-engine content for a ZZT magazine world, I had to use a hex editor to insert SAUCE info inside of them before Moebius would load them.

It would be useful if, bereft of any SAUCE info, the program would at least, as a fallback, try to load all the data inside of it as an 80-width image, rather than just refusing to load them at all. If anything, it would at least allow ENDOOM replacements, or any other textmode file intended to fill the whole width of a classic 80-width screen, to be opened directly in Moebius for editing without workarounds.

Implement a recent files list that keeps track of the last n number of open files.

See: https://www.electronjs.org/docs/latest/tutorial/recent-documents

Whenever you save a file in this program or any other variant of Moebius, it will save two full copies of the SAUCE info with only slightly different information in them for reasons that are unclear to me. This will confuse applications which expect only one SAUCE entry to exist, from the classic SPOON II to 16colo.rs' online SAUCE editor, both of which will only edit the second SAUCE entry and leave the first alone.

In addition, the "Save without Sauce Info" option in the "File" menu does not do what it claims to do: if you select that option and save a file, it will save SAUCE info anyway.

Electron supports drag and drop. It would be nice if we could drag and drop files onto moebius.

*.ans, *.xb, *.asc, etc. text mode documents could open in a new window.
*.f?? fonts could load the font.
*.gpl (gimp palette) could load color palettes.

See: https://www.electronjs.org/docs/latest/tutorial/native-file-drag-drop

We can toggle the reference image already with CTRL+TAB, but we cannot do this for the guides. We should be able to do this.

A common shortcut for this purpose is CTRL+' and it wouldn't be too hard to implement.

We can already pick colors from the canvas with ALT+Left Click to pick FG and ALT+Right Click to pick BG.
It would be very ergonomic to be able to pick char from canvas to load into custom block.

SHIFT+ALT+Left Click could be used to do this.

On the splash screen added by this commit, the last feature referenced is described as, "CHARACTER LIST PICKER WHICH PICKS THE CUSTOM BLCOKS". The last word should read "BLOCKS". :)

When any of the picture size guides from the View ➡ Guides menu are enabled (e.g. Smallscale (80×25)), they will automatically reset to the correct size in relation to the font size whenever the font size changes in any way, such as from loading any font (bundled or from disk), or from enabling the Use 9px Font toggle. However, the same does not apply to the grids from the Drawing grids submenu of View ➡ Guides: if the font size changes while any of the grids are enabled, the grid blocks will remain the size of the previous font rather than resizing to fit the new one. The only remedy is to switch to a different grid, or to turn off the grid and then turn it back on.

(NOTE: This bug also exists in regular Moebius and was not introduced by forks.)

From nitron:

We all always forget to turn on 9px until we ate halfway through the ansi.. some of wish it was the other way so we could set 9px as the default mode if we want to.

If you set the canvas to an uneven width (e.g. 79 instead of 80), and then attempt to save it as a BinaryText / BIN file, it properly fails: because video cards of the time only supported even image widths, the widely-accepted standard for BinaryText in the SAUCE specification encodes the width in the FileType field as half the intended width so as to maximize how wide an image can be using only a single byte (e.g. a width of 80 characters is stored as 40, and the maximum width is 255*2 = 510 characters).

The problem, however, is that it fails silently. While no file is ever saved, no error message is provided explaining this limitation to the user. This means it is possible for the user to create an image of an uneven width, try to save it as a BIN file, and then close the program without ever realizing their picture was never saved, losing all their work.

Moebius contains a warning dialog for saving to ANSI format¹ that informs the user in the event that they attempt to save an ANSI-format image with any of four control characters, and if the user chooses "OK", these characters will be replaced with equivalents that can be displayed. Because it is not possible to save uneven-width images in BIN format, the least one can do is display an error message when attempting to do so, explaining that it is not possible.

¹ For some reason, this is currently disabled by default, whereas in regular Moebius, it is not.

Like with BIN format, attempting to save an XBIN file of uneven width fails silently. However, in this case, the inability to save XBIN files of uneven width is itself a bug: the XBIN format directly stores the intended width in two bytes (rather than storing half the intended width in one byte like the SAUCE BinaryText width field) explicitly enabling images of uneven width (and the specification advises programmers of art viewers in the DOS era, where video memory always had an even length, to write special code to handle the case of an odd-width image).

The other element of the bug is that loading an odd-width image works just fine. The program will load and display the image at the correct width... but will then be unable to save any changes made to it.

This bug is especially noticeable when the program is compared to PabloDraw, which will allow you to load and save XBIN images of uneven width without a fuss.