http://bugs.winehq.org/show_bug.cgi?id=27190
--- Comment #2 from Mateus César Gröess mateuscg@gmail.com 2011-07-02 16:00:54 CDT ---
I have done further investigation of this problem, because is annoying have to alternate frequently between applications and have a different behaviour for the Delphi one. Please consider I'm a sysadmin (development is not my job currently) and a newbie in Windows, Wine and X11 development APIs. A simpler MDI Delphi application is the attachment 1054 (of bug 1719), posted here:
http://bugs.winehq.org/show_bug.cgi?id=1719#c4
I will use it as reference instead of the sample application linked at description of this bug.
First, a correction. In point 6, the first window in Alt+Tab list is not the child MDI window of the application running on wine. Instead it is the special main application window, used by Delphi applications, not visible but present in the task bar. The child MDI window is focused after the hidden window is selected, I guess by some internal focus control, that does not focus also the entire visible window where that child is. To explain by example, after started, for the simpler MDI app referenced by this comment, the window manager will manage two windows, as shown in the output of the "wmctrl -l" command:
0x03a00001 0 localhost Project1 0x03a00003 0 localhost Form1
The user will only see a window titled "Form1", but the button in task bar is named "Project1". There's no Project1 window, it seems to be zero-sized and serve only to control operations. The Form1 window is not in task bar because in its _NET_WM_STATE property is the _NET_WM_STATE_SKIP_TASKBAR flag (a "WM hint"), as seem using the "xprop -id 0x03a00003" command for the example. Metacity has a rule that ignores windows with that flag in Alt+Tab list:
https://bugzilla.gnome.org/show_bug.cgi?id=106249
So, because the visible window of the application is not in the list, the first selected window will be the hidden window of the application itself, instead one of another app. I have tested the behaviour on MS-Windows XP and the window listed in Alt+Tab is Form1, not Project1, but Project1 is the one used in the task bar like happens on Metacity. There's a way to obtain the same Alt+Tab behavior, by showing the button Form1 in the task bar and hiding Project1, but needs change of window hints while the application is running, using these commands in the example:
wmctrl -v -i -r 0x03a00003 -b remove,skip_taskbar wmctrl -v -i -r 0x03a00001 -b add,skip_taskbar
But hidding the special window as a workaround for Alt+Tab will break some operations, like no button in task list when minimizing, as seem in wine bug 26670. If only the first command is run, two buttons will appear, but after the visible window is minimized, it will not reappear in task bar when restored unless the same command is run again.
I don't know if there's a way to solve this problem. Seems like Metacity would need to ignore Project1 window in Alt+Tab list, but not in task bar, and ignore Form1 window just in task bar, but not in Alt+Tab list. The window manager specifies the list by the following definition in its file src/core/display.c:
#define IN_TAB_CHAIN(w,t) (((t) == META_TAB_LIST_NORMAL && META_WINDOW_IN_NORMAL_TAB_CHAIN (w)) \ || ((t) == META_TAB_LIST_DOCKS && META_WINDOW_IN_DOCK_TAB_CHAIN (w)) \ || ((t) == META_TAB_LIST_GROUP && META_WINDOW_IN_GROUP_TAB_CHAIN (w, get_focussed_group(w->display))))
The macro META_WINDOW_IN_NORMAL_TAB_CHAIN is defined in src/core/window-private.h, and has the condition, added in the previously mentioned bug in Gnome bugzilla, to ignore windows not in task bar:
#define META_WINDOW_IN_NORMAL_TAB_CHAIN(w) \ (((w)->input || (w)->take_focus ) && META_WINDOW_IN_NORMAL_TAB_CHAIN_TYPE (w) && (!(w)->skip_taskbar))
Would be possible to specify another Window Type for one of the two windows used by the Delphi MDI application, that would allow the desired behavior? Other solution?