Modal HtmlDialog on Mac?


#1

How does modal HtmlDialogs work on Mac? On Windows the Ruby interpreter is “paused” until the dialog is closed, meaning we can use the dialog to define define the return value of the method creating it.

# @return [1, 2, nil] depending on how user closes dialog.
def test
  return_value = nil

  html =
    "<button onclick=\"sketchup.callback(1)\">1</button>"\
    "<button onclick=\"sketchup.callback(2)\">2</button>"
  dlg = UI::HtmlDialog.new
  dlg.set_html(html)
  dlg.add_action_callback("callback") { |_, v| return_value = v; dlg.close }
  dlg.show_modal

  return_value
end

Does this work on Mac?

Also, on Mac if I’m not mistaking models that are open simultaneously run in the same SketchUp instance, with the same Ruby interpreter (or whatever it is called)? Does creating a modal dialog in one document pause Ruby in the other? Does it prevent the user from interacting with the other model? Does it allow the user to switch window at all, like on PC when the dialog is only modal to the parent window?


#2

How tools are affected by MDI has been discussed, but I can’t find anything about HtmlDialogs, or HtmlDialogs (https://sketchucation.com/forums/viewtopic.php?f=180&t=42154).


#3

Interesting questions I haven’t checked. On my phone now, but I’ll look into it later.


#4

all it does as the moment is blocks SU completely…

no dlg shows at all, and you can’t escape or even quit SU…

needed to force quit…

I’ll have a look at why…

john


#5
# @return [1, 2, nil] depending on how user closes dialog.
def test
  return_value = nil

  html =
    "<button onclick=\"sketchup.callback(1)\">1</button>"\
    "<button onclick=\"sketchup.callback(2)\">2</button>"
 dlg = UI::HtmlDialog.new(
  :dialog_title => 'test dlg',
  :preferences_key => "com.sample.plugin",
  :style => UI::HtmlDialog::STYLE_DIALOG
)
  dlg.set_html(html)
  dlg.add_action_callback("callback") { |_, v| return_value = v; dlg.close }
  dlg.show_modal

  return_value
end

works only with some hash items for the dlg…

john


#6

Hmm. I don’t get quite the same result as @john_drivenupthewall. On my Mac your dialog window opens when I invoke test from the Ruby console. While it is open, you can’t change the active model view to a different file, you can’t select a Tool - neither Ruby extension nor built-in, all the menu items in SketchUp are greyed out, and the Ruby console is “dead”. However, it seems the app is consuming OS events because it does not go to the “non-responding spinning beachball”. Clicking either of the two buttons in the dialog returns the corresponding value to the Ruby console and releases the modal block. That seems to me to be how it ought to work.

So far as I know, SketchUp embeds only a single instance of the Ruby interpreter and passes control to it while a Ruby script is executing. So if the interpreter is blocked waiting for something or doing some long-running task, all of SketchUp is frozen and may beachball. I believe whatever tool is active on one model’s view is suspended (or maybe deactivated) when you change to the other model’s view. There used to be a bug in which some operations by a Tool in one model’s view could bleed into the other view, but that was fixed (not sure whether it was in 2017 or 2018…).


#7

Thanks!

This helps me understand how to make my extensions work better on Mac.

I’m a little confused though, how do you switch between documents in SketchUp for Mac? I was first under the impression the program had some sort of tabbed interface, then I had the impression the documents ran in completely different windows, and that the MID (multi document interface) just affected developers and it appeared to the user as separate instances of the program.


#8

You would normally have just one instance of SketchUp running. Each model file opens in its own window. You can run multiple instances, but most people wouldn’t do this or even know how to.


#9

Yes, but is it evident to the end user there is just one SketchUp instance running (e.g. model switching interface being a inside of a single parent window)? Or is this just happening under the hood?

Could anyone share a screenshot of what switching model is like on Mac?


#10

Yes, it’s obvious to the user that only one instance is running and that it can have multiple windows. It has one menu bar at the top of the screen which is not attached to any window. SketchUp will have an icon in the dock and a black dot to show that it is running. If you did run multiple instances, each instance would have its own icon in the dock (not normal on Macs).

I forgot to show this, but if you click on File menu -> New you get a new window.
When you see the big icons in the middle of the screen, that’s me command-tabbing to change applications (to SketchUp). At around 0:07s I’m using exposé to see all SketchUp’s windows and choose which one I want on top.

Click the Youtube logo to watch it larger.

Edit:
The video shows SketchUp Pro 2018 on OS X 10.11.3 El Capitan. The same version of SketchUp on a newer operating system macOS 10.13 High Sierra does have tabs in addition to all the above. I don’t know if 10.12 had tabs too, I skipped that version.


#11

I’m trying to make sense of the Mac issue of the dialog freezing SU.

If I understand it correctly a modal dialog is created and locks the parent window (process?), but the dialog fails to be shown, meaning you can’t close it and unfreeze SketchUp. This appears to be a severe bug!

Does this code show a modal dialog, pausing SketchUp, and makes SU continue as normal once the dialog is closed?

def test
  dlg = UI::HtmlDialog.new(
    :dialog_title => "Dialog title",
    :preferences_key => "com.sample.plugin",
    :style => UI::HtmlDialog::STYLE_DIALOG
  )
  dlg.set_html("HTML")
  dlg.show_modal
end

test

If so, what options can be omitted and still have it work?

It would make very much sense to not have to specify a preference_key for a message box like dialog (they always appear in center, regardless of last position). I sincerely hope preference_key isn’t compulsory.

style is documented as optional, with UI::HtmlDialog::STYLE_DIALOG as default.

It would make sense that all dialogs need a title, but then SketchUp should throw an error if it’s missing, and not freeze. Or better, just through in “SketchUp” as title. In production I always specify a title but I didn’t care for this test. SU on Window’s doesn’t require it and seems to use a temp file name as title.

SketchUp%20freeze


#12

That’s what @john_drivenupthewall saw, but not what I saw! On my Mac the dialog from your original version appears on screen and looks like this:

Clicking either of the buttons or the red close circle closes the window and returns control to SU. The dialog’s default title is somewhat funky, so one would want to provide something more sensible, but it works.

The second version opens a large window with the title you provided and the contents just the word HTML. It works the same as before, but of course there are no buttons so I must click the red circle to close it, at which point control returns to SU.

Perhaps the behavior is sensitive to the version of OS X, as John’s profile says 10.11.5 whereas I am running 10.13.3. If there is a version sensitivity that causes this, yes it is a serious bug!


#13

And a follow up question on how SU for Mac handles dialogs: do dialog windows (non modal) belong to a parent SketchUp window? On Windows Ruby dialogs (at least with the style UI::HtmlDialog::STYLE_UTILITY) belong to a single SketchUp window, and switching to another SU main window shows that window’s dialogs instead.

Does windows on Mac belong to a parent window like this, or is the same dialog shown regardless of active window? If you want to, say, create an Entity Info clone in Ruby that depends on the active selection, would one and the same window have to be shared between models and somehow update when the user switches model, or would different models show different dialog windows?

Edit: Forgot to post the exampel video how SU for Windows handles dialogs.

On Windows even the floating toolbars are window-specific. They appear on the same place when SketchUp starts but can be moved around in one window without affecting the other.


#14

Seems to be version related then. Maybe 10.11.5 requires a certain hash option, but 10.13.3 doesn’t. I’d like to file an issue for this in the SketchUp API issue tracker but it’s probably best to leave it to someone who can reproduce it.


#15

The key thing to appreciate here is that the Mac’s application-centric interface (a better term than MDI) is the reason why the Ruby API has the method called Sketchup.active_model. There can be several models open in the same instance of SketchUp, each with its own view window, but only one of them is active at a time.

All of the built-in inspectors automatically notice when you move the focus to another view window (i.e. change the active model) and change their contents accordingly. When a modal HtmlDialog is posted, it is not possible to change focus to another model view so the question is irrelevant then. If your code opens a non-modal HtmlDialog, you can change the active model and you would then have to use an observer to refresh the dialog if the contents depend on the active model. There is one customizable toolbar at the top of each view window, but it is the same for all view windows; you can’t customize it differently per-view. All other toolbars are always “floating”. They don’t attach to any specific view window and don’t change when you switch to a different active model.

I must note that most of the things you write about Windows would also be true on Mac (aside from the fact that the SketchUp GUI on Mac doesn’t provide trays) if the user launched a second instance of SketchUp instead of opening another model within the current instance. For instance, switching to a different instance of SketchUp would activate that instance’s dialogs instead of the previous one’s. But, as noted by @McGordon, a Mac user would not normally open a second instance of an app; it is in fact a bit awkward to do so.


#16

That is good to know! Then I should probably do the same for my non-modal dialogs showing model specific content. Instead of creating a new dialog for each model (to somehow mimic window’s owned windows) I update the content to correspond to the active model each time the user switches active model.

I’ll use modal dialogs only when necessarily to wait for a return value or to show an error message, similarly to how UI.inputbox, UI.openpanel and UI.messaegbox functions.

Thanks!


#17

for any HtmlDialog to ‘show’ on El Capitan they seem to need either:

dlg  = UI::HtmlDialog.new( preferences_key: 'some_key' ) # with or without {}
dlg.show
dlg = UI::HtmlDialog.new
dlg.center # set_size also works
dlg.show

@McGordon, what happens on your El Capitan mac?

john


#18

It seems like this issue is easy to miss as it just happens to work in most real use cases.

@tt_su is this a known bug?


#19

Firstly I’d like to say that I’ve never used HtmlDialog before, I’ve only used WebDialog, so I’m no expert on this.

I Tested the code in Eneroth’s first post and the dialog displays and locks you out of all windows in SketchUp. Clicking button 1 or 2 returns the correct value. I can still activate the menus but most tools native tools are deactivated.

3D Text is one that is active, but if you click on it and click the “Place” button, nothing happens. The HtmlDialog is still blocking it. Once you dismiss the dialog by clicking 1 or 2, the 3D text is on the cursor ready to place. The same happens with the SketchUp->About SketchUp dialog. It displays but you can’t dismiss it until you’ve dealt with the HtmlDialog.

Plugins/Extensions are still active but if you click on them and they open a WebDialog you can’t actually use them, SketchUp is still locked up by the HtmlDialog.

This was on El Capitan 10.11.6.

An example of doing it the right way on a Mac would be sheets which are modal to a window. Like Page Setup in TextEdit. The dialog (sheet) slides down from the top of the window and locks up just that window. You can still switch to other windows in the same application. Only the window with the sheet down is locked.


#20

That is about how much experience I have using Mac.

Am I correct that sheet is the element being used for Save As on Mac? It really does sound like this would be the expected UI element for a modal HtmlDialog, but with a shared Ruby interpreter that pauses until the dialog is dismissed I think it has to lock all windows of that SketchUp instance :confused: .

How does messagebox and inputbox work on Mac? Do they lock all SketchUp windows for the same SketchUp instance?

Is running multiple SU instances on mac something users actually do, e.g. to make extensions developed on PC work better or to avoid loosing all open documents on a crash?