(Webdialog) Window match clientsize.

Dan Rathbun

On the Ruby-side, you can get SketchUp's client HxW via view#vpheight and view#vpwidth

If you divide those integers by any numeric, you should use .to_i() to be sure that your dialog HxW values are integers.

When you create your WebDialog object via new() or by setting via webdialog#set_size, SketchUp will automatically save the size (in the registry on Win, or plist file on Mac,) when the dialog is closed, and reuse it in subsequent sessions.

This allows the user to resize your dialog to their own preference. (Unless you set sizeable to false in the new() call.)

So keep in mind that when you call show() or show_modal(), and this is not the first session that your dialog was created, the SketchUp engine will override your original size settings with those that were saved into the "WebDialog_#{*pref_key*}" default key.
FYI: These values on Windows are DWORD data type and cannot be read with Sketchup.read_default(). You would need to use Win32API or WIN32OLE (safer) calls to read them.

The user's screen size IS stored in the Windows registry under key:
HKEY_CURRENT_USER\Software\Google\SketchUp8\ToolbarsUser-Summary
in DWORD value attributes:
ScreenCX and ScreenCY

I am not sure if this key is the same for the Mac plist file !

Dan Rathbun

@jolran said:

I have a callback in Ruby to get in JS "screen.width" and "screen.height", which appears highly supported by all browsers. (it is the Computer screen resolution BTW)

The screen object is CSSOM View Module, 4.2, which may not be fully supported on older Windows computers, running an older version of the MS WebBrowser control (which SketchUp uses.)

FULL Testing would be required.

However there IS a known issue, (on Windows computers,) ie:
@unknownuser said:

** object](http://msdn.microsoft.com/en-us/library/ms535868(v) in Community Additions":11opu1oc]Multiple displays
The screen.width and screen.height properties return the resolution of the primary screen, no matter which screen the browser is in. This is more of an issue, when the two screens have different resolutions. Firefox, Opera, Safari, Chrome all seem to be returning the resolution of the screen that the browser is in.
... and ...
Multiple displays
The screen object only contains data for the primary system screen. Information for any additional screens to which the desktop is extended is unavailable. For instance, if you have two screens, at 1280x1024 each positioned side-by-side, you might expect screen.availWidth to return 2560. Alas, it will return only 1280, which is the available width of the primary screen.

This makes positioning popup windows a bit of a pain if the browser isn't on the primary monitor.

jolran

Lots of good information, thanks Dan.

I posted this topic more as a question regarding how and why to do callbacks to resize dialogs?

Since I saw a script doing it, started to think that is something one must do.

Can't find any documentation about this. Must be some thread burried deep down this forum somewhere...

On the matter about this method I created. As I suspected you(Dan) found a lot of pitfalls in it. So I put it on the shelf for a while. Might prove to useful later on, one never knows..

thomthom

@jolran said:

I posted this topic more as a question regarding how and why to do callbacks to resize dialogs?

I use callbacks when I want to ensure a given client size. I've not found any other method as the window frame differ from OS to OS - even from window theme to window theme.

Aerilius

I'm not exactly sure what you were trying to achieve.

@jolran said:

Is that to make the dialog always have the same proportions regardless the user window size?

It is for the case that you can't predict the size of the content of the webdialog (because you have dynamic content or it depends on browser/font rendering).
If you just want to set the dialog to a fixed size, you use no more than webdialog.set_size(300, 640).

** %(#000000)[doc_width = size[0].to_f w_factor = doc_width/300 # Gives me 5.6 wd_width = doc_width/w_factor]
This gives for me 300 again. **If we need to adjust the webdialog's size to the size of the html document, we let the html document report its document size (clientWidth not screen.width) back to ruby.
Unfortunately the SketchUp API sets the window size of the webdialog (including window titlebar and border) and we actually only measure the document size of the webdialog content.

Aerilius

If we want to work around this problem we would need a strategy like the following:
desired window size = document size + window border size
with
window border size = original window size - window inner size.

I set the webdialog to a fixed size before showing it, like 380×300.
dlg.set_size(380, 300)
After showing the dialog, I let JavaScript report the inner size of the window (the visible area where html is rendered, excluding the title bar and window border):
%(#000080)[window.location.href = 'skp:windowInner@['+(**window.innerWidth**||document.documentElement.clientWidth)+','+(**window.innerHeight**||document.documentElement.clientHeight)+']';]
(The || operator lets us fall back to an alternative expression for browsers that don't understand the first one.)
The webdialog has a callback that saves the window border size into variables (that where initialized to 0).
dlg.add_action_callback('windowInner') { |d, params| params = eval(params) **window_border_width** = (380 - params[0].to_i)/2 **window_titlebar_height** = 300 - params[1].to_i d.execute_script('resizeHeight()') }
Then JavaScript reports the size of the html document (the whole document including where it is not visible) and requests to resize the dialog to fit that size:
%(#000080)[function resizeHeight() { window.location.href = 'skp:resizeHeight@['+(**document.body.clientWidth**||document.body.scrollWidth)+','+(**document.body.clientHeight**||document.body.scrollHeight)+']'; }]
Finally Ruby adds the window border to the document size:
dlg.add_action_callback('resizeHeight') { |d, params| params = eval(params) width = 2 * window_border_width + params[0].to_i height = window_titlebar_height + params[1].to_i d.**set_size(width, height)** }

jolran

@unknownuser said:

I use callbacks when I want to ensure a given client size. I've not found any other method as the window frame differ from OS to OS - even from window theme to window theme

I see. That make sence.

As I said, my code snippets was more of a question than a revelation.

@unknownuser said:

doc_width = size[0].to_f
w_factor = doc_width/300 # Gives me 5.6
wd_width = doc_width/w_factor
This gives for me 300 again.

But it should? I hope I havent done any wierd backward-logic again..
The main Idea was that the dialog should have the same size-proportional regardless of screen resolution.

Aerilius. I will have a deep look at your code and come back later.
Have some other boring stuff to take care of first.

Thank you for your answer and code.

jolran

Finally had the time to go through your explaination, Aerilius.
And I now understand what you are doing in your code.

That make perfect sence, I got it all backwards.

Somehow I got the impression one had to resize dialog window to compensate for different user monitor sizes.
Thats why I was fiddeling with screen size.
And as Dan was pointing out, this can easyly become problematic.

I think dlg.set_size will do fine for me. Thanks

Dan Rathbun

It feels SO good to have an epiphany !

jolran

Epiphany

thomthom

@jolran said:

:enlight: Epiphany

Sounds like the name of a girl...

jolran

@unknownuser said:

Sounds like the name of a girl...

Yeah, Tiffany.

On the subject about resizing webdialogs. I have been experimenting with dlg.set_size a little today. And it's possible to change layout with the click on a button, for ex. With some callbacks and CSS. Cool! One can therefore have vertical or horisontalmenys as an option.

Now since I'm on a roll with strange solutions and odd logic, I gotta ask. Is there any pitfall doing this?

I reckon 1 is that the dialog dimensions will only be remembered during sessions(if using @variables), and go back to default setting when restarting Sketchup.

I'm just experimenting so it's not sure I would need a function like this, but it would be nice to know if its safe to use.

driven

@jolran said:

I reckon 1 is that the dialog dimensions will only be remembered during sessions(if using @variables), and go back to default setting when restarting Sketchup.

don't forget it's not the WWW and a independent browser.
SU can collect values and rewrite the html and can use .min_height, .max_height etc. to lock and carry the setting to the next session...

overall position is harder to guarantee.
john

jolran

@unknownuser said:

don't forget it's not the WWW and a independent browser.
SU can collect values and rewrite the html and can use .min_height, .max_height etc. to lock and carry the setting to the next session...

Yeah, Trying to get a grasp of that. It's not evident (for me anyway) what one "should do" in ruby and what goes best in html/JS.

Storing setting to the next session on the Ruby side, must not attributes be good choice then?

@unknownuser said:

overall position is harder to guarantee.

You mean :left => 600, :top => 200 ?

Why would that be more difficult to store?

Thanks.

Aerilius

Although it is possible we should be careful not to fiddle too much with window management without a good reason. Dialogs in SketchUp store their size and position automatically.

If a dialog needs to have a specific size set to work correctly (because of dynamic content etc.) then we can do this. There is even less often a reason to force a specific position on the screen (other than the position from the last session, which the dialog should remember on its own). Window positioning is user land and should be left to be intelligently managed by the window manager (placing windows on free screen area, considering screen size and workspaces etc.).

driven

@aerilius said:

If a dialog needs to have a specific size set to work correctly (because of dynamic content etc.)

I think dynamic 'context' is also a good reason.

I have a webdialog that changes it's position, size and content [based on where I moved it to] each open 'model space', SU can't handle that level of user choice.
john

jolran

I think I'm going to consider this:

@unknownuser said:

Although it is possible we should be careful not to fiddle too much with window management without a good reason

Don't really have a good reason to use it. Just mucking around.

@unknownuser said:

I have a webdialog that changes it's position, size and content [based on where I moved it to] each open 'model space', SU can't handle that level of user choice.

Sounds really advanced. Responsive window.

driven

@jolran said:

Sounds really advanced. Responsive window.

it's a prototype that seems to work on my mac, might find an excuse to finish it one day.
john