support loading charsets

[nurpax]

Refactor petmate to support loading in custom charsets. All of this refactoring would also be needed should petmate ever add support for drawing custom charsets.

To-do:

• [x] Extend redux state to contain fonts.
  • Perhaps they Framebuf field charset can be a key to workspace's custom font data.. Eg., right now it's upper, lower, but it could also be something like custom_a if the user loaded a custom font and named it that.
• [x] Plug through enough state everywhere so that the lower level routines can get a font from the redux state with that charset name.
  • Right now this is hardcoded to the two ROM fonts in getFontBits function. Should rename getFontBits to getROMFontBits to separate it from the more general FB getFontBits that reads the redux state for the actual font data.
• [x] Change saveWorkspace(filename: string, screens: number[], getFramebufById: GetFramebufByIdFunc, updateLastSavedSnapshot: () => void) signature to get rid of the silly getFramebufById indirection.
  • Just pass in all the data directly that's needed to save the workspace. Will need to pass in font data to this.
• [ ] UI for loading custom fonts, setting a name for them (or maybe just use custom_1, custom_2, etc. because.. lazyness!)
• [x] Save custom fonts along with a workspace
• [x] Custom font selector under char select (there's not enough horizontal space for more than one entry here.. so maybe a dropdown selector or similar?)
• [ ] Rename fonts
• [ ] Delete fonts
  • I don't know how this should work if any existing screens use the deleted font?
• [ ] Charset <select> max width -- can grow too large now with a long font name
• [ ] Reloading fonts with some key shortcut
  • This is not supported and probably will-not-fix for first release. Problem: doesn't align well with how it's implemented into Redux and workspace now. Once you load a font into Petmate, it loses any connection it had with the .64c font file.
  • I'd prefer this type of thing to be handled by Petmate supporting font bitmap editing.

Should take every opportunity along the way to clean up import/export/load|saveWorkspace code as that really is kind of a mess.

Prompted by https://github.com/nurpax/petmate/pull/173

[nurpax]

FYI @manuelvio @Esshahn

Here's what I have so far:

This is with redux plumbing. And now Petmate supports the usual ROM fonts along with any custom fonts. There's just not any UI yet to load fonts, save them, etc. But the ugly plumbing part is in reasonable shape.

If you have any thoughts on UI, always happy to hear suggestions. Right now I'm feeling sort of lazy in that this patch only supports adding new fonts but not modifying them (e.g., changing the charset name from custom_1 to sth else) or removing them once added into the workspace. I definitely want to support loading multiple custom fonts into the workspace. Because different screens can have a different custom font enabled.

[Esshahn]

Sounds great! I'm looking forward to using the s*it out of this feature! As for UI, I think I would be totally fine with just exposing a 'charset' folder and not importing the charsets via UI itself. Some wonky reasons:

• People are used to putting Fonts in folders on all OSes.
• Other creative tools have a similar approach e.g. for custom color palettes, brushes or plugins
• it's easier for the user to drag some files into a folder than understanding the custom import mechanism of an App
• it's more code to maintain
• It's unclear for the user if the import state is "per petmate file" or globally per App

My suggestion would be that you introduce the pulldown menu where you have it right now and make an additional entry in the pulldown like

add charset...

which would simply open the folder so users can drag the files in. Same option could be added to petmate's menu.

[manuelvio]

I like @Esshahn 's filesystem idea, is simple and effective indeed, but I think it could lead to some kind of ambiguity if used in combination with font embedding in .petmate files as planned in the checklist. Filesystem provided fonts are an application-space feature, while .petmate embedded fonts are a workspace-space (ugh...) feature, if they are going to cohexist I foresee a lot of surrounding code.

At this point I think it would be better, for the sake of a portable approach, to take just the road of the workspace oriented feature, thus thinking ahead of a small general management ui (add, remove, rename) and a simple combobox where the user can specify which custom font (if any) should apply to the screen.

It means a discrete amount of initial management code compared to the fs approach but I think it could pay off in the long term.

[nurpax]

I'm pretty strongly in favor of associating (and saving) this data with the Petmate workspace.

As a kind of simplification: if you think of Petmate as a text editor, keeping fonts in some directory on your machine is kind of ok. E.g., an "A" is an A, a "B" is a B, etc. You switch fonts but the output kinda looks the same.

But if you think of Petmate more of a tile graphics editor (which PETSCII in some sense kind of is), the tile bitmaps (=the font) are definitely part of content. So for example, if I'd be making a game or a demo with some friends, and my graphics artists sends a .petmate file over, I'd definitely expect the file to contain everything I need to view it on my computer. Maybe he added a new .petmate file in a Dropbox folder.. When I double click on that file, I want it to open exactly as the author saw it.

My short term plan for fonts in Petmate doesn't include editing bitmap fonts. But I want custom fonts to be designed in a way that will eventually support that. So if I eventually add font editing, I'd like the font data to be saved along with everything else in the Petmate workspace. Otherwise, where would that stuff be saved? Exported as some separate font file? Also if you look at other PETSCII editors like http://petscii.krissz.hu/, it also seems to save fonts along with the project file.

There may be other such data that I want to include as part of the workspace. One would be RGB palettes. Shockingly, there are some people who'd like to edit PETSCII but use their own custom RGB palette to go with it. Again, I consider this to be part of the artwork, because the colors also really do define an art piece.

[nurpax]

I'm happy with this part of the UI that replaces the old ABC/abc buttons with a select box. IMO we don't lose anything with this change as I'd imagine there's usually no need to quickly switch between different charsets.

[nurpax]

Should take every opportunity along the way to clean up import/export/load|saveWorkspace code as that really is kind of a mess.

LOL I did almost none of that! :)

FYI @Esshahn @manuelvio I have something working that I feel is pretty ok, certainly better than what Petmate previously had. :) I'll prepare some beta builds in case you want to try how it feels like. Ask me in DMs for a link.

[nurpax]

I released this in pretty much the same state that I detailed here earlier. I started to feel lazy about polishing this for a release and figured it's better to get the less polished feature out rather than sit on it indefinitely.