Hi all,
I’m finally trying to get my Eneroth Viewport Resizer to work on Mac. However I have no Mac to try on myself, and have no idea what APIs there are. Is there a way to get and set the size of the SketchUp window, similarly to how you can do with Win32Api or the User32 dll on Windows?
This is what my low level Windows window module looks like, that I’m trying to recreate for Mac.
I sent you the code 3 years ago and you weren’t interested…
jcb_mac_viewport.rbz (8.2 KB)
I prefer doing it manually and I use this one now…
john
Hello John,
I struggle a bit to follow this code. Am I correct that the model has to be closed and re-open to apply the new window size? Id there any API on Mac for directly changing the size of an existing window?
no, I written hundreds of versions over the years using Applesricpt, ossascript, objc, cocoa, and ruby, but they all require specific user permissions to function…
people are just not happy to allow the level of ‘control’ needed…
I’ll PM you what I use as I believe it’s cross platform…
john
I’d prefer special permissions, like SketchUp having to run as administrator, over hacks that makes assumptions of where the data is stored or the like. Also getting and setting the current value of the existing window is an absolute requirement for how the extension is built. This versions updates the fields live when the window is resized and changes the window when the fields are changed.
there are no assumptions regarding where…
but as it’s at System level it needs initial sudo [super user] permission which are even higher than administrator privileges granted to extensions…
you basically have to pop up another dialog that then takes the user to System Preferences where they have to unlock the security and grant access,
it is simple and safe, but extremely ‘scary’ for many users…
hence, making it manual…
john
Unless there is an API contract stating where the PLIST file is located and what format it has, accessing it is based on numerous assumptions. Also the PLIST hack doesn’t appear to be live.
that old one of mine uses SU plist which only stores those when ‘closed’…
earlier versions used the ‘live’ System window position dameon [not plist] but every version of mac OS restricted access further and further, until it wasn’t worth pursuing…
SU.app would have to ‘allow access’ to the doc window and expose it in the API for us to seamlessly use it…
Here is the developer portal that lists many of the Frameworks and APIs …
There used to be Carbon (32-bit only) but it’s gone …
This leaves Cocoa …
… and possibly Core Foundation …
With this said I think I think I’ll stop pursuing mac support for the time being.
I’ve had the need for this myself for writing reliable tests. I’ve also only gotten Windows working with Win32. But I’m thinking it could be worth adding some utility to the SketchUp API for this. Not sure what a sane API would be for this that is able to cater for Macs MDI…
I actually started writing on an API FR but deleted it thinking this was quite far outside the scope of the API. Typically this would be done with OS API, but maybe there are reasons to add support in the SU API.
I don’t know what API design would be good either, and if the window position should be exposed in addition to the size. The multi document interface also raises some questions. Perhaps there could be an optional argument taking the Model object, but defaulting to the active one.
a good start is the ‘parent’ screen bounds co-ord for view.centre…
current doc bounds are only needed for resizing…
john
Main reason I can think of is testing. It’s come up enough times where a reliable viewport size is useful.
Maybe a method on the Sketchup::View object? Probably where it makes the most sense.
model.active_view.resize(640, 320)
I don’t quite follow what you are saying here… “parent screen bounds”? view.centre?
‘parent’ screen bounds
equivalent to javascript’s __proto__ : "Screen"
equivalent to javascript’s [screen.width/2, screen.height/2]
at the moment we have to create a HtmlDialog to retrieve this information…
having API access would be simpler…
john
set_size would be more consistent to HtmlDialog.
Perhaps there could be a new Window class that also has a set_position and a bring_to_front method and some other methods HtmlDialog has. I don’t know what other people need. Even if no other functionality is added to start with, a new class gives more possibilities without cluttering the existing classes.
Maybe Model can have a window method returning this object. The method name active_view suggest a model can have multiple views, like one for each scene, but I don’t know if this is true. If it is all these views would use the same window, but if not the getter is maybe better suited in the View class.
+100 for :set_size…
for me most useful would be…
model.active_view.get_size(x, y, w, h) # rounds the circle for resizing
# for dialog positioning
model.active_view.center_offset # position on client screen...
# use case
offset = model.active_view.center_offset
dialog.set_postion(offset)
# this could also be a HtmlDialog method to position them relative
# to the active model window.
dialog.center # we have
# missing
dialog.top_left
dialog.top_right
dialog.bottom_left
dialog.bottom_right
john