I'm trying to port an application I've written in Qt from the windows platform to the Mac OS X platform.
The application is relatively simple:
It queries the user for a document (either MS Word, or OOo Writer document). It than launches that that document inside the
respective application, and than replaces various text elements with other data (Think Mailmerge).
It starts up the application and does the text replacing using QAxObject which is wrapper for COM.
Now I'm wanting to port this to the Mac OS X. I've installed Qt Creator on the Mac etc., but obivously COM is a windows technique not available on the Mac OS X.
So I've been looking around for techniques on the Mac OS X that are similiar to COM.
For now, I'm especially interested in using the OOo API http://api.openoffice.org/.
I'd like some pointers which techniques I should be looking at. I'm also willing to accept that this just plainly is not possible at all.
Thanks in advance.
A bit of information about COM on OS X is available in this 2004 article from O'Reilly's MacDevCenter.
From the description of your problem, however, you're looking for something that works with Apple Events. Apple has developed an entire language for working with Apple Events, so most people equate them with the language -- AppleScript. You'll want to start exploring the field of scripting GUI applications with exploration of AppleScript, or Apple Events.
Each directly scriptable app has a "dictionary" of "verbs" and "nouns" you can manipulate. Nouns have properties, and name of the property is often either a string or the name of another noun (or a plural of a noun, which implies a collection - an array).
If the app doesn't have a dictionary (i.e. it isn't scriptable) or doesn't provide what you need via the dictionary, it is possible to send generic UI scripting commands to an "application" called "System Events".
Hmmm -- not a lot of experience in the OOo arena, but have you considered using UNO, the component model that is part of OpenOffice?
Some documentation can be found in the Developer's Guide here.
Related
I am trying to find the best way to handle application windows on Mac OS from a script. I am open to any language, but I want it to have the following capabilities
Get list of open applications
Get location of specific application
Change focus, position, and size of specific application
Send key events to only specific application
I have managed to get a list of applications using JNA, Apple's Core Graphics library, and some code from this question, but the capabilities seem to be limited. Is there a way to implement the functionality I am looking for, or is Mac OS too closed down for this? Like I said, I am open to all languages.
Thanks so much!
I'm automating excel with python through the COM interface, with pywin32. I'd like to port my script to mac. Is there any chance of this happening? I realize that I can't use COM on a mac, and the xlutils python modules won't work (since I need to copy graphs, etc.). Is there anything else I can use?
Unfortunately development of appscript has been stopped,
I'm not aware the development of AppleScript has been stopped. What is your source on that?
As far as I can tell, AppleScript is still maintained and has a future and is working well.
Also there is a distinction between "AppleScript" the scripting language and the Inter-Application Communication Technology (IAC) called: "AppleEvents"
You can find the AppleScript Editor.app at the following location on your Mac:
/Applications/Utilities/AppleScript Editor.app
Open up the AppleScript Editor.app and then choose from the File menu: "Open Dictionary..."
Then select "Excel.app"
This will open the Apple Event dictionary for Excel. You will be able to see "Nouns" and "Verbs" and "Properties" that are supported in Excel for Apple Events.
AppleScript can be used to send commands to Excel via Apple Events, but so can other scripting languages such as Python.
If I were you, I would consider making an abstract class of Excel and two concrete subclasses, one that uses the Windows version of the code for Windows and anther that uses the Apple Event code that the Mac version of Excel might need.
See: the Wikipedia Article on Apple Events:
http://en.wikipedia.org/wiki/Apple_events
It's really Apple Events -- not AppleScript that you may want to use, but you could look at the following article too:
See Also: the Wikipedia Article on AppleScript:
http://en.wikipedia.org/wiki/AppleScript
--- edit ---
I believe that the misconception that Apple is lessening its support of AppleScript comes from the fact that AppleScript Studio was discontinued, but it was replaced with something just as good or better. Now, you can use AppleScript to develop full-fledged Mac applications in XCode. In addition, AppleScript can also still be used in Automator workflows, in XCode to build Automator actions, and in the AppleScript Editor, all of which are delivered by Apple in the latest version of OS X (Mountain Lion 10.8.4) and in the latest version of XCode (version 4.6.2)
So AppleScript is still a viable option, though the OP was asking about a Python solution. Apple Events are available from Python.
Currently the only possible solution would be appscript, which is a module that allows to write AppleScript macros in python (and ruby). Unfortunately development of appscript has been stopped, but for now it keeps working well enough.
I'm developing an app for the Mac OS X that provides various system statistics. I have a little problem with the printer because I have never worked with it before. Is there any way to listen to the printer and count pages printed in color and in b&w?
Edit: I remember that I was using a Mac OS X kiosk machine once and it offered color and b&w prints priced per page, so there must be a way to do this. Also, I develop this app for my own needs and for practice so the solution doesn't have to be universal.
I'm pretty sure access to this information is specific to individual printer models. I don't believe there's a system API that will help you here as it would require querying individual printer drivers or utilities.
The Core Printing Reference which is the documentation for the Mac OS X printing API doesn't appear to contain any calls that would allow you to extract this information from a printer.
For a given extension, for example ".psd", I'd like to be able to determine the default application path for opening this file, for example "/Applications/Adobe Photoshop CS4.app".
I've looked into the Launch Services API, and there are clearly programmatic ways to get this information. Unfortunately for my particular scenario, only a scripting solution (Applescript or shell script) will do.
I've also looked at "lsregister -dump". It seems to be unwise to rely on parsing this information, since there are no guarantees as to the stability of the output format.
I've been solving this problem in the past with Creator Codes, but since Apple seems to be phasing them out since Snow Leopard I'm trying to eliminate dependence on Creator Codes.
thanks
Launch Services is the one and only place to get that information. You can write a scripting addition that will expose its functionality to AppleScript, but then you have to install that on whatever machine you plan to run on.
System Events does give you this in Leopard
alt text http://img.skitch.com/20091222-eessetxeqbai2mnwduygtm1cd5.png
In the wikipedia article on Cocoa it says:
There are also open source implementations of major parts of the Cocoa framework that allows cross-platform (including Microsoft Windows) Cocoa application development, such as GNUstep, Cappuccino, and Cocotron.
Yet when I looked into whether Mac application Tweetie was available for windows the developer had ruled it out:
Windows doesn't have Cocoa, the programming environment that Tweetie is made in, as such, it seems like a poor possibility.
I'd like to have an answer to point the Tweetie developers (and as a resource for other cocoa developers) which would tell them:
Which implementation is the most suitable for getting a cocoa app running on windows?
How much work is it likely to take to get the app running under windows?
How easy/hard is it to maintain a common code base for Mac and Windows?
(any other considerations I've missed?)
Of course if it would be too much work I'd like to know that too before suggesting it and potentially sending someone else on a fruitless search.
Don't forget:
“Major parts of the Cocoa frameworks” is not the same as “the entirety of the Cocoa frameworks”. Tweetie could be using something that's missing.
Tweetie could be (very probably is) using APIs from the non-Cocoa frameworks, such as Core Foundation, Core Services, Core Graphics, and Core Animation. A port of the Cocoa frameworks alone won't include any of these APIs, and even a more complete Mac-API-emulation framework will not include all of them.
These frameworks are eternally chasing Apple. Even if they catch up, they'll be instantly behind again as of the next Mac OS X release. Mac developers already put off using new APIs in new Mac OS X releases while they wait for users to upgrade to those new releases; now you're asking atebits to also wait for the other-framework developer to catch up to Apple again.
Any second implementation of an existing API will have bugs that the first implementation doesn't, and vice versa. These differences will cause development and support problems.
You're asking atebits to add a third platform to an application that already exists on two. Supporting one platform is a lot of work. Supporting two platforms is a hell of a lot of work. Supporting three? Now you're getting into big-company territory.
So, even with these Cocoa-like frameworks, the answer is: Hard.
Among GNUstep, Cappuccino and Cocotron, Cocotron is only possible choice to port a Mac application to windows.
Cappuccino is for web and GNUstep only runs on top of cygwin or mingw, which means the GUI looks nothing like native windows apps.
It is theoretically possible to build cocoa windows apps using Cocotron. However, the reality is that it is still very hard to use, and it is still quite limited in the Cocoa API.
Therefore, two possible solutions:
Try hard to remove the codes that are not supported by Cocotron in the original code base and do the cross compilation. Maintaining common code base will be painful.
Start a new GUI at all, no common code base. two choices here
Start a cross platform project with cross application framework such as Qt, or Java.
Start a windows only project. There are a lot of choices here, .Net WinForm application, MFC, etc.
There are Windows compilers for Objective-C (the programming language used to write cocoa apps). However, Cocoa includes the frameworks for presenting the GUI. These visual frameworks are specific to Mac OS X because they use OS X only windows and other controls. So someone would need to re-implement the controls in Cocoa to use Windows controls.
Also, I am fairly certain that Tweetie uses Mac OS X only technologies like Core Animation. This does not exist on Windows, so the nice animation effects present in the apps would have to be implemented in a completely different way.