Mac UI.messagebox - hud and timeout

[driven]

@thomthom said:

Modal popup? Gimmegimmegimmegimmegimme!

thought you might like this...

so far i can get it working locally from SU, but it uses an Apple utility that isn't normally installed on macs.

I can host that utility almost anywhere and point to it.

For it to work on other peoples mac's, I can include it in a sub-directory for my module.

I need to work out the best approach to instal it for any other scripts to access.

I could use /usr/local/lib/bhtxt, but I'd have to build the folder structure to instal 'bhtxt' into for most people...

Is your mac up and running?

[TIG]

Could you not make a cross-platform Java [jar] based utility to do this? Borderless/transparent popup with images/text etc...

[driven]

@tig said:

Could you not make a cross-platform Java [jar] based utility to do this? Borderless/transparent popup with images/text etc... :roll:

possibly some java wizard could, all I'm doing here is re-purposing a pre-compiled apple utility then writing a shell script in SU to run it.
e.g. #!/bin/sh
/usr/local/lib/bhtxt -p 10 -f yellow -b purple -s cyan -o 0.640 -w 90% -h 90% -x 60 -y 60 " A Message  Goes Here "``
I can target it using w=(Sketchup.active_model.active_view.vp_width), etc...
but, I haven't worked out how to use all the options, any clues welcome

Options;
   -h windowHeight
   -w windowWidth
          height and width can be either pixels,
          or percentages of the screen size.
          The default is  -w 90% -h 20%  
   -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.
   -m     Ignore mouse clicks. Window stays put.
   -M     Ignore mouse clicks AND allow the user to move the window around.
            By default, mouse clicks make the window go away.
   -p N   Wait for at most N seconds. Use -p 0 to wait forever.
          The default is to display the message for 3 seconds.
   -d     detach and run in the background
   -f col Set the foreground (text) color.  Default is white.
   -b col Set the background (window) color. Default is black.
   -s col Set the text shadow color. Default is black.
          Colors can be a hex RGB value, e.g.  -f 00ff00  (green)
          or one of the standard NSColor names; black, darkGray, lightGray, white,
			gray, red, green, blue, cyan, yellow, magenta, orange, purple, brown.
   -o alpha  
          Set the transparency of the window. default is 0.640.
          0 is fully transparent, 1 is fully opaque.
   -d     detach and run in the background
   -v voice    Also say the text in the given voice (see "man say")   -H     Honk.
   -X     Exit with status 2 on timeout, 3 on user click.  (Rather than always 0.)
          Useful in scripts, if you need to differentiate a click from a timeout,
          but without -X, we always exit with status 0, which makes scripts simpler.
 b   -      read text from standard in, rather than arguments.
   --help Print this help message.
Text, including multi-line text, will be shrunk as needed to fit.

john

[Dan Rathbun]

I would suggest that the method take an options hash argument for complex uses (like the UI::WebDialog class does. And try to mimic it as closely as you can.)

The method could also take a few important args (and use defaults for the rest, or calculate position and size,) for simpler situations.

module GUI

  def self.widgetbox( *args )
    if args.empty?
      raise(ArgumentError,"no arguments given.",caller)
    elsif args.length == 1
      # it should be a Hash arg
      unless args[0].is_a?(Hash)
        raise(TypeError,"Hash type as single argument expected.",caller)
      end
      h = args[0]
      #
    else # it's multi-arg list
      # build internal Hash from arglist
      h = Hash.new
      # set min number of keys here
      unless args[0].is_a?(String)
        raise(TypeError,"String type for first argument expected.",caller)
      else
        h['message']=args[0]
      end
      #
      #  ... etc ... etc
      #
    end

    # Check h for missing key/vals and set them.
    # Also check that vals are within valid ranges.

    cmdpath = 'some/path'

    # call command using replacement
    retval = %x(#{cmdpath} -p #{h['wait']} -x #{h['x']} -y #{h['y']} "#{h['message']}")

  end # def

end # module

[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]

1. What does MUI stand for ?

2. What happens if the user resizes the Sketchup application window, after the module is loaded ?

[driven]

@dan rathbun said:

1. 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:

2. 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:

1. 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