Технически вы ничего не можете предотвратить, поскольку WM могут делать все, что хотят, но наиболее разумные оконные менеджеры позволят вам это контролировать.
Предпочтительный современный способ сделать это - установить семантический тип _NET_WM_WINDOW_TYPE, если любой из них применим. Например, во многих WM тип диалога может подразумевать не максимизируемый.
http://standards.freedesktop.org/wm-spec/1.3/
Похоже, что ни один из них не применим к вашему приложению, хотя, вероятно, вам придется установить конкретные подсказки.
Чтобы избежать максимизации, вы просто хотите, чтобы окно не изменяло размеры. Как вы обнаружили, «борьба» с изменением размера путем изменения размера назад - плохая идея. Среди прочего, он имеет потенциал бесконечного цикла.
XSetWMSizeHints () - правильный способ избежать максимизации. Установите минимальный размер = максимальный размер. вуаля, не изменяемого размера.
Чтобы избежать минимизации, вы должны использовать немного старого унаследованного фрактала, называемого подсказками Mwm. К сожалению, это включает в себя вырезание и вставку определения структуры, а затем установку свойства для битов структуры.
Я только что гуглил MWM, намекает на документы, и один из результатов - это то, что я предложил их документировать, 9 лет назад ;-)
http://mail.gnome.org/archives/wm-spec-list/2001-December/msg00044.html
К сожалению, ни один из результатов не является действительным документом.
Вы, вероятно, можете понять это из http://git.gnome.org/browse/gtk+/tree/gdk/x11/MwmUtil.h и gdk_window_set_mwm_hints () http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkwindow-x11.c#n4389
MwmUtil.h - это структура, которая вырезана и вставлена везде (в большинство WM и наборов инструментов).
Подсказка _NET_WM_ALLOWED_ACTIONS устанавливается в вашем окне с помощью WM , указывая, какие функции WM решил добавить в окно. Основная цель этой подсказки заключается в том, что пейджеры, списки задач и другие компоненты рабочего стола могут затем предложить соответствующие действия для окна.
Спецификациями, которые охватывают все это, являются ICCCM (старая спецификация, все еще в основном действующая) и EMWH (новые расширения и уточнения, так как ICCCM оставил множество вещей без внимания).
Для подробностей, попробуйте исходный код ... например, recalc_window_features () в файле metacity's window.c, в настоящее время в строке 6185 http://git.gnome.org/browse/metacity/tree/src/core/window.c#n6185
Философская корректировка при кодировании X: пробег зависит от оконного менеджера. «Основные», которые обычно используют многие люди, будут следовать спецификациям и работать так, как вы и ожидаете. Тем не менее, есть все виды WM, некоторые сломаны, другие намеренно причудливы. Худшее, что вы можете сделать, это попытаться «бороться» или работать вокруг WM, потому что в основном все способы, которые это делают, могут привести к поломке приложения при работе с нормальным WM. Лучше всего сделать так, чтобы все соответствовало спецификациям, работало с обычными WM, и если вы расстроили пользователей тем, что они могут изменить размер вашего не изменяемого размера окна, потому что это позволяет их WM, вы просто должны сказать им, чтобы они жаловались тому, кто предоставляет эту WM. , Весь смысл подключаемого дизайна WM заключается в том, что WM определяет некоторые из этих действий, а не приложение.
Удачи. Современный X довольно сложен, и кодирование Xlib без инструментария вроде бы требует, чтобы все было ... не совсем правильно. Но вы, вероятно, можете сделать это достаточно хорошо. : -Р