[1/3] Make mac driver the default on OS X

[Ken Thomases]

On Mar 7, 2013, at 12:03 PM, Charles Davis wrote:

> On Mar 6, 2013, at 7:56 AM, Ken Thomases wrote:
> 
>> On Mar 6, 2013, at 8:24 AM, <Joerg-Cyril.Hoehle at t-systems.com> <Joerg-Cyril.Hoehle at t-systems.com> wrote:
>> 
>>> Bug report:
>>> Toying around with built-in notepad, clock, winhlp32, I noticed that
>>> notepad and winhlp32 are not resizable, whereas the system
>>> preferences "control" is.  By comparison, with the x11 driver,
>>> notepad's window is resizable even though it has no triangle
>>> widget at the bottom left.
>> 
>> Works here™.  I can resize notepad and winhlp32 just fine.
> The problem is that the ability to resize windows by dragging their borders with the mouse was added in Lion. I'll bet Jörg is running Snow Leopard, where you can only resize windows by dragging the size box in the lower right (for me, anyway) corner.

I'm running Snow Leopard, myself.

> Except that many windows don't even have size boxes, even though you can still resize them by clicking and dragging their lower-right corner.
> 
> If a window doesn't have a size box already (usually, a status bar with the SBARS_SIZEGRIP style), we should add a transparent one ourselves on SL, similar to what Xplugin does. Or, we should change the cursor into IDC_SIZENWSE when the pointer hovers over the corner.

Alexandre specifically suggested that I suppress the grow box in the Mac driver since drawing resize widgets should be up to the Windows app, so that's what I did.  It's the call to [window setShowsResizeIndicator:NO] in cocoa_window.m.

Also, Jörg already was aware that windows may be resized when they don't show grow box, since he noted that there isn't one with the X11 driver.  So what he reported is something else.


>>> Also, the virtual desktop seems gone or not yet implemented.  This is a key
>>> requirement for enough apps that do not handle today's huge resolutions.
>> 
>> There is no mechanism for one Mac process to draw into the windows of another.
> But there is--an indirect one, anyway. You can have everyone else draw into an IOSurface, and then share the IOSurface with Explorer (which I assume is responsible for managing the desktop window). You can even use an IOSurface as a GL texture (and, by extension, render with OpenGL into the IOSurface). This is how Chrome (and probably Safari too, since it uses the same underlying engine) implements sandbox'd rendering: the renderer draws the page into an IOSurface, then the browser draws the IOSurface into the window. And yes, this will work on Snow Leopard.

I'm aware of IOSurface.  It's one of the shared-memory mechanisms I mentioned as being in consideration.  As always, patches welcome!  ;)


>>> Another annoyance was that there's no HIDE function or short cut and some
>>> dialogues do not provide the orange button (middle one) to iconify the window.
>>> As a result, those pesky windows clutter your screen.
>>> That alone is enough reason to me a reason not to use that driver. It is not
>>> acceptable that one cannot get rid of a set of windows!
>>> Example: wine control, then navigate to the root CA certificates.
>> 
>> More items can be added to the menus easily enough.  However, I'm loathe to assign the usual keyboard shortcuts.  The problem is that the Command key is used to generate Alt keystrokes and it's relatively likely that a Windows program will want to receive Alt-H for its menus.
> 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, 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.

And, yes, it sucks that the key is labelled Alt but can't be used as Alt. :(

-Ken