I am writing Contextual Menu Plugins for Leopard OS and referring Writing Contextual Menu Plugins for OS X, part 1 article by Brent Simmons. My plugin is working fine.
Is there any way to move my test menu into main menu (above the Label)?
The short answer is "no".
The OS controls what gets displayed in that menu, so in order to change it around, you would need to call private methods, reimplement system-level functionality, and just in general do some Very Bad Things which would be unsafe, could break at a moment's notice, and possibly work differently between even dot releases of the same OS.
Yes, it's called a system service, and was introduced in OS X 10.5. I know for a fact that many applications can do this, and Automator routines can be triggered this way because Automator itself is a system service. To see a service applicable for an application (i.e. Finder) go to the Application menu on the top bar (for lack of better name T_T), such as the Finder bolded text, and go down to Services > and it will show you all services that can be used in the app. If you need pointers on how to build this, just comment here.
EDIT: Yes, a SIMBL plugin is also considered a service, and on second read of your question, that's what you want.
Related
Reading the book "The Spec UI framework". Trying to implement the part described in chapter "Taking over the entire screen".
After executing the code suggested in the book:
WindowExample new openWorldWithSpec
it seems to be impossible to return to previous state. Tried to delete the new WorldMorph in the inspector. Also tried with halos, as the book suggests but those buttons that are available in the halo menu don't allow it to be closed.
Is it an intended behaviour for this (to be executed to prepare an end-user environment and disable programming UI) or am I missing something?
Working in Pharo 5.0, Mac OS X version.
That is indeed intended behaviour, as part of making applications that do not allow access to the development environment anymore. But you can take a look at the code for PharoLauncher to see how you can enable a developer mode
You can actually get back to normal by:
Alt-Ctrl-Clicking on the Morph (macOS combo may be different, this is for Windows).
Clicking on the little wrench and ask for inspect.
In the evaluation pane, do:
self delete
World menu is available again.
Open a browser.
Done.
If one disables halos in settings, this is a tad harder.
As a OS X user, you must be quite familiar with the "New Documents" window when you start some Apple's apps, like Pages.
This window is so common, that I thought it must be some system-provided window, am I right?
I tried to mimic the window, and it turns out to be quite tedious. As a developer, I have to first create a finder-like browser view with list-style selection support. Also, iCloud integration is quite difficult not to mention search support.
So, my question is how can I implement this window, is there any documentation writing about this window? Big thanks!
Look at NSDocument. That is Apple's suggested way of creating document-based apps. You create a subclass of NSDocument to handle tasks specific to your data format, and the superclass handles all the heavy lifting, including iCloud support. I haven't used it myself, but I know that it handles open and save chores, so that's probably where the panel is coming from.
As it turns out, to get this window, all I need to do is to enable iCloud support in Capabilities tab of project properties page.
A little heads up: doesn't work for Swift in Xcode6 Beta. I don't know why to be frankly. And it took me a day to searching around...
I'm working on wrapping some Cocoa functionality in an Objective-C library that will be called from a cross-platform C library. One of my goals is to provide someone who does development in C on Linux with the ability to deploy to OSX without having to get into XCode, nib files, etc. I want them to be able to compile and link their code on OSX using the command line tools, and end up with a regular resizeable main window with the usual buttons and so on, an application menu and a dock icon that looks and behaves as expected, etc.
I'm working on OSX 10.8.5. I have XCode 5.0 installed. Here's my gcc --version output:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
I've figured out how to present a main window, how to set up the application menu, and various other things, programmatically, without using XCode or any nib or plist, but I've run into a problem with the dock icon.
I set a custom dock icon image by calling:
[NSApp setApplicationIconImage:dockImage];
When the user quits the app, the dock icon image reverts to something else (some kind of default application icon or view), briefly, before going away. How can I prevent that from happening without using XCode to create a nib or a plist?
I've tried setting the activation policy of NSApp to prohibitted in the app delegate's applicationShouldTerminate method, to try to hide the dock icon before this switch back occurs. That didn't help, it does hide the window and the dock icon, but the dock icon still switches back to the default icon, briefly, as part of the process of hiding. I confirmed this by returning NSTerminateLator, and confirming that setting the activation policy to prohibited does cause the dock and the icon to hide even though the app is not terminating, and not setting it leaves it unhidden.
I've tried subclassing NSApplication and overriding the setApplicationIconImage call. I have confirmed that it is being called a second time, by something other than my code (well, or not directly by my code, anyway), just before the program exits. I've tried preventing the second call to it from working by calling the super function the first time, but not the second time, and I've confirmed that code in that function can prevent my code from changing the application icon, but that didn't fix the problem. It still happens anyway, somehow.
I've also tried removing the application badge, like this:
[[window dockTile] setShowsApplicationBadge: NO];
just in case it was something to do with that, but that didn't work. The docs say that app badges are no longer relevant as of 10.6, but I was grasping at straws.
Being stumped on the programmatic front, I'm now trying to find out how to package an .app from scratch,without using XCode, and see if maybe I can create a plist from scratch that has a reference to application image in it. But a programmatic solution would be preferable, as I'd really like to minimize what goes into the OSX-specific packaging of a deployment.
Another possibility might be to use XCode once, to produce a very generic, bare-bones .app that my deployment scripts copy and alter.
Please don't shoot my question down as being "too broad" or "not constructive" or something like that. I realize I'm reinventing wheels that already exist in various forms, but there's no law against trying to build a better mouse trap, or just a different or even a worse one, for that matter. I realize I'm trying to fix a problem that a lot of people would consider inconsequential, but XCode-produced apps don't have this problem, and I really don't want the tools I'm creating to produce any user-visible artifacts like that. I'm not intending to diss Apple's tool chain or invite debate about whether or not what I'm pursuing should be pursued. I have a specific, technical problem that I'm looking for solution to that is within the constraints of my goals.
I would like to enhance the OS X Standard Save dialog with some features (add some controls).
DefaultFolderX actually achieved this
http://www.stclairsoft.com/DefaultFolderX/faq.html
.
They note:
"This means that Default Folder X loads a small piece of program code into each application's memory space (in RAM) so that it can communicate with Navigation Services, the OS X service that provides the Open and Save dialogs."
The question is, is this the easiest way to do this?
If yes, how would someone start on this endeavor (e.g. what kind of Project in Xcode, how to handle the "hook" mechanism if at all necessary, what documentation to read)?
If you want controls at the bottom of the open/save dialog in your app, the NSSavePanel and NSOpenPanel have a function where you can set your own custom view that will sit on the bottom of the dialog. If you want to modify the NSOpenPanels and NSSavePanels differently, or across the whole system, that will take a lot of work that might just break every time Apple updates their OS.
I am a newbie in Mac application development. I want to write a GUI application in Cocoa using Interface Builder. I want multiple screens i.e. when one button on a screen is clicked, another screen should be displayed. How can I activate a new screen at button click event?
I would heartily recommend Aaron Hilegass's book Cocoa Programming for Mac OS X. It took me from feeling like everything was impossible to being relatively competent in the space of a few short weeks. I was very impressed with it.
Apple's documentation is amazingly good, but it takes a while to get used to the style, and you will need to know which objects actually exist before you can look up how to use them, which is where Aaron's book comes in.
Your library may have a copy of it, or be able to order one for you if they don't.
I think you mean windows, not screens. Screens are the displays (monitors) on which all the user's windows from all the user's applications appear.
And I second Jonathan's recommendation of the Hillegass book.
The button has a target. That should link to the new window. As its action you can tell the window to show itself.
Take a look at:
http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/WinPanel/WinPanel.html
I think what you want is the type of interface like that seen in Coda, or System Preferences where there is a toolbar on the top of the screen that can be used to select between the content of the window.
The simplest method I have found is to use BWToolkit.
Another method is to use a series of views, and switch between them when the toolbar is clicked. I've found one description here, but that's not the one I used first (which may have been originally in Ruby Cocoa, IIRC).
NSTabView.