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.
