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, Joerg-Cyril.Hoehle@t-systems.com Joerg-Cyril.Hoehle@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.
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.
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? 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