This restores the ability to use arbitrary installed fonts with the Text tool, which previously worked using the Flash plugin.
This functionality should ideally be included in FontDetective, but it was easier to get it working in JS Paint first.
As discussed in https://github.com/1j01/jspaint/issues/326,
the drawing of rectangles show a blurred/anti-aliased edge in the recent versions of Firefox. This change restores sharp edges in Firefox. The change is modeled after how the existing code handles the degenerate case of drawing the rectangle (when the rectangle is either not as tall or not as wide as double the rectangle line width), but this version just draws four rectangles, one for each side.
I'm not terribly worried about XSS here, but it is a good practice to
avoid implicit HTML parsing. Mainly, though, I really don't want to
go through every button in my app to make sure the formatting is okay,
so I'm changing this back to treating text as text, and handling the one
place where I need HTML specially, by passing an Element instead.
- DANGER: I made $Button treat the label parameter as HTML.
This is terrible! What am I doing?
- Note: MS Paint actually supports modifier-less shortcuts when no
textual input is focused. I should do what I did for the Custom Zoom
window here too, but I haven't yet.
MS Paint supports pressing 1, 2, 4, 6, or 8 with or without a modifier,
to select the corresponding zoom levels, but it doesn't have a textual
numeric input field to contend with.
I'm handling this by conditionally enabling the digit shortcuts without
a modifier, and always enabling the digit shortcuts with Alt.
This can't happen in the original MS Paint, but it's fine, I can just
handle it. I didn't even have to type half of this code.
I love AI autocomplete. I especially love turning TODO comments into
comments that guide the AI with natural language.
The field itself should be focused when clicking on the field directly,
and the caret should be placed where you click.
You know, I thought of this solution quickly, and GitHub Copilot
autocompleted it, but I'm having trouble pinning down what the problem
actually was.
Why does focusing this input programmatically lead to the input not
being focused ultimately after the click? At any rate, letting it focus
naturally works, and is clearly superior.
Note: This buggy behavior was showing up in Firefox.
This prevents a confusing scenario where you tab to the field rather
than clicking on it, type a custom zoom value, and hit Enter/OK, and
it's not used because the radio for a standard zoom value is still
selected.
Neither are generally effective since the submit event doesn't fire
due to the form being removed from the DOM when the window closes.
But this is cleaner/safer, more general, as a safety measure.
- Merge the two cases of [type="submit"] and plain buttons,
matching the HTML semantics that plain buttons are literally submit
buttons (at least if they're in a form), and not lower priority
than buttons explicitly marked with type="submit".
- Never consider button[type="button"] a submit button.
A button with type="button" should only be highlighted if focused.
- Show the button that will be activated if you hit Enter with a special
style. This is the focused button, if there is one, or else the submit
button (usually the "OK" button.)
- Mark buttons with type="submit" or type="button". This may or may not
prevent bad implicit Enter handling in some dialog(s).
- TODO: handle Enter in Edit Colors dialog; test everything
- Dictating into a checkbox, for example, is nonsensical.
- Inputting into a color picker with voice is not supported.
- Inputting into number fields is not supported yet, although there is some very limited natural language number parsing for changing brush sizes.
These two modules were designed to handle cleanup upon repeated execution, i.e. via the JS Console, for development.
Simply changing `window` to `exports` here is a little weird, as it obscures this intent (without technically invalidating that aspect).
radex
Isaiah Odhner