On May 15, 2013, at 8:49 PM, Kevin Eaves wrote: > … The title is also empty when exiting borderless to titled, which can be > fixed here.
Hmm, good catch. I'll have to check, but I suspect the window no longer remembers its title at that point. And the Mac driver doesn't currently store it anywhere else. So, we may need to do so in order to restore it. >> Also, if the Windows program changes a window from resizable to >> non-resizable, then we should probably pull the window out of Cocoa >> fullscreen. The Windows program _may_ have intended to make the window >> full-screen but we can't know that. It may simply be changing the window >> style for some other purpose, and that may make it no longer a candidate for >> Cocoa full-screen mode. > > Allowing Windows fullscreen in Cocoa fullscreen was never a very good idea. > I did not want to force the window out, but a borderless window would not be > allowed to enter Cocoa fullscreen, so it probably should not be there. Yeah. It may make for a poor user experience to force the window out of Cocoa full-screen, especially if it's just going to go Windows full-screen right afterward, but I think it's probably necessary. I think it's a relatively rare occurrence, anyway. >> I disagree. Windows programs that are not expecting their window to resize >> (because they haven't made them resizable) can misbehave badly if the window >> does resize. Just because that didn't happen in your testing doesn't mean >> it won't. >> >> As you mentioned in your original email, Cocoa full-screen is roughly akin >> to window resizing. So, it should be disabled if/when the window is made >> non-resizable. > > I do not see the reason to disable buttons and make the windows > non-resizable. Probably wrong here, but doesn't this just eliminate > click-through, which is typical of Windows apps, because the Windows paradigm > stinks? Well, that's how it works on Windows. And the X11 driver in Wine. And native Mac apps. (Open TextEdit. Its window has all the buttons enabled and can be resized. Open the modal Open dialog. The document window still has all its buttons and, on 10.6, the grow box, but they're disabled. On 10.7+, the resize cursors around the edge still show, but they're ineffective. I suppose we can achieve that same effect by not using the min and max sizes to prevent resize but do it by overriding -windowWillResize:toSize:, but I prefer it to be obviously not resizable.) The main reason is that some Windows apps will probably freak out if their windows get resized, closed, or minimized when they're supposed to be disabled. >> I don't follow this. It is possible to resize any window even non-resizable >> ones? To what are you referring? Possible how? Do you mean specifically >> just with this full-screen patch? > > It is possible to do anything we want with a window. The actual Windows > program not freaking out is another story. Just pointing out that we are not > limited. Sure, but Wine is aiming for compatibility with Windows apps, so the "not freaking out" thing is kind of a big deal. ;) -Ken
