I wanted to know if it is possible to draw a window (like overlay window) or a shape (using cairo) such that, that window is the parent of root window.
It seems illogical to think like this, as root window itself means the root of all windows; but still I am curious if this is possible. If yes then what is the method for that.
Thanks.
No, it is not possible. The root window is the root of the window hierarchy.
Related
I want to build and editor, similar to many 3d editors out there, that has an opengl viewport somewhere in the window, and the rest of the window contains Windows controls. How do I do that? So far I managed to create a window that opengl renders to all of its area.
Although it is better to avoid rendering to the OpenGL window except via OpenGL, the controls are child windows in their own right, so there should be no problem simply rendering to part of the parent window (glViewPort can help with that). Windows will take care of drawing the controls "on top of" the parent window. Alternatively, you can create a child window of your own and attach the OpenGL context to the child window. Then you can render to the whole of the child window.
I am in the process of creating a small image editor.
What I aim, is to create a window with transparent titlebar, but not what contains inside the window.
I have check HUD Window, but it's really is a panel, not a window. And I am missing the regular close,maximize and minimize button.
Is there anyway to create such window?
Or can we modify HUD to hold regular close,max and min button?
Thanks so much in advance!
Eko
Use a standard borderless window approach and provide a content view that draws something. Even if the content view's bounds rect is just filled with [NSColor whiteColor].
Update: Re-reading, I see you seem to be asking for just a transparent title bare but still with the window controls. See this StackOverflow question for an approach at customizing a window's title bar. Careful, though - I'm not sure this would be accepted into the App Store. Best to have a backup plan in case it's not.
Here is what I found that match to what I want : window trasparency
The trick is making the main window transparent, but not the content by creating a special view for this.
I have a need to spawn a window that will hover just above my main window in a cocoa application. I want this main window to allow the user to enter some text in an input box. All is well until the text input box actually gains focus. The main window becomes "deactivated." This window is borderless and is a slightly custom shape -- its more like a hover card than anything else, I suppose.
Basically, I'd like this thing to work almost exactly like Spotlight (Apple + Space) -- you can enter text, but this is such an an ancillary operation that in the context of the greater UX, you don't want the jarring effect of the main window graying out (becoming inactive). You'll notice when you have some application open and in-focus, spotlight will not cause the window of that application to become inactive.
This problem arises because text input seems to REQUIRE that the child window become the key window (it will not let you place the cursor in the text input field). When it becomes key, the main window becomes inactive.
So far I've tried:
Subclassing NSWindow for my main application and overriding isKeyWindow such that it only loses key when the application is no longer the users focus (as opposed to the window). This had the unintended effect of colliding with key status of the child window and having very strange effects on the keyboard input (some keys are not captured, like delete)
Creating a view instead of a window. Doesn't work because of this problem -- you cannot draw over a Webkit WebView these days.
Anybody Cocoa/OSX wizards have any ideas? I've become a little obsessed with this one. An itch I can't scratch.
Edit: have also tried overriding the following on the child window. When clicked, the window makes the main application window become inactive.
- (BOOL)canBecomeKeyWindow {
return YES;
}
- (BOOL)canBecomeMainWindow {
return NO;
}
Edit 2:
After screwing about with NSMenu for a while, I scrapped that approach. It seems I found something, however. In NSPanel there is a window style mask called:
NSNonactivatingPanelMask
The panel can receive keyboard input without activating the owning application.
Valid only for an instance of NSPanel or its subclasses; not valid for a window.
Trying this out now...
Edit 3: NSNonactivatingPanelMask did not do the trick. No ideas.
What you want is a window that can become the key window but which cannot become the main window. You could implement such a class yourself, but this is basically what NSPanel is for, so you might try that first.
I think this can help you:
[self.childWindow makeKeyAndOrderFront:self];
How do I go about adding/removing the window border after it has been created? the window was already designed in interface builder and I would prefer to avoid writing the window purely in code as I am still a long ways before i can say i am experienced with objective-c/cocoa.
Example Program:
a single window with the border initially, a button on it. If you click the button once it makes the boarder disappear and if you click it again then the boarder reappears.
Thanks
As far as I can tell, you can't. You might be able to fake it by taking the content view out of one window and making it be the content view of another window.
Is there a way to preserve window position in Interface Builder? Every time I reopen a nib file, the MainWindow.xib window finds its way back to the top left of the screen, behind the window containing the interface I'm laying out. Moving it back to where I had it before every time is starting to get on my nerves. Seems like there should be an easy way to do this, but if there is I haven't been able to find it.
Thanks!
Interface Builder does not save window location/size on a per-nib basis, but it does automatically remember the size and position of the last nib window and uses that when opening future nib files. For example, if I open up nib file A, change its window's position, and then quit IB, then open up nib file B, its nib window shows up with the same location/size I had set for nib file A.
However, it appears that Interface Builder also cascades multiple windows down and to the right slightly when you open them up, so that a second nib file's window doesn't appear directly on top of one that's already open - makes sense. The problem appears to be that if you have a nib window positioned all the way at the bottom of the screen, so there's not enough room to open the next nib window, it results in the window being placed all the way at the top of the screen. Then of course once that happens, IB remembers that window position as the default, so subsequent windows also get opened at the top of the screen.
So, the "solution" is a) file an enhancement request on Bug Reporter to remember per-nib window positions :-), and b) in the meantime be careful about positioning your windows too close to the bottom of the screen.