Are there plans to use a different browser engine?


#1

Hi,

the experience I had with web dialogs in Sketchup were displeasing. Not only do the engines depend on the OS, but also their version (older Windows with IE9, newer with IE10). We need to use workarounds like calling show or show_modal depending on the OS, and it’s astoundingly hard to debug JavaScript errors with no dev-console. And of course Internet Explorer itself has a lot of missing features/quirks that make developing a rich dialog cumbersome…

Are there any discussions, decisions or plans to use for example the Chromium embedded framework for a consistent result among all platforms combined with a much better developer tooling/experience?


#2

Everything you said in your opening paragraph above has already been said before.

Thomas Thomassen has a WebDialog manual online:

Many over the years. Some in old forums that have long since been archived and are no longer available. (SketchUp has been owned by 3 companies, and the first two owners went through a couple of different forum sites. I think this site may be at least the fifth official SketchUp forum.)

You’ll find quite a few discussions about the UI::WebDialog class over at the SketchUcation Developers forum, going back more than 8 years.

As a publicly traded company, Trimble employees cannot make any “forward looking statements” nor divulge future product plans. That is marketing’s job. Historically, the “plans” are never revealed until the public release, and they usually happen along with some fanfare / event like Trimble Horizons, or 3D BaseCamp.


I myself played around and tested running ChromeFrame inside a MSIE SketchUp WebDialog, and it worked,… BUT,… it required that security was switched off machine-wide, which was an unacceptable risk. So that avenue died, quickly. I even discussed fixing this issue with the Google developers in CA, but they were not interested in tweaking the public build for embedded use, and basically said we need to tweak and build our own edition of Chromium. I looked into it and it is way too complicated unless you already know *nix like systems and GNU tools. Way beyond me.

At one time, I was suggesting perhaps an API wrapper around Gecko. (I think,… it was a long while ago.)

Anyway, since those times, Thomas Thomassen has written some wrappers around the Webdialog using the JQuery framework.


#3

UPDATE


[Issue Solved]

With the release of SketchUp 2017, the SketchUp Ruby API now ships with a custom embedded Chromium framework which is wrapped by an API class named UI::HtmlDialog.

Note also that the old UI::WebDialog class is now dreprecated.


#4

I agree this is a much better and cleaner way forward. But unless (and I don’t see how it could happen) there’s a way to retrofit HtmlDialog so it can work in earlier versions, making backward compatible rich dialogues is no easier.

But it is certainly a better platform for current and future versions of SU.


#5

Hmmm, interesting idea.

It is not at all likely any retrofit could happen for those old versions running pre version 2.x Ruby (ie, SketchUp 2013 and older,) as unicode support is really needed and all those versions running various Ruby 1.8.x versions have no Ruby unicode character support on Windows.

Also, the compiled Ruby interfaces are Ruby 2.2, so I’m not even sure that any direct porting to SketchUp with Ruby 2.0 (2014…2016) could happen either.

SketchUp has never released any backport-type of releases for older versions. It is just not within policy.
The licensees who paid the maintenance subscription fees (that help offset this kind of improvement,) could “cry foul” and ask why should they be paying for improvements to those people who haven’t been paying their share,… or they’d start to think that they don’t need to be upgrading if the old versions are going to “get some new sugar” also.

Also, the developers don’t expect this, and some have written their code to check version number and load UI::HtmlDialog compatible code if version 17 or higher, and otherwise use UI::WebDialog code. So, doing a big backport like this might cause unexpected issues for plugin developers.

Lastly, there is no way that 4 installer/packages [Make/Pro (Win/OSX)] for 12 languages (48), for the previous 3 SketchUp versions (2014…2016) using Ruby 2.0, (144 total) would be re-compiled and re-issued as updates. (Even only those last 2 versions still “in support” would result in 96 packages to compile and distribute.) And I haven’t even mentioned the costs of testing.


The only way it could or would happen, would be an extension that must be explicitly installed by users.