Mac driver screen flicker on launch (Was: Re: [1/3] Make mac driver the default on OS X)
On Mar 8, 2013, at 6:20 AM, wrote: > 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 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
Re: [1/3] Make mac driver the default on OS X (try 2)
Josh DuBois writes: > Ken also noted that the error reporting could be simpler if it were in > gdi instead of user32. My impression, after having poked at it a > while with Ken, is that it is in theory possible that an application > which never tried to create a window would print less noise with the > errors being reported as they are here than it would if the errors > were reported directly from gdi, so that this may be superior because > it is quieter. However, I'm not an expert and if the rigamarole is > not worth the extra lines, I'm sure Alexandre will indicate so by not > applying this. It needs to be printed on window creation because of command line apps, but that's not a reason for doing something as ugly and complicated as this... -- Alexandre Julliard julli...@winehq.org
[1/3] Make mac driver the default on OS X
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
[1/3] Make mac driver the default on OS X
Hi, >> 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. 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
[1/3] Make mac driver the default on OS X
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. >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. See above. I used notepad etc. with wine-1.5.25. > 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. 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
Re: [1/3] Make mac driver the default on OS X
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
Re: [1/3] Make mac driver the default on OS X
On Mar 7, 2013, at 1:23 PM, Ken Thomases wrote: > 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, >>> 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. 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 :). > > 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! ;) Guess I'll get right to work on that ;). > > 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. >>
Re: [1/3] Make mac driver the default on OS X
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, >> 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
Re: [1/3] Make mac driver the default on OS X
On Thu, Mar 7, 2013 at 3:03 PM, Charles Davis 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,
--
Per Johansson
Re: [1/3] Make mac driver the default on OS X
On Mar 6, 2013, at 7:56 AM, Ken Thomases wrote: > On Mar 6, 2013, at 8:24 AM, > 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. 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. > > >> 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 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. > > >> 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? :) Chip
Re: [1/3] Make mac driver the default on OS X
On Mar 6, 2013, at 8:24 AM, 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
[1/3] Make mac driver the default on OS X
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
Re: [1/3] Make mac driver the default on OS X
On 3/6/13 12:24 AM, Ken Thomases wrote: As I believe you're aware, I think that the Mac driver should not be made the default until OpenGL and clipboard support are in. So, maybe this was just submitted in preparation for that time, but there should probably have been a note to that effect. Sure. Also, this patch seems exceedingly complex for a relatively simple problem. Just because it has historically been user32 that reported failure to load the driver doesn't mean it must remain so, at least to my way of thinking. Why not just print out the diagnostics directly in gdi32 as each attempt to load a driver fails? I figured it was that way for a reason, so I was trying to reduce noise in the case that fall-through drivers fail. Even with making mac the first thing we try to load, it seemed that a valid use was setting by hand to, e.g., x11,mac, with working X11 libraries and DISPLAY unset. But yes, it's more complicated: I don't care where they're printed. (The same is true for the ERR->TRACE bits in the third chunk - I certainly don't mind them both staying ERRs, or WARNs. I had interpreted the failure of those things differently until the point at which a window creation was attempted, but maybe that's wrong.) +case ERROR_DLL_INIT_FAILED: +load_err->err_msg = "Make sure you have permission to create \na window or check for errors with Console.app. \n(The Mac driver cannot do remote display: try X11 if you need that.)"; +break; Probably it's just best to say that the Mac driver is running in a non-GUI session such as a remote login. Well, if something in Apple's code fails, it's still likely they'll print to the console, yes? At any rate, I'm not attached to the error message. As for whether to print errors in gdi32 or user32, I don't feel strongly about that personally, either, but I'm curious what others think.
Re: [1/3] Make mac driver the default on OS X
On Mar 5, 2013, at 6:32 PM, Josh DuBois wrote: > --- > dlls/gdi32/driver.c | 102 +++-- > dlls/gdi32/gdi32.spec |1 + > dlls/gdi32/gdi_private.h |2 + > dlls/user32/driver.c | 27 ++-- > include/wine/gdi_driver.h | 11 + > 5 files changed, 125 insertions(+), 18 deletions(-) > > <0001-Track-and-report-multiple-errors-loading-display-drive.txt> As I believe you're aware, I think that the Mac driver should not be made the default until OpenGL and clipboard support are in. So, maybe this was just submitted in preparation for that time, but there should probably have been a note to that effect. Also, this patch seems exceedingly complex for a relatively simple problem. Just because it has historically been user32 that reported failure to load the driver doesn't mean it must remain so, at least to my way of thinking. Why not just print out the diagnostics directly in gdi32 as each attempt to load a driver fails? In user32, there can be a secondary, driver-agnostic message about failure to create a window. > +case ERROR_DLL_INIT_FAILED: > +load_err->err_msg = "Make sure you have permission to create \na > window or check for errors with Console.app. \n(The Mac driver cannot do > remote display: try X11 if you need that.)"; > +break; "Make sure you have permission to create a window" doesn't mean anything to me. Checking Console.app isn't very useful either. If the user sees this message, then they're already looking at wherever the process's output is going. Running Wine from a shell won't write anything to the console logs. As of Mountain Lion, running it from a GUI app won't either; Apple changed things so that stdout and stderr of GUI apps go to /dev/null rather than console logs. (Only things like NSLog() or asl_log() go to the console log.) Probably it's just best to say that the Mac driver is running in a non-GUI session such as a remote login. -Ken
