Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow multiple Mappings windows #16

Open
Lorp opened this issue Jun 6, 2024 · 5 comments
Open

Allow multiple Mappings windows #16

Lorp opened this issue Jun 6, 2024 · 5 comments

Comments

@Lorp
Copy link
Owner

Lorp commented Jun 6, 2024

Multiple Mappings windows will allow users to have a complete view of a variable font with more than 2 axes, with changes in all axes visualized. A button could potentially create all windows necessary for the axes in the font, so for a 20-axis font 10 Mappings windows would be created.

@davelab6
Copy link

https://developer.mozilla.org/en-US/docs/Web/API/VisualViewport could help make room by "zooming out"

@Lorp
Copy link
Owner Author

Lorp commented Jul 23, 2024

The main functionality, handling multiple View windows, is now implemented in a54ddec. New View windows are created with the same size as the last-created window and positioned at an offset of (20,20) from it. This has the disadvantage of obscuring previous View windows.

How about this logic for new View window layout?

  • Size: take the dimensions of the last-created View window.
  • Position: find space for the new View window in the document as close to the top as possible — if no rectangle large enough exists, then expand the canvas downwards to create space.

This way, we leave it to the user to decide whether very small View windows are ever created.

@Lorp
Copy link
Owner Author

Lorp commented Jul 24, 2024

Zooming the viewport, à la Prezi, is intriguing. However the reduction of size of UI elements (text labels, axis sliders, draggable mappings, window title bars, etc.) seems to be an overwhelming disadvantage in this situation.

@davelab6
Copy link

I'm not sure, I think its OK to make all the UI read-only once zoomed out a certain amount, the point is to see an overview, and interaction can require zooming in.

@Lorp
Copy link
Owner Author

Lorp commented Aug 11, 2024

I’m still thinking this will lead to interminable discussion over the ideal UI for various zooms, a kind of opsz axis for UI.

How about the following approach?

  • A button opens a new window, "Mini views", by default containing small versions of enough 2D graphs to cover all axes (thus 16 Mini Views for a 31-axis font).
  • Delete any Mini Views you don’t need.
  • Add new Mini Views for custom 2-axis combos by clicking "Add Mini View" on a suitable large View.
  • Click on a Mini View to open a large View, then edit mappings on those two axes.
  • Reorder Mini Views by dragging.

This approach means just a single zoom scale for me to pick, along with its UI specifics. I suggest dropping all backgrounds, only showing the mappings. Maybe the Mini Views are so simple graphically that users can choose the zoom for them all with a slider, like setting the scale for image thumbnails in macOS Finder.

The only additional issue is preserving state so that you don’t need to set up Views and Mini Views each time you open a given font in Fencer. The solution to this is to key the window states to the filename or font name in LocalStorage.

@davelab6 davelab6 mentioned this issue Oct 15, 2024
11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants