TLDR; is it possible to send/receive objects between an app and a 3rd party launch agent?
I'm writing an extension for an existing app (A). It's packaged and I do not have access to the source - but I can write simple plug-ins that can do some basic Cocoa and host a UI. Read: very limited options.
Ideally, what I'd like to do is have the plugin in app (A) message an external service (B) [sending objects], have (B) do some heavy lifting, then respond back to (A) so the UI can update.
I've been reading up on Launch Agents and they look promising, but I noted the examples all use basic types - no objects. I found one post discussing how to use Distributed Objects, but that's about it. It looks great, but what worries me is I'm not seeing a whole lot of current information on DO and I can't tell if it's something Apple will continue to support going forward.
Does anyone have any suggestions on options for a scenario like this? Maybe I'm just approaching this the wrong way?
Another option is I just completely split this out - write a separate full app and have (A) open it up with AppleScript. The UX wouldn't be as nice, but it would also work.
Thank you,
Eric
NOTE: I can't use NSTask. Or at least I've failed utterly to get it to work in this specific situation. Due to issues with app (A) it breaks when some of the methods run within the process. If I could somehow spawn NSTask so it was executing completely outside of (A) that might be an option. Which is actually what prompted me to look at Launch Agents...
Related
I am working with the QuickTime API and need to perform a few lengthy (as in hours) operations in the background. Unfortunately, it is not multi-thread friendly, so I am falling back to perform the tasks in a separate process, so all QuickTime related calls can happen in its main thread.
After launching it, I need a way of getting feedback on its progress, since the operations can take very long.
I am unsure of how to do this, specifically:
Should the separate process be compiled as another cocoa app or a command line tool?
How to launch it from the main cocoa app?
How to periodically get an object from it to get status information?
How to determine when it finished?
How to avoid showing a window/console when called?
How to have it part of the .app bundle so that it does not appear as a separate executable to the user?
These are really 6+ questions, but they are very related and very specific, and I think anyone needing to launch external processes (instead of spawning worker threads) can benefit from their answers. Generic code examples would be very helpful.
If it is possible, then implement the functionality in a command line tool, or another form of GUI-less application. For Cocoa applications it is possible to prevent them appearing on the Dock or in the Force Quit dialog, however a command line tool is a single binary file which does that anyway, so that would probably be a better way.
In terms of launching the tool, NSTask & NSPipe are your friends in this endeavour. The tool can definitely be kept inside your main Application's bundle, inside the Resources directory or some such, and then launched when needed. You can use the pipe to communicate back and forth.
I don't have any example code to hand, and its been a long while since I've had occasion to use either of these classes so the information I can give is limited, but it should be enough to point you in the right direction.
I want to develop an application for Mac OS X to record audio from one application.
I played around with Soundflower, but it only grabs the full system audio.
I know that I have to use a HAL plug-in. This plug-in is loaded from an application that uses Core Audio and then I can communicate with the plug-in to grab the audio.
My question is: How does such a plug-in look like? Are there examples on the internet? I have not found anything about this topic.
Now that you've decided that using Cocoa injection is a feasible solution to your problem, let's start there.
What you need to do is find out how the ObjC classes in the app are setting up to play audio, and hook in to set a different AU in place of the default system out.
There are two options (besides writing your own custom AU from scratch, which you don't need to do). You can use AUHAL as the AU, and capture the data from AUHAL. This is a bit easier from the point of view of hooking things up, but it means you have to write the code that renderers and saves the audio. Or you can just hook in a save-to-file AU, which is a bit harder to hook up, but once you do it takes care of rendering automatically.
So, how do you hook things in? Well, most of the higher-level CA calls are written to just write to the current output. If the app is doing things that way, you just need to hook in at startup to find your replacement AU and set it as the current output, in place of the default. On the other hand, if the app is writing directly to an AU that it stores in a variable, you have to hook it to store your AU as a variable. And if it's building a graph of AUs, you either replace the default output, or stick yours in front of it, in the graph.
See TN2091 for some sample code fragments for most of the hard parts for most of the possibilities. It doesn't show you how to put them together, and it's got a lot more about setting inputs than outputs (because that's harder), and the terminology can get confusing, but if you read it carefully, you should be able to find the parts you need.
If you haven't yet built a simple AU host and AU plugin before, you really should take the time to work through the whole Audio Unit Development Fundamentals guide. (And if you don't think you really need to know all that to do something simple, you're wrong. Why CoreAudio is Hard explains half of the reason; the changes between OS X versions versions are the other half of the reason.)
You probably also want to look at CocoaDev's CoreAudioAndAudioUnitsTutorial page for a placeholder page for a complete tutorial that nobody's ever written, with links to a lot of useful stuff.
Meanwhile, if injecting the whole MTCoreAudio framework into the app is feasible, it comes with a ton of nice, complete samples. In fact, even if you aren't going to use the framework, it's worth reading the Overview documentation, and possibly the source code.
I have created an update program for my project, and I'm thinking what is better - to be GUI, or to be console app?
Here's both pros and cons:
GUI: user-friendly,easy, but too much for so little program. It is unnecesseraly.
Console: Simple, but not user-friendly. And easy too!
EDIT:
Thanks for the answers! My dilemma is that the GUI is kinda too much for something so small - it will have buttons, labels, progress bars, while with console you just click, and boom. It's super easy!
Try to separate the update logic from the user interface. This makes it easy to try both of them.
You could have three separate projects in one solution. One class library containing the update logic. One console program and one WinForms program, both referencing the class library.
Well, the answer to that depends on exactly the questions you asked: who do you want to do most of the work, you or the user? In most cases, the answer is 'you'. It's your job as a developer to give the user a usable product.
Also, remember that you only develop once, but the user uses your program again and again.
Just because it's a GUI doesn't mean that it has to be a complex GUI. You could have something as simple as a form with a label in it that says "Application Updating".
I personally would go the GUI route with an option for a non-interactive install (i.e. don't show the user interface form).
The reason for this approach is that at some point down the road, you may want/need additional options or user interaction and if you start with the console route, you may need to switch to GUI eventually or risk having the console UI becoming overly complicated.
For example, if you want to charge for an update because of massive improvements, or you want to have an advanced mode for the application that is purchasable, then you would probably want to obtain a key from the user to enable this. Collecting this information in a form could be much more user friendly than keying it in at the console.
You also may want to provide a hyperlink in the update form to link to the list of new features on your web site or in the install directory. Again, it would be more user friendly in a GUI.
Where can I find the code for creating an online rebol console like the one here ?
http://tryrebol.esperconsultancy.nl/
Update: for the sandbox system on the server, can't Rebol manage it itself with some security wrapper and its security options ?
As for console itself, I don't know Ruby so I don't want to use TryRuby and why would I need it ? Can't I mimic Rebol console itself by "remoting" it somehow ? Why RT or Esper Consultancy can't make an opensource version ? There's no value in keeping it closed source. Rebol needs to prove it's more open than in the past.
In my opinion, you should aim higher with something like the already open-sourced Try Ruby. You'd type in expressions and it would guide you. Their showcase site is at tryruby.org and is fairly slick.
I modified TryRuby to work with Rebol and it wound up looking like this:
But I'm not going to run it on my server because I didn't want to belabor the necessary sandboxing/etc. or protections against someone running an infinite loop. I can give you what I've got so far if you want it.
I started a tutorial script here that no one seemed interested in helping me with, so I wandered off to other tasks:
http://www.rebol.net/wiki/Interactive_tutorial_script
I'm not sure what exactly you want. You mention you want a remote REBOL shell instead of a tutoring setup, but that's what the Try REBOL site is. There are several reasons it's not open source:
It's in heavy development. I'm currently changing the code regularly.
So it's not in a release state. Preparing it for release, documenting and publishing it would take a lot of extra work, as with most projects.
It's written in my CMS that's also in heavy development. Even if the Try REBOL site were open source, it wouldn't run. The CMS is not planned to be open sourced soon.
It's not meant as a generic REBOL remoting tool, but as a one-off demo site. If that site is running, what's the use of more of them?
As others have answered, there are many generic solutions for remoting that you could use. Also, most parts of the Try REBOL site are readily available as open source:
Syllable Server, produced and published by us.
The Cheyenne web server.
The HTML source of the web client can be viewed, including my simple JavaScript command service bus.
Syllable Server is an essential part of the site, as the sandboxing is not done with REBOL facilities (except some extra limits in the R3 backend), but with standard Linux facilities.
A truly air tight (do I mean silica tight?) sandbox is close to impossible with R2.
R3 (still in alpha) is looking a lot more promising. The deep technical discussions in flight right now (see Cure code and AltME/REBOL3 Proposals regarding unwinds and protect and even occasionally mentioning sandboxes should lead to an excellent sandbox capability.
Right now, the big advance R3 has that makes Kaj's tryREBOL possible is R3's secure policy settings which make it possible (with some careful wrapper code) to construct an alpha/demo sandbox.
To answer your precise question("where can I find code...", you could try asking Kaj for his :)
I'm new to StackOverflow. I'm not sure if this is going to end up as a reply to your comment, or as a new answer.
The somewhat common idea that any project can be open sourced and contributed to by others is a naive view. In the case of my Try REBOL site, it makes no sense. It's not just in heavy development; it's written in a CMS that's also in heavy development. Basically noone could contribute to it at this point, because I'm the only one who knows my CMS. Or in any case its newest features, which I develop by developing Try REBOL, and other example sites. So developing Try REBOL means developing the CMS at the same time, and by definition, I'm the only one who can do that.
More generally, my projects are bleeding edge, innovative technology with a strong vision. The vision is mine, and to teach it to others, I have to build it to show how I intended it to work. So there's a catch 22: to enable others to contribute, I have to finish my projects first, because people typically don't understand them until I show them how they work.
There certainly are other projects where mass contribution makes more sense. Still, only the top projects get the contributors. We found that out the hard way. We created Syllable Desktop and Syllable Server with surrounding infrastructure for contributions. These are fairly classic, well understood operating systems that many people could work on in parallel. However, despite years of begging, we get very few contributions.
So, if you feel a burning need to contribute to our projects, please pick one of the many tasks in Syllable to execute. :-)
In the bad old days of interactive console applications, Don Libes created a tool called Expect, which enabled you to write Tcl scripts that interacted with these applications, much as a user would. Expect had two tremendous benefits:
It was possible to script interactions that otherwise would have had to be repeated by hand, tediously. A classic example was dialup Internet access hell (from the days before PPP).
It was possible to write scripts to test one's own interactive applications, programmatically, as part of a regression suite.
Today most interactive applications are on the web, not on the console. Hence my question: is there any tool that provides the ability to interact with web pages and web forms programmatically, much as Expect provides the ability to interact with console applications programmatically?
(The closest thing I am aware of is Chickenfoot.)
You might be looking for Selenium
I've used Selenium RC in conjunction with Python to drive web page interactions programmatically. This has allowed me to write pretty extensive user tests in which forms and inputs are driven and their results are measured.
Check out the Selenium IDE on Firefox (as mentioned above). It allows you to record tests in the browser and play them back, either using the IDE itself, or the Remote Control app.
Perl Mechanize works pretty well for this exact issue.
HTTPS and some authentication issues are tricky at times. I will be posting couple questions about those in the future.
I did a ton of Expect work in a former life and always thought Don Libes' Expect book was one of the best-written and most enlightening technical books I'd ever seen.
Hands down I would say that Perl's WWW::Mechanize library is what you want. I note above that you were having trouble finding documentation. There is good documentation for it! Look up the module's distribution on search.cpan.org and see what all is packaged with it. There's a FAQ, Cookbook with examples, etc. Plus I've always been able to get help on the web. If you can't get it here, try at use.perl.org or perlmonks.org. WWW::Mechanize's author, Andy Lester, is present on Stack Overflow. (He's also an all around friendly and helpful guy.)
I believe WWW::Mechanize also has a program that is analogous to Expect's autoexpect program: you set up a proxy process running this program as a server, point your browser to it as a proxy, perform the actions you want to automate, and then the proxy program gives you a WWW::Mechanize program for you to use as a base for your project. (If it works like autoexpect, you will certainly want to make modifications from there.)
As mentioned above, WWW::Mechanize is a browser (to be more exact, it is a web client or http client) that happens to be programmable. The last time I looked, there was even work in progress to make it support JavaScript.
In addition to Selenium, if you're doing the Ruby/Rails thing, there's Webrat.