WebDialogs using Chrome : any interest ?

Dan Rathbun

I believe I can implement WebDialogs using Chrome on the PC.

Is there any interest from Developers ?

And no I can't do it for free.

I imagine it would be impossible to convince plain users, to pay any fee (however small,) to add a Library so that certain plugins would work or (perhaps work better, making development easier, etc.)

That means there would need to be a "Developer License."

What would be fair ??

Would you (as a developer,) be adverse to the requirement of scrambling any script (or at least a portion,) that calls the library in question. [ie: teaching non-licensed users how to call the library would be a no-no.]

thomthom

I don't feel the need for it.
To keep it simple I just require my users to have an up to date Internet Explorer, as IE has shaped up very well in the recent releases. Because of that, I don't feel the need to force Chrome into the WebDialog and add an extra layer of complexity into what is already an troublesome interaction between SketchUp and the dialogs. Nor do I see IE as a problem where I'd pay to eliminate it.

I think you need to present your selling points, because IE isn't the old dog it used to be any more.

tomot

I don't use Chrome or IE!
But I am hoping for better integration + greater simplicity.
(knowledge of 3 languages to build one WEB dialog, is not making it simpler)

some questions:
Are Web dialogs, going to be just a passing fad shortly?
With the increasing use of Smartphones and increasing presence of the Android market. Would it not make more sense to build an Android dialog with Ruby/SU integration?

thomthom

@tomot said:

I don't use Chrome or IE!

But SketchUp under Windows use IE, and under OSX it uses Webkit. What you use as a personal browser is another matter.

@tomot said:

But I am hoping for better integration + greater simplicity.
(knowledge of 3 languages to build one WEB dialog, is not making it simpler)

I've been slowly building a wrapper that let me create an manipulate WebDialog controls via Ruby.

@tomot said:

With the increasing use of Smartphones and increasing presence of the Android market. Would it not make more sense to build an Android dialog with Ruby/SU integration?

I thought Android UI was using HTML... ?

tbd

anyone tried Google Chrome Frame ? there is a non-admin install released lately - http://blog.chromium.org/2011/06/introducing-non-admin-chrome-frame.html

tomot

This is probably more meaningful to developers:
http://developer.android.com/guide/basics/what-is-android.html
I envision a screen sized dialog in Android format (same size as the typical smartphone), being used instead of the current Web dialog.

Dan Rathbun

@tomot said:

I envision a screen sized dialog in Android format (same size as the typical smartphone), being used instead of the current Web dialog.

Why don't you start another topic to discuss Android.. I'd like to keep THIS topic on Chrome / ChromeFrame WebDialog's, if you please.

Dan Rathbun

@unknownuser said:

anyone tried Google Chrome Frame ?

YES. And it works.. so far in my testing.

This is actually Option 1 (taking the least amount of time, on my part.)

@unknownuser said:

... there is a non-admin install released lately -

Yes... but it's an additional thing for the user to install, in order to "enable" plugins to be "pure Webkit."

I can make the process as painless as possible (Google shows how.. it's a matter of Cut & Paste code, from their website.)

Dan Rathbun

@thomthom said:

To keep it simple I just require my users to have an up to date Internet Explorer, as IE has shaped up very well in the recent releases. ..., because IE isn't the old dog it used to be any more.

Personally from a user standpoint, I've quit using IE altogether. Chrome is so much faster !!
I got so sick of waiting for IE to initialize.. and render websites, on a 64bit machine with a fresh Win7 install (my Dad's office machine,) that we installed Chrome on it last week. My Dad has not used used IE since.

From a developer perspective.. I'm just done with dealing with the MS quirks.. standards mode, emulated mode, and "there is no public standard that applies to this [HTML/CSS property or method.]" crap.

@thomthom said:

Nor do I see IE as a problem where I'd pay to eliminate it.

OK that's a fair opinion.. and valuable info.

I'm not about to waste time developing something no one wants.

I was under the impression awhile back (before SU8 came out,) that cross-platform WebKit / Chrome WebDialogs were high on the developer community's "wish list."

thomthom

@dan rathbun said:

I was under the impression awhile back (before SU8 came out,) that cross-platform WebKit / Chrome WebDialogs were high on the developer community's "wish list."

This is true, but IE9 is doing very well standard wise. And with the jQuery framework, or similar, scripting JS becomes easy. The main issue is that the WebDialog class itself behaves differently across platforms.

What I'd really find useful is a complete framework similar to what I have a feeble beginning of; a wrapper that lets you manipulate WebDialog content with Ruby classes.

fredo6

Personally I tend to agree with Thomthom:

It is preferable to have only one browser per platform to interact with Ruby. Coping with the different versions of IE (and Safari on Mac) is already a challenge.
IE is much more flexible for HTML and Javascript programming than WebToolkit. Most problems I encountered with Web dialog boxes are precisely on Mac / Safari, not on Windows/IE
It is true that IE might be slower than Firefox or Chrome in many instances, but for the type of web dialogs we need for Ruby scripts, I don't think it does matter too much.
All Windows users have an IE version installed on their PC (and Safari on Mac), so there is no dependency on alternate config.

It is sure that the SU team should spend time to improve the WebDialog class, in particular

for the odd asynchronous behavior on Safari and better exchange of data back and forth with Ruby
for changing the programming framework on Mac (Cocoa or Carbon) to have the click-though behavior like on Windows
for giving static info on the browser control characteristics (which version, size of screen, etc....)
for giving more flexibility in the appearance (web dialog without toolbars, hide which is not a close, etc...)

I hope they work on it in SU9,. After some hesitation, I must say that it was really a damned good choice to interface Sketchup Ruby to HTML controls, because it gives an unlimited power to the GUI.

Fredo

chrisglasier

I am very interested in this and in fact made some effort in a similar direction in this topic ...

@chrisglasier said:

...

Just today I wondered what would happen if I opened the localhost in a webdialog. Surprisingly (to me) the localhost worked just as before. I closed Sketchup and added a link in the localhost to a .skp file in the same directory. Clicking on the link launched Sketchup and opened the file. I also added a simple skp:callback which worked OK once I had opened the webdialog from the plugins menus.

...

I guess there are many if and buts but I very much like the idea of having a universal interface that can call up Sketchup as a kind of plugin and then transform itself into a plug in to Sketchup. So I think it is worth pursuing.

I may have got the wrong end of the stick but would be interested in whether any of this type of approach fits with yours.

iaselle

Hello Dan,

I'm very interested in your topic.

Sketchup uses IE7 as a renderer even on machines with a native IE9. And it seems to uses the quirks mode even with XHTML strict.

I'm developping a commercial plugin and this is an issue. Therefore, I'm interested in your development.

What would be the installation process of your plugin (any executable to run first) ?
Would it impact the usage of the native IE on the computer ?
What are your financial requirements (you can reply through private message if you wish) ?

By the way, "Google Frame" works on native IE but not in the frame of Sketchup IE !!

Dan Rathbun

@iaselle said:

Sketchup uses IE7 as a renderer even on machines with a native IE9. And it seems to uses the quirks mode even with XHTML strict.

It's NOT Sketchup that "does" this. It's the Microsoft WebBrowser control. (ie The native Win32 API HTMLDialog.)

The "IE7" mode is ONLY a default.

@unknownuser said:

(http://forums.sketchucation.com/viewtopic.php?f)":23z4tpg8]And then you can also force the browser mode via a META tag:
%(#8000BF)[<META http-equiv="X-UA-Compatible" content="IE=7" > ]
.. just in case they change the default mode, in the future.

Refering to: META Tags and Locking in Future Compatibility

@unknownuser said:

By default, Internet Explorer 8 uses EmulateIE8 mode to display pages loaded from the Internet Zone. Web pages loaded from the Intranet Zone or with the Web Browser control are displayed in EmulateIE7 mode. These defaults can be changed.

and ...

@unknownuser said:

EmulateIE7 mode tells Windows Internet Explorer to use the <!DOCTYPE> directive to determine how to render content. Standards mode directives are displayed in Internet Explorer 7 Standards mode, and Quirks mode directives are displayed in IE5 mode. Unlike IE7 mode, EmulateIE7 mode respects the <!DOCTYPE> directive.

iaselle

Ok Dan,

But back to your first post in this topic, are you about to succeed I implementing WebDialogs using Chrome on the PC ?

Because, there are still companies that have pools of computers with legacy XP+IE6 ... and javascript execution on IE6 (and even IE7) is very very slow (assuming you're using fancy webdialogs with jQuery etc).

So, I'm still interested and I'm staying tuned

Dan Rathbun

@iaselle said:

But back to your first post in this topic, are you about to succeed I implementing WebDialogs using Chrome on the PC ?

I CAN have (Option 1) working very soon, which is ChromeFrame inside an IE browser window.
(I DO have it working inside Sketchup WebDialogs.) But there are issues, concerning the settings. The settings are meant to control it's behavour for the normal IE browser. If the user or an IT admin make changes to the settngs, it could affect how GCF works with WebDialogs.
More testing is required.

Option 2 : Will take much more time. It will be writing a dedicated DLL, to implement a true ChromeDialog, that does not use IE or Safari, at all.

iaselle

Hello Dan,

I think that the option 1 is worth to be tested.
According to a Computerworld benchmark, IE8 + Google Chrome Fame is 10 times faster that IE8 on its own ... and IE7 and IE6 are 2x slower than IE8 !!

Option 2 seems to be kind of a burden, with a lot of developing, testing and maintenance concerns.

In my context, I will have to install an executable that will be shipped with my SU plugin (with imposed set of dlls I'll be obliged to cope with).

Therefore, a Windows setup will be required (Inno Setup for instance).
If your option 1 need registry keys to force Chrome Fame Usage, this setup could be used for it.

Dan Rathbun

@iaselle said:

If your option 1 need registry keys to force Chrome Frame Usage, this setup could be used for it.

Yes well I have several setup packages that can be used, or I could just use a reg file, or use my private Win32 registry library. Setting registry keys/values is not a problem.

The main issue is to allow use of GCF for local webdialog use without compromising the security of the normal IE browser.

The security policy is reversed for the two cases. In normal browser use, you want to keep the Internet Zone sandboxed within the "Temporary Internet Files" directory, and restrict access to local files, but with local HTMLdialogs, the opposite is usually true. (And if the user navigates in a local HTMLdialog, from the local zone into the Internet Zone, then normal security policies, are supposed to come into play.)

I do not wish to open up a big hole in security. But then perhaps I'm being overly cautious?

iaselle

Let me make sure I understand well the issue with your setup :

If the normal IE browser is not sandboxed anymore, this is an unacceptable security issue
If only webdialogs are not sandboxed anymore, the issue would be coming from other applications installed on the computer, that make use of webdialogs and that allow the user to surf on the web with it. I do not know if there are many of them

First, this problem is only for windows XP users (and the number of XP users is decreasing).
Users with Vista/seven would be adviced to upgrade to IE9 if necessary.

I can accept that for those remaining XP users, my plugin could be used only by administrators.
In that way, could the registry be changed trough the plugin at each startup (before starting the webdialog) and changed back when the users quit the webdialogs ?

Then the issue could happen only if the user would start another application with webdialog while SU is running.

Dan Rathbun

@iaselle said:

Let me make sure I understand well the issue with your setup :

If the normal IE browser is not sandboxed anymore, this is an unacceptable security issue

This is true.

@iaselle said:

If only webdialogs are not sandboxed anymore, the issue would be coming from other applications installed on the computer, that make use of webdialogs and that allow the user to surf on the web with it. I do not know if there are many of them.

Actually WebDialogs (and HTAs,) are not sandboxed by default. But.. (if memory serves,) if you were to have an FRAME or an IFRAME within a HTA that navigated into another domain (especially the Internet Zone,) then the Security Policies for the Internet Zone are supposed to "kick in" automatically.
I am not sure that this works as it should, even now, with the standard API UI::WebDialog class, as we have to explicitly call the set_full_security() method, if we want 'sandboxing.'

@iaselle said:

First, this problem is only for windows XP users (and the number of XP users is decreasing).
Users with Vista/seven would be adviced to upgrade to IE9 if necessary.

Perhaps.. from the point of view, of some here (and I respect that,) but me personally,... I am weary of having to deal with IE and all it's quirks, and all the MSIE only features.

So my point of view is wanting one cross-platform HTMLdialog where I don't need to have platform conditional code on the Ruby-side, and browser conditional code on the HTML/Js side of things.

Also, NaCl (NativeClient,) is looking good for the future, and it's likely to be implemented in Chrome (and Safari,) before it is in MSIE. .. unless I'm wrong and Microsoft has also taken an interest?

@iaselle said:

I can accept that for those remaining XP users, my plugin could be used only by administrators.
In that way, could the registry be changed trough the plugin at each startup (before starting the webdialog) and changed back when the users quit the webdialogs ?

Well.. that is the plan.. but I think that I'd need to "allow" it only for the show() methods, then switch it off again immediately, because the user may have the normal browser open. (I do, actually did have IE open all the time with many tabs open to reference websites like the Sketchup API, and MSDN, etc. But I have switched to Chrome. It just starts and runs, so much faster than IE8. Shuts down faster as well. I also find the options much easier to use than all those postage stamp sized nested dialogs that Microsoft is so fond of.)

@iaselle said:

Then the issue could happen only if the user would start another application with webdialog while SU is running.

No.. really it has to do with whether the user is using MSIE with GCF enabled, at the same time that they are using Sketchup webdialogs.

The main problem I have is, there seems to be a GCF bug... which I formally logged... where I CAN tell if CGF is installed.. but NOT whether it is enabled or disabled as an MSIE extension. (I need to do more testing.. but the ideal situation, would be to use GCF for Sketchup IE WebDialogs in both cases.)

Another "top" issue, is to be sure there is a way, for guys like Fredo and Thom, who have spent a lot of time, tweaking their PC editions of plugin webdialogs to render correctly in IE. Forcing those dialogs to render in GCF, may "break" their functionality at worst, make them look bad at best. I'm sure that they do not want to be inundated with complaints from customers, if things start acting "funny."