New way to use ASObj-C

AppleScript
#1

I posted this in the AppleScript category because it is meant for scripters that don’t use Xcode as well as those who do use Xcode. This pertains to anyone who uses ASObj-C. Posting it in “AppleScript Xcode” would not reach most of the people I am am sending this to. This is a post about getting around Xcode as far as coding goes.

I have been thinking a long time on how to make ASObj-C more accessible to AppleScript users. Xcode itself can build an entire application that can be modified in a delegate. But Xcode is such a pain to work with.

I have two ways in mind. One does not involve Xcode at all and the second involves very little in Xcode and the rest in Script Debugger. For both ways all the scripting (coding) would be done in Script debugger.

I have something working right now for a very small part done in Xcode with the rest Script Debugger. I have included the Xcode project in this post. For this method Xcode is for the most part used to make an Application and the real work goes on inside Script Debugger.

I created a fully functioning text editor that loads, saves and edits rtf files in Xcode. Just to give you an idea how powerful Xcode can be I included all the code used to create the editor in this post. All the code is in the script CustomDocument and all of it is ASObj-C. As you can see it doesn’t take much code. Xcode give default objects and the only coding needed is when you want to change something (what is called over ridding). In this example only 3 things are done. It overrides one thing (windowNibName()) and adds 2 things (on dataOfType:typeName |error|:outError and readFromData:theData ofType:typeName |error|:outError). All the rest of the functionality of the text editor come automatically from Xcode with no programming or scripting.

I should point out the scripter doesn’t have to modify the CustomDocument script object in any way to get things to work. I only show it so you can see how little it takes it create a shell. This means for me it is quicker and easier to create shells. This is all early stuff and I am hoping for feed back from other scripters about what could be done to improve the process. Perhaps even the minimal user connection to Xcode can be eliminated and Xcode can work quietly in the background.

The way I envisioned this working is you go to Xcode open the project file that contains an already complete text editor, open the file to work on in Xcode and then select “open with external editor” and the script will open in “Script Debugger” as long as that is what your default AppleScript browser is set to. Then you work on it in SD, save it (saving it in SD actually save it to the Xcode project) and then go to Xcode and click the run button to see if it works. When it does work you create an application and that’s it.

I have been testing this out for a while and I think it’s ready to use.

The second method involves leaving things not completely done in the Xcode project. The missing pieces would be customized and placed in a file that can be edited in Script Debugger and then connected to to the Xcode project later. I’ve got this to works but problems have come up here and there so it is not ready to show.

But in either case I would make a bunch of different kind os shells and the scripts could fill in what they wanted to. I have working and tested code to dynamically creates the menus for the application without using Xcode. I took over an applet, deleted it menus, create new menus and hook in handlers for the new menu items and this worked with no problem. The code is currently not as user friendly as I would like but after I clean it up a bit I can post it.

I uploaded a zip file called “Other files.zip” This contains 2 files that go inside the Xcode project but can have all the work done on them in Script Debugger. This files CustomDelegate.applescript and CustomDocument.applescript. CustomDocument.applescript doesn’t need to be modified but I put it in the zip archive so you could see what it looked like. I also uploaded a zip file of the entire Xcode project which in this case is very small. CustomDelegate.applescript and the CustomDocument.applescript are the same in both of these archives. Currently CustomDelegate.applescript does not have anything in the the file. But I included a blank file because it will be part later when the app is customized.

I am open to suggestions and advice. I think it’s time that AppleScripters should have access to this more advanced stuff. Apple is never going to make Xcode more accessible for scripters so I thought it was time that AppleScripters made it more accessible.

Bill Kopp

script CustomDocument
	property parent : class "NSDocument"
	
	property myTextView : missing value
	property attributedStringToLoadIntoTextView : missing value
	
	on init()
		continue init()
		return me
	end init
	

	on windowNibName()
NSWindowControllers, you should remove this method and override -makeWindowControllers instead.
		return "CustomDocument"
	end windowNibName
	
	on dataOfType:typeName |error|:outError
		
		set theData to missing value
		
		set entireLength to myTextView's |string|'s |length|
		set range to (current application's NSMakeRange(0, entireLength))
		set theData to myTextView's RTFFromRange:range
		
		set succeeded to (theData is not missing value)
		
		if not succeeded and outError is not missing value then
			set contents of outError to current application's NSError's errorWithDomain:(current application's NSCocoaErrorDomain) code:(current application's NSFileWriteUnknownError) userInfo:(missing value)
		end if
		return theData
	end dataOfType:|error|:
	
	
	on readFromData:theData ofType:typeName |error|:outError
		set attributedStringToLoadIntoTextView to current application's NSAttributedString's alloc's initWithRTF:theData documentAttributes:(missing value)
		
		set succeeded to (attributedStringToLoadIntoTextView is not missing value)
		
		if not succeeded and outError is not missing value then
			set contents of outError to current application's NSError's errorWithDomain:(current application's NSCocoaErrorDomain) code:(current application's NSFileReadUnknownError) userInfo:(missing value)
		end if
		
		return succeeded
	end readFromData:ofType:|error|:
	
	
	on windowControllerDidLoadNib:aController
		
		continue windowControllerDidLoadNib:aController
		
		if attributedStringToLoadIntoTextView is not missing value then
			
			set theTextStorage to myTextView's textStorage
			theTextStorage's setAttributedString:attributedStringToLoadIntoTextView
			
			set attributedStringToLoadIntoTextView to missing value
		end if
	end windowControllerDidLoadNib:
	
	
	on autosavesInPlace()
		return true
	end autosavesInPlace
	
end script

Text editor.zip (40.0 KB)

Other files.zip (2.6 KB)

#2

It’s a laudable effort, Bill, but I can’t but help question the original premise: that scripters should avoid Xcode as much as possible.

Xcode isn’t that hard to get to know, but you do need a way in. Shane provided that (in my case) with one of his first ASObjC books, and the only “downside” to that from a scripting POV is that I soon migrated away from ASObjC and AppleScript altogether to work in C, Objective-C and Cocoa directly.

I know not everyone wants to do that, but I’d think providing an “Introduction to Xcode for Scripters” tutorial would both be more effective and, arguably, more beneficial.

#3

Phil,

I wasn’t saying scripters should avoid Xcode. I was offering a way where they could avoid it if they wanted to. I myself have never met a full time scripture that had any use for Xcode and I have been with AppleScript since day one. AppleScript is about gaining advantage from being able to work with, and get information from, applications as well as send information to Applications. But the AppleScript interface to get input from users, as well as display information for users, has remained primitive and all kinds of third party solutions have popped up that cause all kinds of new problems.

I thought AppleScript Studio might be the answer but it was the wrong kind of answer. Developers and scripters solve different problems, have different constraints and different levels of perceived importance about things. I script because it is so much different then development even thought I went to school for software engineering and worked in that area first. The one size fits all doesn’t work here.

But I have to admit most developers do share your thoughts. Perhaps the answer lay between our different view points. That was why I asked for input from other scripters. I don’t know if what I am purposing is right. It feels right to me but that doesn’t mean anything as far as all scripters go. I’m not insisting on my solution. I just trying to start a process to find a solution. I am not convinced scripters can not handle anything about or contact with Xcode but many people have disagreed with me on this and say no scripter will ever use Xcode.

I myself absolutely despise Xcode. The only reason I’ve worked a lot with it lately is to find a way to do wonderful things without having much to do with it. The basic problem is it requires a lot of learning that scripters will never need to know about just to accomplish small things in Xcode. I suspect many scripters feel the learning curve is very steep to learn when 70% or more of what they learn will not help them do more as a scripter. What it comes down to is what you have to put in to get what you want back. Learning Xcode allows someone to do very powerful things if they are also willing to learn the programming language that goes with. But other then Shane and Mark I haven’t met any scripters that would choose Xcode as it is now and I’m not sure Shane or Mark would say the love Xcode.

But perhaps I just just don’t meet the right people. As a developer you might met scripters that would like to learn Xcode, or already use Xcode. That could very well be the case. But I would still like to see if a movement could start that would relieve some of the frustration scripters experience with limitations in AppleScript and the intimidation they feel with the ASObj-C enhancements to AppleScript.

But I would welcome any kind of response you would like to make to this post. A compromise can never be found by insisting on a particular solution before learning all the alternatives. For me the big question is what would a scripter gain by putting in the time to learn Xcode, and Objective-C or Swift?

Bill

#4

You’re not Robinson Crusoe in that, and if ASObjC eases the transition, that’s probably a good thing. However, I think the printing and related industry still account for a large number of scripters, and knowing Objective-C or C doesn’t solve their problems. Sure, they can then perhaps crunch data and handle house-keeping better, but they’re still likely to rely on AppleScript for driving applications like InDesign, Illustrator, and Photoshop, and even apps like Excel.

I still miss FaceSpan…

#5

Agreed. It’s why in my final paragraph I said “arguably, more beneficial”.

AppleScript still plays a central role in my day-to-day coding endeavors; it’s a great way to quickly prototype an idea, and sometimes it’s the only way to execute an idea, even with the power of Cocoa at your fingertips. I wasn’t suggesting for a minute that AppleScript is redundant (I’m still here aren’t I? :slight_smile:), it’s just that in general it’s an inferior way to create standalone apps, and that’s more or less where my main focus is these days.

That said, I really don’t see any way to do interapplication communication without AS. I haven’t been sold on javascript for automation, and shell scripting often can’t bridge the gap you need to drive desktop apps.

#6

Shane,

In house tech support in a lot of companies use AppleScript. Every place I’ve worked tech support I ended up automating things with AppleScript if it wasn’t already automated. This is one of the bigger places after the printing industries. AppleScript can make managing technical type assets a lot easier. Larger business use it to move their work flow through the office and even automate things for people in the field for bigger companies. I’ve seen it in a lot of schools like collages and universities. There are still lots of places it’s used. It’s just that as far as programming goes it is not a large part. Compared to iOS programming a lot of things aren’t that big.

When FaceSpan faded away customers were not as happy with AppleScript solutions until some replacement stuff came out but it was always pledged with strange or unexpected problems. 24U probably had some of the better stuff but they are based in the Ukraine and haven’t been that active since Russia decided to invade the Ukraine.

That’s why I was thinking the answer probably lies in Xcode and ASObj-C. Then I don’t get strange problems in unexpected places or have things break with every system release.

I loved FaceSpan as well. I used it a lot. It is memories of FaceSpan that are motivating what I am trying now. As part of what I’m trying to do I’m working on examples of the various interface items that can be dropped into a project and allow far better interfaces without incompatibility issues or breaking with system updates. I think the act of inserting interface items in ASObj-C can itself be automated somewhat to make them easier to use.

My ideas is to have parameters for various interface items and the users work with that interface. Like you did with the dialogs. The idea you had is a great one but I think there needs to be more of them and more kinds of them. I know you’re too busy to do that now so I decided to work on it.

So what do you think of what I’m trying to do? Do you think I’m wasting my time? I do not plan on selling any of this stuff. My plan is to let whoever whats to use it to just use it. I’d probably copyright it just so someone else doesn’t come along and copyright it on me. I had that that happen once and that is very annoying. But people can do what they want with it. Certainly you and Mark can do whatever you want with it. I don’t care if you or Mark create derivative products from it. I’d even put that in writing and send it to you guys. I just want AppleScript to be more usable, for more people.

Bill

#7

Yeah, I think it all boils down to what the ‘scripter’ is trying to do.

For me, if I want to write a script (as opposed to a script bundle or app), SD 6 has pretty much everything I need, and I can stay well away from Xcode.

However, if I want to turn my script into a bundle or an app (and I think one of the main reasons for doing that is precisely as you say, to improve user input and display options, as well as easily add things like bundle resources, sparkle updater, license key encryption etc), then SD6 isn’t going to work for me. I know Mark’s done great work trying to beef up SD6 to handle bundles, but my experience with trying to manage an app project in SD6 was really frustrating, to say the least. If you want to distribute bundled apps, Xcode is really the way to go, IMO.

Some time ago, Mark mentioned in passing the idea that SD7 might be project-based. I didn’t like the idea when he said it, and I still don’t, not for developing scripts, but it makes massive sense for developing bundles and apps. I’m not sure what percentage of his user base that would apply to though, and I’m quite happy with SD6 as it is for scripting scripts, and Xcode for anything more ambitious.

I still think an Xcode tutorial for scripters would be hugely valid piece of work and go a long way towards your stated aims. What you’ve done here is great stuff, I’m just not sure that learning it is really that much less work than diving into Xcode, or that it’ll have much longevity. Apple have a habit of breaking things on a yearly basis these days, and one of the only ways to keep up is by getting your head and hands around Xcode.

By way of full disclosure, I will say that most Apple developers I come across say they hate Xcode too. I’m one of the oddballs. I work with it every day, but I am by no means a ‘professional’ (‘busy hobbyist’ is my best self-description). Still, I marvel (in between the occassional frustrations) at just how well put-together it is as a piece of s/w engineering. Given its complexity, it’s amazing that it works so well.

#8

Same here. Almost daily, in fact. Xcode is such a monstrosity. Powerful, yes. But not designed for the occasional user.

#9

Phil,

Thanks for your reply. You do have a point about using what Apple decides is the way to go. If they decide Xcode is the way to go they will be stubborn about it. That is why I suggest using Xcode at all. It is easy to get a fully “compliant” application with Xcode but it is a …, as Ray put it a monstrosity. Before I tried using the part Xcode method I found it a continuing list of problems getting things to work. Including Xcode in a very light way fixed all the problems and the app is fully compatible, and works great with no interface or system problems coming up later.

I think the best way to do it is to manage Xcode through an intermediate like Script Debugger. Then you have all that power without the added headache. Unfortunately Xcode itself is not scriptable. With something as complex as Xcode I wouldn’t even try to script its interface. But things can still be automated.

Mark has things planned for Script Debugger 7. As I understand it will not crash when an Xcode script in SD crashes. That is a big plus.

But I myself will automate Xcode for me, and I figured I might as well share what I come up with for myself. The fact that Script Debugger can be used as an editor is a really big plus. Xcode’s interface is just terrible as far as it’s editor goes. It is a lot harder to read the code, and just plain harder to work in.

Perhaps you are right about an Xcode tutorial. It might work for some scripters but I doubt it would work for all of them. Script Debugger is so easy and simple to use that when Xcode is compared to it Xcode looks even worse than normal, and normally it looks pretty bad as far as complexity goes.

Thanks for your input :slight_smile:

Bill

#10

As long as you’re getting something from it, even if it’s just personal satisfaction, then you’re not wasting your time.

Part of the issue, I think, is your target. Most scripters want things simple and familiar. Given that most also have a day job, and that AS has been sold as simple since day one, that’s not unreasonable. But it’s incompatible with doing more than linear processes with minimal UI.

I wish there were a FaceSpan-style offering, but part of the reason there isn’t is that it still requires more understanding and effort than most scripters feel they can justify. Most won’t even venture into ASObjC – some of the objection is philosophical, I think, but a lot of it boils down to passing a threshold of simplicity a lot of people simply don’t want to cross.

#11

Shane,

Thanks for the reply. Well I do intend to use the stuff I am doing for myself. I can still offer it to anybody who wants to use it. But from what you said don’t expect a lot of people to be interested.

I’d have to do some serious programing to make it as easy as Script Debugger or suddenly get really really clever. But I am going to start putting better interfaces in my scripts.

Your answer got me to realize I might not be a typical scripter. I was a full time automator for a long time then I worked in places as tech support that required automation for a while. Then when I got injured and became disabled I continued to work with AppleScript a lot. So perhaps I don’t understand scripters as well as I thought. Some AppleScript solutions I did when doing full time automation got pretty involved and required a lot of interface issues to be solved before it worked. Many of them got very technical in nature. It seemed like the easier I make it for them the harder it got for me. Probably most scripters aren’t looking for that kind of thing.

But your dialog toolkit did get a lot of interest. When I wrote documentation for it there was a lot of interest in the docs. So that level was still simple enough to be of interest to scripters. I was thinking of objects with parameters but that is like FaceSpan and something like that isn’t simple enough.

So it looks like a library that can implement single functions is simple enough. But overall systems that creates an entire package might be too much. However trying to get lots of other interface items to work as easily as dialog toolkit would definitely take some time. The NSAlert is a very special kind of object that allows a lot of different things to be done while it’s open. But not many ASObj-C objects are that versatile.

Bill

#12

Oh, sure it is. Take a look at its dictionary.
You can also make Xcode run shell scripts to script itself in its Build Phases | Run Script pane**.

I think it all goes back to familiarity. Sure, you have to invest time in Xcode if you want to get anything out of it, but then I found the same to be true of SD6. It wasn’t until I worked through Matt’s videos that I really gained the benefit of it.

**EDIT: It’s only just occurred to me that that, of course, includes running osascript commands. You might be able to do some interesting AppleScripty things with that, too!

#13

To put it in context… Xcode used to be very scriptable, around version 3 or 4. Then it was almost completely broken, although the dictionary remained the same for several versions. And finally it’s been overhauled in version 8.

Heck, the latest dictionary even includes some sample scripts, and a couple of other things that I don’t think were in 8.0.

#14

Phil,

I tried out the Xcode and it does in fact seem to have a working AppleScript. So you got me on that one. I thought it had died, been given a burial, cursed at all through the funeral and then buried in some secrete location no one will ever guess after which all the people who buried it had mind wipes then it was placed under a national security seal and now has armed guards patrolling the burial site so no one can every be hurt but that beast again. But I guess all just that was rumor.

Thanks for passing that along.

Bill

#15

Nah, that was just all the other apps Apple develop. :sunglasses:

#16

The post for ASObj-C has been moved to a new permanent topic called
Permanent place for ASObj-C database

All further post will go to this topic

Bill