Web dialog on a Mac

Dan Rathbun

Specifically I do not know.

Generally the OSX GUI is different from the MS Windows GUI.

Garry K

I have also been experimenting with web dialogs. This works with Windows 7 and sketchup 7,8 and 2013.

Hopefully someone with a MAC can try this and see if it works in Safari.

I have Chrome, IE11 and Firefox installed. The code works with these Browsers but only if I rem out the line that references sk

web dialog

This file adds a menu Item under Plugins called "Web Dialog Test"

driven

looks like this in SU, and works
but you do need a version of

    # then set_html or file/url if separate...
    @dlg.set_html html
    if( (RUBY_PLATFORM =~ /darwin/i) )
    @dlg.show_modal
    else
    @dlg.show
    end #if

john

Garry K

Thanks

I can easily add that.

When you clicked "Ok" button did you get a list of Control Id's and values?

driven

you mean this?

pre-setting the size [webDialog] is better as well.

john

Garry K

Yes - that is what I meant.

Pre-setting the size would help on Windows for the first time it is run. But after that the window uses the last known size and position that the user set it to.

Does it work differently on the MAC?

driven

same, it just seems more polished if it comes in at the correct size...
john

Garry K

I hear you. If you change the first line of the function to this does it work correctly?

dlg = UI::WebDialog.new( "Stair Measurements", false, "StairMaker_Web_Dialog", 570, 452, 0, 0, true );

driven

I think I used 628 × 500, SU include the Title-bar in it's size on most mac's...

I'll check later

john

Garry K

One difference that I see is with margin.
margin: 2px works on Windows = but it appears that the margin is larger in Safari.

Perhaps the margin is simply ignored with Safari.

The other difference that I see is the check box. I set width to 120px, the same for everything. It centers in Windows and left justifies with Safari.

Is this the same for all MAC's ???

Garry K

I added this line immediately after <head> and also tried it immediately after <html>
I tried it set to "yes" and set to "no with Windows and did not see any difference.

There is a <style> section prior to <head>
When I put the line immediately after <style type="text/css"> then the background color for the body failed to apply regardless if I set content to "yes" or to "no"

So I'm not sure exactly what this metatag is suppose to do. I'm not sure where the tag should go ( although I did read a microsoft page where they placed it immediately after <head>

Also - what will it do with Safari? Did you suggest it because the margins are different with safari?

jolran

You could do some css reset to "try" to remove some browser specific styling..
Has it's pros and cons. Testing needed..

driven

Meta goes in here above Title

<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  <meta http-equiv="Content-Style-Type" content="text/css">
  <title></title>
  <style> *, body {
  -webkit-appearance;none;
 }
 </style>
</head>
<body>
<div>
</div>
</body>
</html>

and if you add that line -webkit-appearance:none;in your styles you get this....
your fighting WebKit, not Safari....

Dan Rathbun

@garry k said:

So I'm not sure exactly what this metatag is suppose to do. I'm not sure where the tag should go ( although I did read a microsoft page where they placed it immediately after <head>

WITHIN the HEAD section, BEFORE any SCRIPT or STYLE sections (tags).

I am sorry that webpage shows the tag incorrectly.

It should be:

<meta http-equiv="MSThemeCompatible" content="Yes">

It will be ignored under Safari.
On Windows it will make the web browser control use native MS Common Control styling (just like the users dialog boxes. Buttons with hover effect, styled checkboxes etc.)

Dan Rathbun

Activate Windows native control styling...

How to: <meta http-equiv="MSThemeCompatible" content="Yes">

EDIT: changed name= to http-equiv=

Garry K

Thanks - I will see if someone will help test this on a Mac once I get closer to releasing the StairMaker plugin.

tt_su

A bit late to the party, but if you just need simple controls and theming then you can try out SKUI: https://github.com/thomthom/SKUI/wiki/Quick-Overview

Takes care of all the WebDialog stuff and exposes only a Ruby object model to the GUI elements.

Garry K

Interesting idea - but what I need goes a bit above this. I want to add into the web dialog a jquery call using JSON to query a MySql database on my website. I will use PHP for the server portion.

In any event - good knowledge of CSS, HTML and JS is good to have.

Garry K

Well, call me frustrated.

The simple test application worked with the Mac. But the complete Stair Maker plugin does not work with the Mac.

I've added instance variables for the web dialog.
I've stored the text that Ruby passes over to the Web Dialog as an instance variable and built prior to calling the web dialog.

I must be missing something. The overall strategy now is:

if ( document.addEventListener )
document.addEventListener( "DOMContentLoaded", ready, false );
else if ( document.attachEvent )
document.attachEvent( "onreadystatechange", check_ready );

When the DOM is loaded it makes a call back to ruby with text == 'loaded'.
ruby then passes the string over to the web dialog for processing.
When the user clicks the button the web dialog traverses the DOM and peels out all of the text for input controls and builds up a single string. Then makes a call back to ruby and closes the dialog.

One question I have is can Safari handle making a call to execute script from within the ruby call back. Or do I need to consider turning this into a state machine?

slbaumgartner

@garry k said:

Well, call me frustrated.

One question I have is can Safari handle making a call to execute script from within the ruby call back. Or do I need to consider turning this into a state machine?

Yes, WebKit can handle making an execute_script call from within a Ruby skp: callback. But you have to be careful what the script does. On the Mac, Ruby will wait synchronously for javascript to return, but javascript will not wait for Ruby, so you have to be careful. Sometimes a state machine or similar is the only solution.

A picky point we Mac'ers need always to reinforce: WebDialog uses the WebKit library, not Safari.