Some questions about UI in ASObjC

I have some question about building UI in ASObjC.

  1. Would it be possible to hard code every interface property from Interface Builder ??. (No XCode)
    I do understand its properly not a good approach but I do believe hard coding make the learning
    more fun (more difficult but in return greater value of learning).

  2. Would it be possible to load a Nib (MainMenu.nib) to be used in AppleScriptObjC and hard code the linking without XCode ??.

  3. If I have a applet that call NSWindow from Script Library and the applet is stay open. If I close the window the app will still be open. Could I use applicationShouldTerminateAfterLastWindowClosed on applet or should I use it in handler of Script Library ??

Thanks.

It wouldn’t be practical. But you can look at my Dialog Toolkit Plus lib for an example.

You need Xcode to create the Nib, but yes, you can then load it.

You can’t implement applicationShouldTerminateAfterLastWindowClosed: because your script is not the application’s delegate.

You can use “NSWindowWillCloseNotification”:


use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use scripting additions

property ca : current application

set nc to ca's NSNotificationCenter's defaultCenter()
nc's addObserver:me selector:"windowWillClose:" |name|:"NSWindowWillCloseNotification" object:(missing value) -- or the NSWindow

on windowWillClose:param
	set theWindow to param's object
	my (nc's removeObserver:me |name|:"NSWindowWillCloseNotification" object:(missing value))
	display notification "A window of the current application will be closed: " & (theWindow's title as text)
	-- tell me to quit
end windowWillClose:

@Shane
I have look at your code in Dialog Toolkit and I truly like to learn to make UI.
I do know little more today and yesterday to thanks again.

@db123
Thanks to much… (This code I will save… so useful)

theWindow variable is a NSWindow… part of the code I add to the applet and it works. :slight_smile:

set theWindow to display URL theURL window size {1024, 850}

set notificationCenter to current application's NSNotificationCenter's defaultCenter()
notificationCenter's addObserver:me selector:"windowWillClose:" |name|:"NSWindowWillCloseNotification" object:theWindow -- or the NSWindow

on windowWillClose:param
	set theWindow to param's object
	my (notificationCenter's removeObserver:me |name|:"NSWindowWillCloseNotification" object:(missing value))
	tell me to quit
end windowWillClose:

@Fredrik71
Small optimization:


on windowWillClose:param
	set theWindow to param's object
	my (notificationCenter's removeObserver:me |name|:"NSWindowWillCloseNotification" object:theWindow)
	tell me to quit
end windowWillClose:

But it doesn’t really matter, because the app will be closed anyway.

@db123
You are right, I test both and they did the same.

The strange thing, 2 days ago I look at NotificationCenter to learn more…

I discover all this type alias from NSNotificationName…
https://developer.apple.com/documentation/foundation/nsnotificationname?language=objc

But never understood exactly how it works, but from your code its much easier now :), thanks.

One of the biggest issues is the sheer amount of code required for anything complicated, and the fact that AS simply doesn’t cope with very long scripts.

https://rixstep.com/2/0/articles/ib.shtml
I could understand what you mean.

Lets think loud for a moment…
Apple could have chosen a better approach, I will give you 2 examples.

Approach 1)
They could have included class and properties to build UI

ex.
make window with rect {0,0,300,300} at center
input textfield {myTitle,myText,{20,20,100,25}}
input button {myTitle,{20,40,100,25},myActionClick}
end make window

or

tell application “Script UI”
set theWindow to make window with properties {title:“myTitle”,rect:{0,0,300,300}}
tell theWindow
set button to {title:“myTitle”,rect:{x,y,w,h},attribute:{font:“Menlo”,size:14,color:“colorYellow”}}
set textfield to {title:“myTitle”,rect:{x,y,w,h},placeHolder:“Type some text…”}
end tell

Approach 2)
There any parameters in node graph could be a user input in UI. When the script is compiled
it also build the user interface dynamically. So when a user run a compiled script it also
has the UI elements. People who are programmer have other approaches they take to make things done. The power of scripting is to take a person without programming knowledge to do same things a programmer do in some sense. But scripting is also very useful to know if we like to make test cases for a bigger task or ideas. Scripting is also useful for doing things with less code.

Instead of invented a new approach of Automator to do something other have done already.
Visual node graph have been around before 2008 and Automator was released in 2007.
Sidefx Houdini have used it before 2000.

History of node graph use
https://en.wikipedia.org/wiki/Node_graph_architecture

If you do not know what visual node graph is
http://blog.interfacevision.com/design/design-visual-progarmming-languages-snapshots/

I mean theClass could be any Class or Instance Method of AppKit

property theClass : missing value

set theWindow to make new theClass with properties {title:"myTitle", rect:{0, 0, 300, 300}}

on make new theClass with properties theProperties as record : {}
	return theProperties
end make

{its title of theWindow, its rect of theWindow}