Import/export settings handling

[nurpax]

Status

• Import will not have an options dialog (yay @Esshahn)
• Export dialogs are all implemented for whatever output formats we support.

What's missing:

• [x] PNG double pixels & twitter alpha not implemented
• [x] Exports for formats that don't have any configurable options still pop the export dialog, which feels really stupid. So should somehow bypass the export dialog for such formats.

Description

Several export options require the user to specify some extra options for importing or exporting.

For example:

• PNG: alpha pixel for twitter, double size
• PNG: color palette selection
• .C import: load only one screen into currently selected screen, or append new screens for each frame in .c file (or maybe let user choose which frames to import).
• .C export: export current screen only or some selection
• PRG: multiple screens slideshow. maybe SID music
• .asm: which assembler to format for, which screens, maybe some other options like including the kickassembler "main program" that loads the image into the display

This points to some kind of a settings pane that triggers when the user selects "Export..." or "Import...".

Not sure if this settings pane should always open (for e.g., Export PNg...") or if we should have a separate "Export..." which would open the settings and then this settings screen could be used to select input/output format.

Here are the bugs that require this settings pane:

• Save as assembly source #13
• Save options for the image saving #55
• export multiple screens as a gif anim #44
• Import all screens from (other) PETSCII editor #15
• Save as BASIC listing #14

Filing this bug to gather some feedback on what's a good way to do this UI-wise. Currently there's a settings pane (https://www.youtube.com/watch?v=sFGjRimuBBM) for application preferences. I'd like to use to use a similar modal dialog for export/import options.

Some questions:

• Should the Menu/Export PNG/format X, format Y/ items always bring up this export dialog? Or should there be just "Export..." and then the export dialog would have a field to select which export format to use. At least for import, separate menu item per format works better because then the open file dialog can filter by file extension.
• Should there be some "quick export" which just exports the currently selected screen, or should export always pop up the screen selector? (Maybe pre-fill the settings dialog for the currently selected screen?)

[nurpax]

Summoning @Esshahn, @Viza74 for comments.

[Esshahn]

Thank you for this summary! Here are some quick thoughts from my side:

Generally Specify the main export options in the menu, like

• Export...
  • Image
  • Assembly source
  • PRG
  • .C

And then show a modal with specifications, like for image:

• PNG
  • [ ] Double Size
  • [ ] Export with transparent pixel for Twitter
• Animated GIF
  • __ Frames Per Second
  • From Frame to Frame

Reason

• It's generally easy for a user to make a very basic decision right at start, like "I want it to be an image" or "I want to use it in my game". We can use this to structure and simplify all further steps.
• On contrast, having menu options like "Export as PNG with double size for Twitter" takes a lot of processing and leaves out space for explanation if needed. This is usually not a great UX approach

As for some of the other questions/topics above

.C import: load only one screen into currently selected screen, or append new screens for each frame in .c file (or maybe let user choose which frames to import).

I would keep this simple and always import all screens. It's much easier and less error prone to let the user delete screens after import and there's no quirky step in between (will the user decide based on screen number? Or position? Or name? Or thumbnails with checkboxes? -> It's too much)

.C export: export current screen only or some selection

Same here.

PRG: multiple screens slideshow.

Makes sense to offer e.g. switching screens with cursor keys. Was considering that for Spritemate as well

maybe SID music

Too much. Let the tool focus on what the tool should be doing

At least for import, separate menu item per format works better because then the open file dialog can filter by file extension.

I'd still recommend to not have import at all ;) A user should not care about the format they are about to load, it can be handled smartly by the app (file type, analyzing bytes etc.). All supported files should be accepted when loading a file (including proper filtering). This avoids confusion on user's side like "why isn't that file clickable? I want to load it now. Oh... maybe I need to cancel and click on import instead".

As for saving files, Export is a common and working metaphor, as the output format may be lossy (you can't go back from a PNG to a Petmate file for example) and a separation from normal saving is making sense therefore.

Should there be some "quick export" which just exports the currently selected screen, or should export always pop up the screen selector? (Maybe pre-fill the settings dialog for the currently selected screen?)

Some apps like Photoshop do this, e.g. "quick export as PNG". I'm not sure Petmate needs this as of right now, since I don't clearly see a workflow that's like 80% true for every user. Having said that, I do think it makes sense to check which export options can be simplified to they do not need an additional settings modal and therefore can be reduced to one click on the menu.

Hope that helps?

[nurpax]

Hope that helps?

Yes, this is great.

Also I now agree with your Open (or well, I will keep it Import for just the time being) with basically "no options, let the computer decide" philosophy.

[nurpax]

WIP export settings dialog: https://youtu.be/Q66c2vFPn6w

[nurpax]

@Esshahn I can't make my mind on import.

When importing multiple screens from let's say a .c file. Should the screens be imported so that we retain the existing screens before import and append new screens (one for each screen in the .c file) or should the whole editor state be reset to just the set of screens that came from the import (this would be like the current workspace load)?

It'd be simpler to just reset screens to an empty list and then load the screens from the file. But it feels like being able to append screens from a file could be handy too (especially as there's no real copy&paste support of say copy&pasting a screen from another Petmate window to the current window).

[nurpax]

Implemented "append new screen" import of multiple screens for .c PETSCII. Feels pretty good this way.