Can I change NSScreen visibleframe? - cocoa

I trying to create a toolbar that docks on the top of the screen below the OS X menu bar.
I would like no other application's to be able to overlap my application when they are maximized. I can get the visible frame dimensions using NSScreen's visibleframe method, but can I adjust the visibleframe to omit the size and position of my application?

The simple answer is that no, you can't. I think that the only way to change the screen's visibleRect would be to inject code into AppKit and swizzle the method.
Even then, it might not do what you want because that method might not be what Apple uses to determine the "safe area" for windows and almost certainly would not work with Carbon apps.
Nothing you do with window levels will change this.
What you could do is use the Accessibility framework to reposition windows if you detect that their frames have changed such that they overlap your toolbar window. Unfortunately, I think you might need use polling for this.

Try setting your window's level to NSDockWindowLevel.
This may not work, depending on whether the system subtracts all windows on that level or only ever the Dock's window, but it's worth a try.

Related

Set the width of a scrollbar in wxWidgets on Windows

I'm looking for a way to set the width of the scrollbar in may class which inherits from wxScrolledWindow. I wouldn't mind editing the framework source code (3.1.0). I've looked there but I could not find the solution for my problem since the wxScrolledWindow and its base classes don't seem to use the wxScrollBar class.
You can't change the width (or any other aspect of the appearance) of the standard scroll bars, used for scrolling a window -- this is part of the native look-and-feel you get when using wxWidgets.
If you absolutely need to do something different (why?), you have no choice but to write your own scrolled window class using a plain window without scrollbars and one or two standalone wxScrollBars for scrolling it. Needless to say, this is going to be complicated and won't work as well as native scrolling, so you shouldn't do it unless you really can't live without this.

OSX maximum window height

A window can only be a certain height on OSX. It think this maximum height is: screenheight - menu bar height - title bar height - dock height (only if its visible).
Is there an easy way to get was this value is, or how do you get these values individually? Is this correct?
If You can use Cocoa try visibleFrame method of NSScreen class.
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSScreen_Class/Reference/Reference.html#//apple_ref/occ/instm/NSScreen/visibleFrame
see NSScreen visibleFrame
And screens
Register for and handle
NSApplicationDidChangeScreenParametersNotification
People use multiple displays, external displays and change their display preferences.
You'll also need to decide what to do about the Dock.
You also need to figure out the height when a window spans multiple displays.
Or if it should at a maximum size.
You'll want to consider window restoration handling.
You'll do well to consider handling sleep and wake notifications.
Lastly you'll want to test carefully. This isn't hard but there are a number of dynamics in play that your own setup may not reflect.
One more. Keep in mind that the OS will try to keep a small space for the Dock edge even when the Dock is hiding (left right or bottom) the NSScreen method accounts for this. On Mavericks it seems to be 4 points if I recall correctly.
You can make your app run with the Dock unavailable while your app is active and front. But doing so by API enforcement also hides the menuBar. If you need to do that, either do full screen or consider increasing the window level a lot. ( that's not as rewarding as it sounds but interesting to explore)
Lastly, this stuff changes sometimes in major OS releases. So expect that you may need to accommodate different OS versions.
A window can only be a certain height on OS X.
I could not find a reference to the limits of window sizes, but they are definitely less limited than the current screen size.
Windows can stretch over several (vertically) arranged screens or overlap the menubar and the dock.

Scrollable large NSDocument on Macbook Pro 13" XGA display

I'm having all kinds of trouble understanding how NSWindows can have larger documents than the window bounds in them.
Unfortunately, layout and contents prevents me from simply shrinking the document (and I wouldn't want to make the layout cramped for those with larger screens).
A school needs to run this app on their new 13", non-retina MacBook Pros. Scrolling is acceptable to them, but I'm unsure as to the approach, and I'd like your advice on the best way to handle this to avoid forced scrolling on larger screens.
I've tried setting the NSWindow min and max size and embedding the document in a Scroll View. But even though you can see part of the document view sticking out, no scroll bars appear (I have set them to Always in sys prefs).
If this is the way to go I would appreciate a link to a tutorial on this exact subject, because I'm a bit lost with all the measurements and options.
If not I'd like a pointer where to start and what to read. I'm experienced with Cocoa Touch but a relative newcomer to Mac development.
Without more information it sounds like you have embedded a NSScrollView but didn't set up the springs and struts properly to allow the scroll view to resize when its parent view (assuming it's the window) resizes.
You might want to check out Specifying a View’s Behavior as Its Container Resizes in the Interface Builder Help documentation.

Xcode Storyboard Zoom Magnification

I'm currently using the storyboard feature to position views. Due to the nature of these views, they need to be positioned with precision.
I'd like to view the Storyboard Scene/View in a magnification/zoom level greater than 100%, but it doesn't seem to be possible using the standard zoom in/out feature.
Is it possible to do this?
Note - I understand how to use the 'Size Inspector'.
It doesn't look like there is a way to do this, but there is at least one alternative that works fairly well:
Go to System Preferences > Accessibility > Zoom
Turn on the keyboard shortcut or scroll gesture
You should now be able to zoom in on any part of the operating system, including storyboards.
To make editing even easier, enable these options, some of which are found under More Options...:
Turn off Smooth images
Change Zoom Style to Picture-in-picture
Window Position: Follow mouse cursor
Cursor style: Crosshair
Enable temporary zoom
No, I am almost positive it is not possible to do this. You are stuck with 100% zoom. However, if you need great precision, you could try selecting the element you wish to move and use the arrow-keys to move the item around accurately.
However, like MacN00b, I do not use Storyboards a lot, so perhaps there is some top-super-secret setting buried somewhere.
This is one of the reasons I don't use storyboard but prefer good old fashion individual xibs. I don't think it is possible to zoom in past 100%, you may try double clicking on the background, I know that normally zooms in.

NSLevelIndicator - Cocoa

How would I be able to use a NSLevelIndicator? I am very new to this so, I don't know much on how to use a progress bar for my application.
You wouldn't use NSLevelIndicator for a progress bar. Check out NSProgressIndicator instead. It does both progress bars and "spinner" controls. NSLevelIndicator is used, for example, to show how full a disk is, or how much battery life is left in your wireless mouse.
You don't explain your level of experience. Assuming you have a window already created in Interface Builder, drag an NSLevelIndicator onto the window, create an outlet to it in your application, and set its value as needed. If you don't understand any of that, follow Apple's standard beginners' tutorial and start from there.
How would I be able to use a NSLevelIndicator?
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSLevelIndicator_Class/
how would I use a NSProgressIndicator?
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSProgressIndicator_Class/

Resources