Mac UI.messagebox - hud and timeout

Dan Rathbun

Also.. everything else in the API, and webdialogs use upper left corner, so y would need to be translated to this.

driven

@dan rathbun said:

Also.. everything else in the API, and webdialogs use upper left corner, so y would need to be translated to this.

I was thinking of using
y=(view.corner(2)[0].to_s + ", " + view.corner(2)[1].to_s)
would that cause issues if it's in a module?

BTW and OT. I may have an easy way to access SiteRuby...

Dan Rathbun

You misunderstand, apparently.

In Ruby we will be using and passing our desired upper left corner.

Internal to the method, you'll need to translate the y passed into the method, by adding the dialog's height to it (unless on the Mac, the screen origin 0,0 is at the bottom left, in that case you'd have to subtract the height,)...

... BEFORE passing the -y value to the %x (backquoted) shell command string.

Dan Rathbun

I would think, in most situations, authors will want the dialog centered, so you would just not pass -x & -y, to the shell command, at all.

Problem with using the API's View class, is that it is really the client area viewport, and not the screen. On my machine I dont have Sketchup maximized widthwise. On the left, ~ 16% is for ToolWindow dialogs. Then I have space taken up by vertical toolbars, etc.

Add to that.. the myriad monitor screen resolutions.... and well... it just makes sense to either use percentages, and/or let the system center the dialog.

driven

Hi Dan, I couldn't reply last night, something odd with my internet...

@dan rathbun said:

You misunderstand, apparently.

possibly, I know very little about PC windows, but quite a lot about the mac ones.

@dan rathbun said:

I would think, in most situations, authors will want the dialog centered, so you would just not pass -x & -y, to the shell command, at all.
I agree with the centering, but you have to pass- x, -y to do that.

If I run the shell from applescript I can place the window in relation to the forefront SU windows size and position or the full desktop, but it has no idea where the SU 'design area' is.

To have the message 'appear' to part of SU [and plugins] you need to take SU's screen width into account and address the design window, which WD's don't address at all.

mac main screen sizes are cornered at 0, 0 [screen top/left] for the window containing the menu bar but all sub-window measurements require additional maths.

If you set SketchUp's window at [1000, 0, 1000, 1000] you get AXPosition (W): “x=1000 y=22” AXSize (W): “w=900 h=1000”

If you then set a WebDialog in that SU window at [1000, 1000, 1000, 0 ] you get AXPosition (W): “x=1000 y=22” AXSize (W): “w=1000 h=1000”

SU has taken the menu "y=22" height into account, but not it's toolbar, width or position, for a centered messages that is essential.

Ideally, need to know the 'viewport' || 'design window' position and size.

If I collect the viewport rectangle corners in SU I may as well use that match the shell script requirements and then apply the hashes, which can appear in the same order as WD.

I do something similar to 'print to scale' the viewport using a shell script, in another ruby.

The main difference's here is I need the 'desktop' size as well, especially for dual monitor setups and in the other script I can set SU to a datum size, compare that to viewport size, do any maths and then resize the viewport accurately.

here's the WIP applescript, not streamlined or tested for dual monitors yet, for comments... john

tell application "Finder"
	set macScrn to the bounds of window of desktop
	set macH to item 4 of macScrn
	set macW to item 3 of macScrn
end tell
tell application "SketchUp"
	activate
	set foremost to true
	set SUscrn to the bounds of window 1
	set SUx to item 1 of SUscrn
	set SUy to item 2 of SUscrn
	set SUw to item 3 of SUscrn
	set SUh to item 4 of SUscrn
end tell
do shell script "./usr/local/lib/bhtxt  -p 10 -b purple -w " & ((SUw - SUx) * 0.75) & " -h " & ((SUh - SUy) * 0.6) & " -x " & (SUx + ((SUw - SUx) * 0.5) * 0.25) & " -y " & (macH - SUh + ((SUh - SUy) * 0.5) * 0.4) & "  A Message  Goes Here "

Dan Rathbun

@driven said:

I agree with the centering, but you have to pass- x, -y to do that.

Uh.. John. You posted the options list for the utility, that said:

@unknownuser said:

-x xposition -y yposition Specify lower left corner of window. You can specify either pixels, or precentages of the screen size. ****If unspecified, window will be centered.****

So if the author does not pass position, (they want it centered by the utility,) then you do not pass position args either.

Dan Rathbun

Will this just be a splash screen like "notice" window, or will it have all the same button options that a messagebox has ?? (OK, Yes/No, Yes/No/Cancel, etc.)

driven

Dan,

In it's original use it 'SELF CENTERS' the message on any computer screen, [mac or PC] on an apple remote desktop network.

To target an individual App window it needs to know where the app is, in relation to the 'full screen' it was designed for.

You can only input text, using the single supplied font. You can set the time out so message appears to blink, or give a series of notices that require a click to cancel.

It's not a replacement for user input, unless single option clicks. i.e. "click to abort, allow timeout to continue"

However it could replace all the messages that don't really need clicks. e.g. "Select Group or Component" with a 1 second timeout. or script error messages when testing.

It can respond to and return the single click or the timeout as values, which could be acted upon.

My original planed usage is to give stepped instructions for using a specific tool instead of using instructor, reading the help files in a WD or using a skp with scenes.

The user can at any time turn this 'aid' on or off after first run that contains essential operational details.

I don't mind messages from scripts, but hate the fact I always have to cancel them, the timeout is the main attraction to me.

It may well be extendable, but first it needs be to reliably 'stuck' to the SketchUp.active_model.active_view or there's not much point to it, except maybe license agreements, copy write read-me's, etc. where you want to cover everything until acknowledged.

Currently, I've got it capable of replacing e.g. UI.messagebox("Cheese activated.") with MUI.messagebox("Cheese activated.")
with MUI being up to "full-SU-screen" and on a timeout/click anywhere on background.

I want to "full-SU-screen" to exclude the 'mac toolbar', which I can only do now with a hardcoded reduction in size. If linked to 'viewport' size it become dynamic.

depending on how I launch it, it can be modal or non-modal in the normal mac [app specific] fashion.

Your feedback is valued, as it makes me think, so thanks again.

john

Dan Rathbun

No problem.. it does help to talk things out.

For Windows, there is always ONLY one active model... so no floating document windows to iterate.

But the model can have more than one scene page (actually, looks like it uses the same "pane" window for all scenes.)

This topic (Sketchup View origin ) covered how to get the (upper-left) viewport origin (in relation to the desktop screen origin, which is also upper-left.)

The location of the Sketchup application window, and it's size, IS stored in the registry, when SU closes. But it's only good, until the user moves or resizes the app window. The settings are not updated "live", which is why we use Win32API calls instead.

driven

@dan rathbun said:

The location of the Sketchup application window, and it's size, IS stored in the registry, when SU closes. But it's only good, until the user moves or resizes the app window. The settings are not updated "live", which is why we use Win32API calls instead.

All the positions of all current windows are stored by the System Window Server.

You have to query it in a very specific fashion to get the normally hidden details.

AppleScript uses it to get a 'restricted' amount of information, but you can get a bit more.

I actually got Ruby Console and a WebDialogs 'live' positions out earlier, but I accidently deleted the script and can't reproduce it now...

john

Dan Rathbun

Well deleting the poll, did not help. It still was marked (in the topic list,) that this thread had new posts, and that the last poster was driven, even tho, it was me that was the last poster.

Let's see if, by me posting this message, if the forum topic lister PHP, gets things set back to normal.

EDIT: Hey looks like it worked !!

driven

So, it was you that broke it then... I had to get Gai to remove the poll, I don't have the delete button, it may be admin only...

I made some progress on doing this sensibly.

I currently write a dat file to user prefs folder that holds both Desktop's and SU's current position and overall size,
I collect that in ruby, factor in the view.center, height and width and set the default MUI.message_box to match SU's current UI.message_box dims and position.

the option hash would be a percentage increase in height and/or width, 0-100 being default to full-viewport.

If an author wanted total Monitor Screen they can write directly to the utility as a separate operation.

By approaching it this way, the initial installation of the utility could be added by users as a standalone mac enhancement that replaces the standard annoying UI.message_box's [message-only that have to be clicked for no reason], rather than part of any particular plugin.

Once installed, MUI module, 'bht' utility and the positions dat file could then be accessed by any author for any purpose.

thoughts welcome

john

Dan Rathbun

What does MUI stand for ?
What happens if the user resizes the Sketchup application window, after the module is loaded ?

driven

@dan rathbun said:

What does MUI stand for ?
mac UI, you had used GUI in your template and I just change it to MUI, for now at least.

@unknownuser said:

What happens if the user resizes the Sketchup application window, after the module is loaded ?
It's dynamic, it updates the prefs file with changes then modifies shell script before running. The dat file is a list of 8 items so it's quick and has very little overhead, compared to the normal applescript methods.
I still need to read/write some back in ruby, but I'm trying to limit that to a minimum.

john

Dan Rathbun

@driven said:

@dan rathbun said:

What does MUI stand for ?
mac UI, you had used GUI in your template and I just change it to MUI, for now at least.

Well I think the ultimate goal, is to have a cross-platform UI module:

example:

module SKX;;GUI

  MAC =( RUBY_PLATFORM =~ /(darwin)/ ? true ; false )
  WIN =( not MAC )

  if MAC
    def self.timed_splash( *args )
      # code calling Applescript, etc.
    end
  else # it's Windows
    def self.timed_splash( *args )
      # code using Win32API calls
    end
  end # if MAC

end # module

In practice actually, there would be a loader that determines the platform, and it would require one of two files:
skx_gui_mac.rb or skx_gui_win.rb

This is how Wx::Windows is setup when it loads.

Anyhow, within any author's nested plugin module or class, they can create a pointer to the actual GUI module, using anyname they wish (since it's local to their namespace.)
Ex:

module Driven
  module Util
    class ExportWidget
      MUI = SKX;;GUI
      MUI.timed_splash("John's Export Widget",10)
      # more code ...
    end # class
  end
end

The pointer can be a local constant, or a local var, a class var, doesn't matter. All references in Ruby just point at objects. A class or module name is just a constant that points at the instance objects of class Class and class Module, respectively.

driven

An update for those interested,

After following up on Dan's old suggestion to TIG, about using Thread.new for mac shell running, I have a non-freezing applescript/shell test that runs from a button in SU. The problem I was having with the shell/SU blocking has gone... yeh.

At the moment I've made a proof of principle/demo, to show that the 'threading' works and speed is useable.

It dynamically resizes SU to a number of random sizes, based on host Monitor size.

For each, in turn, it dynamically creates a 'centered' random sized message-box based on the new windows size. [min-max preset as %]

The messages are also random, as are the font, shadow and background colors.

It takes SU full screen at the end.

What I need next is confirmation of it working the same on other macs, before adding all the other bits that already work separately, but not yet combined. There's no reason to think it won't as it uses all mac, SU and Ruby 1.8.5 standard functions. but....

I'll try and make a small enough screen-cast to post this demo here for none mac watchers.

here's a zipped dmg for any willing mac owners... please.
download for testing...
john

driven

For some reason i can't upload to YouTube, so I put a movie up here http://gallery.me.com/johnboundy#100086

the movies quite compact at 1.2MB, but a small, crap animated giff version comes in at 12MB... I don't follow that.
it has 6 or so random window being created...

Dan Rathbun

Bummer.. it a QT movie. Cannot install anything else right now. (Getting the old "System part of the Resgistry has reached it's limit..." messagesboxes.)

Perhaps someone else can convert it WMV or AVI or something that YouTube likes ?

driven

Can you not view it online?

I can make and upload to youTube normally, just not at the moment... I'll try tomorrow. john

driven

Dan, could you try to stick this on YouTube?

emu zipped PC friendly AVI.... I think