(Webdialog) Window match clientsize.

Aerilius

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

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