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

[Ken Thomases]

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.


> 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.  That's key to how the virtual desktop is implemented.  So, it's not really possible as things stand.  Alexandre and I have considered some sort of shared-memory mechanism, but it's barely into the conceptualization stage, let alone design or implementation.

Alternatively, we'd have to recreate X11 – a protocol for shuttling drawing operation requests from one process to another – to fix this.

I'm not sure it's worth it.  In my experience, the virtual desktop has more often been used to work around X window manager limitations.  The hope is that we have greater control with the Mac driver.  If all else fails, the X11 driver is still available.


> 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.  Or, perhaps, a game uses Alt for a player action (e.g. crouch) and H for another action and the user would end up pressing them simultaneously without even considering them a key combination.

My principle has been that only keyboard shortcuts that combine Command and Option should be used, since that's unlikely to be pressed by accident.  In the case of the Hide menu item, though, Command-Option-H would ordinarily mean Hide Others, just the opposite of Hide.

In any case, for the meantime, you can hide a Wine app from its Dock menu.


> The menu bar sometimes was refreshed badly, causing some texts therein
> to be displayed twice, shifted by a few pixels, or with varying fonts.

I'm not familiar with that, but it's not likely to be the fault of the Mac driver.  The Mac driver is not really a "graphics" driver.  It doesn't draw anything.  It uses Wine's relatively new client-side graphics implementation.  User32 arranges for the DIB engine to do all of the drawing and then just deliver bitmaps to the Mac driver for it to blit to the window.

Are you sure you aren't see the same thing with the X11 driver?

-Ken