On Sun, 27 Jan 2002, Ori Pessach wrote:
On Sunday 27 January 2002 11:22, Ove Kaaven wrote:
On Sat, 26 Jan 2002, Ori Pessach wrote:
FALSE for those windows. Are there any other types of windows that shouldn't be managed?
Yes, Alexandre mentions popup menus and tooltips. Perhaps a chart could be made, so that it is possible to work out what conditions should be used to decide whether to make a window managed...
Yep... Managed tooltips look silly. In any case, unmanaged windows behave badly, and I don't see any reason to use unmanaged windows when Wine is running in managed mode.
Does anybody know how X toolkits display tooltips, popup menus, etc.?
I looked at the GTK+ sources before creating that patch... for popup windows like menus and tooltips and stuff, GTK+ sets the override-redirect window attribute, which causes the window to become unmanaged. Effectively the same as Wine does.
I would think that when running managed Wine, all window should be managed, and the distinction should be between decorationless windows and everything else, not managed windows and everything else.
If nobody else wants to dig into this, I'll probably take a shot at it.
Go ahead.
On Sunday 27 January 2002 14:04, Ove Kaaven wrote:
On Sun, 27 Jan 2002, Ori Pessach wrote:
On Sunday 27 January 2002 11:22, Ove Kaaven wrote:
On Sat, 26 Jan 2002, Ori Pessach wrote:
FALSE for those windows. Are there any other types of windows that shouldn't be managed?
Yes, Alexandre mentions popup menus and tooltips. Perhaps a chart could be made, so that it is possible to work out what conditions should be used to decide whether to make a window managed...
Yep... Managed tooltips look silly. In any case, unmanaged windows behave badly, and I don't see any reason to use unmanaged windows when Wine is running in managed mode.
Does anybody know how X toolkits display tooltips, popup menus, etc.?
I looked at the GTK+ sources before creating that patch... for popup windows like menus and tooltips and stuff, GTK+ sets the override-redirect window attribute, which causes the window to become unmanaged. Effectively the same as Wine does.
OK... I'll take a look at this.
-Ori Pessach
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Hi,
With three small changes to menu.c, tooltips.c and window.c, things I'm getting much better results with Pajam Sam et al, without getting WM decorations on tooltips and context menus.
The changes are:
- Changed is_window_managed()'s default return value to TRUE - In tooltips.c, TOOLTIPS_NCCreate(), I set the WS_EX_TOOLWINDOW bit in the tooltip's dwExStyle field. This, I believe, is the right thing to do regardless of WM considerations, since MSDN specifies that tooltip windows have that bit set. (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla...) - In menu.c, I replaced CreateWindowA() with CreateWindowExA(), passing WS_EX_TOOLWINDOW as the first parameter. I'm not so sure about this one. I don't know whether Windows does this (Win16 surely doesn't), and if it doesn't, it might break apps that examine those bits.
With these changes, Pajama Sam works correctly, except for the KDE panel problem. I tested another app (WinRAR) for tooltip and context menu behavior, and it worked fine. I'd be happier if somebody else tested this, too, before submitting the patch. If someone with a Windows machine could check the dwExStyle bits on menus somehow, that would be nice. I'll do it myself, as soon as I can get my hands on the necessary software. (Windows, mostly).
Anyway, here's the patch:
Index: controls/menu.c =================================================================== RCS file: /home/wine/wine/controls/menu.c,v retrieving revision 1.135 diff -u -r1.135 menu.c --- controls/menu.c 2002/01/03 02:35:23 1.135 +++ controls/menu.c 2002/01/28 05:51:10 @@ -1618,10 +1618,12 @@ }
/* NOTE: In Windows, top menu popup is not owned. */ - menu->hWnd = CreateWindowA( POPUPMENU_CLASS_ATOM, NULL, - WS_POPUP, x, y, width, height, - hwndOwner, 0, GetWindowLongA(hwndOwner,GWL_HINSTANCE), - (LPVOID)hmenu ); + menu->hWnd = CreateWindowExA( WS_EX_TOOLWINDOW, + POPUPMENU_CLASS_ATOM, NULL, + WS_POPUP, x, y, width, height, + hwndOwner, 0, GetWindowLongA(hwndOwner,GWL_HINSTANCE), + (LPVOID)hmenu ); + if( !menu->hWnd ) return FALSE; if (!top_popup) top_popup = menu->hWnd;
Index: dlls/comctl32/tooltips.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/tooltips.c,v retrieving revision 1.40 diff -u -r1.40 tooltips.c --- dlls/comctl32/tooltips.c 2002/01/04 21:27:34 1.40 +++ dlls/comctl32/tooltips.c 2002/01/28 05:51:11 @@ -2114,10 +2114,14 @@ TOOLTIPS_NCCreate (HWND hwnd, WPARAM wParam, LPARAM lParam) { DWORD dwStyle = GetWindowLongA (hwnd, GWL_STYLE); + DWORD dwExStyle = GetWindowLongA (hwnd, GWL_EXSTYLE);
dwStyle &= 0x0000FFFF; dwStyle |= (WS_POPUP | WS_BORDER | WS_CLIPSIBLINGS); SetWindowLongA (hwnd, GWL_STYLE, dwStyle); + + dwExStyle |= WS_EX_TOOLWINDOW; + SetWindowLongA (hwnd, GWL_EXSTYLE, dwExStyle);
return TRUE; } Index: dlls/x11drv/window.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/window.c,v retrieving revision 1.30 diff -u -r1.30 window.c --- dlls/x11drv/window.c 2002/01/21 18:41:27 1.30 +++ dlls/x11drv/window.c 2002/01/28 05:51:19 @@ -71,8 +71,9 @@ /* windows with caption or thick frame are managed */ if ((win->dwStyle & WS_CAPTION) == WS_CAPTION) return TRUE; if (win->dwStyle & WS_THICKFRAME) return TRUE; + /* default: not managed */ - return FALSE; + return TRUE; }
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
On Mon, 28 Jan 2002, Ori Pessach wrote:
- Changed is_window_managed()'s default return value to TRUE
Perhaps remove the cruft this leaves behind, then.
- In tooltips.c, TOOLTIPS_NCCreate(), I set the WS_EX_TOOLWINDOW bit in the
tooltip's dwExStyle field. This, I believe, is the right thing to do regardless of WM considerations, since MSDN specifies that tooltip windows have that bit set. (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla...)
Then I suggest you submit this piece of the patch to wine-patches independently of the rest of this.
- In menu.c, I replaced CreateWindowA() with CreateWindowExA(), passing
WS_EX_TOOLWINDOW as the first parameter. I'm not so sure about this one. I don't know whether Windows does this (Win16 surely doesn't), and if it doesn't, it might break apps that examine those bits.
Since this is probably not the case, perhaps it's better to check for the popup menu class in is_window_managed(), something like
if (GetClassLongA(win->hwndSelf, GCW_ATOM) == POPUPMENU_CLASS_ATOM) return FALSE;
With these changes, Pajama Sam works correctly, except for the KDE panel problem.
I'm currently looking at that issue.
On Wednesday 30 January 2002 17:39, Ove Kaaven wrote:
On Mon, 28 Jan 2002, Ori Pessach wrote:
- Changed is_window_managed()'s default return value to TRUE
Perhaps remove the cruft this leaves behind, then.
Of course.
- In tooltips.c, TOOLTIPS_NCCreate(), I set the WS_EX_TOOLWINDOW bit in
the tooltip's dwExStyle field. This, I believe, is the right thing to do
Then I suggest you submit this piece of the patch to wine-patches independently of the rest of this.
Will do.
Since this is probably not the case, perhaps it's better to check for the popup menu class in is_window_managed(), something like
if (GetClassLongA(win->hwndSelf, GCW_ATOM) == POPUPMENU_CLASS_ATOM) return FALSE;
Ah ha! Exactly what I had in mind. After thinking about this, it seemed to me that is_window_managed() should examine the window's class, as well as its style bits, since the class will give a more accurate indication of what kind of window we're dealing with than just the style bits.
-Ori Pessach
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
"Ori Pessach" ori_pessach_blah@yahoo.com wrote:
Since this is probably not the case, perhaps it's better to check for the popup menu class in is_window_managed(), something like
if (GetClassLongA(win->hwndSelf, GCW_ATOM) == POPUPMENU_CLASS_ATOM) return FALSE;
Ah ha! Exactly what I had in mind. After thinking about this, it seemed to me that is_window_managed() should examine the window's class, as well as its style bits, since the class will give a more accurate indication of what kind of window we're dealing with than just the style bits.
Unfortunately this aproach does not work well in all cases, especially in the case of subclassed windows.
On Fri, 1 Feb 2002, Dmitry Timoshkov wrote:
"Ori Pessach" ori_pessach_blah@yahoo.com wrote:
Since this is probably not the case, perhaps it's better to check for the popup menu class in is_window_managed(), something like
if (GetClassLongA(win->hwndSelf, GCW_ATOM) == POPUPMENU_CLASS_ATOM) return FALSE;
Ah ha! Exactly what I had in mind. After thinking about this, it seemed to me that is_window_managed() should examine the window's class, as well as its style bits, since the class will give a more accurate indication of what kind of window we're dealing with than just the style bits.
Unfortunately this aproach does not work well in all cases, especially in the case of subclassed windows.
Do you have any examples where it might not work... window subclassing is the act of using SetWindowLong to replace the window procedure, which does not change the class atom, as far as I know?
Ove Kaaven ovehk@ping.uio.no writes:
Do you have any examples where it might not work... window subclassing is the act of using SetWindowLong to replace the window procedure, which does not change the class atom, as far as I know?
That's if you want to subclass all windows of a given class. If you just want to create your own menu windows but not change the existing menus, you would create a new class with a new name, and then chain down to the menu window proc for any unhandled message.
On 31 Jan 2002, Alexandre Julliard wrote:
Ove Kaaven ovehk@ping.uio.no writes:
Do you have any examples where it might not work... window subclassing is the act of using SetWindowLong to replace the window procedure, which does not change the class atom, as far as I know?
That's if you want to subclass all windows of a given class.
Hmm. I thought SetWindowLong worked differently than SetClassLong. Weird stuff...
Ove Kaaven ovehk@ping.uio.no writes:
Hmm. I thought SetWindowLong worked differently than SetClassLong. Weird stuff...
Yes it does, you are right my explanation was more for SetClassLong than SetWindowLong. Basically SetClassLong will affect all windows created with a given class, SetWindowLong will affect a single window, and creating a new class + GetClassLong on the old one will affect all windows created with the new class but not those created with the old class. The nice thing with the Windows API is that everything is so straightforward...
"Ove Kaaven" ovehk@ping.uio.no wrote:
Since this is probably not the case, perhaps it's better to check for the popup menu class in is_window_managed(), something like
if (GetClassLongA(win->hwndSelf, GCW_ATOM) == POPUPMENU_CLASS_ATOM) return FALSE;
Ah ha! Exactly what I had in mind. After thinking about this, it seemed to me that is_window_managed() should examine the window's class, as well as its style bits, since the class will give a more accurate indication of what kind of window we're dealing with than just the style bits.
Unfortunately this aproach does not work well in all cases, especially in the case of subclassed windows.
Do you have any examples where it might not work... window subclassing is the act of using SetWindowLong to replace the window procedure, which does not change the class atom, as far as I know?
Here is what I did for testing a progress bar control:
GetClassInfo(0, "msctls_progress32", &wnd_class); old_ProgressProc = wnd_class.lpfnWndProc; wnd_class.lpfnWndProc = my_ProgressProc; wnd_class.lpszClassName = "my_progress32"; RegisterClass(&wnd_class);
my_ProgressProc just logs all received messages and then calls an old window procedure: CallWindowProc(old_ProgressProc, hWnd, uMsg, wParam, lParam);
-
Alexandre Julliard -
Dmitry Timoshkov -
Ori Pessach -
Ove Kaaven