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

Menus permanently disabled (Mac only) #12

Closed
csatt opened this issue Jun 28, 2018 · 1 comment
Closed

Menus permanently disabled (Mac only) #12

csatt opened this issue Jun 28, 2018 · 1 comment
Assignees
Labels

Comments

@csatt
Copy link
Owner

csatt commented Jun 28, 2018

There's a bug in version of Tk (8.5.9) that is included with OSX/MacOS versions since 10.7 (Lion) and up to at least 10.13 (High Sierra) that has the effect that menu items may become permanently disabled (grayed out). See https://bugs.python.org/issue21757.

The easiest way to reproduce this problem in IV Swinger 2 is:

  • Open Preferences
  • Try to pull down any menu - they will all be grayed out, as they
    should be
  • Close Preferences
  • Try to pull down any menu - they will still be grayed out, which is
    no good - only way out is to close the app and reopen

The bug is encountered when we use the grab_set() method to make a dialog "modal".

This can be solved by installing Python from python.org, but it would be desirable to avoid the problem as much as possible so anyone can run the (raw python) app on a stock Mac without hitting this bug. Not calling grab_set() in the Dialog class avoids the problem, but removes the "modal" quality of the dialogs that inherit from it. But this means that dialogs now may have to take specific precautions to restrict what the user can do while the dialog is open.

Note also that the built-in dialogs (tkMessageBox, tkSimpleDialog, and tkFileDialog) are all modal. They probably call grab_set() themselves. These are used for error/warning dialogs, simple prompts, etc. It is not worth the time it would take to convert all of these to non-modal custom dialogs. It's also much less likely that someone will trigger the bug when one of these dialogs is open.

@csatt csatt added the bug label Jun 28, 2018
@csatt csatt self-assigned this Jun 28, 2018
csatt added a commit that referenced this issue Jun 28, 2018
Change default for the generic Dialog class to be non-modal.

Some of the dialogs that extend this class now have a constrain_master() method to selectively prevent destructive actions while they are open, and a restore_master() method to re-enable those actions.
@csatt
Copy link
Owner Author

csatt commented Jun 28, 2018

As noted in Issue #12, this does not completely work around the Mac bug, but it is unlikely to be encountered.

@csatt csatt closed this as completed Jun 28, 2018
csatt added a commit that referenced this issue Aug 8, 2018
There's no way to make the file choosing dialog non-modal, since it is a MacOS dialog.  So to fix this problem, we just recreate the menu bar after the dialog is closed.  To do this, it was necessary to keep track of which entries in the Calibrate menu are enabled and disabled.  This is done with properties in the master class.

This might have been a better way to fix Issue #12 (without making the dialogs non-modal), but we're not going to change that now.
csatt added a commit that referenced this issue Feb 6, 2019
This is a better fix for Issue #12 and Issue #36 that:
   - Also fix all other cases where the bug could manifest itself (all tk dialogs)
   - Restores the Dialog class to be modal

The new workaround is to recreate the whole menubar whenever a modal window is closed. This is the same workaround used for Issue #36, but is now enclosed in a method mac_grayed_menu_workaround. Calls to that method are placed after every usage of a dialog. To reduce the clutter, most of the tk dialogs (tkMessageBox, tkSimpleDialog, etc) are enclosed in wrappers that include the workaround.

The generic Dialog class is now reverted to its original modal behavior. All the dialog classes derived from Dialog no longer need the constrain_master and restore_master methods, so those (and calls to them) have been removed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant