Qt, multi-screen, virtual desktop, workspaces

QWidget::saveGeometry()/QWidget::restoreGeometry()

QMainWindow::saveState()/QMainWindow::restoreState()

Размечтался ))

Это я тоже дебажил вчера — только для одного скрина.

У меня работало на разных

Для разных чего? Скринов, десктопов или воркспейсов? Для первых двух оно работает, да.

обычно этим занимается WM, не проще ли его покрутить (kwin и compiz точно умели, гномоподелки сливались)

Если у тебя десктоп тянется на несколько экранов, то это будет работать. Ну типа для 1024x768 сосиска из четырех вирт десктопов будет QRect(0, 0, 4096, 768). У меня же всегда возвращается как для одного, и сосиски нет, а воркспейсы есть и окна я меж ними таскаю («Move to another workspace» в меню окна по титлебару).

Вот и надо узнать как спросить у ВМ (но нагуглилось только напрямую у иксов, да и то, указание флага что окно на всех воркспейсах) на каком воркспейсе окно, записать это в сеттингс, а при запуске сказать ВМу на какой воркспей я хочу.

воркспейсы

Видимо, это что-то совсем мятное и в иных системах неведанное

Вот тебе живой пример что оно работает: Ardour. Если отдетачить микшер в отдельное окно и оттащить его на другой воркспейс, то при запуске он отправляет окно микшера в нужный. Но там ГТК, да, а мне нужно решение для кутэ.

Qt, multi-screen, virtual desktop, workspaces (комментарий)

Кстати, если компильнешь свое приложение под пятые кути в 32 бита (или скинешь сорцы, сам соберу) — могу потестить как оно работает у меня под гтк и матэ. А вдруг я что-то делаю не так, раз ты заявляешь что у тебя все работает?

Qt не видит воркспейсы. Я пробовал и дебажил каждый метод для:

Надо: сохранять положение окна на соответствующих скрине, десктопе, воркспейсе. И после закрытия окна, открывать его точно в том месте в каком оно было закрыто.

Своего самописного приложения или вообще любых приложений на Qt,даже чужих?

Я плохо знаю Qt. Но вот если Qt действительно ничего не знает про рабочие столы, то эта информация берется по EWMH. См. свойство _NET_WM_DESKTOP. Надо выяснить, есть ли у них функции, которые устанавливают это свойство.

Своего. У меня несколько окон, нужно определять в каком месте открывались второстепенные. То понятно, что если главное открывается в новом месте, то нужно смещать и второстепенные, и это решаемо.

Не решаемым пока является получить вообще на каком воркспейсе окно находится. Нет, судя по ссылке на стековерфлоу в моем стартпосте и по поведению Qt на моей машинке — оно не знает про воркспейсы.

Вот список доступных флагов: http://doc.qt.io/qt-5/qt.html#WindowType-enum там нет того что нужно.

_NET_WM_DESKTOP — я смотрел и даже нашел https://tronche.com/gui/x/xlib/window-information/XGetWindowProperty.html и https://tronche.com/gui/x/xlib/window-information/XChangeProperty.html

Я плохо знаю Qt.

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

Чтобы узнать, надо вызвать XGetWindowProperty (если через xlib) или соответствующую функцию xcb. В xcb есть библиотека по работе с EWMH, но я до сих пор и не смотрел, что там вообще. :)

libxcb-ewmh2 - utility libraries for X C Binding -- ewmh  

Чтобы отправить окно на нужный рабочий стол, надо послать пользовательское сообщение при помощи XSendEvent (или аналог в XCB). Об этом, кстати, в конце раздела по ссылке, которую я дал выше, говорится.

В общем, если тебе нужен конкретный код, то я лучше выдрать откуда-нибудь, чтобы не писать вслепую. Можно выдрать из wmctrl, так как программка маленькая. В main.c. См. функции get_property (получить свойство) и функцию client_msg (послать пользовательское сообщение). Вызовы:

/* получить десктоп */

(unsigned long *)get_property(disp, win,
            XA_CARDINAL, "_NET_WM_DESKTOP", NULL)

/* попросить перекинуть на десктоп */

client_msg(disp, win, "_NET_WM_DESKTOP", (unsigned long)desktop, 0, 0, 0, 0)

disp - дисплей, win - XID окна.

О! Премного сяп! Дальше, думаю, разберусь. Отпишусь что получилось.

Нашел вот это: https://api.kde.org/frameworks/kwindowsystem/html/classKWindowSystem.html

Как говорят «не надо пугаться KDE» оно зависит только от Qt. Это, похоже, то что нужно. По крайней мере не придется велосипедить — все уже инкапсулировано в Qt API.

Да, похоже на то, что нужно

https://api.kde.org/frameworks/kwindowsystem/html/netwm_8cpp_source.html#l03277

Если учесть что там даже вяленый есть, то вообще сказка — написал один раз и забыл, ну может пару условий дописать потом если бага всплывет.

Есть только одно НО — в debian jessie этого пакета (libkf5windowsystem, libkf5windowsystem-dev) в доступном виде нет. Кроме того нужно решить, поднимать нижнюю планку требований версии Qt (5.3.2) или нет (пакет хочет 5.5.0), но тогда нужно еще и версию Qt куда-то отдельно ставить и/или таскать с собой. Или всетаки завелосипедить функции геттер-сеттер через иксы. Тут уж не знаю даже что лучше. Как считаешь?

А задача сделать именно под Qt5 или Qt4 надо? Для начала можно попробовать сделать бэкпорт для jessie. Я пока не думаю, что там настолько принципиальная зависимость от новой версии Qt. Часто сопровождающие просто ставят зависимость от актуальной версии Qt в дистрибутиве, а в реальности оказывается, что и с более старыми собирается и работает. Просто сопровождающий не может поставить >=5.1.0, например, потому что не может дать гарантии, что только что скачанная самая новая KWindowSystem соберется и заработает на более старых Qt. Он и не проверяет, так как собирает для новых дистрибутивов только. Собралось с актуальной, то и ставит >=5.5.0. Но вот я тут точно не скажу. Надо просто попробовать собрать и потестировать. Бэкпорт можно заодно и на jessie-backports загнать.

Если бэкпорт сделать по каким-то причинам очень сложно, то можно тогда и затычку для более ранних версий написать самостоятельно. Или вообще плюнуть на эту библиотеку вообще и выдирать оттуда куски для себя.

Да, задача сделать под 5 версию.

Не охота бекпорты. И тут не лень, а самоцель — использовать только стандартные доступные в репах либы.

Насчет выдрать куски — возможно.

Вобщем скачал сорцы квиндовсистем, посмотрел. Там все вкусно конечно, под все платформы. Ну как, определен основной класс с заглушками методами, в остальных классах под каждую платформу переопределяются нужные методы, остальные остаются заглушками из базового.

В принципе, как совсем психованый вариант — брать его весь к себе или бекпортить.

Но вот: http://doc.qt.io/qt-5/qx11info.html то что доступно и в версии 5.3. Подскажи, можно ли достучаться до _NET_WM_DESKTOP через xcb_connection_t и Display которые там доступны? Вроде как выше ты писал что можно. Тогда нафиг эту квиндовсистем.

Можно, конечно. Писанины на XCB чуть больше, чем Xlib, но так как qt5 уже перешли на XCB, то пользоваться Xlib уже нет смысла. Для того, чтобы писать c XCB, надо держать в уме его асинхронную природу, то есть перед запросом резервируется место, куда и придет ответ (куки), потом делается запрос, а ответ на него не ожидается обычно сразу. Можно, конечно, и сразу ждать ответ и забрать, но можно чего-нибудь другое поделать, а потом, когда ответ уже нужен, его можно из куки забрать и использовать. Несколько низкоуровневое программирование, конечно, но это не так страшно. KWindowSystem как раз использует XCB.

Что-то я в экземплах, например http://manpages.ubuntu.com/manpages/xenial/man3/xcb_get_property.3.html не увидел что ответ как-то можно подождать асинхронно(?). Или просто через некоторое время проверить что в куках что-то поменялось?

Да, в этом и смысл latency hiding. Ты посылаешь запрос, а ответ придет в куки. Потом соответствующей функцией xcb_get_property_reply можно забрать. Можно забрать не сразу, можно заранее наинтернить атомов на сервер и не ждать, пока он каждый ответ пришлет, а что-то еще параллельно делать. Если ответ не пришел к моменту, когда его уже просят, то тогда уже функция будет ждать его прихода. А если он уже пришел к моменту необходимости, то просто прочитается. В Xlib каждая функция, которая требует ответа, ждала его и не шла дальше.

Жесть.. Претензии не к тебе, просто подгорает.

https://xcb.freedesktop.org/manual/group__XCB____API.html#ga86312758f2d011c37...

Во всем гугле в экземплах только получение WM_NAME.

Где искать список возможных значений для property, type (этот «an atom»)? А для остальных? А какой тип данных указывать при запрашивании «вот этого» проперти, а «вот того»?

А это вообще прекрасно:

TODO: talk about type

TODO: talk about delete

TODO: talk about the offset/length thing. what's a valid use case?

Все типы - в стандартах ICCCM и EWMH. Вот выше ссылка на _NET_WM_DESKTOP говорит: «_NET_WM_DESKTOP desktop, CARDINAL/32». Значит, тип XCB_ATOM_CARDINAL. Ща накидаю примерно, как запрашивать.

В общем, пишу я это вслепую. То есть вот просто, без компиляции, без ничего. Проверок минимум, все быстро накидал, мог где-то ошибиться. Потом проверю. Здесь conn - это переменная типа xcb_connection_t, которую ты из Qt берешь, а wid - это XID окна в иксах, который ты тоже у окна приложения из Qt берешь. Не знаю, где он там, но должен быть где-то в классе окна. Проверку на ошибки надо еще раз глянуть, чтобы все корректно было. Объявления функции нет - сам сделай. Результатом по идее должен быть номер рабочего стола.

// резервируем cookies для приема ответа от сервера

xcb_intern_atom_cookie_t intern_atom_cookie;
xcb_get_property_cookie_t get_property_cookie;
xcb_atom_t atom;

// Интерним атом в X-сервер при помощи InternAtom.

intern_atom_cookie = xcb_intern_atom(conn, 0, strlen("_NET_WM_DESKTOP"), "_NET_WM_DESKTOP");

// Забираем ответ от сервера. Можно забирать гораздо позже, когда
// данные действительно понадобятся.

xcb_intern_atom_reply_t *intern_atom_reply = xcb_intern_atom_reply(conn, intern_atom_cookie, NULL);

// Вот наш XID атома. Им оперируем.

if (!intern_atom_reply)
    return;

atom = intern_atom_reply->atom;
free(intern_atom_reply);

// Теперь спросим про его значение. wid - это XID окна.

get_property_cookie = xcb_get_property(conn, 0, wid, atom, XCB_ATOM_CARDINAL, 0, 1);

xcb_get_property_reply_t *get_property_reply = xcb_get_property_reply(conn, get_property_cookie, NULL);

// Проверяем, все ли правильно

if (get_property_reply) {
    if (get_property_reply->type == XCB_ATOM_CARDINAL &&
	get_property_reply->value_len == 1 &&
	get_property_reply->format == 32) {

	// Все ок, читаем свойство.
	uint32_t *value = (uint32_t *) xcb_get_property_value(get_property_reply);
    }
    free(get_property_reply);
    return value;
}
 
return;

Я тут всетаки решил пока попробовать собрать квиндовсистем.

Сижу, ржу..

Ладно анюзед вериэйбл, ладно депрекейтед валом летят (причем даже про мои старые иксовые заголовочники).

Ладно «no known conversion for argument 2 from ‘void (KWindowSystem::*)()’ to ‘const char*’».

Но, ****ь! QGuiApplication имеет screenAdded() но не имеет screenRemoved() — это эпик!

-----------------------------

Спасибо за примеры! Буду рабираться.

Еще раз спасибо! Все работает!

Ну типа для 1024x768 сосиска из четырех вирт десктопов будет QRect(0, 0, 4096, 768)

Это уже интересно. Можешь описать конфигурацию системы, в которой корректно создается эта самая «сосиска»?

В моей нет. У XMs да. Кастанул, подождем что скажет. И ты же понимаешь что там могут быть разные «сосиски» в зависимости от кол-ва скринов, вирт десктопов и воркспейсов.

OIM, Три монитора (точнее, два монитора и один зомбоящик): 1280×1024, 2×1920×1080, широкоформатники выводят одно и то же, область их общего рабочего стола стоит вплотную к области рабочего стола первого монитора (не знаю, как лучше описать), так, чтобы курсор, окна и т. п. можно было переносить между ними. DE — кеды, WM — KWin

Как я уже говорил в твоей теме — возьми квиндовсистем, только готовый пакет, ибо как я его пытался собрать у себя, ты можешь глянуть тут выше.

Вобщем смотри.

Я тут не помню когда, но недавно, писал тебе в другом треде, но ты проигнорил. Да и ладно. Я тут повторюсь, ибо оно важно.

Короче запилил я вот эти все xcb фичи и оно работало. Под Матэ. Пока я не влупил в него компиз. Вот с компизом оно вообще не работает. И я не могу точно установить по какой причине. Игнорит компиз эти команды или вообще не понимает, факт прост — оно не пашет как ожидалось.

И тут вопрос такой: а что есть, чтобы универсально работало во всех ВМ и всех композиторах? Ну такое, например, у меня в мыслях крутится только дибас. Но есть ли он везде — мне не известно.

Вот что делать?

Я тут не помню когда, но недавно, писал тебе в другом треде, но ты проигнорил. Да и ладно. Я тут повторюсь, ибо оно важно.

Я могу что-то пропустить. О каком треде речь, я даже не пойму. Но раз ладно, то и ладно.

Короче запилил я вот эти все xcb фичи и оно работало. Под Матэ. Пока я не влупил в него компиз. Вот с компизом оно вообще не работает. И я не могу точно установить по какой причине.

И тут не понимаю. Про какие фичи идет речь? Про фичи, которые были в том треде, который я пропустил? Или про те, что в этом топике обсуждаются? Если не работает то, что в этом топике обсуждалось, то вижу причину — compiz просто не реализует концепцию десктопов, как они прописаны в EWMH (NetWM), а выдумали что-то свое. Другими словами, не следуют спецификации и поэтому никак не меняют или даже не определяют значение _NET_WM_DESKTOP. Надо посмотреть, что пишут по этому поводу и выяснить, какой механизм используется.

Я глянул очень быстро и прочел, что в compiz не реализуют концепцию desktops, декстоп там всегда один. У них используется концепция viewports. Проверь в compiz, что выдает на разных десктопах (в смысле compiz) команда xdotool get_desktop_viewport (она выдаст координаты). И также проверь, какой номер десктопа она выдает при тех же условиях. Вангую, что декстоп всегда будет один и тот же.

Да, речь про этот топик.

Ну вот если компиз не работает, а ты и сам уже убедился в этом. Так что же делать?

Дело в том, что сам матэ как-то ведь понимает что работает с компизом и перемещает окна на другие вьюпорты, а когда работает не с компизом, то всеравно перемещает на другие десктопы. Т.е. работает и так и так.

Поэтому я и задумался, а через что он работает? Через костыли или какой-то более высокоуровневый способ, например, дибас. Нет, я еще не смотрел в сорцы чтобы что-то утверждать, я только размышляю.

В том другом топике я тебя просто увидел и решил написать о проблеме которую стоило продолжить обсуждать в этом топике.

Короче смысл в том, что, если ВМы все уже и так поддерживают с помощью собственных костылей различные композиторы.

Так и вывод у меня соответствующий: а почему бы не использовать самое апи этих ВМов, вместо того, чтобы костылять в своем приложении всё те же самые костыли, которые и так уже накостылены в ВМах.

Отсюда следует мысль: а какое апи есть у ВМов, да такое, чтобы общее, такое же как и EWMH только выше уровнем, где костыли для композиторов инкапсулированы внутри ВМов.

Можно еще через xprop узнать, какое значение у _NET_DESKTOP_VIEWPORT у root window.

Ну вот если компиз не работает, а ты и сам уже убедился в этом. Так что же делать?

Ну потому что они сделали так, не следуют спецификации. Кто же тут доктор? Я не знаю, как лучше сделать. Сделать специальную поддержку для compiz? Ну это как-то я даже не знаю.

Поэтому я и задумался, а через что он работает? Через костыли или какой-то более высокоуровневый способ,

Он не работает через костыли! Он работает через другое - через viewport. то есть они эти viewports внутри себя нумеруют. Получается. что в compiz своя экосистема, которая работает только внутри него. Вот что делать? Viewport тоже определены в EWMH, но это не то же самое, что десктоп

https://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317690112

Что касается dbus, то я не знаю ничего, какие там стандарты. Поддержка каких-то стандартов dbus оконным менеджером не гарантируется. Иксы предлагают WM использовать ICCCM/EWMH. Кто-то реализует полностью, кто-то частично, хотя большинство все же реализуют достаточно полно. Десктопы практически везде работают (кроме compiz :)

И это. https://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#largedesks

Десктопы практически везде работают (кроме compiz :)

Возможно, есть еще и третий вариант реализации в КДЕ, т.к. по заверениям XMs там в настройки сохраняется и номер десктопа без всех этих свистоплясок что мы тут с тобой обсуждаем.

Дибас я имею ввиду в том смысле что ВМ слушает по дибас команды, в том числе и по пересылке окна на другой воркспейс/вьюпорт, где для моей программы не важны нюансы как это сделать для того или иного композитора, а я просто отправляю запрос, но уже в контексте ВМа. Ну и сам дибас только как пример, я хз что там у них есть еще.

В настройки чего? Что-то не пойму. Если KDE реализует _NET_WM_DESKTOP по EWMH, то все там нормально. Насколько я знаю, KDE вполне себе все поддерживает, а что и куда он сохраняет - его личное дело. Нельзя завязываться на это. Если программы используют какие-то библиотеки KDE, чтобы с ним интегрироваться, то это их дело.

У окна в Qt есть некоторые свойства, их можно сохранить в настройки и восстановить. Но, у меня под матэ теряется номер десктопа. Т.е. положение, размер и состояние окна восстанавливается, но появляется оно на текущем открытом воркспейсе. По заверениям XMs в кедах такой беды нет, что наводит на мысль, что кеды и культи как-то разруливают этот вопрос между собой.

У окна в Qt есть некоторые свойства, их можно сохранить в настройки и восстановить.

А для окон GTK? И для Xaw тоже? :)

На восстановление свойств приложения тоже был стандарт https://en.wikipedia.org/wiki/X_session_manager , но хочу огорчить - ему тоже не все следуют, хотя хорошая была инициатива. KDE, кстати, и ему следовал, но потом начали что-то свое изобретать, завязанное на dbus. Вот как-то давно обсуждали это: [tl;dr] [KDE Daily] Сессии, переносимые между устройствами, XSMP и Вейленд

Ну вот походу ноги КДЕшно НЕпроблемы с той стороны и растут.

Даже не заглядывая в спеки, полагаю что там все описано, что мне надо:

Размер окна: высота и ширина.

Положение окна: от верхнего и от левого углов.

Номер скрина: на каком мониторе оно.

Номер десктопа: или вьпорта, как теперь выяснилось.

Состояние: обычное, распахнутое, свернутое, фуллскрин.

Мне нужно читать и писать все из перечисленных, конечно же проверяя что там поменялось кол-во воркспейсов или скринов или разрешение. Но пока не выходит. Из чистых культей доступ есть не ко всему. И опять же, по заверениям XMs оно в «приватном» режиме для КДЕ эти вопросы решает само.

Не то, чтобы я отказывался от своих слов или чего-то подобного, но где я об этом писал? А то я даже предмет диалога спустя столько времени не могу вспомнить

И опять же, по заверениям XMs оно в «приватном» режиме для КДЕ эти вопросы решает само.

Если Qt5 не имеет вообще понятия о рабочих столах (о них теперь толкьо KWindowSystem имеет понятие), то о чем «приватно» KDE может договориться с Qt, если там даже технически это знание не реализовано? Ни о чем не может.

Короче запилил я вот эти все xcb фичи и оно работало. Под Матэ. Пока я не влупил в него компиз. Вот с компизом оно вообще не работает.

Насколько я понимаю, для compiz достаточно запомнить положение окна, а desktop будет всегда равен 1. В compiz один большой рабочий стол, на котором размещены приложения. Проверь этот момент, глянь, какие координаты у приложения. Они по идее должны быть большими. Больше, чем размер экрана. Я так понимаю. Ну и восстанавливать их.