i'm talking about the "zoom" functionality in the universal access system preference panel. normally this is accomplished with command–option–8. then the zoom controls are command–option–+ (magnify) and command–option–- (minus/minify).
my most recent attempt involved sending the keypresses for the shortcuts as events. however this approach has serious bugs. on top of that, i don't know whether the user already has zoom enabled. i'm looking for something cleaner. like, the way you're supposed to do it.
of course there is always using applescript to open the system preferences pane and toggle the radio buttons, but that is not really what i would call "clean."
even if you don't know exactly how to accomplish what i'm asking, even some pointers as to where this kind of thing (programmatic toggling of os functionality) might be documented would be helpful. the language doesn't matter. thanks.
it's not quite what i wanted, but UAZoomEnabled() in /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Headers/UniversalAccess.h lets me know whether zoom is currently enabled. then i know whether to send the command-option-8 keystrokes using CGEventCreateKeyboardEvent(), CGEventSetFlags() and CGEventPost(). in order to make sure that they're zoomed in 10 ticks, i zoom out 100 ticks, then zoom in 10 ticks.
source: http://lists.apple.com/archives/accessibility-dev/2011/Mar/msg00013.html
Related
It seems scrollWheel: has to be it, for receiving these. Unfortunately the trackpad's scrolling deltas are orders of magnitude higher than a mouse's, so the scroll speed is psychotically high. Ergo I need to distinguish them so that I can apply an appropriate dampener.
The docs perplexingly note that while you usually do this by checking NSEvent's subtype, in scrollWheel: specifically that doesn't work. But they don't say what you should do. Experimentation has shown me that while trackpad scrolls are indeed not correctly typed as NSTouchEventSubtype, their type is different from mouse wheel scrolls - NSTabletPointEventSubtype vs NSMouseEventSubtype. The problem is, NSTabletPointEventSubtype is also what's used for genuine tablet scroll events, and the deltas in those are even more ridiculously high. So I need to distinguish those too.
NB: Similar prior questions include this, where the only suggestion was inference based on an undocumented API, or others featuring similar hacks. Some seem to be recommending that you ignore scrollWheel: entirely and track touch events manually, but that seems to be a lot of redundant work that might break in future OS releases.
I believe [event hasPreciseScrollingDeltas] is what you're looking for. It's available in OS X 10.7.
I previously asked a question about changing the cursor system-wide on OSX. I used NSCursor to change the cursor, but the effects are only as long as the application is active. When another application becomes active, the custom cursor is lost.
Here is a related, more general question. How can you write an application to have system-wife effects? For example drawing an image on-screen even when your application is not active, and something else is?
I understand I probably need to go at a lower level than the Cocoa APIs. I just cannot figure out where to start looking? Any specific Carbon APIs that I need to be looking at? Or even lower?
Any pointers would be appreciated! If you specifically know how to change the cursor system-wide or how to draw an image and move it around (no matter what application is active), that would solve my current problem as well! Can I write an application that can achieve this when its installed on the system?
Thanks!
You can achieve the effect you want, but not the way you're thinking about doing it.
You say,
I am writing a presentation aid application that shows the equivalent of the "laser pointer" on screen, programmatically. My first idea was to use the mouse cursor itself as the pointer, and change its appearance as a red circle.
Then fake that. Create an application, perhaps of type LSUIElement, perhaps not, depending on the behavior you want. Create a borderless window (type NSBorderlessWindowMask) and fill it with a clear color. Set its window level high enough so that it floats over everything (using -[NSWindow setLevel:], though I can't think of what the best level would be off-hand), and draw into it.
It's true that you cannot set the cursor when you are not the foremost app. It's true that you cannot just scribble on the screen. But you can get the same effects if you're clever.
This behaviour is not provided by any APIs on Mac OS X. You would have to modify the resource files in the OS, and that's a very dangerous operation that could brick the target computer. You have to know what you're doing.
Are you trying to implement a theming app or something like that? What's your goal? If you tell us what you are trying to do, we may be able to suggest alternate approaches.
I want to put help buttons on all my windows, like this:
But when I put the help button in, the minimize/maximize buttons disappear. Does Windows forbid having the min/max buttons together with the help buttons? That would be disappointing because that would mean I could put the help button only on dialogs and not on frames.
If Windows does forbid this, it would be nice to see an official Microsoft document which talks about this policy.
It is not possible through setting windows styles. If you really wanted to you could set some hooks that would probably let you do what you want, but I would not recommend doing that. You can mimic the functionality of the help button by sending the WM_HELP message.
According to MSDN, the styles WS_MAXIMIZEBOX and WS_MINIMIZEBOX can not be combined with WS_EX_CONTEXTHELP.
Although it is true what daalbert says, with some effort it is indeed possible to draw just about anything properly on the window frame. Of course this is in no way "official" and the limitation that daalbert mentions still stands.
You can listen for WM_NCPAINT and draw the button yourself with the help of DrawFrameControl with DFC_BUTTON (which makes sure it will look like the real thing). Use WM_NCHITTEST and friends (WM_NC*BUTTON*) to find out whether the button you draw gets clicked.
So yes, it's technically possible to achieve what you want but usually not worth the extra effort.
Just wanted to have this on record for completeness.
Although I have a feeling that this isn't technically possible, it's worth asking anyways. Is it possible to turn on the Macbook Pro's keyboard backlights for individual keys? I am working on a piece of grid-based software which allows the user to navigate around by pressing any key on the keyboard to position the cursor at that point in the grid. It would be very cool if I could somehow just turn on the backlight for certain keys to give the user an easy way to see the current position of the cursor.
Is it even possible for an application to control the keyboard backlighting at all, let alone for individual keys?
Yes, on programs controlling the backlight.
iTunes visualizer that pusles keyboard backlighting to music:
http://www.youtube.com/watch?v=LUXLkwlF9e8
How to manually adjust (via plugin):
http://osxdaily.com/2006/11/30/how-to-manually-adjust-the-macbook-pro-keyboard-backlight/
Not sure on programs controlling individual keys, but as that would require additional hardware to be installed on Mac's part, i doubt it.
Well after trawling the webs, it looks like the answer to that is no. But I'd like to point out that each key does have its own key- a tiny little LED (same kind they use under phone keypad buttons). Also, I've seen some people saying that flashing these lights on and off repeatedly is bad for them. Bullshit- all digital electronics control light output from LED's by flashing on and off many many times a second. Read up on PWM on wikipedia or something..
Anyways just had to get that out there :)
Thanks,
Nic
How would I go about implementing something along the lines of "scrubby sliders", like in Photoshop and quite a few other image-processing applications?
They are slightly hard to describe.. basically you have a regular numeric input-box, but you can click-and-hold the mouse button, and it functions like a slider (until you release). If you click in the box, you can select text, edit/paste/etc as usual.
The Photoshop docs describe it, and I put together a quick example video (an example of the sliders in Shake)
Another similar implementation would be the jog-wheel in Final Cut Pro, which functions similarly, without the numeric readout being underneath.
I can't seem to find any mention of implementing these, although there is probably alternative names for this. It is for a OS X 10.5 Cocoa application.
It is for a colour-grading application, where a user might need to make tiny adjustments (0.001, for example), to huge adjustments (say, -100 +100) on the same control. A regular slider isn't accurate enough over that range of value.
Copy-and-pasting values into the box would be a secondary concern to scrubbing the values, and the Photoshop/Shake setup really well. The unobviousness of the control is also of a low concern, as it's not a "regular desktop application"
I've encountered those. They suck, because they prevent the user from dragging to select the text of the number.
A better idea would be a miniature slider beneath the field that expands to a full-size slider when the user holds down the mouse button on it and collapses back to its miniature size when the user releases the mouse button. This way, the selection behavior is still available, but you also provide the slider—and in a more obvious way.
There's no built-in class in Cocoa for either one. You'll have to implement your own.
I doubt that this exists in Cocoa framework. As far as I remember it is not mentioned in the Apple Human Interface Guidelines.
You can develop one yourself by using a custom view and tracking mouse events (-mouseDown:, mouseUp:, -mouseDragged:).