I'm trying to re-write an old image-viewing plugin for the mac. The old version uses QuickDraw (I said it was old) and resources (really really old) and so it doesn't work in Firefox 3.6 (which is why I'm re-writing it)
I know some Objective C, and so I figure I'm going co re-write this in that using new-fangled Mac routines and nibs, etc. However, I don't know how to start. I've got the BasicPlugin example that comes with mozilla source, so I know how to create a plugin with entrypoints, etc. However, I don't know how to create the nib, and how to interface Obj-C with the entrypoints, etc.
Does anyone know of a more advanced sample for mac than BasicPlugin.bundle? (Preferably simple enough that I can just look at it and understand it...)
thanks.
Sadly i don't really know of any good "intermediate" example. However, integrating Obj-C isn't that difficult. Thus, following is a short overview of what needs to be done.
You can use Obj-C and C/C++-sources in the same project, its just recommendable to keep them seperated to some extent. This can for example be done by letting the source file with the entry-points and other NPAPI-interfacing stay plain C or C++ files and e.g. forward calls into the plugin from there.
Opaque pointers help to keep a clean seperation, see e.g. here.
The main changes to your plugin include switching to different drawing and event models. These have to be negotiated in NPP_New(), here is an example for the drawing model. When using Cocoa and to support 64bit enviroments, you need to use the Cocoa event model.
To draw UI elements you should be able to use a NSGraphicsContext from the CGContextRef and then draw an NSView in the context. See also the details provided in this post and its follow-ups.
Related
I am writing a Mac OS X desktop application in which I want to be able to parse fragments of Objective-C such as variable and method declarations, as well as full Objective-C header and source files.
It looks to me as if I should be making use of Clang to do this, but I could do with some pointers and examples on how to integrate it as a library in my project, and how to invoke it to parse strings and files.
Can anyone provide me with any help on this?
You probably want libclang, code browsable at http://llvm.org/svn/llvm-project/cfe/trunk/tools/libclang/ (though you'll need to checkout the entire Clang repo to build it). There's very little documentation around on it, sadly. There is a presentation at http://llvm.org/devmtg/2010-11/Gregor-libclang.pdf that might help kickstart things, but mostly just some hunting through the code is the way to go.
Clang is actually more modular than libclang provides for (you can import just the components you want). If you've adventurous, there are examples at http://llvm.org/svn/llvm-project/cfe/trunk/examples/.
For the application I am writing, I need to access some other applications' items, for which Applescript seems the best way to go. I have been using the Appscript framework, which worked well, because it allowed me to thread it and not make my app lock up when an Applescript was taking a while. However, now I am attempting to make my application 64 bit compatible, and it seems like the Appscript framework does not support 64 bit. Is there a "good" way to use Applescript in Cocoa that will not lock up my application, but still give me the full control I need?
--firen
It seems like SBApplication should work, but I haven't used it before.
According to #cocoadevcentral:
SBApplication: use to make cross-application scripting calls with Objective-C instead of AppleScript. Ex: get current iTunes track.
Here is is the excerpt from the documentation:
The SBApplication class provides a mechanism enabling an Objective-C program to send Apple events to a scriptable application and receive Apple events in response. It thereby makes it possible for that program to control the application and exchange data with it. Scripting Bridge works by bridging data types between Apple event descriptors and Cocoa objects.
Although SBApplication includes methods that manually send and process Apple events, you should never have to call these methods directly. Instead, subclasses of SBApplication implement application-specific methods that handle the sending of Apple events automatically.
For example, if you wanted to get the current iTunes track, you can simply use the currentTrack method of the dynamically defined subclass for the iTunes application—which handles the details of sending the Apple event for you—rather than figuring out the more complicated, low-level alternative:
[iTunes propertyWithCode:'pTrk'];
If you do need to send Apple events manually, consider using the NSAppleEventDescriptor class.
Hope that helps!
As Blaenk mentioned Scripting Bridge may well be the way to go, although it can prove somewhat inefficient if you have to iterating through large arrays etc.
The simplest way to run an Applescript in Cocoa is using NSAppleScript.
Apple has some pretty good examples, which I found useful when I needed to do something similar. There are three articles you might want to take a look at. They all contain some sample code, which I always find very useful.
A Few Examples of using Scripting Bridge
Performance & Optimisation with Scripting Bridge
NSAppleScript Technote/Example
I created a gist with the full URLs as I can't post more than one link, what with being a newbie and all.
http://gist.github.com/130146
it seems like the Appscript framework does not support 64 bit.
Should work. Make sure you set the correct architectures and SDK (64-bit requires 10.5) in the Xcode project. File a bug report if you have a specific problem.
I've started programming on Mac OS X in Objective-C and decided to create a little card game. At first I create a command line version. If everything works fine I would like to implement a GUI: Nothing big, just a green window with cards which can be dragged and dropped.
Since I don't have any idea about how to do this: What can I use to implement my card game GUI?
Since Objective-C and Cocoa looks like a "bundle" on Mac OS X, is it possible to use Cocoa for this (and how)? If not, what else should I use or is there already sth. like this?
Regards,
inno
Apple has some sample code here that could point you in the right direction.
This is a fine study in MVC.
Your Model (an active game, player and non-player characters, the cards in the game, etc.) will be entirely in Foundation, at least at first. You can add AppKit-dependent properties such as images later, and use the C preprocessor to conditionalize that code if you want to continue maintaining your command-line program.
Your Controllers will also generally be in pure Foundation. I say “Controllers” because you'll have one for both programs (owning the model, responding to user actions, and running the game—that is, dealing cards, enforcing the rules, etc.), one specifically for the command-line program (holding the readline/output loop), and at least one specifically for the GUI program (owning the game window).
In the GUI app, you'll write your Views with AppKit, of course. In the command-line app, you may want to make a View class, separate from the Controllers, to make it easy to radically change the output quickly (even at runtime, if you want to allow that). Of course, that View will not descend from NSView, and will use terminal output instead of graphical drawing.
I recommend keeping the command-line version of the program alive after you make the GUI version, at least for a little while. You'll know you're doing it right when you can maintain both working versions of the program without much fuss, and even find a bug in one version of the program and fix it in both.
I would prefer to create my interfaces programatically. Seems as if all the docs on Apple Developer assume you're using Interface Builder. Is it possible to create these interfaces programatically, and if so where do I start learning about how to do this
I thought the relevant document for this, if possible would be in this section: http://developer.apple.com/referencelibrary/Cocoa/idxUserExperience-date.html
I like the question, and I'd also like to know of resources for going IB-less. Usefulness (the "why") is limited only by imagination. Off the top of my head, here are some possible reasons to program UIs explicitly:
Implementing a better Interface Builder.
Programming dynamic UIs, i.e., ones whose structure is not knowable statically (at compile/xcode time).
Implementing the Cocoa back-end of a cross-platform library or language for UIs.
There is a series of blog posts on working without a nib and a recent description by Michael Mucha on cocoa-dev.
I would prefer to create my interfaces programatically.
Why? Interface Builder is easier and faster. You can't write a typo by drag and drop, and you don't get those oh-so-handy Aqua guides when you're typing rectangles by hand.
Don't fight it. Interface Builder is your friend. Let it help you.
If you insist on wasting your own time and energy by writing your UI in code:
Not document-based (generally library-based, like Mail, iTunes, iPhoto): Create a subclass of NSObject, instantiate it, and make it the application's delegate, and in the delegate's applicationDidFinishLaunching: method, create a window, populate it with views, and order it front.
Document-based (like TextEdit, Preview, QuickTime Player): In the makeWindowControllers method in your subclass of NSDocument, create your windows (and populate them with views) and create window controllers for them, making sure to send yourself addWindowController: for each window controller.
As a completely blind developer I can say that IB is not compatible with VoiceOver (the built-in screen-reader on OS X).
This means that without access to robust documentation on using Cocoa without IB I cannot develop apps for OS X / iPhone in Cocoa, which means I (ironically) cannot easily develop apps that are accessible to the blind (and all others) on OS X / iOS.
My current solution, which I would prefer not to use, is Java + SWT, of course this works for OS X, not so much for iOS.
In fact IB becomes totally unusefull when you start to write your own UI classes. Let say that you create your own button that use an skin system based on a plist. Or you create an dinamic toolbar that load and unload items based on user selection.
IB doesn't accept custom UI elements, so more complex UI can't use him. And YES you will want to do more complex things that the UIKit gives you.
Though this is quiet a bit old...
I tried many times to do everything only with programmatically. This is hard, but possible.
Update:
I posted another question for this specific issue: View-based NSOutlineView without NIB?, and now
I believe everything can be done in programmatical way, but it's incredibly hard without consulting from Apple engineers due to lack of information or examples.
Below argument might be off-topic, but I like to note why I strongly prefer programmatically way.
I also prefer programmatic way. Because
Static layout tool cannot handle anything dynamic.
Reproducing same UI state across multiple NIBs is hard. Everything is implicit or hidden. You need to visit all the panels to find parameters. This kind of job is very easy to make mistake - mistake friendly.
Managing consistent state is hard. Because reproducing same look is hard.
Automation impossible. You cannot make auto-generated input form.
Parameter indirection - such as variable element size chosen by user - is not possible.
Aiming small point is a lot harder than hitting finger sized keys at fixed location - funny that this is serious usability issue for developers!
IB sometimes screws. Which means it's compilable, and still working, but when I open the source, it looks broken and extra editing becomes impossible. (you may not experienced this yet, but if XIB file goes complex, this must happen)
It's image based serialization. The concept is good. But the problem is image-base only. IB doesn't keep the source code for clean boot by replaying the source code. Clean boot is very important to guarantee specific running state. Also, we cannot fix the bugs in source-code. Bug s just will be stacked infinitely. This is core reason why we cannot reproduce the equal(not similar looking) UI state in IB.
Of course these stuffs can be solved by post-processing NIB UI, but if we have to configure everything again, there's no reason to use IB at first.
With text code, it's easy to reproducing the same state - just copy the code. Also easy to inspecting and fixing wrong part - because we have full control. But in IB, we have no control on hard-core details.
IB can't be ultimate solution. It's like a Photoshop, but even Photoshop offers text-based scripting facility. GUI is a moving program, and not a static image or graphic. An IB approach is completely wrong even for visual editing of GUI. If you're one of the Apple folks reading this, I beg you to remove whole dependency to IB completely ASAP.
I'm a complete Xcode/Objective-C/Cocoa newbie but I'm learning fast and really starting to enjoy getting to grips with a new language, platform and paradigm.
One thing is though, having been using Visual Studio with R# for so long I've kind of been spoiled with the coding tools such as refactorings and completion etc and as far as I can tell Xcode has some fairly limited built in support for this stuff.
On that note, does anyone know if any add-ins or whatever are available for the Xcode environment which add coding helpers such as automatically generating implementation skeletons from a class interface definition etc?
I suspect there aren't but I suppose it can't help to ask.
You sound as if you're looking for three major things: code templates, refactoring tools, and auto-completion.
The good news is that Xcode 3 and later come with superb auto-completion and template support. By default, you have to explicitly request completion by hitting the escape key. (This actually works in all NSTextViews; try it!) If you want to have the completions appear automatically, you can go to Preferences -> Code Sense and set the pop-up to appear automatically after a few seconds. You should find good completions for C and Objective-C code, and pretty good completions for C++.
Xcode also has a solid template/skeleton system that you can use. You can see what templates are available by default by going to Edit -> Insert Text Macro. Of course, you don't want to insert text macros with the mouse; that defeats the point. Instead, you have two options:
Back in Preferences,go to Key Bindings, and then, under Menu Key Bindings, assign a specific shortcut to macros you use often. I personally don't bother doing this, but I know plenty of great Mac devs who do
Use the CompletionPrefix. By default, nearly all of the templates have a special prefix that, if you type and then hit the escape key, will result in the template being inserted. You can use Control-/ to move between the completion fields.
You can see a full list of Xcode's default macros and their associated CompletionPrefixes at Crooked Spin.
You can also add your own macros, or modify the defaults. To do so, edit the file /Developer/Library/Xcode/Specifications/{C,HTML}.xctxtmacro. The syntax should be self-explanatory, if not terribly friendly.
Unfortunately, if you're addicted to R#, you will be disappointed by your refactoring options. Basic refactoring is provided within Xcode through the context menu or by hitting Shift-Apple-J. From there, you can extract and rename methods, promote and demote them through the class hierarchy, and a few other common operations. Unfortunately, neither Xcode nor any third-party utilities offer anything approaching Resharper, so on that front, you're currently out of luck. Thankfully, Apple has already demonstrated versions of Xcode in the works that have vastly improved refactoring capabilities, so hopefully you won't have to wait too long before the situation starts to improve.
I'm excited to say that JetBrains have decided to make a decent IDE for Objective-C coders.
It's called AppCode and it's based on their other tools like RubyMine and Resharper. It's not native Cocoa, but has loads of raw refactoring power.
http://www.jetbrains.com/objc/index.html
I've started using it for my main Objective C project and I'm already in love. It's still in it's infancy, but for code editing and refactoring it already blows Xcode away.
Update
It's now at a totally usable speed. I've switched over to it full time and it still blows my mind how amazing refactoring and coding is compared with Xcode. It just handles so much for you - auto importing, almost infinite customisation. It makes Xcode look like a toy.
Xcode has refactoring for C and Objective-C built in. Just select what you'd like to refactor, choose "Refactor..." from either the menu bar or the contextual menu, and you'll get a window including the available refactorings and a preview area.
Xcode doesn't currently have a public plug-in API; if there are specific types of plug-ins you'd like Apple to enable, file enhancement requests in the Bug Reporter. That way Apple can count and track such requests.
However, there are third-party tools like Accessorizer and mogenerator (the latest release is mogenerator 1.10) that you can use to make various development tasks faster. Accessorizer helps you create accessor methods for your classes, while mogenerator does more advanced code generation for Core Data managed object classes that are modeled using Xcode's modeling tools.
Just so people know, Accessorizer does more than just generate accessors (both 1.0 and properties for 2.0) it also generates Core Data code for persisting non-standard attributes, your NSSet accessors for custom to-many relationships.
In fact, Accessorizer will help provide you with the init, keypath, keyed-archiving, indexed accessors, accessors for unordered collections such as NSSet, copyWithZone, KVO, key-validation, singleton overrides, dealloc, setNilForKey, non-standard attribute persistence (Core Data), locking, headerdoc, convert method to selector, NSUndoManager methods and more.
I found some xtmacro files in Xcode.app package:
/Developer/Applications/Xcode.app/Contents/PlugIns/TextMacros.xctxtmacro/Contents/Resources
Installed Xcode ver. 3.2.5.