Если в конфигураторе поставить точки останова и запустить отладку , то при останове на точке должно появляться окно конфигуратора - но оно не активно и остается на заднем плане.
#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)
