WINE перехватывает фокус у чужого приложения даже для своего внутреннего окна. Самое неприятное, что на отображении это никак не сказываетя... (если конечно в настройках КДЕ не отключить "Уровень предовращения перехода фокуса" - в этом случае окно с фокусом отобразится, но не уверен что это верное поведение...)... просто перестают работать клавиши.
ставил эксперименты
Не удалось воспроизвести ситуацию с разными рабочими столами. Ошибка с подъемом окна, при передаче фокуса внутреннему mdi окну воспроизвелась. Для этого в KDE необходимо настроить: "Уровень предовращения перехода фокуса" = "Нет". В Gnome ошибка воспроизводится с настройками по-умолчанию. Тестировал в windows. Там подъема окна не происходит и фокус клавиатуры не перехватывается. Воспроизводить можно так: 1) бутылка 1c77/1c7727 2) открыть обработку c:\tmp\speedtest3.ert 3) пока идет обработка переключиться на другое X-овое окно В результате по завершении обработки окно 1с поднимается на передний план.
Сломалось коммитом: commit f82d3645e0b746dac674fdbaa259453651b74865 Author: Ilya Shpigor <shpigor@etersoft.ru> Date: Thu Apr 9 16:05:01 2009 +0400 user32/winex11.drv: Using the Drop/Raise window functions for all aplications (eterbug #3768)
Проблема связана с тем, что в результате описанного выше коммита XSetInputFocus отрабатывает всегда, когда wine приложение должно получить winAPI'шный фокус. В windows в аналогичной ситуации приложение также пытается перехватить фокус - получает сообщение WM_SETFOCUS. Но, похоже, сама ОС не позволяет этого сделать. Решение заключается в том, чтобы блокировать работу X11DRV_SetFocus (передачу X-ового фокуса), если managed режим и X-овое окно имеющее фокус не является окном запущенного wine приложения. Этот патч отключается при использовании переменной окружения: WINEENABLERAISE=1 Протестировал кучу уже решенных проблем с фокусом, чтобы ничего не сломалось. Но все равно что-то мог упустить и побочный эффект может быть.
Патч проблему не решил. Эта же ошибка воспроизводится в не managed режиме. Поэтому надо смотреть - почему передается wineapi'шный фокус.
Если быть точнее - патч решил проблему только для KDE. В Gnome и не managed режиме ошибка воспроизводится.
Еще раз все хорошенько протестировал. Патч, который сейчас лежит в рассылке: winex11.drv: Don't set the focus to wine window if another X window had been activated (eterbug #4382) Решает багу в любом DE. Но она продолжает воспроизводится в не managed режиме (на это есть заявка 11863). Постараюсь сделать патч, чтобы проблема решалась в любом режиме. Если не успею к выходу 1.0.12, полагаю, стоит приложить существующий патч.
Написал тест для windows. Приложение перехватывает фокус по таймеру. В windows приложение не может передать фокус своему окну, если в это время фокус принадлежит окну другого процесса. Вероятнее всего, windows отслеживает у какого процесса фокус и запрещает другим процессам его перехватить. Вообще, только SetForegroundWindow может что-то сделать с окном из другого процесса. Сейчас в wine SetForegroundWindow и SetFocus вызывают set_active_window, в результате чего окно получает фокус ввода. Похоже в этом и заключается ошибка.
Выложил новый патч на эту багу. Решение - не вызывать set_active_window из SetFocus. Т.е. теперь поднять окно другого процесса можно только с помощью SetForegroundWindow, как и в windows.
Принято. WINE@Etersoft 1.0.12 eter1/1
Пользователь жалуется, что в 1.0.12 воспроизводится (см. заявку 11863). Надо еще протестировать через NX и на Xfce.
to baraka@ Воспроизведи, пожалуйста, у нас. Пользователь пишет, что бага осталась в 1.0.12, но я не смог воспроизвести. Посмотри заявку 11863, может быть это поможет. Вроде как воспроизводится только на NX.
(In reply to comment #12) > to baraka@ > Воспроизведи, пожалуйста, у нас. > Пользователь пишет, что бага осталась в > 1.0.12, но я не смог воспроизвести. Посмотри > заявку 11863, может быть это поможет. Вроде > как воспроизводится только на NX. > Воспроизвести также не удалось. Пробовал и в Gnome, и в KDE, так же через NX не проявляется ошибка.
Из-за этого коммита появилась ошибка #4623. Решено было откатить текущее решение.
> 1) бутылка 1c77/1c7727 > 2) открыть обработку c:\tmp\speedtest3.ert > 3) пока идет обработка переключиться на > другое X-овое окно > > В результате по завершении обработки окно > 1с поднимается на передний план. > сделал wine --update не воспроизводится(KDE) воспроизвел через GNOME->NX(консольный логин): окно с 1С после окончания обработки всплыло на передний план
После обновления до текущего eterhack - проблема должна решится. сломалось коммитом: user32/winex11.drv: Using the Drop/Raise window functions for all aplications (eterbug #3768) В eterhack откатили все патчи на Drop/Raise в winex11.drv.
Проверить на eterhack.
WINE@Etersoft 1.0 SQL 1.3.27/1.0.12-eter1.15/26 протестировал в KDE Gnome и через NX Самовольного захвата фокуса замечано небыло тестировал скриптом 1c77/1c7727/dosdevices/c:\tmp\speedtest3.ert Закрываю
Бутылку 1c77/1c7727 не нашёл ни в одной из версий swine Место нахождение файла speedtest3.ert тоже оказалось загадкой. Нужно думать как воспроизвести без них.
Продолжительный поиск по папке /var/ftp/pvt/Windows с паттерном "speedtest*" не дал положительного результата. $find /var/ftp/pvt/Windows/* -iname 'speedtest*' find: ‘./Drivers/WLAN_QualcommAtheros_Win7_32_VER1000288’: Отказано в доступе find: ‘./ГосПрограммы/8798_XP03_Client_vbox/Snapshots’: Отказано в доступе
Задача относится к релизу 2.1. , который больше не поддерживается. Аннулирую.
Закрыта.
