Hi,
Ken Thomases wrote:
I think that the Mac driver should not be made the default until OpenGL and clipboard support are in.
Exactly :-(
Following Josh DuBois explanation about HKCU/Software/Wine/Drivers "Graphics"="mac,x11" I decided to give it a try over the week-end and was very disappointed to see that seemingly *not any* app would run. It took me some time to understand that they all want graphics. Please don't waste the user's time when such "basics" don't work.
What you can do is post to wine-devel and the user forum, asking for people to test your work. That would be polite.
Josh DuBois wrote:
I propose an environment variable, WINEDRIVERLOADORDER
Too generic. Include "DISPLAY" into the name, if at all, e.g. WINEDISPLAYDRIVER, or "GRAPHICS" as in the registry. The winepulse driver might face similar issues. I have not looked how Maarten thinks that it may coexist nicely with winealsa.
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.
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.
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.
The menu bar sometimes was refreshed badly, causing some texts therein to be displayed twice, shifted by a few pixels, or with varying fonts.
Regards, Jörg Höhle
On Mar 6, 2013, at 8:24 AM, Joerg-Cyril.Hoehle@t-systems.com Joerg-Cyril.Hoehle@t-systems.com wrote:
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.
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
On Mar 6, 2013, at 7:56 AM, Ken Thomases wrote:
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. 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.
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 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.
True. Anyone who'd even bother to set up a virtual desktop would probably be willing to go to the trouble of installing XQuartz anyway.
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? :)
Chip
On Thu, Mar 7, 2013 at 3:03 PM, Charles Davis cdavis5x@gmail.com wrote:
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? :)
Yes, they are. But even more importantly, most of us Europeans also need it to type [, ], {, }, ~, |, etc. Even @ is option-2 for me.
Regards,
On Mar 7, 2013, at 12:03 PM, Charles Davis wrote:
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.
I'm aware of IOSurface. It's one of the shared-memory mechanisms I mentioned as being in consideration. As always, patches welcome! ;)
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
On Mar 7, 2013, at 1:23 PM, Ken Thomases wrote:
I thought he was referring to the Windows size grip--the one that you get when you put a status bar Common Control at the bottom of your window and give it the SBARS_SIZEGRIP style.
There is a white grow box for me in the lower-right corner when I use the X11 driver. He must have been using a different WM than the default quartz-wm.
If my diagnosis was inaccurate, then I wonder why he really couldn't resize the windows by dragging the corner... I don't have trouble resizing the windows, either.
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 :).
Guess I'll get right to work on that ;).
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? And if we do, we may wish to include a Character Map (charmap.exe) utility so users can insert additional characters anyway.
And, yes, it sucks that the key is labelled Alt but can't be used as Alt. :(
-Ken
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.)
Chip
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.
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
Hi,
Charles Davis wrote:
While we're on the subject of bugs: another annoying problem is that, when a window is first created, the view appears black
I had a very annoying experience: when I started winemac the first time, the whole screen turned black for a fraction of a second. That was very unwelcome and reminded me of the infamous Intel-XOrg screen flickering issue that plagued many Linux distros a few years ago :-(
I'll bet Jörg is running Snow Leopard
Indeed, with newest updates (10.6.8). Note that I'm running Apple X11, not XQuartz. While that X11 server version is older that the 2.6.3 that I used on Leopard 10.5.8, it's nevertheless newer than the first XQuartz that I used with Wine after I got my "early 2009" nVidia Mac Mini 3 years ago. For the moment, I've decided to stick to Apple X11 and see how far it goes.
See above. I used notepad etc. with wine-1.5.25.
You all embarked on the Cmd/Alt-H issue. A menu, even without short- cut, would be nice to have.
Regarding the Alt key, XQuartz has some keyboard configuration option in its settings menu. Maybe winemac should provide a similar choice, such that X11 and winemac provide identical behavior and ease switching?
Regards, Jörg Höhle
On Mar 8, 2013, at 6:20 AM, Joerg-Cyril.Hoehle@t-systems.com Joerg-Cyril.Hoehle@t-systems.com wrote:
I have tracked this down.
Unless explorer.exe is launched explicitly, it is launched on demand. Inside user32.GetDesktopWindow() there's a check if the desktop window exists. If it doesn't, then explorer.exe is launched.
There is a race, of course, if multiple processes or threads call GetDesktopWindow() at roughly the same time before the desktop window has been created. All of them start explorer.exe.
Explorer.exe creates a window that it intends to act as the desktop window. It then checks if that window actually became the desktop window. If it doesn't, it figures some other instance of explorer.exe won the race, destroys the window, and exits. Only one of the explorer.exe instances survives and it owns the real desktop window.
The flicker is the prospective desktop window of the losers. The windows are created visible, so they are briefly shown before being destroyed.
(The real desktop window is also created visible but it doesn't usually show unless virtual desktop is enabled under X11. That's because both the Mac and X11 drivers have checks for the desktop window and treat it specially. But only the real desktop window, from the winning explorer.exe, qualifies for that special treatment. The windows from the losers are just normal windows.)
I think the solution is to have explorer.exe create its prospective desktop window hidden and only show it if it wins the race. I'll submit a patch shortly.
-Ken
Hi,
I completely disagree. I start *all* games with a virtual desktop. Here's why.
When I sarted on the Mac 3 years ago with Wine, xrandr was not available, so the only full screen resolution was the monitor's full 1600x1200 (or rather 1178). None of the full screen games would work with that, they were expecting 800x600, 1024x768 or 1440x1050.
As a result, I started each graphics app with a virtual desktop in a resolution that would make it work well. Initially I considered this solution to be inferior to the full screen we all know from X11 on Linux, however I very soon got used to it. Actually, it's very nice to run all games in a window and it works pleasantly well. E.g. Motocross Madness' maximum 1440x1050 window leaves enough room within 1600x1200 for the activity monitor and a few other displays. Wine manages well to keep the mouse within the window when needed, and there's always Cmd-Tab to switch to another app.
A shared screen is also easier than having to remember the ctrl-alt-a or whatever key that can toggle between the Apple and X11 screens.
At some time, XQuartz added xrandr support. I was not satisfied with it, as I soon found out that while some games may work with the full 1600x1200, they would not display their intro videos that expected a 800x600 screen or worse, would crash at the intro. Also, I did not want apps to switch my monitor's resolution to meager 800x600. The resizable virtual desktop still gives best results: it opens a 800x600 window for the intro videos, then resizes during game. Motocross Madness' menu screen is a fixed 640x480 IIRC and it's only during race that it will resize to 1440x1050.
From today's perspective, I don't always want a full screen 640x480. Actually, it depends on the app. Some apps benefit from the monitor's scaling to full dimensions. Some zoomed content looks awful on today's huge monitors. Some 1024x768 apps look like postal stamps inside a large screen whereas other 1024x768 window contents looks good. The virtual desktop puts the choice in the user's hands.
Sometimes I've used Leopard's zooming feature (cmd-shift-8 IIRC).
Also, with apps as windows, the children can iconify them anytime and start a browser, or go and eat, then resume later, trivially.
Regards, Jörg Höhle
I wrote:
The [notepad] menu bar sometimes was refreshed badly, causing some texts therein to be displayed twice, shifted by a few pixels, or with varying fonts.
That looks much like bug #33154 http://bugs.winehq.org/show_bug.cgi?id=33154 filed about Linux/X11. Nothing specific to winemac -- at least the "shifted by a few pixels" part, I'll have to check again about the "varying fonts" issue (boldface might result from shifting by one pixel).
I believe Daniel Jelinski expressed the issue well in #32334: http://bugs.winehq.org/show_bug.cgi?id=32334#c19
it seems that it also made calculating text extents inconsistent with drawing text.
Somehow it feels strange that Wine's built-in notepad application would depend on a metrics-compatible Tahoma font. Compatible or not, Wine should probably compute sizes aka. extents consistently.
Regards, Jörg Höhle
-
Charles Davis -
Joerg-Cyril.Hoehle＠t-systems.com -
Ken Thomases -
Per Johansson