@mike said:

situation whereby SketchUp v8 could well be regarded, with SketcHucation's Plugin Shop, to be quite satisfactory for requirements

And as for my recent experiences, SU8 has less Ruby bugs and the exactly same Ruby API features. Thus the superior platform for running plugins (if we leave the huge performance optimizations aside).

@unknownuser said:

This one new feature is actually dozens (eventually hundreds) of new features

What impresses me is this fatal dependency. They depend on us and we depend on them: We are strong in working with the API, we are able to create almost thousand plugins, but are unable to push the core of the platform forward or fork it.

We simply lack experience in the core technologies, native code, graphics pipeline and OpenGL stuff.
Calling SketchUp a platform is tough, it neither supports more than two OS (don't mention mobile) nor a near bug-free API. As an open core platform and written from scratch with modern technologies, SketchUp could give its users freedoms that other opensource software has: hardware and OS support spanning from ARM to x86 64bit, with a transparent roadmap and progress that we can influence. But it would require more expertise, a common goal and leadership that simply is hard to achieve in a heterogenous community of free time programmers vs. a proprietary company.

There are plugins that copied that line from the Ruby example scripts. We've hinted the SketchUp team that it would be worth to remove the less recommendable code and follow best practices.

Make sure you don't have sketchup.rb in the Plugins folder (only one should be in the Tools folder).

I agree with Jeff, how would it add a selling point if SketchUp came with included tools that a) work the same way as in other software and b) are already available in the Extension Warehouse? Maybe even not everyone would find them useful. They have just begun removing rarely used functionality and making them optional add-ons.

@unknownuser said:

…they would approach it with a fresh state of mind…

That's what many expected to see in recent releases, but the last time that happened was @ last. The innovative tools that have a vision and inspiration are all those that have been in SketchUp for many years (pushpull, followme, etc.). Later solid tools where added, not world-shaking new, but that was mainly worth the investment because boolean operations are faster in native code.
Now something new!

No changes (fixes?) to the Ruby API? Ok, after years of hunger we have learned to live from nil. But if nothing has been touched then I'd expect at least no regressions.
Now if we compare: the same SketchUp with the same SketchUp, we would not prefer the one with more bugs.

A quick update for compatibility with SketchUp 2013. It was released so quickly.
This is the last version before 2.0

That was a copy paste mistake.

I don't know how it is on OS X. If pixel doubling is used, I'd expect existing webdialogs work without change, but the above points wouldn't hurt. I don't know if it can set anything inbetween.
The same goes also for devices like the Toshiba Kira where the manufacturer added pixel doubling etc.

Internet Explorer interpretes pixel dimensions as screen pixels (at least if the dpi is set to a fraction between 100 and 200%). Because of that, pixel-dimensioned elements preserve their size whereas relatively dimensioned elements scale smoothly to whatever dpi value is set. Websites or webdialogs with a mix of relatively and absolutely dimensioned elements easily show a broken layout with some boxes too big or overflowing.

Thus we can come to the following conclusions:

• If you want your WebDialog not to stay tiny, avoid pixel dimensions (as it should already be best practice), but use relative units instead, like em which is relative to the line height (or % which is sometimes relative to parent box sometimes relative to font size).

• Use the least CSS markup possible.
  The less markup, the less properties override each other or clash and the most readable is your code. Generally it is only necessary to define the font size once for the body ( 1em) and than only on those elements that deviate from it (smaller or larger, like 0.8em, 1.2em).

• If you use CSS2.1 system fonts (link), Internet Explorer behaves wrong and doesn't scale the text like the rest of the interface outside of the browser. The solution is to override the automatic font size with a relative value.
  Once for the body:
  body { font: message-box; font-size: 80% !important; }
  and everywhere else:
  .some_class { font: message-box; font-size: 100% !important; /* or 1em */ }

• Scaled images become interpolated (blurry). You can either double the source image's resolution, or leave the dimensions away to let it stay at a constant pixel size and adjust the layout to make it flow well (align it center/middle).

• Background images don't scale, except in modern browser versions with CSS3 background-size.

• One challenge is the dialog size, that would need to be adjusted by script to fit its content. The SketchUp API methods like UI::WebDialog.width= set the dialog to screen pixels and do not consider dpi settings. So you need to measure the size of the content using JavaScript, send it to Ruby and adjust the webdialog accordingly.

• If you want to test it, set your dpi setting to something that is notably different, like twice the default %(#000000)[2×96 = 192 dpi].
  

I don't see a favor of the C++ API. In fact it was almost dead under Google, and is now only near equally alive as the Ruby API.

@unknownuser said:

Javascript IMHO.

Especially since such a partly implemented API already exists, and even a first plugin.
Even if JS is not a beauty of a language, it's benefits are the wide-spread and the billions that have been invested into its speed optimization (although Python/Ruby&Co. have also benefited from such developments).

For the original topic of this thread, neither webdialogs nor SketchUp's choice of scripting language matter. Node-based interfaces (previously mentioned as visual programming) are neither a replacement nor conflicting with webdialogs.

SketchUp is usually fully backwards compatible. Developers have already moved to SU2013, but did users notice it? Did plugins stop working in older versions?

I am convinced plugin developers would do everything to make their plugins available to as many users as possible, in as many versions as possible. I believe even more than the SketchUp team officially supports.

Shouldn't SCF buy them?
(Or at least infiltrate, which comes out cheaper)

Are you sure you use the latest version?

Many things are a shared decision. Someone decides for you. You decide not to quit your software/OS/platform or whatever. Especially in software development, it is common not to rebuild everything from scratch (aka. from drivers and toolkits) but do high-level programming using components from others on which you have little influence.

@chiefwoodworker said:

So far Trimble gets a failing grade from me for its influence on SketchUp.

In what way does Trimble show a different influence than Google? I don't see any influence.

There's a famous saying in Germany: "You can't rebuild in 10 years what has been rotting for 40 years" (meant about the previous eastern Germany).
I think it fits well to SketchUp. The transition to Trimble has cost a lot of time, effort and resources to rebuild infrastructure that is not yet visible to many. A lot of the foundations of SketchUp have been renewed (latest build systems, UI framework) which is the foundation for something new. While the development team has been continuously grown at a rapid rate, I'd expect visible changes to appear through the Extension Warehouse. This is the way through which Trimble and SketchUp give you new tools.

Inline-reply: And yes, I mean not hobbyist scripts but Trimble extensions. Why should not Trimble add their tools via their own API (how a well-architectured software is supposed to work)?
And: A multi-line Ruby console with unit tests has been added by the SketchUp team, whether you want it to be true or not.

Search the plugins… find

What's coming next

Les barres d'outils ne font plus la fête quand tu ne vois pas.
Et tu peux faire tes propres barres et sortir les icônes en avant ou en arrière!

I will experiment again, but as far as I remember the single thread of SketchUp's Ruby freezes so that either the flag can not be set (because it is busy waiting) or whatever I do to wait never gets time to notice the changed flag.

For now, you can add ".php" in the address bar.

Do you have an example code snippet? When I search for a ruby semaphore, I find threads etc.