Russian Qt Forum

это обсуждали в qt-interest. Окно (в X11 по крайней мере) средствами Qt нельзя сделать выше других (чтобы это работало в 100% случаев). Нужно использовать платформенно-зависимый код для общения с window manager'ом, и для каждой платформы оборачивать его ifdef-ами. В X11 используйте NETWM.

это к чему было?

вообще, т.к. Х-сервер не занимается окнами, а оставляет эту задачу оконному менеджеру, код будет не платформо-зависимым, а оконно-менеджеро-зависимым. причём, в некторых оконных менеджерах сделать как требуется так и не удастся по причине их кривизны.
используйте КДЕ :)

Нужно ориентироваться на самые основные: KDE, Gnome, XFCE. Кстати, начиная с 4 версии, KDE доступен и для винды.

Спасибо.

X сервер создаёт почву для работы wm.


Если wm netwm-совместим (большинство современных wm, в т.ч. и KWin), то нас недолжно волновать, что


достаточно дёрнуть атом _NET_ACTIVE_WINDOW для нашего окна, и всё остальное должен сделать wm.

Это будет решение для X11. Для винды нужно писать, как я уже говорил, другой код и оборачивать его в #ifdef

Вообще, если интересно как это работает со стороны клиента, то можно посмотреть код fspanel - это предок fbpanel, прога на чистом Xlib, и использует X11 вызовы для работы с netwm-совместимым wm-ом.

Вышенаписанное верно. Хочу только добавить что в Qt есть функции для управления окном - QWidget::activateWindow() и QWidget::raise()

Да они то есть... Но похоже, что в КДЕ 4.1 они не работают. Сам сейчас не могу разобраться, как заставить окошко показаться на экране по клику на иконке в трее (QTrayIcon). В винде все работает, в КДЕ не хотит...
Правда в винде другой баг - если окно имеет флаг Qt::Tools, то при клике по десктопу оно пропадает :(

будет ли это работать зависит от реализации window manager'а т.к. общего стандарта поведения в X11-мире нет.

я видел подобное поведение в некоторых window manager в X11 (и это не баг т.к. опять же поведение зависит от реализации window manager'а), но не в винде - проверил сейчас в windows xp в примере examples/widgets/windowflags - окна с типом Qt::Tool не пропадают при потере фокуса. Если вы можете воспроизвести проблему, создайте таску в task-tracker.

http://www.prog.org.ru/topic_7365_0.html

Окно пропадает не при потере фокуса (такого я тоже ни разу не видел), а именно при клике по десктопу и только в винде. У меня при этом parent=0, т.к. окно главное. Думаю, что это все таки баг. Какой бы ни был WM, нет причин самостоятельно скрывать окна.
Тролям написал, но они что то не расчехляются...

ой, я пропустил это предложение. Никогда не отправляйте сообщения с временной меткой CurrentTime! не забывайте указывать корректную временную метку которую можно получить из QX11Info::appUserTime().

вкратце - система передачи фокуса в X11 основана на временных метках (timestamp) которые хранятся для каждого (top-level) окна (в свойстве _NET_WM_USERTIME) и которые отмечают время когда пользователь последний раз взаимодействовал с этим окном. На основе этих меток windowmanager решает какое из окон должно иметь фокус.

Вот пример взаимодействия пользователя с системой: имеется терминальное приложение где пользователь набирает команду запуска приложения xclock, и каждый раз когда пользователь нажимает клавишу на клавиатуре терминал сообщает windowmanager'у об обновлении временной метки. Далее пользователь нажимает enter для запуска приложения, это приложение создает окно (но пока его не показывает на экране!) и отмечает меткой время создания окна, и затем показывает окно на экране (XMapWindow), после чего windowmanager ищет окно с самой свежей временной меткой, "поднимает" его и передает ему фокус. Но система X11 сетевая и асинхронная, поэтому еще до того как xclock создаст свое окно, либо между созданием окна и его отображанием на экране пользователь может продолжать взаимодействовать с терминальным приложением, вследствии чего его временная метка будет более новая, соответственно после отображения окна xclock на экране он не должен перехватить фокус.

Поэтому в пользовательском приложении есть два способа поднять окно - XRaiseWindow/XSetInputFocus или же послать сообщение  _NET_ACTIVE_WINDOW корневому окну. Проблема в том что не гарантируется что windowmanager поддерживает любой из этих способов (и существует много "поломанных" WM который криво реализуют стандарт netwm (kwin не исключение ;). Qt использует первый способ.



такого поведения я у себя тоже не вижу. какой номер таски?

Денис Д. вы ли это? :)


Всё верно, но разве это важно для окна, которое активизируется насильно через _NET_ACTIVE_WINDOW?

А где в KWin кривости netwm? Чтобы знать на будущее.

ммм. как видно из ника это я. Либо я не понял вопроса :)

все равно важно передать правильную временную метку иначе окно будет активировано насильно невзирая на то что пользователь в данный момент печатает что-то в другом окне. Мне бы такое поведение ооооочень сильно не понравилось.

сходу ничего не вспоминается кроме неподдержки _NET_WM_USER_TIME_WINDOW и во всех случаях работающей возможности отключить функциональности окна (например убрать кнопку закрытия окна), хм. хотя это не относится к спецификации netwm.

Всегда приятно видеть отечественных сотрудников Троллтеха! ;)

Раз уж пошла такая пьянка, м.б. активацию окон в Qt сделать через netwm? Потому что чем только люди не занимаются под иксами, чтобы окна активизировать :) Тут уже несколько тем было. Да и на лоре тоже. Очень, очень животрепещущая тема.

Номер проблемы N235809 :)

попробовать стоит. но нужно проверить текущую реализацию и реализацию через _NET_ACTIVE_WINDOW во всех популярных window manager'ах. Очень странно если текущая реализация не работает в kwin - это один из WM в котором обычно тестируем.

ок, вижу ваши письма. саппортеру отписался по поводу первой проблемы, а вторая - с типом окна Qt::Tool - не знаю, сходу не воспроизводится, нужно тестовое приложение от вас.