[AppleScript] - Sketchup PrintRight

driven

yeah.. i'll just have to make sure to click on everything and try different settings in this type of situation

you could write an applescript to do that....

jeff hammond

found a better way to get the dock info.. this will return the actual height etc..

tell application "Finder" set dockOrientation to do shell script "defaults read com.apple.dock orientation" end tell tell application "System Events" to tell process "Dock" set {dockW, dockH} to size in list 1 end tell return {dockOrientation, dockW, dockH}

via:
http://www.snaq.net/software/applescripts.php
that stuff looks way more organized than how i'm doing it.. i'm going to have to make sense of what he's doing there and copy the way he's keeping things neat it if this print script is going to be successful.. it's already starting to get messy

driven

Hi Jeff,

although your away maybe you can try this test file.

after much searching, I can get Raster images to fit an A4 sheet exactly, [pixel perfect if you drawWin to {WinWidth - 4,]
I used 297 and 210 for the input dialogs on the Automator version
PrintTestMac.skp

now for step 2, multiple sheets, that line up.... john

driven

Vector quality as good as I can get at the moment
PrintTestMac_eps.pdf
john

driven

Hi Jeff,

just realised I hadn't added a needed ingredient, that I'm using for both raster and vector output.

a ruby script.

mod = Sketchup.active_model # Open model
ent = mod.entities # All entities in model
sel = mod.selection # Current selection
view = Sketchup.active_model.active_view
 new_view = view.zoom_extents
 new_view = view.zoom 1.0525

I saved it as zoomZoomed.rb and run it after Automator has sized the window, it gets rid of the margin. YMMV... john

if you want it on a button for quick testing I'll knock one up, but if you run it from 'RubyCodeEditor' you can tweak the ratio setting.
or did I send this... am I going mad... etc...

driven

and if you want to save your automator script as an app in plugin subfolder[or anywhere, just fix the path]
you just call that from ruby first.

mod = Sketchup.active_model # Open model
ent = mod.entities # All entities in model
sel = mod.selection # Current selection
view = Sketchup.active_model.active_view

system('open /Library/Application\ Support/Google\ SketchUp\ 8/SketchUp/plugins/zZoomed_PrintRight/PrintRight.app')
 new_view = view.zoom_extents
 new_view = view.zoom 1.0525

needs the full path for system... john

I'm subtracting 4

4, WinHeight} before making the app.

you can still change the app in automator, just re-save and overwrite.

jeff hammond

@driven said:

new_view = view.zoom 1.0525

nice.. in my experiments, i'm actually using a factor of 1.05083 after first setting the FOV to 35.00deg.. (i found the scale factor changes depending on fov so in the script, i preset to 35.00deg)

i almost had this thing up and going then hit yet another wall.. all of my testing so far was using a flat plane as the drawing.. then i tried it on something with a height and everything goes out of whack so it's back to tinkering with available sketchup controls to make it happen..

here's the latest for this part of the script: (copy/paste into applescript editor and run from there -- with a sketchup window open somewhere)

` tell application "SketchUp"
activate
tell application "System Events" to tell process "SketchUp"

	set drawwin to count of windows
	set AppleScript's text item delimiters to {" "}
	
	--set the camera to perspective by checking if Field Of View is enabled
	
	if enabled of menu item "Field of View" of menu 1 of menu bar item "Camera" of menu bar 1 is false then
		click menu item "Perspective" of menu 1 of menu bar item "Camera" of menu bar 1
	end if
	
	--set FOV to 35 deg.. in order for the 1.05083 to work out right..
	click menu item "Field of View" of menu 1 of menu bar item "Camera" of menu bar 1
	keystroke "35" & return
	
	
	click menu item "Zoom Extents" of menu "Camera" of menu bar 1
	click menu item "Zoom" of menu "Camera" of menu bar 1
	
	
	set fv to value of text field 1 of window drawwin
	set FOV to ((first text item of fv) / 1.05083) as text
	keystroke FOV & return
	click menu item "Parallel Projection" of menu "Camera" of menu bar 1
	
end tell

end tell`

with that, if you had a drawing window set to a paper size of 8.5 x 11 borderless then draw a rectangle of say 11' x 8'-6" in sketchup.. after running the script, the actual extents of the drawing would be properly zoomed then under file->Document Setup, you'll see the scale set as expected (entire paper is printed to with a scale of 1" = 1'..)

i was going to use this as a basis for giving 'suggested scales' to the user that the can pick from then the model would zoom in/out in the drawing window to show exactly how it will look on the final print/pdf..

anyway… i wonder if there's a way to use ruby commands in an applescript?? i might have some better control that way of the actual sketchup drawing.. i've seen a couple of examples of using python inside an applescript so i assume ruby would be possible as well?.. (and i guess the big question would be if SketchUp's ruby could be used inside an applescript which will do sketchup things instead of just using OSX's ruby)..
have you ever messed around with doing anything like that?
thanks

driven

quick check gave

"System Events got an error: Can’t get text field 1 of window 9 of process "SketchUp". Invalid index."

I need to sleep, so i'll have a look later.

it's easier to get applescript/system to do stuff from SU than the other way round, and even then there's things that don't fly.

it's also easier to get SU to do SU things and to only add missing or fix broken stuff. [eg. change fov is a one liner, print to scale is broken]

SU is the environment your scripts needs to work in so for example if you call system to kill sketchup from inside SU you get an endless loop.

Have a look inside those sumac.app scripts I posted ages ago, that's why I made them Menu Bar apps.

john

jeff hammond

@driven said:

quick check gave

"System Events got an error: Can’t get text field 1 of window 9 of process "SketchUp". Invalid index."

I need to sleep, so i'll have a look later.

that's probably because you had more than one sketchup window open when you tried it..
the order the sketchup windows appear (entity info etc dialogs first, then the toolbars, finally the drawing window) really make gui scripting sketchup difficult (+, say you have 10 total windows then open a new drawing window.. the new one becomes #10 then the other window becomes #11 and moves to the back ).. i think i have a way to separate the drawing windows from the rest of the stuff then using the frontmost of those so it will work with multiple windows open.. haven't tried to implement it yet.. it's on the cleanup list if i can ever get this to work out..

(fwiw- the desired target you're seeing the error for is the measurement box when in a state that user input is possible)

@unknownuser said:

it's easier to get applescript/system to do stuff from SU than the other way round, and even then there's things that don't fly.

it's also easier to get SU to do SU things and to only add missing or fix broken stuff. [eg. change fov is a one liner, print to scale is broken]

SU is the environment your scripts needs to work in so for example if you call system to kill sketchup from inside SU you get an endless loop.

Have a look inside those sumac.app scripts I posted ages ago, that's why I made them Menu Bar apps.

john

i've tried to find the sumac stuff before and i just can't got a link?

also just thought of an easy, though not too elegant way to use su ruby commands via an applescript... the ruby console
it might actually work out ok.. gonna mess around with it in a little while.

jeff hammond

@unknownuser said:

also just thought of an easy, though not too elegant way to use su ruby commands via an applescript... the ruby console
it might actually work out ok.. gonna mess around with it in a little while.

ha.. it works pretty good..

and i can move forward now using that code you posted earlier (the view = view.zoom factor stuff)..

and the zoom factor is way nicer than what i was trying which was with a set FOV then changing the FOV to fit the window.. zoom factor works regardless of the user's fov setting (but there's no way i could figure out how to change the zoom factor within sketchup itself other than with a mouse so that option was out.. using it now via ruby )

[EDIT] oh.. and more importantly.. you can use the zoom factor in parallel projection while you can't change the FOV (which is what i previously needed to do) in parallel projection.. the fov option is greyed out in normal SU if parallel projecting and i actually crashed SU once or twice trying to change it via ruby while viewing parallel projection

jeff hammond

here's the same thing i was trying above except it now uses ruby for the zoom factor instead of messing around with the camera's FOV.. so i'm now able to work with 3D objects instead of just flat ones..
i think it's just some weird math and a few dialogs to do then this whole idea might actually work

` tell application "SketchUp"
activate
tell application "System Events" to tell process "SketchUp"

	set drawwin to count of windows
	set AppleScript's text item delimiters to {" "}
	
	--set the camera to Parallel Projection by checking if Field Of View is enabled
	--(FOV will NOT be greyed out if Perspective or 2pt Perspective)
	
	if enabled of menu item "Field of View" of menu 1 of menu bar item "Camera" of menu bar 1 is true then
		click menu item "Parallel Projection" of menu 1 of menu bar item "Camera" of menu bar 1
	end if
	
	
	-- Zoom extents then use ruby console to scale zoom by a factor of 1.05405
	
	click menu item "Zoom Extents" of menu "Camera" of menu bar 1
	
	
	click menu item "Ruby Console" of menu "Window" of menu bar 1
	keystroke "view = Sketchup.active_model.active_view
	view = view.zoom 1.05405" & return
	
	
	-- close ruby console
	click button 1 of window "Ruby Console"
	
end tell

end tell`

[edit].. hmm.. that's not compiling properly once i copy/paste it from the forum back into applescript editor.. the ruby part should look like this in applescript editor :
Screen Shot 2011-12-20 at 9.51.58 PM.png

maybe if i break it down into separate keystroke entries i'll be able to post it properly here?

here's the .scpt instead:
SU_ZOOMRUBY.zip

driven

jeff heres a sumac download link, dmg installerhttp://homepage.mac.com/johnboundy/filechute/sumac_dev_2011-03-01-002859.dmg.zip

I need to go back out for an hour or so, I'll have another look at your stuff.

What I see as being really good with what your trying is the idea...

and you've cracked what can't be done from SU ruby.. i.e manipulate the window size and position the window.

ruby can handle all the other bits really easily, without opening dialogs or console at all, it can even send the applescript to system and avoid an external file altogether.

What I find interesting is the possibility of doing other things to other SU windows, so if you click a button, Applescript could get the position and pass that info to a ruby WebDialog that then appears in that spot, hiding the button in the process.
In that WD you could say I want 8 A4 sheets of this drawing, size and zoom the window for accurate printing, and have ruby move camera, save and name image 8 times.

more later
john

driven

Hey Jeff,

lets bump this Applescript stuff and get more people in on the act...

I've been re-reading all the SketchUp Applescript 'google' hits and I think it's time to make it all work.

One of the past problems was no-one seemed to know how to get Applescript to do this sort of thing from INSIDE a ruby script... e.g. »» RUN IN AppleScript Editor

activate application "Sketchup"
tell application "System Events"
   tell process "SketchUp"
      click menu item "Weld" of menu "Plugins" of menu bar 1
   end tell
end tell

Although you could get other apps to run from SU using 'osascript' e.g. »» RUN IN Ruby Console

`osascript -e 'activate application "Safari"'`

Previously, as soon as you changed the app to SketchUp you beach-balled...
well, I finally got it working e.g. »» RUN IN Ruby

runAppleScript=Thread.new{
`osascript <<EOF
activate application "Sketchup"
tell application "System Events"
	tell process "SketchUp"
		click menu item "Weld" of menu "Plugins" of menu bar 1
	end tell
end tell
EOF
`
}
runAppleScript.kill

the missing ingredient was a new Thread... and a HEREDOC to simplify the osascript
so where does that all lead us?
if it has a menu item you can activate it from ruby

so if you have "Arc: Center and 2 points"

#--# UI;;Toolbar why would you want a custom set of menu items?
#
  def aplscrpt_TB
  		aplscrpt_tb = UI;;Toolbar.new "aplscrpt_TB"
      # This command when clicked
      cmd = UI;;Command.new("aplscrpt_TB-Test") {
      	    runAppleScript=Thread.new{
				`osascript <<EOF
					activate application "Sketchup"
					tell application "System Events"
						tell process "SketchUp"
							click menu item "Arc; Center and 2 points" of menu "Draw" of menu bar item "Draw" of menu bar 1
						end tell
					end tell
				EOF
				`
			}
	    runAppleScript.kill
      }
  		aplscrpt_tb.add_item cmd
  		aplscrpt_tb.show
  end # aplscrpt_TB
#
#--#

you can have a button even though it's an encrypted file...

but there's even more we can do with this,

I've worked out how to 'mine' the menu items, and how to 'activate' them from a ruby script, but I'm trying to optimise the parsing to html for use in a 'WebDialog'.

The best way to explain my goal, is a floating 'localised', 'dynamic' menu/toolbar that can be edited (via option boxes) to show only the items you want, and be positioned anywhere, i.e. another monitor.

I use full screen mode alot, and I find getting menu items is a pain. There are only so many shortcut keys I can remember...

Another advantage is it can be 'Stay Open', eg. if you want to check all available camera views in advanced camera tools.

I have made 'html' that looks like a menu, and others that look like toolbar buttons. but I need to full it all together.

and then there's window positioning and sizing, a lot can be gain on using Applescripts strengths from inside ruby...

@ Jeff, if you don't want the highjack, split this to a new thread, but I think it's as good a place as any, mainly cause I like watching RC type itself....
john

driven

I've been working on returning AppleScript Dialogs from SU ruby osascript, [incase it's desired/needed] and I got most of it working, launches and shows in 'SU' but writes result to tmp file.
This is an experiment something we were trying to get externally... for soemthing like this you would most likely just use in a larger AppleScript, rather than return it to ruby...
»»RUN in RUBY CONSOLE

# get the target ratio from the user with an option box
%x(rm "/private/tmp/Prnt_Format")
runAppleScript=Thread.new{
%x(osascript -so > /private/tmp/Prnt_Format <<SU
	tell application "SketchUp"
activate
set Land to "Landscape"
set Portr to "Portrait"
choose from list {¬
	"'A'-Series " & Land, ¬
	"'A'-Series " & Portr, ¬
	"Architectural " & Land, ¬
	"Architectural " & Portr, ¬
	"'US' Letter " & Land, ¬
	"'US' Letter " & Portr, ¬
	"Square", ¬
	"Use Printer Settings"} ¬
	with title ¬
	"Print Format" with prompt ¬
	"Choose one format" OK button name ¬
	"Format View" cancel button name ¬
	"Cancel" default items {"Use Printer Settings"} ¬
	--	with multiple selections allowed
	end tell
SU
)
};
runAppleScript.kill;

then to read back

(`cat /private/tmp/Prnt_Format`)

john

livemixer

Jeff:

I don't know if you still have any interest in this project, but if you do please check out the script below (based on one of your earlier ones) & see if it works for you like it does for me.

tell application "SketchUp"
	-- more robust to error trap for SketchUp not running before telling it anything!
	activate
	tell application "System Events" to tell process "SketchUp"
		set drawwin to count of windows
		click menu item "page setup..." of menu "file" of menu bar 1
		
		repeat while focused of window drawwin = false
			try
				set psz to name of static text 2 of sheet 1 of window drawwin
				(* To dismiss the page setup sheet as soon as it appears,
				uncomment the 'click button' line below.
				May be useful if allowing user changes is not needed &
				the script just needs to get current values & continue?*)
				-- click button "OK" of sheet 1 of window drawwin
			end try
		end repeat
		
	end tell
end tell
(* Bring the AppleScript Editor to the front;
manually check its Result pane for the expected psz text.
Demonstrates that it can be processed outside the
'tell SketchUp' loop
*)
activate me
psz

From what I understand, one of the things you wanted to do was drop down the page setup sheet & let users change its settings before continuing. It seems a little weird, but in my testing the inverted logic "repeat while focused of window drawwin = false" line accomplishes that. Here is (I think) how it works:

The 'Events' pane of the AppleScript Editor shows the script looping through the repeat over & over, grabbing the current 'psz' value on each pass, just as one might expect. But the unexpected part is that SU doesn't seem to return 'focused = true' to the script even if a user changes something in the sheet. That only happens when a button in the sheet is clicked. That causes an error in the repeat loop (because sheet 1 is no longer there) so the script exits the loop & continues with the 'psz' value from the last "good" repeat.

To keep things simple & make testing easier, I didn't do any processing of the 'psz' text in the script. If you run it from Script Editor, it should bring the script window back to the front as soon as you click "OK" in the SU sheet & the text should be the only thing in the 'Result' pane.

That also avoids the distraction of a 'Display Dialog' window & messing with AppleScript's Text Item Delimiters (which really should be saved before a change & restored to the saved value ASAP afterwards so the change won't screw up some other script that expects the default or its own changed value).

jeff hammond

yeah.. i'm pretty much over this project.. i have a version of it which i do use but making it work on pre-lion OSes was too much of a pain for me..

i use the part which can resize the actual drawing window to a desired aspect ratio as well as the part which gives a true zoom extents.. the rest of it was an attempt at automation for others but i dunno.. i guess i lost the drive to make that happen..

that said.. i do have another applescript idea brewing but i haven't really dug into it yet.. maybe you guys want to try some stuff with the idea.. i was going to call it TightenUp.. what it would do is grab all the various windows/toolbars then put them in exact locations.. the only thing missing for me is the algorithm (if that's even what it's called in this case).. but i think we've already figured out how to get bounds of everything and how to move them around etc..

here's the basic idea.. on the left is my typical looking sketchup.. on the right is after running the script (and it would also be useful for people with lost panels etc.. better than sketchup's 'reset workspace' thing..

driven

@livemixer said:

see if it works for you like it does for me.

not Jeff, but gave it a whirl anyway... it didn't work here... and took a little while to see why.

basically I had 2 drawings open, without realising it and it was screwing with the count of windows...

This is actually one of the reasons I'm pursuing the ruby interaction...
suWin = Sketchup.active_model.title if suWin.to_a.length == 1 then suWin = suWin else suWin = "Untitled" end #if if Sketchup.is_pro? @suW =(suWin + ".skp - SketchUp Pro").inspect else @suW =(suWin + ".skp - SketchUp").inspect end #if
returns **"2Arcs_36sided.skp - SketchUp Pro"**
if I have the other model forefront I get, "Untitled.skp - SketchUp Pro"
if your not runing pro it should chop "Pro"
if thats used in the AppleScript there's no ambiguity, which easily, can be a show stopper.
also the value is then easier to get...

get the value of text field 1 of sheet 1 of window "2Arcs_36sided.skp - SketchUp Pro"

john

@Jeff I do have scripts that do that sort of thing, but integrating them into ruby will make then more portable.
you want to split this into the dev forum and we might get more help??
john

jeff hammond

@unknownuser said:

@Jeff I do have scripts that do that sort of thing, but integrating them into ruby will make then more portable.
you want to split this into the dev forum and we might get more help??
john

ha.. crazy but last time this thread was going, i left for a job then i personally fizzled out on pursuing it further..

and yesterday, i flew to a job.. then i go home for 2 days.. then to nashville for a few weeks after that..
so all my energy is zapped for at least a month or so

driven

@unknownuser said:

so all my energy is zapped for at least a month or so

Ok, know how it feels, the next film I had got put back when the lead actor pulled out so I have a reprieve at the moment..., 'sort of luckily' while the money holds out...

I'll start a Dev Forum thread, cause i need help with the ruby anyway and have been PM-ing a-lot, so it makes sense.
I chucked it here because you kicked me into gear the last time, so try out some of this stuff when you get a mo, I think it's going to be worth it, I wrote a quasi "grasshopper" script using AppleScript from ruby the other day, and although it was minor league it was great fun seeing it work...
john

livemixer

@driven said:

not Jeff, but gave it a whirl anyway... it didn't work here... and took a little while to see why.

basically I had 2 drawings open, without realising it and it was screwing with the count of windows...

I knew that using 'count of windows' as a reference to the frontmost document window could cause problems if the app had more than one of them open. I was really just trying to call attention to the fact that System Events apparently 'sees' the focused property of the app change to the sheet of a document window only when one of the sheet's buttons is clicked & not (for example) when one of its text fields or some other UI element is changed. That seems strange since the app's focus has to be on a UI element to enable users to change it … right?