Re: winemac: Disable the zoom button for windows that are disabled.
Hi Kevin, As mentioned in the other thread, I'm not seeing the problem that this is meant to solve on 10.6. I will test 10.7+ tomorrow. Also, I'm pretty sure that setting the style mask after disabling the buttons can reenable them. At least in some versions of the frameworks, we've seen that -setStyleMask: basically resets the standard buttons from scratch. Indeed, in my testing, this patch reenables the close and minimize buttons on a disabled window. Regards, Ken
On May 12, 2013, at 3:22 PM, Ken Thomases wrote:
As mentioned in the other thread, I'm not seeing the problem that this is meant to solve on 10.6. I will test 10.7+ tomorrow.
OK, I've tested on 10.8 and I see that the zoom button highlights when the mouse moves over it, although clicking on it does nothing. I've also verified with a simple Cocoa test app. Toggling NSResizableWindowMask in the style mask does not seem to affect the zoom button. It works the same in the other direction, too. If the window starts without NSResizableWindowMask in its style mask, then adding it in later doesn't enable the zoom button. I've got some more tests I want to run. Oddly, the zoom button behaves properly on 10.8 with the Mac driver in CrossOver 12.x. That's because I handled disabled windows somewhat similarly to what your patch does, disabling the zoom button explicitly. However, I also disable the resize cursors at the edge by setting the max and min size for the window to the current frame size. We may need to go that route. I changed it for a reason, though, when submitting the Mac driver to Wine. I wish I could remember why. :-/ -Ken
I have submitted an alternative patch to fix this issue. It ended up being more involved. First, on considering exactly how disabling a window should interact with its resizability features, I decided that disabling should not remove NSResizableWindowMask from the style mask. Consider a window whose style mask is just NSTitledWindowMask | NSResizableWindowMask – that is, it's not closable or minimizable. If disabling it removed NSResizableWindowMask, then it would have no bits for the window buttons in the mask. So, the window would not display any buttons. That's not the correct behavior. Disabling should leave all the same buttons visible, it's just that they should be, well, disabled. Similarly for the resize indicator (a.k.a. grow box). The Mac driver currently hides it, but I may make that an option in the future. Anyway, if the window is resizable and the resize indicator is showing, then disabling it should not hide it, just make it unresponsive to clicks and drags. (That's how a Mac-native app behaves when a resizable window is behind a modal dialog, for example.) So, to disable the zoom button, I just access it directly and disable it as you did in your patches. However, we also need to disable the resize cursors at the window edges. So, I set the minimum and maximum sizes of the window to match the current size. (The resize cursors themselves don't show for non-main windows, but such windows can still be resized by Command-dragging their edges. That would work with regedit when its Import dialog is open had I not set the min and max sizes, which would be bad.) I encountered some difficulties in implementing the above strategy, however. Basically, -[NSWindow setStyleMask:] is pretty broken on 10.7+. It works properly on 10.6. This isn't related to disabling windows so much as to the Windows program changing the style such that the window changes its resizability. It turns out that adding or removing NSResizableWindowMask when neither of the other two buttons are present in the style mask does _not_ show or hide the buttons like it should. So, if you start with just NSTitledWindowMask and add NSResizableWindowMask, the window still shows no buttons. And if you start with NSTitledWindowMask | NSResizableWindowMask and remove NSResizableWindowMask, then the window does not hide the buttons. The workaround is to also toggle NSClosableWindowMask temporarily in that operation. That seems to force Cocoa to refresh its notion of whether the buttons should show or not. -Ken
participants (1)
-
Ken Thomases