I want to whip something up that would run a small script every time i clicked on the Desktop. Any hints on how to make this happen?
For those interested, the script would toggle the display of desktop icons.
I assume you mean on the desktop background, not any icon. You could create a transparent overlay window, use [window setIgnoresMouseEvents:NO] to make it receive clicks, and set its window level to something between the desktop and the icons (kCGDesktopWindowLevel and kCGDesktopIconWindowLevel).
You would presumably want to create one of those per screen and monitor for changes in the screen configuration to add, remove, or resize them as appropriate. Either observe the NSApplicationDidChangeScreenParametersNotification or implement the -applicationDidChangeScreenParameters: application delegate method (which amounts to the same thing).
Related
I am running a game that has buttons on both sides of the screen, which gives you an easy control on a tablet. But on ARC it makes it difficult to use because you need to move your mouse across the screen a bunch of times. Does ARC Welder have an option to make a key on the keyboard "tap" a certain place on the screen?
If you are comfortable with the concept of scripting, you could use AutoHotKey to use keyboard events to click specific areas of the screen. This would be through your OS, not the ARC, but I think the script can be linked to a specific application so it will only run with that app.
See specifically Click
Imagine I save my window's position in my preferences file. Now, the user moves the window to a second monitor, then quits my app. Then he disconnects the second monitor and launches my app again.
Now my app wants to restore the window's saved location. But if it blindly restores the old window coordinates, the window will be off-screen.
I used to use ConstrainWindowToScreen for my Carbon app, but now that I'm porting it to Cocoa, I can not find an equivalent for this.
The docs suggest that, somehow, Cocoa would automatically prevent this from happening. While that might be the case when the monitors change while the window is open, in my case where I've stored the window location myself and restore them when I re-open the window at launch, this isn't going to work. I need to invoke Cocoa's magic functionality on demand, but how?
(Note: I am aware that I could iterate over all available screens, but that's quite a pain to write myself if I want to get this foolproof. Still, if you can present a complete C or ObjC function that solve it this way, that'd be appreciated, too.)
See the "Managing Window Frames in User Defaults" section in the NSWindow Class Reference. Those methods ensure that a window will be placed entirely on screen.
If you want to save and restore the window location yourself (as a string), use -stringWithSavedFrame and -setFrameFromString:.
Use -saveFrameUsingName: and -setFrameUsingName to have NSWindow save and restore its frame in the user defaults, given a window name.
I agree with Darren's suggestion to use the built-in mechanism for restoring window positions. Really, it's as easy as setting a window's frame autosave name in IB (or with -setFrameAutosaveName:).
That said, if a window has a title bar, then all of the methods which order it onto the screen (e.g. -orderFront: or -makeKeyAndOrderFront:) will automatically reposition it to make sure at least the title bar and a significant chunk of the window is on the screen. It's honestly difficult to get a titled window to be theoretically visible but actually off-screen.
I have a desktop application written in Ruby that is using GTK2. It's just a small test application to play with GTK2, but I'm having problems achieving what I want to do. Is there any way using GTK2 to get at the titlebar (apart from setting the title), specifically to either add a button to it (beside the min/max/etc, B in the below diagram) or to add an option to the menu that pops up when you click the icon on the titlebar (A in the below diagram)?
I'm thinking there might not be because GTK is meant to work with many many different window managers, but I just wondered if there was. As a side question, what event does clicking the 'cross' button fire? At the moment if the user clicks that the window disappears but the program doesn't end - I need to capture that event and quit the program.
Thanks for any help, including hitting me over the head and telling me how silly I am.
Note that this is possible in GTK 3.10 and up, by using gtk_window_set_titlebar(). It replaces the window manager's title bar with a custom one. GtkHeaderBar is a good custom title bar class to use.
You can't, however, make it look just like the window manager would, because you won't know which window manager the user is running.
No, the title bar is owned by the window manager and you will typically not have direct access to it.
When the user tries to close the window by clicking the window manager's button, the window will receive the delete event.
I need to host my window upon a window of another application.
How to enumerate windows of another Cocoa application? Is it possible to control
them?
If no: how can I draw upon a window of another application?
Thanks!
How to enumerate windows of another Cocoa application?
You can enumerate the windows of another application using the Accessibility API. It doesn't matter whether that application is Cocoa or not.
Is it possible to control them?
Here, it does matter, indirectly, whether the application is Cocoa (or Carbon using standard controls). More precisely, it matters whether the application is accessible.
It usually is possible to move another window, resize it, or do simple things with controls in it (such as press buttons).
It is not possible to tape one of your windows to a window in another application. You will have to observe its location and move your window when the other moves. Following a live drag this way is not possible.
If no: how can I draw upon a window of another application?
You can't. You can only draw in your own windows.
You can make a transparent overlay window and draw on that, but that gets you back to the problem of taping one of your windows to a window in another application.
You should probably ask a broader question about whatever it is you hope to achieve by taping one of your windows to a window in another application or by drawing into a window in another application.
Checkout CGWindow.h
CGWindowListCreateDescriptionFromArray() is probably what you're looking for.
Cocoa does not support reparenting of another application window, or drawing on it.
But, there're two ways to get windows attributes for all the applications, like position, size, z-order, etc.
Accessibility API (also allows to control a foreign application window: move, resize, press buttons on it, etc.). If a foreign application does not support Accessibility API, then...
Quartz Window Services and a sample code for them, called "Son of Grab".
I would like to show the user a splash screen (a picture) while my Cocoa-based application launches. How would this be possible?
First thanks a lot. because my app running for a while time , so I want to show a splash before app running . Now if I show a window inside with a image , after that how to run the app? How to make sure that the app running after the splash showing ? How to do to get the sequence ?
First Thank you very much. And I show the window in applicationWillFinishLaunching method use orderFront,then hide it in applicationDidFinishLaunching: use orderOut,Now I found that the mainWindow not to show and the app terminate ,why ? How to do to resolute this question? Thanks!
Although Peter's answer is ultimately correct (you should rewrite your app to launch faster), sometimes that's not a practical option. For example loading code later in the application may take too long (e.g. a data acquisition application), forcing it to be loaded at startup. If you decide that you want to show a splash screen, the easiest way is to show it in the application delegate's applicationWillFinishLaunching: method. Create a splash window in your applications MainMenu.nib and add an outlet to your app delegate referencing that window. You can then put the window onscreen in applicationWillFinishLaunching: and hide it in applicationDidFinishLaunching:. Note that the main thread's NSRunLoop is not iterating during this time, so if you want to update the splash screen (with status, a progress bar, or such), you'll need to manage those redraw events yourself.
Again, think very hard about whether the long startup is necessary. If it is, showing a splash screen with a progess indicator is the minimum that you owe your users.
Why do you hate your users?
Seriously, don't do this. Don't make your users wait to use your app. Make your app launch quickly instead.
(And just in case you insist on an answer: Show a window with the image in it, then hide the window when you feel the user has waited long enough.)
Just put up a window with the image and close it when you are done with your launch initialization.
Barry's answer above does not seem to work for document-based apps. Showing a splash window within applicationWillFinishLaunching: interferes with the startup sequence of the app such that the document window isn't created. I've uploaded an example project here. In applicationWillFinishLaunching:, comment out [_splashWindow orderFront:self ] and the document window will come up.