Add Abilitity to 'Dock' HtmlDialogs

The hacking of the trays.

You are free to re-position if want. I’ve done that.

Sometimes there is no other way than a timer, but be sure to keep persistent reference to the timer while it’s “live”, so it can be switched off when unneeded.

Okay, so how would I do this fake docking ?

I’d create an invisible window, and set the parent window for the two “docking” windows, to be this invisible parent window. (Perhaps even create two sub-panes inside the parent window.)

Interesting. As I said, I’m in learning mode on this one. I never fooled around much with windows API till yesterday. I’m not sure how to set a window as parent or how to intercept window messages. I guess I’ll need to do some more research.

There was a WxRuby implementation of WxWindows for SketchUp, at one time. I don’t know if it will run anymore since SU went to Ruby 2.x, but the code might enlighten you. Basically it wrapped the whole SketchUp application window in an invisible WxWindow frame, and made SketchUp the direct child of it. (This is needed for the WxWindows framework, as the topmost window needs to be one of the classes to be the top of the messaging chain for Wx messages.)

I think it was called WxSU.

It helps to download the Windows SDK:

And bookmark info on technet:

… such as:

So I could have SketchUp and another Standalone program both be child windows, and dock them together using the WxWindow frame? I’ve downloaded the WxSU and will take a look at it.

Some day I should learn C or C++

I suppose, not a guarantee.

I’m not saying to go crazy with this stuff. Most especially without a thorough understanding of how window objects interact (messaging) in MS Windows. The WxWindows messaging is separate scheme that does not suppress the former, in the case of WxSU.

This sure sounds like a good time, as it is required for the Windows API. I mean at least basic introductory C, so you can read code examples, and understand what the function documentation means when it says it needs a pointer or a struct.

Ok thanks for your help. I will let you know if I have more questions.

I would like to put my upvote on this feature request. The issue with all these hacks is that, they don’t resolve the actual reason a user would want to dock a dialog. In my case for example, I would want my user to be able to see the HtmlDialog side-by-side next to their model while they are working on it because my dialog changes as the user makes changes to the model. From a UX standpoint, it would be bothersome if my HtmlDialog covers parts of their model. When a tray is docked in SU, it actually changes the viewport and so it’s not possible to cover the model with it.


I was just wondering if that could be achieved by creating a custom tool and showing your HTML in the instructor? Or perhaps (potentially a bad idea?) even override the instructor for the standard tools like the select tool. The problem that I for see is no action callbacks or other methods. It wouldn’t seem hard for SketchUp to add an HTML panel similar to an HTML dialog.

Also with that there should be a way for users to manipulate the tray using the Ruby API.

  1. Add and remove panels from tray.
  2. Expand and collapse panels.
  3. Add and remove trays. Rename existing trays.
  4. Pin or unpin tray.
  5. Re-order panels in trays
  6. Un-dock, re-dock, or change docking position for trays.
  7. Maybe there are more…?

Who needs cumbersome HTML Dialogs anyway! :stuck_out_tongue:
Imagine the improved workflow/user experience if they would go away!
BTW: I noticed the instructor panel already uses the Chrome browser. :+1:

1 Like

If you set up a local web server within your plugin and use it for the inspector I think you could implement callbacks that way. I wouldn’t recommend using such a hack in a real plugin though even if it would be cool to make a proof of concept. I think quite a lot of users always keep the instructor closed because of how distracting it is.

I really want this to be supported natively.

There could be additional arguments to the HTMLDialog constructor to allow it to be docked and to have it docked when first shown. However the native tray “objects” (I don’t know what they are called) are always available so from UX standpoint it might be odd to have a plugin create new ones and remove them on runtime. Perhaps it’s best to register new tray “objects” when a plugin is first loaded, and then have it available regardless of things like active tool, similar to how the Material browser is available without the paint bucket tool being active? Maybe there could also be a dedicated tray “object” for tool settings that is associated with a tool object just as the instructor? The default behaviour of SketchUp could be to expand it when activating a tool that uses it and collapse it when activating a tool that doesn’t.

1 Like

In my opinion proper UI would be to use dialogs as a popup for input or to inform the user. They should be such that they would be closed when the user is finished interacting. Trays on the other hand are great for stuff like inspectors where you want them to become part of the UI. Using dialogs for this is cumbersome and annoying.

I envision adding trays/panels being similar to creating tool bars and toolbar buttons. Although unlike toolbars and menus I would like to be able to access them later and modify or remove them. I would be OK with having a ‘handle’ similar to timer and observers. This would prevent other extensions from modifying my trays. Also it would allow you to change your trays according to tool usage or other things. For example you might want some type of inspector that is only shown when your tool is active.

It might not be necessary to manipulate the ‘built in’ trays, but creating custom built trays for an extension would be a huge UI improvement in my opinion.

1 Like

I think it has not yet been done, because the trays have not been implemented in the Mac editions.

Of course not, as the Instructor is exactly this.

Sure if it only happens during your custom tool.

Yes, bad idea. Anger the users, or violate the normal operation of the application. (Trimble is not likely to be happy about this idea.)


what gives you this impression?


As far as I can tell, HtmlDialogs are being handled by a modified Chromium.

I think the first and easiest step for now is to just be able to register an HtmlDialog to be added to the list of tray dialogs (see below screenshot). This just means adding a parameter to the constructor of HtmlDialog like :tray_dialog => true/false.

1 Like

Chromium and the system browser (IE or Safari) are used for some dialogs. Some aren’t based on HTML and are handled directly by SketchUp without any browser.

When it comes to implementing this I think there is much more to it than just add the attribute. The native tray dialogs are always available, not created and removed while using the program. Maybe custom tray dialog should obey this convention, i.e. be registered when the extension is initialized, I don’t know.

… Chrome I mean … :grinning:

Just noting this was requested in a “wishlist” thread recently …

1 Like

We really need this feature!!! Pretty please with a cherry on top… :pray: