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.