[Bug 27190] Incorrect focus and Alt+Tab order with Delphi MDI application

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=27190

--- Comment #2 from Mateus César Gröess <mateuscg at 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?

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.