building an AppleScript editor app

[sqwarqDev]

Apologies for cross-posting, but I suspect there could be experts on both sides 
of the divide that may be able to help me. 

As the title suggests, I'm building an AppleScript editor (Objective-C, not 
Swift). I've got reasonably far replicating the abilities of the in-built 
Script editor and have even added a few bells and whistles. However, I'm stuck, 
conceptually, on one particular hump.

When a script in my editor returns a record that contains the four-letter codes 
defined in the target application's dictionary, what is the best way to 
translate the code back into human readable form for display in the results 
window?

For example, a simple script like this run in my editor:

 tell application System Events
   activate
   get properties
 end tell


will produce something like this:

 AEDescriptor is:
 NSAppleEventDescriptor: 'capp'{ 'desk':'obj '{ 'form':'name', 'want':'cfol', 
 'seld':'utxt'(Fusion:Users:sphil:Desktop:), ..., 

To see the output I want, just run the AppleScript code in OS X's built-in 
Script Editor and look at the Results pane. 

I can get seld's 'utxt' easily enough with the stringValue property, but I'm 
assuming the rest require parsing the codes from the target app's dictionary 
(unless someone know's a better way). 

I haven't yet got round to building my XML parser for my Dictionary viewer 
(that's next up), so I don't know if there are some methods that might help me 
in NSXML (a brief look over the class didn't suggest anything useful), but I'm 
imagining that I'm going to have to do something like this:

i. load the applications dictionary into my code 
-- (I'm assuming I do this with an NSTask calling sdef...any other 
suggestions?)

ii. parse the AEDescriptor result  for the four-letter codes 
-- (currently, my thinking here is to turn the whole result into an 
NSString and use an NSScanner)

iii. see if each has a match in the target application's dictionary
-- (I'm thinking some devil's brew of a concoction with regex, 
NSString methods and C functions to scan and match patterns, substrings and 
chars)

iv. if a match is found, format a result string from the match.
-- (haven't figured out how I'll do this yet; it'll obviously depend 
very much on what monstroisty I come up with in iii.)


While all that's a lot of code, errors and edge-cases to debug, it's not an 
insurmountable challenge (he says intrepidly, looking up from the bottom of the 
mountain with no idea of the obstacles hiding on the trail...), but before I 
set off on such a mammoth trek, I'm wondering if there's an easier/better way 
to do all this, or (thinking that Christmas is coming...) even an API that'll 
do large part of it for me

Any thoughts would be massively appreciated!



Best


Phil


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: building an AppleScript editor app

[Ken Thomases]

On Dec 7, 2014, at 3:46 AM, sqwarqDev 2551p...@gmail.com wrote:

 As the title suggests, I'm building an AppleScript editor (Objective-C, not 
 Swift). I've got reasonably far replicating the abilities of the in-built 
 Script editor and have even added a few bells and whistles. However, I'm 
 stuck, conceptually, on one particular hump.
 will produce something like this:

Are you aware of the OSAKit framework and the OSAScriptView and 
OSAScriptController classes?  I don't find documentation, but the headers seem 
relatively straightforward.  From the looks of it, a lot of the functionality 
of Script Editor is just a thin wrapper around these classes.


 AEDescriptor is:
 NSAppleEventDescriptor: 'capp'{ 'desk':'obj '{ 'form':'name', 
 'want':'cfol', 'seld':'utxt'(Fusion:Users:sphil:Desktop:), ..., 
 
 To see the output I want, just run the AppleScript code in OS X's built-in 
 Script Editor and look at the Results pane. 
 
 I can get seld's 'utxt' easily enough with the stringValue property, but I'm 
 assuming the rest require parsing the codes from the target app's dictionary 
 (unless someone know's a better way). 

 ii. parse the AEDescriptor result  for the four-letter codes 
   -- (currently, my thinking here is to turn the whole result into an 
 NSString and use an NSScanner)

That's crazy.  An NSAppleEventDescriptor is already a data structure.  
Converting it into a string and then parsing the string into a data structure 
is just redundant.

What you've shown above is just the description string of the 
NSAppleEventDescriptor.  It's not its native content.

You can query the descriptor for its -descriptorType.  If it's typeAEList, then 
you would use -numberOfItems and -descriptorAtIndex: to iterate over the 
elements.  Remember that -descriptorAtIndex: takes one-based indexes.

In many cases, the descriptor will be a record.  The descriptor you showed 
above is a record.  A record can have an arbitrary descriptorType.  You can use 
AECheckIsRecord(anAEDescriptor.aeDesc) to test if it's a record.  I don't see a 
Cocoa equivalent.  The descriptorType will indicate what specific type of 
record it is.  Here you would need to consult the scripting terminology 
dictionary to figure out what class it represents.  However, even without 
knowing the class, you can enumerate the keywords using -numberOfItems and 
-keywordForDescriptorAtIndex: (again, one-based index).  For each keyword, you 
can get the value descriptor using -descriptorForKeyword:.  Actually, if you're 
iterating by index, you can also use -descriptorAtIndex: to get the value, too. 
 An AERecord is a special type of AEList, so it can be accessed like a list.

Given that each value is a descriptor, you can apply the same techniques 
recursively to traverse them.  Obviously, you'll eventually get to leaf nodes, 
which won't be lists or records.  Those will have descriptorTypes of 
typeUnicodeText or typeSInt32 or the like.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: building an AppleScript editor app

[sqwarqDev]

Ken, many thanks for taking the time to respond. 

Yes, I'm very familiar with OSAKit framework, but only in the sense that the 
more I look at it the more infuriating it becomes...

 What you've shown above is just the description string of the 
 NSAppleEventDescriptor.  It's not its native content.

Acutally, its the result of 

NSAppleEventDescriptor *result =[_userScript executeAndReturnError:myError];

I've been playing with both descriptorForKeyword and descriptorAtIndex: for 
some time, but none of that gets me past the four-letter codes. I need to query 
the applications dictionary to do that as far as I can tell. I was just 
wondering if anyone knew how that's done other than manually trying to match 
the four-letter code with what's in the sdef file.

If that is the task, then I don't quite undertand what you mean here:

 That's crazy.  An NSAppleEventDescriptor is already a data structure.  
 Converting it into a string and then parsing the string into a data structure 
 is just redundant.

I have to match the code with what's in the dictionary. How else do I do that 
other than turning them both into the same object (eg. NSStrings or char 
strings)? What am I missing?

Best


Phil



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: building an AppleScript editor app

[sqwarqDev]

 On 7 Dec 2014, at 18:59, sqwarqDev 2551p...@gmail.com wrote:


 AEDescriptor is:
 NSAppleEventDescriptor: 'capp'{ 'desk':'obj '{ 'form':'name', 
 'want':'cfol', 'seld':'utxt'(Fusion:Users:sphil:Desktop:), ..., 
 
 What you've shown above is just the description string of the 
 NSAppleEventDescriptor. It's not its native content.
 
 Acutally, its the result of 
 
 NSAppleEventDescriptor *result =[_userScript executeAndReturnError:myError];


Just to add a bit more clarity, lest we end up going down a rabbit hole here 
(I've been in this warren before when discussing AppleScript...), the 
AEDescriptor that I gave an example of is exactly the same as what you'll see 
if you run a script in Script Editor, then leave your cursor hovering over the 
Replies or Events panels (Accessory view) at the bottom of Script Editor. 

After a second or two, you'll see a popup view with the raw AppleScript result 
code, which Script Editor magically turns into human readable code in the 
Accessory view panel.

I am looking for any tips on how to go about performing the same trick.


Best


Phil









___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: building an AppleScript editor app

[has]

sqwarqDev wrote:

 As the title suggests, I'm building an AppleScript editor 
(Objective-C, not Swift). I've got reasonably far replicating the 
abilities of the in-built Script editor and have even added a few bells 
and whistles. However, I'm stuck, conceptually, on one particular hump.


IMO you're almost certainly wasting your time. The aged AppleScript 
market is moribund, and the nascent JavaScript for Automation market is 
stymied by JXA being a total sack of crap.


OSA is built upon the Carbon Component Manager, which was deprecated in 
10.8. The Carbon OSA (OpenScripting) framework has been a legacy API 
since 10.6, and some functions also require deprecated types such as 
FSRef in addition to Component/ComponentInstance. OSAKit framework is 
supposed to be a Cocoa alternative, but is an undocumented sack of crap, 
and you still have to drop down to the Carbon OSA APIs for the sorts of 
non-trivial operations an OSA editor requires.



 When a script in my editor returns a record that contains the 
four-letter codes defined in the target application's dictionary, what 
is the best way to translate the code back into human readable form for 
display in the results window?


You don't. You use the OSA to do it for you. OSAExecute and friends 
return an OSAID for a newly created ScriptValue object containing the 
raw result. You pass that ID to something like OSADisplay if you want 
that result as a display string, or to OSACoerceToDesc if you want it as 
an AEDesc. It's quite tedious, but it works. Or you use OSAScript, which 
has a very stupid method that returns both a display string and an 
AEDesc at the same time.




 I haven't yet got round to building my XML parser for my Dictionary 
viewer (that's next up), so I don't know if there are some methods that 
might help me in NSXML (a brief look over the class didn't suggest 
anything useful), but I'm imagining that I'm going to have to do 
something like this:


 i. load the applications dictionary into my code
 -- (I'm assuming I do this with an NSTask calling sdef...any other 
suggestions?)


OSACopyScriptingDefinitionFromURL() is busted: documentation says both 
file: and eppc: URLs are accepted, but file: URLs return garbage 
(specifically, an SDEF for AEM's degenerate XML-RPC/SOAP support). 
OSACopyScriptingDefinition() requires an FSRef, which in turn requires 
use of deprecated functions like CFURLGetFSRef(). Honestly, calling out 
to `sdef` is probably the least horrid option.



 ii. parse the AEDescriptor result  for the four-letter codes
 -- (currently, my thinking here is to turn the whole result into an 
NSString and use an NSScanner)


Wut? Or are you still talking about displaying the script's return 
value? If so, stop shoveling and see above.


As to dictionary viewers in general: OSAKit contains the dictionary 
viewer classes used by SE, though needless to say it doesn't work right, 
particularly when displaying inheritance and containment graphs which it 
almost invariably mucks up. I wrote some thoroughly horrible code for 
ASDictionary that does a much better job, although I don't think I ever 
finished the SDEF parser as the AS team keep mucking with the format and 
SDEF's always had bugs. Public domain code can be found in the old 
appscript svn repo. Either way, you deal with crap, insanity, or both. 
And you'll be pretty much on your own all the way: after a few thousand 
hours down the toilet I no longer provide any public appscript support 
(so if you want specifics you'll have to pay consultant rates), and good 
luck trying to get help out of any of the current AppleScript engineers 
(not that they understand half this stuff right anyway).



As to general advice: I suggest you find yourself the original Inside 
Macintosh sections on Apple Event Manager and Scripting Components and 
read those to get some idea of how OSA works. (Be aware that even these 
are horribly light on specifics.) Also William Cook's HOPL paper on the 
early history of AppleScript is useful background. The JavaScriptOSA 
component I wrote after WWDC14 so the JXA devs could use it as reference 
(they didn't) is available at 
http://sourceforge.net/projects/appscript/files/. Again, unsupported, 
unfinished, and not 100% right (the more obscure, advanced behaviors I 
was semi-guessing due to lack of public Apple documentation), but it may 
provide some insight into how OSA is designed to operate. (I did 
actually start writing an OSAKit replacement as well, but a brief bout 
of sanity cured me in time.)


Bear in mind too that OSA and the AS component are twenty year-old tech, 
and hopelessly obsolete by modern standards. There's no support for 
incremental parsing, for example, which you need to support stuff like 
dynamic code coloring and auto-complete which modern scripters expect. 
There's no hooks for debuggers or profilers, which users also expect, 
and you will probably go insane trying to hack your own workaround. The 
only person 

Re: building an AppleScript editor app

[sqwarqDev]

 IMO you're almost certainly wasting your time.

I've been told this since I first mentioned it over a year and a half ago. I'm 
not a professional developer, it's a hobby. Wasting my time on this is no worse 
than watching re-runs of Kung Fu and sure beats suffering on the sofa 
watching Leeds United getting hammered again... :(

 
 You don't. You use the OSA to do it for you. OSAExecute and friends return an 
 OSAID for a newly created ScriptValue object containing the raw result. You 
 pass that ID to something like OSADisplay if you want that result as a 
 display string, or to OSACoerceToDesc if you want it as an AEDesc.

Great news. Just the sort of tip I was looking for.

  Or you use OSAScript, which has a very stupid method that returns both a 
 display string and an AEDesc at the same time.

Huh? Which method are you talking about? I can't see anything in OSAScript that 
returns much anything than various ints, none of which seem obviously useful 
for getting human readable text out of.

  Honestly, calling out to `sdef` is probably the least horrid option.
 

Great, thanks for the time-saver. I won't bother looking elsewhere.


 As to dictionary viewers in general: OSAKit contains the dictionary viewer 
 classes used by SE, though needless to say it doesn't work right, 

I was thinking I'd just build my own besoke XML viewer. Aside from the fact I 
won't be able to load any old dictionary files that aren't sdefs (I'm happy to 
forsake them) that seems the easiest part of the job.

 As to general advice: I suggest you find yourself the original Inside 
 Macintosh sections on Apple Event Manager and Scripting Components and read 
 those to get some idea of how OSA works. (Be aware that even these are 
 horribly light on specifics.) Also William Cook's HOPL paper on the early 
 history of AppleScript is useful background.

Thanks, I'll take a look at those. In case anyone else is in the madhouse, I 
collated all these and other AppleScript legacy docs last year:

https://applescriptlibrary.wordpress.com


 Bear in mind too that OSA and the AS component are twenty year-old tech, and 
 hopelessly obsolete by modern standards. There's no support for incremental 
 parsing, for example, which you need to support stuff like dynamic code 
 coloring and auto-complete which modern scripters expect. There's no hooks 
 for debuggers or profilers,

This is what first got me interested in writing a decent editor to start 
with...well, that and I refuse to pay $199 for the only alternative.

 The only person who's ever managed is Mark Aldritt, and I doubt he'll want to 
 share his secrets. 

If it can be done by one person, it can be done by another. Not to say that 
it'll be me. I'm really not smart enough, and I've really scaled down my 
ambitions. In fact, I only got into this again (after letting it lie for nearly 
a year) because I was building another app and realized I'd discovered the 
answer to one of the puzzles that had frustrated me last year. 

So, I (foolishly) started thinking, Ohh, maybe I'm nearly there... well, I've 
solved almost all the puzzles this project has presented me with so far (with 
some help)...and there's been a lot...I just don't know yet whether that's 1% 
of the total or 99%...

I'll keep plugging away till TV re-runs get the better of me or Leeds go on a 
winning streak. Thanks for the tips, has. Amongst the discouragement, there was 
some useful leads. :)


Best


Phil







___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Opening an Embedded Application in Terminal

[SevenBits]

Hi there everyone,

I have a sandboxed app destined for the Mac App Store. Inside of it is an 
embedded console program which I want to open in Terminal (i.e Terminal.app 
opens and the app runs in its window). Here’s what I’m doing:

NSString *interactiveExecutablePath = [[[NSBundle mainBundle] bundlePath] 
stringByAppendingPathComponent:@/Contents/MacOS/app];
[NSTask launchedTaskWithLaunchPath:@/usr/bin/open arguments:@[@-a, 
@Terminal, interactiveExecutablePath]];

When the app is not sandboxed, this works; when it is sandboxed, however, it 
fails saying that ““app” can’t be opened because CoreServicesUIAgent is not 
allowed to open documents in Terminal.”

I really need this to work as it’s an important aspect of my application. Can 
anyone advise?

Thanks,

— SevenBits


signature.asc
Description: Message signed with OpenPGP using GPGMail
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Opening an Embedded Application in Terminal

[Ken Thomases]

On Dec 7, 2014, at 2:29 PM, SevenBits sevenbitst...@gmail.com wrote:

 I have a sandboxed app destined for the Mac App Store. Inside of it is an 
 embedded console program which I want to open in Terminal (i.e Terminal.app 
 opens and the app runs in its window). Here’s what I’m doing:
 
 NSString *interactiveExecutablePath = [[[NSBundle mainBundle] bundlePath] 
 stringByAppendingPathComponent:@/Contents/MacOS/app];
 [NSTask launchedTaskWithLaunchPath:@/usr/bin/open arguments:@[@-a, 
 @Terminal, interactiveExecutablePath]];

First, it never makes any sense for a program to spawn a subprocess to run 
/usr/bin/open.  /usr/bin/open is just a wrapper around Launch Services.  So, 
you could just call Launch Services directly or use NSWorkspace, which is also 
a wrapper around Launch Services.

Second, even using Launch Services isn't the best way to do this (sandbox 
issues aside).  It's better to run the equivalent of this AppleScript script:

tell app Terminal
activate
do script your command goes here
end

You can do that using NSAppleScript or the Scripting Bridge.

I don't know if this approach is more likely to work in a sandboxed app.  I 
doubt it, because it would be an enormous hole in the sandbox.  If you can 
direct Terminal to run arbitrary commands, what protection does the sandbox 
provide?


 I really need this to work as it’s an important aspect of my application. Can 
 anyone advise?

I suspect you have a serious problem, then.  You will probably need to deploy 
outside of the Mac App Store so that you don't have to sandbox your app.  
Alternatively, you can build a terminal emulator UI into your app and run the 
embedded console program within that, instead of Terminal.  Depending on the 
needs of your console program, that may be a relatively straightforward 
prospect or a very complex one.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: building an AppleScript editor app

[has]

sqwarqDev wrote:

 it's a hobby.

The Aristocrats!


 Wasting my time on this is no worse than watching re-runs of Kung 
Fu and sure beats suffering on the sofa watching Leeds United getting 
hammered again... :(


(Bradford City FTW)


  Or you use OSAScript, which has a very stupid method that returns 
both a display string and an AEDesc at the same time.


 Huh? Which method are you talking about? I can't see anything in 
OSAScript that returns much anything than various ints, none of which 
seem obviously useful for getting human readable text out of.


-[OSAScript executeAndReturnDisplayValue:error:]


 As to dictionary viewers in general: OSAKit contains the dictionary 
viewer classes used by SE, though needless to say it doesn't work right,


 I was thinking I'd just build my own besoke XML viewer. Aside from 
the fact I won't be able to load any old dictionary files that aren't 
sdefs (I'm happy to forsake them)


`sdef` and OSACopyScriptingDefinition...() automatically translate older 
formats to XML SDEF. This isn't to say they translate 100% correctly, 
but it's probably good enough for documentation purposes.



 that seems the easiest part of the job.

You wish. Getting inheritance and containment graphs right in particular 
is a pig, since dictionaries are not validated and frequently contain 
errors and omissions. You may wish to install a copy of Python appscript 
alongside ASDictionary, and play about with its built-in help() method, 
which manages fairly decent graphs generated from AETE data. That alone 
was several hundred hours' work.


The only info that's reasonably accurate is keyword names and codes, and 
what they represent (command, property, etc), since that's what 
AppleScript relies on to compile scripts, and even that can be glitchy 
at times, particularly in the big Carbon-based productivity apps. Plus 
there's stupid stuff like SDEF not being able to distinguish `text` 
strings from `text` application objects, and then there's the 
documentation element and XInclude messes, and I don't know how SDEF 
even deals with dynamically loaded dictionaries for scriptable plugins.



 Bear in mind too that OSA and the AS component are twenty year-old 
tech, and hopelessly obsolete by modern standards. There's no support 
for incremental parsing, for example, which you need to support stuff 
like dynamic code coloring and auto-complete which modern scripters 
expect. There's no hooks for debuggers or profilers,


 This is what first got me interested in writing a decent editor to 
start with...


As I say, you'd be easier writing your own interpreter, then writing an 
editor around that. (Although the AppleScript language is such a pig to 
interpret correctly, I wouldn't recommend attempting that as a first 
choice.)



 well, that and I refuse to pay $199 for the only alternative.

Meh, a couple hundred bucks is nothing for a product that works for a 
living. (Adobe'll happily gouge you ten times that, and let's not even 
mention the hole that the likes of AutoDesk like to make.)


Heck, you could pay for SD in a few hours just by calling yourself 
automation consultant and hitting up the local graphic design outfits 
for some freelance scripting work.


Or, if you're really cheap, go give Satimage's Smile editor a go. The 
standard version is free, and you can have hours of brain-melting fun 
just by exploring its own insanely deep use of OSA. 
http://www.satimage.fr/software/en/index.html



 I'll keep plugging away till TV re-runs get the better of me or Leeds 
go on a winning streak. Thanks for the tips, has. Amongst the 
discouragement, there was some useful leads. :)


Just words from the wise. I know how many hours I've sunk into this crap 
myself, for great pain and little reward. Honestly, take up Flamenco or 
Taekwondo or something like that. Or get yourself a copy of Seymour 
Papert's Mindstorms and figure out how to make a modern Logo environment 
that properly rocks. Building languages is way more fun [1], and Lispy 
interpreters are ridiculously easy to make, yet will seriously expand 
your mind as you realize how deep and powerful they are.


Regards,

has

[1] It's what I do myself now. http://www.mantasystems.co.uk/docs.html
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Opening an Embedded Application in Terminal

[SevenBits]

 On Dec 7, 2014, at 4:03 PM, Ken Thomases k...@codeweavers.com wrote:
 
 On Dec 7, 2014, at 2:29 PM, SevenBits sevenbitst...@gmail.com wrote:
 
 I have a sandboxed app destined for the Mac App Store. Inside of it is an 
 embedded console program which I want to open in Terminal (i.e Terminal.app 
 opens and the app runs in its window). Here’s what I’m doing:
 
 NSString *interactiveExecutablePath = [[[NSBundle mainBundle] bundlePath] 
 stringByAppendingPathComponent:@/Contents/MacOS/app];
 [NSTask launchedTaskWithLaunchPath:@/usr/bin/open arguments:@[@-a, 
 @Terminal, interactiveExecutablePath]];
 
 First, it never makes any sense for a program to spawn a subprocess to run 
 /usr/bin/open.  /usr/bin/open is just a wrapper around Launch Services.  So, 
 you could just call Launch Services directly or use NSWorkspace, which is 
 also a wrapper around Launch Services.
 
 Second, even using Launch Services isn't the best way to do this (sandbox 
 issues aside).  It's better to run the equivalent of this AppleScript script:
 
 tell app Terminal
activate
do script your command goes here
 end
 
 You can do that using NSAppleScript or the Scripting Bridge.

Okay, but out of curiosity, what makes AppleScript a better choice in this 
scenario? Doesn’t it ultimately fall back on Launch Services just like the 
other options?

 
 I don't know if this approach is more likely to work in a sandboxed app.  I 
 doubt it, because it would be an enormous hole in the sandbox.  If you can 
 direct Terminal to run arbitrary commands, what protection does the sandbox 
 provide?

I get your point, but the fact is, I’m not trying to run an arbitrary command, 
and I don’t even care if Terminal inherits the sandbox from my process. I just 
need to run this command in a window so that the user can type input in and 
receive the results back. In other words, I’m looking for Terminal’s user 
interface, not its ability to run arbitrary commands.

If it matters, the executable is a program that evaluates instructions using 
REPL (read-eval-print loop).

 
 
 I really need this to work as it’s an important aspect of my application. 
 Can anyone advise?
 
 I suspect you have a serious problem, then.  You will probably need to deploy 
 outside of the Mac App Store so that you don't have to sandbox your app.  
 Alternatively, you can build a terminal emulator UI into your app and run the 
 embedded console program within that, instead of Terminal.  Depending on the 
 needs of your console program, that may be a relatively straightforward 
 prospect or a very complex one.

Well, I’m stuck in the middle. On the one hand, implementing a full-brown 
terminal emulator along the lines of iTerms 2 for my app is overkill and isn’t 
worth the extra megabytes. But I don’t want to implement a kludgy 
NSTextField-based interface to feed in input using NSTask and output/input 
streams either, as it doesn’t look that great.

However, unless someone can come up with a good way to provide a Terminal-like 
environment for REPL applications, the second approach is the one I’ll probably 
have to take…

Thanks,

— SevenBits

 
 Regards,
 Ken
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Opening an Embedded Application in Terminal

[Keary Suska]

On Dec 7, 2014, at 1:35 PM, SevenBits sevenbitst...@gmail.com wrote:

 
 I don't know if this approach is more likely to work in a sandboxed app.  I 
 doubt it, because it would be an enormous hole in the sandbox.  If you can 
 direct Terminal to run arbitrary commands, what protection does the sandbox 
 provide?
 
 I get your point, but the fact is, I’m not trying to run an arbitrary 
 command, and I don’t even care if Terminal inherits the sandbox from my 
 process. I just need to run this command in a window so that the user can 
 type input in and receive the results back. In other words, I’m looking for 
 Terminal’s user interface, not its ability to run arbitrary commands.
 
 If it matters, the executable is a program that evaluates instructions using 
 REPL (read-eval-print loop).
 
 
 
 I really need this to work as it’s an important aspect of my application. 
 Can anyone advise?
 
 I suspect you have a serious problem, then.  You will probably need to 
 deploy outside of the Mac App Store so that you don't have to sandbox your 
 app.  Alternatively, you can build a terminal emulator UI into your app and 
 run the embedded console program within that, instead of Terminal.  
 Depending on the needs of your console program, that may be a relatively 
 straightforward prospect or a very complex one.
 
 Well, I’m stuck in the middle. On the one hand, implementing a full-brown 
 terminal emulator along the lines of iTerms 2 for my app is overkill and 
 isn’t worth the extra megabytes. But I don’t want to implement a kludgy 
 NSTextField-based interface to feed in input using NSTask and output/input 
 streams either, as it doesn’t look that great.
 
 However, unless someone can come up with a good way to provide a 
 Terminal-like environment for REPL applications, the second approach is the 
 one I’ll probably have to take…

I would first try NSTextView instead--you get a lot of control simply from 
delegate calls, although you will need to subclass. The only tricky part is how 
to handle the parts that would not be editable, and what to do when someone 
tries to edit it. Setting a custom attribute is probably the way to go.

HTH,

Keary Suska
Esoteritech, Inc.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Opening an Embedded Application in Terminal

[Ken Thomases]

On Dec 7, 2014, at 5:35 PM, SevenBits sevenbitst...@gmail.com wrote:

 On Dec 7, 2014, at 4:03 PM, Ken Thomases k...@codeweavers.com wrote:
 
 Second, even using Launch Services isn't the best way to do this (sandbox 
 issues aside).  It's better to run the equivalent of this AppleScript script:
 
 tell app Terminal
   activate
   do script your command goes here
 end
 
 You can do that using NSAppleScript or the Scripting Bridge.
 
 Okay, but out of curiosity, what makes AppleScript a better choice in this 
 scenario? Doesn’t it ultimately fall back on Launch Services just like the 
 other options?

Not exactly.  AppleScript will use Launch Services to launch Terminal if it's 
not already running, but not otherwise.  And Launch Services delivers Apple 
Events to tell Terminal to open a document.

The reason I consider the Apple Script (or Scripting Bridge) approach to be 
better is that it is more specific to what you're trying to do.  It's not at 
all clear to me that opening an executable with Terminal is going to 
_reliably_ run that executable's path as a command in a new window.  Directly 
telling Terminal to run a particular command with its AppleScript interface 
seems much closer to the specific thing you're trying to accomplish.


 I don't know if this approach is more likely to work in a sandboxed app.  I 
 doubt it, because it would be an enormous hole in the sandbox.  If you can 
 direct Terminal to run arbitrary commands, what protection does the sandbox 
 provide?
 
 I get your point, but the fact is, I’m not trying to run an arbitrary 
 command, and I don’t even care if Terminal inherits the sandbox from my 
 process.

If Terminal is already running, it won't inherit your sandbox.

 I just need to run this command in a window so that the user can type input 
 in and receive the results back. In other words, I’m looking for Terminal’s 
 user interface, not its ability to run arbitrary commands.

There's no separating Terminal from its ability to run arbitrary commands.  
There's certainly no way that the system is going to have the insight into what 
you're doing to understand that it should be allowed.  There are too many 
layers of indirection and interpretation of arguments.

Among other things, any Terminal window is going to run a login shell, which is 
going to process /etc/profile and one of ~/.bash_profile, ~/.bash_login, or 
~/.profile.

 If it matters, the executable is a program that evaluates instructions using 
 REPL (read-eval-print loop).

I'm guessing it doesn't need much in terms of terminal emulation.  I.e. it's 
not using curses/ncurses, terminal control, color, etc.  In that case, it may 
be a good candidate for driving via NSTask and pipes.  You will want to make 
sure that it flushes standard output before blocking waiting for input.  That's 
automatic when standard input and output are connected to a terminal device, 
but not when they're connected to pipes.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [SOLVED] building an AppleScript editor app

[2551]

 
 -[OSAScript executeAndReturnDisplayValue:error:]


Bingo! THAT's what I was looking for! 

In my current project (I have several derivatives of the editor I'm building, 
which is another thing that keeps me playing with it), I'd switched to 
NSAppleScript and forgotten that OSAScript has one or two more tricks. I was 
also spending too much time looking at NSAppleEventDescriptor thinking the 
answer was/should have been in there somewhere. 

Right, then. Now, let's see about that dictionary viewer...




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Using AV Foundation to record m3u8 stream to disk

[Graham Cox]

The title says it all really: is it possble to use AV Foundation to record a 
m3u8 stream to a movie file (optionally transcoded). I have set up a simple 
exploratory app and I can get it to play a m3u8 stream in a view fine, but when 
I add a AVAssetExportSession, (allowing for the asynchronous loading and 
preparation of the stream so that asset tracks are created and loaded) it 
always reports a failure, usually saying that the operation is unsupported for 
the media. This seems to be the case no matter what export preset I use, 
including passthrough.

Is this deliberately impossible? Or have I just not found the magic combinaiton 
yet?

--Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com