On Mar 7, 2013, at 5:12 PM, Charles Davis wrote: > In the case that the window doesn't have its own grow box, though, it can be > hard to tell that you actually still can resize the window by dragging the > corner. (In notepad's case, it's weird, because I can click and drag the Down > button on the scroll bar to resize the window. It happens to be about where > the native grow box would have been drawn if it weren't turned off.) On > Windows, resizable windows have at least a thicker frame (THICKFRAME style), > and they usually also have the CLIENTEDGE and WINDOWEDGE extended styles > (giving the appearance of a frame that you can grab and drag to resize the > window). The Quartz window server precludes that with its pixel-thin border > and insistence that you grab the lower-right corner--at least, prior to Lion. > That's why I suggested changing the cursor to SIZENWSE at the lower-right > corner. I should really write a patch that does that :).
Yeah, maybe changing the cursor is right, although, again, the Windows app should be responsible for the cursor within its borders. The driver is responsible for how much of the window border shows or doesn't, though. See get_mac_rect_offset(). It may make sense to expose some of them if they're thick and resizable. Might look bad, though. >>> Why aren't we using Option as Alt? Nearly every Mac keyboard labels it as >>> "Alt" these days. Is typing characters like 'ü' and 'ø' and '∆' really that >>> important? :) >> >> Given the smiley, I can't tell if you're joking or not, > Yeah, I'm joking. I realized just how silly taking that away would be as I > was typing. >> but, yes, accessing additional characters from the keyboard layout is >> important. CodeWeavers' experience with support requests actually strongly >> influenced my decision to reserve Option for that. I'm open to introducing >> a registry setting to allow that to be changed. > > If we introduce a registry setting, should we also add a Control Panel > (something akin to Windows' Keyboard applet) or Preference Pane or something > to change it? I have considered a Cocoa preferences dialog accessible from the Mac menu bar. It would show and modify any future Mac-driver-specific registry settings, similar to winecfg's Graphics tab for the X11 driver. There would be a radio button to change whether it's working with the settings for just the current executable or all executables. Some programs, though, will run full-screen, making the preferences dialog inaccessible. So, winecfg would probably need to let users edit Mac driver settings, too. In that case, a preferences dialog is duplicated effort that maybe shouldn't be done. > And if we do, we may wish to include a Character Map (charmap.exe) utility so > users can insert additional characters anyway. No. The right solution is to integrate with Mac input methods, including the Keyboard Viewer and Character Viewer. I've been working on that. (CrossOver has an implementation which works with Asian-language input methods, but not with the viewers or palettes. It also doesn't support the press-and-hold mechanism introduced with Lion. I hope to support all of these.) > While we're on the subject of bugs: another annoying problem is that, when a > window is first created, the view appears black, and then the contents are > filled in. This happens even with minor windows like menus. (It happens with > the X11 driver too, just less often.) Yeah. Also, with the X11 driver, the windows are white before they're drawn rather than black, making the problem less noticeable to the eye, I think. The Mac driver is using a "pull" model to get the drawn bits from the window surface. The problem is that Cocoa asks us to draw as soon as the window is ordered on-screen, but the surface is still blank at that point. A short while later, the surface gets drawn (at least partially) and user32 tells us to flush. We tell Cocoa that the view needs to be redrawn and Cocoa asks us to draw, at which point we pull the drawn bits. My best thought for how to fix this is to simply defer ordering the window onto the screen until the surface is flushed. A similar problem arises when windows are resized, and the solution may be the same: defer the actual resize until the surface has been flushed. -Ken
