Note to Google: Better Browser == Better WebDialogs

tbd

you dont need to install FF (or other browser), you just need to add a DLL to SU distribution and integrate it.

I would like to have Awesomium - it is a Webkit based (Chromium) and allows creation of JS objects with C++ code, so no need for that cumbersome bridge between Ruby/Webdialog via window.location

you can even go further by having the WebDialog window inside the 3D space - e.g. as a 'texture' on a face (look at the video demos on the Awesomium page) with transparency

chrisglasier

@unknownuser said:

you dont need to install FF (or other browser), you just need to add a DLL to SU distribution and integrate it.

I would like to have Awesomium - it is a Webkit based (Chromium) and allows creation of JS objects with C++ code, so no need for that cumbersome bridge between Ruby/Webdialog via window.location

you can even go further by having the WebDialog window inside the 3D space - e.g. as a 'texture' on a face (look at the video demos on the Awesomium page) with transparency

I think the emergence of this kind of information is sufficient evidence for the need for a separate webdialog forum in order to encourage more ...

Don't you think so?

Chris

thomthom

I'm up for anything that encourage a single renderengine for webdialogs across platforms.
Whether its embedded Mozilla engine or the web-kit - I don't mind. The useful aspect here is uniform rendering and behaviour.

The mozilla engine has for a very long time offered embedding - like the IE.

thomthom

From what I hear, the reasons that Google chose IE for Windows and Webkit of OSX was because they are embedded into the OS - so no extra components needs to be installed to use it.

Somewhat convenient - but also a problem. As the rendering output would then depend on whether the user keeps the system up to date. As it is now - making a webdialog faces the same problems as making a website - an unknown user agent with possible multiple versions, resulting in varying results for the user.

If Sketchup used an embedded engine it's be stable, between platforms and be independent of OS update. The features available would depend on the SketchUp version -what embedded version it shipped, and it's much easier to test for SU version than a multitude of IE and Webkit versions.

This is something I'm hoping for for SU8:
More power to the SU ruby API - develop SU as a platform for other developers. More API and a stable webdialog system.

MartinRinehart

Summary, this far:

one vote for any browser that supports <canvas>
one vote for Firefox (which supports <canvas>)
one vote for Awesomium (which is a Chrome fork, which supports <canvas>)
one vote for a single render engine (all suggested alternatives support <canvas>)

I agree with everyone and would like to switch my vote to agree with ThomThom: a single render engine (as long as it supports <canvas>).

Is that Firefox vote a vote for FF the browser, or could it be interpreted as a vote for FF's engine?

Mine is not a vote against Awesomium. I don't know enough at this point to pick one engine over another. I'd like to hear from those who know more than I know. Is there an engine that will bring the <sketchup> tag closer to reality?

thomthom

I think the options for embedding layout engines, AFIK are:
Gecko - The engine Firefox uses
Webkit - The engine Safari and Chrome uses
Trident - The engine Internet Explorer uses (not really an option)

"Browser" is the UI shell over the engine. There is many browsers - but a fewer selection of layout engines. http://en.wikipedia.org/wiki/Comparison_of_layout_engines

Gecko and Webkit is the larger ones are are kept under constant development. Both which now supports canvas. (Not sure if any of them support it 100% - but the standard is still being developed... but I'll get there.)
Any of the two is good choices IMO.

MartinRinehart

@unknownuser said:

you can even go further by having the WebDialog window inside the 3D space - e.g. as a 'texture' on a face

I read that too quickly, first time. I do hope everyone gives that some thought!

Now what is the relationship between Awesomium and WebKit? Does Awesomium stand alone or are there other WebKit-based alternatives?

And where is everyone else? Chime in, all!

Chris Fullmer

I chimed in and you didn't even count my vote!

I really don't know anything about it though, so I'm not a great person to really speak up here. But from what I've seen, implementing a browser that works identically on Mac and Windows (or webkit, I suppose) is paramount. And that's why I'm voting for Chrome, since it is Google's very own.

Chris

tbd

@martinrinehart said:

Now what is the relationship between Awesomium and WebKit?

Awesomium uses WebKit for the page layout and javascript engine. and also renders the web page to a texture so you can put it on a face. and extends the javascript object space so you can bridge with other apps easily.

@martinrinehart said:

Does Awesomium stand alone or are there other WebKit-based alternatives?

you can take a look here for some examples of WebKit usage

using the webkit nightly build I was able to play JSNes (a NES emulator writter in JS, open source) with 50fps compared with 16fps in latest Safari/Firefox (on Windows Firefox was not playable at all)

as Google Chrome/Chromium is using WebKit I think it is a safe bet to have a WebKit based WebDialogs in SketchUp

thomthom

Awesomium sounds very interesting. Haven't heard of it before.

MartinRinehart

@chris fullmer said:

I chimed in and you didn't even count my vote!

A thousand apologies.

@unknownuser said:

... as Google Chrome/Chromium is using WebKit I think it is a safe bet to have a WebKit based WebDialogs in SketchUp

I think we're unanimous on the first point: SU should have a single HTML/JavaScript engine.

Which engine? I assume that the Google engineers who did Chrome studied the alternatives and chose WebKit for valid reasons.

Can we make this unanimous? WebKit/Chromium with a strong recommendation to examine the Awesomium flavor?

And do we have a volunteer to carry the message to the right place in Boulder?

chrisglasier

@martinrinehart said:

And do we have a volunteer to carry the message to the right place in Boulder?

As this seems very much related to browsers and operating systems, whether for operating computers or operating businesses*, don't you think this is more Google directive?

And I still think a separate web dialog forum would give the subject more status.

Chris

*in a similar sense that barcoding supports supermarket business operations

tbd

@unknownuser said:

is just so dominant normally hovering around the 90% mark

this depends on the site, for example on sketchucation IE is only 31% compared with 33% of Firefox and 10% of Chrome. maybe we can switch to Google Chrome Frame in IE

MartinRinehart

@unknownuser said:

the Sketchucation audience is very specialized.

Good to see a new face. Welcome.

Yes, almost everyone you see here has DLd/installed SketchUp. That does not take great strength nor Einstein's IQ, but it does show some minimal computer moxie.

Now let me address the MSIE issue. I'll try to keep this clean.

Webmasters (pros and amateurs like me) hate MSIE. That's a deep-in-the-bone hatred based on untold hours of working around MSIE's refusal to comply with standards. On Windows, I have a "user" named "Browser Test". It has Chrome, Firefox, MSIE, Opera and Safari browsers. Four of the five basically run the same HTML and JavaScript, the same way, getting the same result. MSIE is in a world unto itself.

One example: in my VisMap plugin,

http://www.martinrinehart.com/models/rubies/vismapdoc.html

examine the HTML. It's layout is screwball. Why? MSIE was unable to lay this out without the bogus, no-content first row. How long did I take working around this single MSIE issue? I'm trying to forget!

Here's an example from P.P. Koch's excellent Quirksmode reference. Suppose the user clicks the mouse. Your code needs to know the mouse's position to respond intelligently. This is what you need, in a standards-based browser:


function doSomething(e) {
   var posx = e.pageX;
   var posy = e.pageY;
   // posx and posy contain the mouse position relative to the document
   // Do something with this information
}

This is the same function, but written to support that other browser, too.


function doSomething(e) {
   var posx = 0;
   var posy = 0;
   if (!e) var e = window.event;
   if (e.pageX || e.pageY) {
      posx = e.pageX;
      posy = e.pageY;
   }
   else if (e.clientX || e.clientY) {
      posx = e.clientX + document.body.scrollLeft
      + document.documentElement.scrollLeft;
      posy = e.clientY + document.body.scrollTop
      + document.documentElement.scrollTop;
   }
   // posx and posy contain the mouse position relative to the document
   // Do something with this information
}

And that is why some of us are hoping to create a little MSIE-free zone in this corner of the world.

Chris Fullmer

Even if we went with IE, just make it so that both win and PC use the same browser.

SU could package up their own version of chrome to disctribute with SU. Plus that would put chrome on to millions of computers rather quickly.

Chris

thomthom

I think the most important criteria: which ones will let the .execute_script be synchronous?