Our (NSOpenGLView) application has two modes, one windowed and one "fullscreen" (the fullscreen behaves like the the new "fullscreen" feature of OS X Lion, so it takes the whole space, hides the dock and the menu becomes visible, if you drag your mouse to the top, and over the place where the dock is located).
In the windowed mode, a standard cursor is used, in the "fulscreen" mode, we don't render the system cursor, so on switch of the modes, we just toggle
[NSCursor hide]
[NSCursor unhide]
because in "fullscreen" we want to render our custom cursor in OpenGL.
Everything is ok, except the part, if the user moves over the the top, and the menu appears, or over the place where the dock is, and the dock appears, than the system automatically unhides the cursor which is on one place good, because the user can select from the top menu, but is also a problem as then the cursor is unhidden and both the opengl and the system cursor are rendered.
We tried various notification and delegate methods, to catch this situation and adjust the cursor visibility, but with no success.
Related
I am building a simple menu bar for my Pyglet app. I would like to stick the menu on the top left corner of the window, and also I would like my menu to have the same width of the window but fixed height.
So what I've done is to add a local_on_resize method that calls my menu resize method that performs all the necessary transformations.
def local_on_resize(self, x, y):
self.menu.resize(self.width, self.height)
and this method is pushed in this way in the window constructor:
self.push_handlers(on_resize=self.local_on_resize)
This seemed to work, as if I try to resize the window by dragging the borders of my window the menu gets resized correctly. The problem comes when I try to maximize/restore my window. In fact when I click on the maximize button the window gets maximized but I get a black screen (the menu bar disappears). However, if I try to click anywhere, or raise any event, the menubar reappears correctly. Same thing for restore button: if I restore my window, the menubar disappears but it gets back if I click on the window. So what I see if that the resize mechanism seems to work when I resize the window "continuously" by dragging it, but doesn't work when I maximize/restore it.
Does anybody know how can I fix this?
The project is to have a main window GUI with tabs, and the ability to tear off tabs into their own floating main windows. Exactly like the Chrome browser I'm using right now (probably most/all browsers do this). Using Windows 10, Python 3.7.7, PySide2 5.15.0.
I'm looking at similar questions here and elsewhere that use the native C++. They all seem to have one thing in common: Picking up mouse events on the tab.
I can create a subclassed QTabWidget and do all the things that pick up mouse events, for instance, putting a "installEventFilter()" in the class' "__init__()", and an "eventFilter()" function. Or simply overriding the "event()" function. I can pick up all kinds of events, including mouse events, but not on the tabs. Click/move in the tab view, yes; click/move next to the existing tabs on the tab bar, yes; but click/move on the tabs themselves produces "Paint" events. This is correct, as the tab view must be repainted when the tab is selected. But I can't pick up a mouse event for use in the dragging techniques I see in the C++ code. I can't pick up the mouse event that results in the Paint event.
Apparently, in native C++, the mouse events can be intercepted before they get to the tabs. I'm not seeing a way to intercept mouse events on the tabs in PySide2.
I've been looking for awhile now to no avail for this.
What I'm trying to do is find a way to detect if a mouse icon changes when you mouse over something.
For example: If you mouse over a link it changes from the arrow to a finger.
My plan is to grab the ID of a window, and scan it for clickable objects based on the mouse icon changing. I can grab the window, bring it to the front, and move the mouse around by setting the x,y coord of the mouse, but I don't see a way to detect if the mouse has found anything.
I would prefer this to be something built into vb.net, but if I have to use an API I'm fine with that.
The approach is wrong because the concepts are different from what you observe visually.
There's no such thing as "click" -- there's Button Down event (Windows message sent by the GUI subsystem to the application), Button Up event and Mouse Move event. If there were Button Down and Button Up with no or little Mouse Move, then the OS considers this a click.
All events are sent to the window under the mouse cursor hotspot unless the mouse input is captured by the other window.
When the cursor is moved over the window, the OS sends WM_NCHITTEST message to the window to determine, how the window treats the area under the cursor. Based on window's response Windows either performs the window operation (window move or resize etc) or passes mouse-related events to the window procedure. The procedure then decides how to react - do nothing, make visual changes, perform some action etc.
As you can see from the description, cursor change and actual actions are two different loosely related operations. There can be an action without cursor change or cursor change without an action.
Idea is simple(stolen from Ubuntu): autohide Dock when you drag window toward it and begin to overlap it. Turn autohiding off and show Dock when window is moved out of area when Dock is located.
What API can be used to achieve that ?
update:
managing autohide possible from command line this way but it's horrible
defaults write com.apple.dock autohide -bool true
killall Dock
Well, when the Dock is configured to (always) stay visible, the Window Manager will simply refuse to position the window directly under the Dock. It prevents users from putting stuff to where they can't reach. (Not every user is a power user; not every user knows the Dock can be hidden and since the Dock has no click-throughs...)
The system will hide the Dock when the app goes fullscreen. But, again, the system takes care of it.
Aside from directly mucking around with the user's Dock preferences (never change a user's preference for a third-party app behind their back!) like you mentionned; it can't be done legitematly.
There's is no API to control the Dock... at best, you can only suggest a tile to represent your app when present on the Dock.
I am building a Cocoa Mac application that runs in the background but has a main window.
To make it run in the background I've set "Application is background only" to "YES".
I built a system tray:
If you close the main window, you can re-open it by clicking "open".
I have however some issues with the layering of windows:
When I start the application, the main window opens however it appears in the background, behind any other windows or applications I have open at the time.
Clicking on "open" doesn't bring the window to the foreground. It opens it correctly if it was closed, however it stays behind any windows.
Clicking on preferences or about has the same issue. It opens the correct window but it appears behind any other windows.
On my main window there is a textfield. I can click on it, the cursor blinks as if I am ready to type. But when I type it actually types in some other background window! For example if I have TextWrangler open in the background, it will type there instead of the textfield...
Here is my code for handling the "open":
- (IBAction)show:(id)sender {
[NSApp activateIgnoringOtherApps:YES];
[window makeKeyAndOrderFront:sender];
}
Note that IF I set "Application is background only" to "NO" (which means I have a dock icon appearing), then clicking on "open" brings the window to the foreground as expected. And typing in the textfield works as expected.
Instead of background only, I think you want Application is agent (UIElement) set to YES. Background only is for application not intended to be visible for users.
Background only (LSBackgroundOnly YES) is intended for faceless background applications, Accessory (LSUIElement YES) is intended for background applications with a UI and status menu (menu extra/accessory menu/etc. - the name changes...).
An accessory will not appear in the dock, have a standard menu bar, or appear in the Finder's Force Quit dialog. It can be "active" and can have the key window.
Though it does not have a standard menu bar bizarrely (maybe a bug) if a MainMenu is declared in the XIB then it will respond to key shortcuts when it is active. To avoid this make sure you have no MainMenu or use [NSApp setMainMenu:nil] when you wish to disable the shortcuts.
The whole background/accessory/application/active/etc. area is not exactly well-defined, be prepared for "fun"...