Bug 3024

#2758 - похоже?

Мало того что окно не активно и на заднем плане, оно вообще не отвечает. 

Иногда при срабатывании точки останова, возникает ситуация, очень похожая на багу #3048 (пункт 17 - конфигуратор висит).

*** Bug 102 has been marked as a duplicate of this bug. ***

Здесь опять придется решать проблему подъема окна на передний план в Gnome. Все очень похоже на ситуацию с #1837. 

В идеале все будет происходить так:
Происходит останов, срабатывает SetForeground для конфигуратора, срабатывает X11DRV_SetFocus для него же и все. Окно конфигуратора имеет фокус, но остается на заднем плане.

В KDE ситуация лучше. Если в настройках поведения окон установить "Управление фокусом" на "нет" - после передачи фокуса окно поднимется.

Если в KDE есть возможность улучшить поведение настройками окон,
то надо найти в каком они файле и поставлять свои настройки
вместе с wine (или ставить их при wine --update), чтобы улучшить ситуацию.

(In reply to comment #5)
> Здесь опять придется решать проблему
> подъема окна на передний план в Gnome. Все
> очень похоже на ситуацию с #1837. 
> 
> В идеале все будет происходить так:
> Происходит останов, срабатывает SetForeground
> для конфигуратора, срабатывает X11DRV_SetFocus
> для него же и все. Окно конфигуратора имеет
> фокус, но остается на заднем плане.
> 
> В KDE ситуация лучше. Если в настройках
> поведения окон установить "Управление
> фокусом" на "нет" - после передачи фокуса
> окно поднимется.
> 

Лучше смотреть работу функции SetActiveWindow в /user32/focus.c, при вызове этой функции конфигуратор должен перейти на передний план и получить активность+фокус.

Выложил серию патчей.

Проблема осложнялась тем, что необходимо было передавать X фокус между разными потоками. Поэтому пришлось ввести дополнительную функцию X11 драйвера - X11DRV_DropWindow.

Механизм работы вытаскивания окон наверх стал следующий. При вызове X11DRV_SetFocus окно вытаскивается наверх (через WS_EX_TOPMOST и update_net_wm_states), при этом предыдущее topmost окно сбрасывается в нормальное состояние. Если вызывается SetForegroundWindow для окна потока, отличного от текущего, то WS_EX_TOPMOST текущего окна сбрасывается, чтобы окно другого потока смогло корректно оказаться на переднем плане.

>Лучше смотреть работу функции SetActiveWindow в
>/user32/focus.c, при вызове этой функции
>конфигуратор должен перейти на передний
>план и получить активность+фокус.

Все правильно, но, к сожалению, Gnome не вытаскивает окно на передний план при передачи X фокуса (эту особенность разработчики Gnome признают).

(In reply to comment #8)
> Все правильно, но, к сожалению, Gnome не
> вытаскивает окно на передний план при
> передачи X фокуса (эту особенность
> разработчики Gnome признают).
> 

Ну хорошо, возможно это правильно, но аналог свойства "активность" из Windows под Gnome есть?

> Ну хорошо, возможно это правильно, но
> аналог свойства "активность" из Windows под Gnome
> есть?

Есть X-овый атом _NET_ACTIVE_WINDOW. По идее, он должен отвечать за активность окна. Но почему-то в wine он не используется.

(In reply to comment #10)
> 
> Есть X-овый атом _NET_ACTIVE_WINDOW. По идее, он
> должен отвечать за активность окна. Но
> почему-то в wine он не используется.
> 
Прекрасно, а как Gnome ведёт себя когда окно получает этот атом? И есть ли отличие в поведении KDE? Возможно так будет легче вытаскивать окно на передний план. В том смысле, что активному окну по умолчанию должен передаваться фокус. Есть шанс, что под Gnome так и будет, а так же окно будет поверх других окон. 

То что в wine это не используется, не вижу ничего странного, т.к. часть user32, которая отвечает за интерфейс написана по принципу "вроде ведёт себя так же как и в Win, ну и чёрт с ним". Это и объясняет ещё то, почему одни и те же функции то и дело кочуют из user32 в winex11.drv и обратно. Архитектура работы с окнами ещё не продумана и разработчики то и дело перекидывают функциональность то на X, то на Wine.

Проверил работу Gnome с атомом NET_ACTIVE_WINDOW. Он корректно активизирует X-овое окно и передает ему фокус ввода, но не всегда его поднимает на передний план. Т.е. после активации окна, предыдущее активированное этим атомом остается поверх него (эта проблема проявляется в 1с8).
Полагаю, работа с NET_WM_STATE_ABOVE атомом будет надежнее, т.к. он определяет положение окна в стеке уровней окон:

http://standards.freedesktop.org/wm-spec/1.3/ar01s07.html#STACKINGORDER

(In reply to comment #12)
> Проверил работу Gnome с атомом NET_ACTIVE_WINDOW. Он
> корректно активизирует X-овое окно и
> передает ему фокус ввода, но не всегда его
> поднимает на передний план.
...
> Полагаю, работа с NET_WM_STATE_ABOVE атомом будет
> надежнее, т.к. он определяет положение окна
> в стеке уровней окон:

Хммм. может быть лучше снимать атом с того окна, которое выше, чем пытаться заместить его более приоритетным? Хотя не факт, что так правильно делать..

В ходе решения баги #3967 возникли некоторые изменения. Теперь чтобы при запуске wine работали патчи на подъем окон разных процессов, необходимо задавать переменную окружения - WINEENABLERAISE. 

Запуск программы будет выглядеть например так:

WINEENABLERAISE=1 wine 1cv8.exe

> Запуск программы будет выглядеть например
> так:
> 
> WINEENABLERAISE=1 wine 1cv8.exe
> 

Принято.
WINE@Etersoft 1.0.11 eter4/eter2(In reply to comment #14)