I'm a total rookie when it comes to Objective-C so please bear with me...
Been thinking of learning the basics and trying out creating some software of my own. One thing that's bothering me (and never seem to show up as an alternative in any updates) is the ability to require a double-click in order to start an app in the Dock. I always seem to manage to click at the wrong place when switching between apps...
Yes, I am very well aware of Cmd+Tab thank you :) I really want this feature and it shouldn't be too hard to set up as long as overriding the default functionality of the Dock is possible. Thoughts/suggestions? Perhaps just a Terminal command is enough...
Related
For a fun winterbreak project, I'm trying to write a tool for mac that, depending on whichever application is currently in focus, will show all the appropriate Keyboard shortcuts. I'm still thinking about how it might work, as well as still looking around for info. But, I'm of course wondering whether or not there is even a streamlined format for defining keyboard shortcuts on mac. Does anyone have any light to shed here? I'm looking for plist's on my computer, but nothing is coming up, so I'm not sure that that is the proper solution.
Any ideas?
Thank you in advance, even for downvotes(:
I have a cross platform Qt application that's running into some trouble in OSX. There's a feature that OSX has that I didn't even know existed - the 'Help' key. My MBP doesn't have one, and neither does my Apple wired keyboard purchased a year ago. It seems that this is mostly something that older Macs have. Apparently it generates the same scan code as the Insert key on PC keyboards.
Anyways, when the Help key is pressed, the cursor over our application (or any application that receives the Help key event) turns into a little question mark. This seems to be part of what's called 'context-sensitive help mode', as documented in the NSHelpManager's setContextHelpModeActive: method and in the NSApplication's activateContextHelpMode: method docs. From the docs:
In this mode, the cursor becomes a question mark, and help appears for any user interface item the user clicks.
Most applications don’t use this method. Instead, applications enter
context-sensitive mode when the user presses the Help key.
Applications exit context-sensitive help mode upon the first event
after a help window is displayed.
How many Cocoa developers actually know about this? I'm assuming that clicking on something in the application with this question mark cursor should do something like bring up a help message, but I haven't found a single Cocoa application where it actually does anything at all - not even Apple's apps do anything. In fact, it even seems to put a lot of applications into a strange mode where the cursor text selection is enabled.
The problem is that when we change the application cursor programmatically in Qt when we're in this help-question-cursor-mode, bad things happen. Specifically, our application actually crashes. The crash happens deep inside Cocoa in the NSApplication's NSHelpManager. I'd like to find out why we're seeing this crash, but I'm actually more interested in how we can suppress this 'help' mode. There's nothing in Qt or Cocoa that I can see that would stop it, other than perhaps intercepting and squashing an event, which I haven't tried yet.
Does anyone know any more about this?
I'm in the situation where I love the Terminal.app of the mac, but I would love to add some further enhancements, like split views, terminal sets, etc.
Basically I tried to rebuild the Terminal.app with an NSTask/PseudoTTY approach which basically works but just doesn't feel and behave like the beloved Terminal.app itself. There's also no need to reinvent the wheel, I think.
So is there any approach to start an cocoa application (b) from another cocoa application (a) and manage the window or view of b from a? Like I have a ManageTerminals.app that start 6 Terminals and puts the views of them fullscreen in a grid, every instance being a fully working Terminal.app?
I found the SIMBL that basically allows to do something like that. At least the website says so. But there are no manuals or documentation available.
Does anybody have an idea how to accomplish this? I don't want to change an App, I just want to manage the size and appearance of the window/view on the screen.
Thanks for any ideas or concepts!
-- EDIT
I tried Apples ScriptingBridge now which almost does the job. There's just one little last step missing that might be a show stopper. Right now I have the following:
terminal = [SBApplication applicationWithBundleIdentifier:#"com.apple.Terminal"];
[terminal activate];
if([terminal isRunning]){
TerminalWindow *terminalWindow = [[[terminal windows] get] objectAtIndex:0];
view = (NSView*)[terminalWindow contentView];
}
Of course it's giving me an unrecognized selector, because there's no method to retrieve the view from the terminalWindow in the Terminal header. But if that was possible I could create x instances of my application and replug the view of the terminals to an own window that manages only the views.
Does someone know how to accomplish this, or do you think it's totally capsuled away?
You can launch an application with [[NSWorkspace sharedWorkspace] launchApplication:#"iChat"]. However you can't manage views. Youre only allowed to change the windows frame. AppleScript might help you here out. I've never used SIMBL before but theres a [wiki page][code.google.com/p/simbl/w/list]
You should probably take a look at iTerm which is an open-source terminal emulator for Mac OS X. You might be able to modify it to your needs, or at least see how a terminal emulator works via Cocoa.
Otherwise, you can use the Accessibility framework to control the position of other apps' windows. The user has to specifically allow this via the "Allow access for assistive devices" preference in the Accessibility pane of System Preferences.
Doing much more than that becomes more complex. Apple Events/AppleScript may give you the tools you need. I know Terminal has an AppleScript interface but I'm not sure how complete it is. I really don't recommend using SIMBL. This does allow you to inject your code into another app's memory space but since you would need to reverse engineer the other app you cannot guarantee stability.
I often see all this crazy stuff with Apple scripting, involving telling menus and menu items, and UI elements and all that crazy soft of stuff to do things. I don't mind that it's kind of a crazy way to get things done - as long as it works - but my question is this: How do you debug that stuff? I mean, how do you know what your options are?
I have apple script editor and script debugger, but I'm not sure how to use them to see what the options are. I've tried searching with google but I haven't come up with anything.
I do some web development so I'm used to using Firebug to examine the DOM of a web page, I just assume that there should be something easy and similar to help with Applescript.
Thoughts?
I'm not sure if you're asking how to script the GUI or how to tell which GUI elements are available in an application. If the former, try starting with Graphic User Interface (GUI) Scripting.
If you want to find out what the GUI hierarchy is for an application, check out UI Browser, which will allow you to see the UI elements of an application and provide the information you need to target one of them.
I'm writing a Cocoa application that installs itself as an menulet in the menu bar (i.e. like the volume or battery icons). When the program crashes, it isn't possible to use the Force-Quit dialog, because it doesn't show up in the list. Of course, I can still kill it using the command-line, but my users don't know how to do that. Is there any way to fix this, say by making the program show up in the Force-Quit dialog?
(Note: the app is Leopard only).
To be honest, the proper solution is to make sure your app never hangs or crashes for users. This should be your #1 priority, rather than figuring out how to let users deal with crashes and hangs. Obviously it isn't always possible to make sure your app never breaks in these ways, but it should definitely be the exception rather than the rule.
On another note, MenuExtras is a private API which I hope you aren't using to create your "menulet". Rather, the public class NSStatusItem (part of Cocoa) is the Apple-approved, recommended way to install icons into your menu bar.
Not really an answer, but hopefully helpful still ...
I think that most people who know how to force quit also know they can kill a process in the activity monitor. Just make sure it's not named '93AZkZ' or something.
You could provide a PreferencePane for your application that can send the proper signal to it, if you want to allow users an easy way to shut it down or restart it. This is the pattern that MySQL uses on OS X.