Make dialogs movable and sizable. #1357
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds the ability to move and resize the dialog boxes used in MathJax, like the "Show Math As ..." output and the explorer help dialog. (This was requested in mathjax/MathJax#3411).
To do this, it creates a new DraggableDialog class and several subclasses for handling dialogs. These are used instead of the current Info and SelectableInfo classes from mj-context-menu. While it would have been possible to modify the menu classes, I didn't want to have the dialog boxes be dependent on the men code, since, for example, the explorer help dialog would then be dependent on having the menu code, and I thought they should be independent. The one complication was the Clearspeak preferences panel, where I grafted the new code onto the existing SelectionBox implementation via a subclass. This is a bit of a hack in order to get access to the layout mechanism implemented in SelectionBox. I think it would be guid to revisit the menu code sometime soon, and plan to clean up that situation at that time, so this is a "just for now" hack.
The main dialog code is in
ui/dialog/DraggableDialog.ts
, which uses thedialog
HTML element when possible, as in #1334 (and this PR supersedes that one). It adds drag areas along the edges and at the corners for sizing the dialog and makes the remainder of the grey frame be the drag areas for moving the dialog. The dialog now centers horizontally and vertically automatically (whether it uses thedialog
element or not), and the handling of maximum widths and heights is improved over the current setup.The CSS for the help dialog has been moved largely to the DraggableDialog class, with help-specific CSS moves to the creation of the help dialog in the
help()
method of the KeyExplorer. The help message creation function and platform data are moved to static properties of the KeyExplorer (so they can be made available to subclasses or customizations, if needed). That makes the diff a little convoluted around that, so this is just a heads-up about that.The
help()
method is changed to basically just be a call to theInfoDialog
subclass ofDraggableDialog
. Note that this allows setting of styles specific to the dialog, and so some of the CSS has been moved here, while the code for creating the dialog has been moved to DraggableDialog.The menu code that used to use
Info
and its ownSelectableInfo
subclass has been modified to useInfoDialog
andCopyDialog
instead. That includes the Annotation menu and the Clearspeak preferences dialog. TheSpeechMenu.ts
changes are to use the newSelectionDialog
rather thanSelectionBox
. I added a few type definitions to make that a bit easier. TheSelectionDialog
is actually a subclass ofSelectionBox
for now, so that it can access the existing layout and event methods; it callsInfroDialog
to create the actual dialog itself when posted. I did have to copy most of thedisplay()
method in order to avoid it callingsuper.display()
, however, and because most of the methods areprivate
rather thanprotected
, I had to cast toany
in order to call them. Again, that can all be straightened out when the menu code is revisited.The Annotation menu actually wan't working as it didn't include the needed callbacks, so it never became active. I've fixed that here as well.
The changes to
MJContextMenu.ts
are to create the new type definitions, and to only try to unpost if it is actually posted (this is to avoid an error when selections are made in the Clearspeak preferences panels, which try to unpost the main menu, even though it is not posted).The changes in
Menu.ts
are mostly to change from usingInfo
andSelectableInfo
objects to using the newInfoDialog
andCopyDialog
classes. A few of the dialogs are augmented, however. The About dialog now lists all the packages that have been loaded and their versions (like in the old v2 about box), and the SVG Image dialog now formats the output so that it is more readable. The code that attaches the info boxes to the menu is no longer needed, and theformatSource()
method is moved to theCopyDialog
class. Some of the SVG code is simplified (usingasync functions and
awaitrather than explicit
.then()calls). Finally, the default Zoom Trigger is set to use
Altrather than nothing, since plain clicking and double-clicking both are used to activate the explorer now, so a modifier key is needed for zooming unless the explorer is disabled. The
SelectableInfo.ts` file is removed, since it is replaced by the CopyDialog class.The CopyDialog class subclasses the InfoDialog class, overriding its HTML creation function to always add the "Copy to Clipboard" button, and to add a
code
option that causes the dialog text to be formatted as source code (escaping the HTML special characters) and wrapped in apre
element.I'm hoping the
DraggableDialog
code is commented enough to make it clear. If not, let me know and I can explain further.Currently, I've added the DraggableDialog and InfoDialog objects to the core component, so that both the menu and explorer code have access to them. It would be possible to make a separate component for these and have the menu and explorer code have that dialog component as a dependency. I'm not sure which approach is better. The current one doesn't change the number of files that need to be downloaded, but makes the core component larger when the dialogs may never be needed. But making a separate component means an additional download in the case where individual components are loaded. Since most people use one of the combined components (like
tex-mml-chtml
), and these include both core and the menu and explorer code, it won't make a difference to most users; it only affects loading individual components in a custom setup, or those building their own combined component (who would need to preload an additional component). Any thoughts on that?