Здравствуйте,

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

Для модального диалога делаю так:

Atom wm_type=x11_XInternAtom(display, "_NET_WM_WINDOW_TYPE", False);
Atom type_dialog=x11_XInternAtom(display, "_NET_WM_WINDOW_TYPE_DIALOG", False);
x11_XChangeProperty(display, window, wm_type, XA_ATOM, 32, PropModeReplace, (unsigned char*)&type_dialog, 1);

Atom state=x11_XInternAtom(display, "_NET_WM_STATE", False);
Atom modal=x11_XInternAtom(display, "_NET_WM_STATE_MODAL", False);
x11_XChangeProperty(display, window, state, XA_ATOM, 32, PropModeReplace, (unsigned char *)&modal, 1);

Далее ещё была идея установить общую группу для всех окон:

Atom XLeader=XInternAtom(display, "WM_CLIENT_LEADER", False);
XChangeProperty(display, window, XLeader, XA_WINDOW, 32, PropModeReplace, (unsigned char*)&leader, 1);

XWMHints h={0};
h.flags=WindowGroupHint;
h.window_group=leader;
XSetWMHints(display, window, &h);

if (mode==LINUX_WINMODE_MODAL)
        XSetTransientForHint(display, window, leader);

Здесь leader - это главное окно и этот leader устанавливается для всех существующих окон. Но модальное окно так и не стало полноценным - происходит игнорирование дополнительного окна.

Что ещё можно сделать ? Или предполагается, что нужно руками блокировать все попытки взаимодействовать с другими окнами во время появления модального диалога ?

Debian Xfce 4.18

Здравствуйте,

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

Здравствуйте,

Toolkit-ы не использую.

Самый очевидный способ - это при сборке пускового файла поставить на компьютер все нужные библиотеки x11 и wayland одновременно. Это позволяет собрать результат, но это также требует в зависимостях пакета указывать runtime-версии всех нужных библиотек опять же и под x11, и под wayland. В результате при установке пакета в систему влетят библиотеки из другого дисплейного менеджера, что вроде бы некритично, но может и не очень красиво выглядит. Это правильный способ или можно всё решить как-то изящнее? Например, можно сделать экспорт функций из runtime-библиотек, тогда эти библиотеки не будут явно требоваться при старте приложения. Плюс вроде в этом есть, но как-то всё это стрёмно выглядит. И если экспорт функций в x11 прокатывает без проблем

void* handle=dlopen("libX11.so.6", RTLD_LAZY);
    if (!handle)
    {
        fprintf(stderr, "Failed to load libX11.so.6: %s\n", dlerror());
        return false;
    }
    exp_XConvertSelection=(PFN_XConvertSelection)dlsym(handle, "XConvertSelection");
    exp_XGetWindowAttributes=(PFN_XGetWindowAttributes)dlsym(handle, "XGetWindowAttributes");

, то wayland вообще обрубил меня на первой же функции:

uint32_t wlnd_proxy_get_version(struct wl_proxy *proxy)

Даже выбросив все обращения на функцию wlnd_proxy_get_version в программе я всё равно получаю на ней ошибку линковки, потому что wayland где-то внутри всё равно к ней обращается.

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

Здравствуйте,

Я обнаружил, что в x11 вполне работает библиотека tinyfiledialogs, но она не сама открывает диалог выбора, а использует zenity, которая опять использует кого-то там. В wayland всё это уже нормально не работает, и я нашел очень сложный вариант через dbus. Работает не идеально - окно появляется не модальное, но пользоваться вполне можно. Может кто-то знает универсальный вариант попроще? Что мне больше всего сейчас не нравится так это то, что если под wayland всё же принудительно использовать x11, то открытие диалогов вообще не происходит, так как tinyfiledialogs не очень-то любит этот wayland.

Здравствуйте,

Пытаюсь заставить свою программу работать под wayland. Добрался до реализации Drag & Drop (буфер обмена уже заработал). Когда происходит Drag & Drop над моим окном, я получаю обратные вызовы enter (мышь заходит в окно) и motion (мышь двигается по окну). На них я реагирую через

wl_data_offer_accept(data_offer, serial, mime);

И если в mime я передаю NULL, то я ожидаю, что курсор станет disabled. И так и есть, но только в момент enter, а в момент motion курсор уже не меняется. Выглядит это очень нелепо, потому что получается так, что смена курсора возможна только когда мышь впервые попадает в окно.

Я вижу, что моя функция обратного вызова motion не имеет параметра serial (я его сейчас беру из функции enter), но вроде бы в новых версиях wayland этот serial уже должен быть. Попытки обновить wayland натыкаются на сообщение типа «у вас и так всё прекрасно». При этом я вижу, что, например, Code::Blocks, которым я пользуюсь, запросто меняет курсор во время Drag & Drop, когда этот курсор над его окном. Может я что-то не понимаю ? Просто у меня особых идей уже нет. Ну, неужели разработчики wayland могли сделать так, чтобы во время перемещения курсор в Drag & Drop не менялся ? Там же даже своих компонентов нет, т.е. GUI целиком пользовательский, а значит пользователь должен этот курсор менять как ему нужно.

Fedora/Gnome/Wayland

Здравствуйте

Я пытаюсь добиться, чтобы моя программа работала под Wayland (пока мне удалось запустить работу под Windows и X11). Хочу уточнить некоторые ограничения, которые, как мне кажется, в Wayland являются непреодолимыми. У меня многооконное приложение типа «одно главное окно + любое количество дополнительных окон». Дополнительные окна являются чем-то вроде «панелей», которые можно стыковать к докерам (напоминает интерфейс Photoshop-а). GUI свой, поэтому я рисую в окне всё, что хочу. Но с Wayland возникают большие проблемы.

1. Я не вижу возможности гарантированно обнаружить нажатие кнопки «свернуть окно». Да, одно окно, на котором эта кнопка нажата свернётся, но остальные останутся на экране. Вроде бы есть состояние XDG_TOPLEVEL_STATE_MINIMIZED, но, как я понял, оно не приходит почти нигде. А другого способа вообще не видно.

2. Как я понимаю, окна в wayland нельзя перемещать по глубине. Соответственно, запросто возможна ситуация, когда дополнительные окна оказываются под основным, о чем я даже не узнаю. Это совсем плохо.

3. Существует проблема с ALT+TAB, потому что wayland нельзя указать какое именно окно там показывать, а значит он может выкинуть туда все окна сразу. Правда, вроде бы есть вариант с помощью xdg_toplevel_set_app_id() указать одинаковый id для всех своих окон, что в теории должно остановить wayland от показа всех окон сразу по ALT+TAB.

Это тот минимум, в который я пока упёрся. Если я что-то неверно понимаю, то прошу мне объяснить этот вопрос. Я могу рисовать все «панели» внутри главного окна, но это портит всю концепцию, так как «панели» полезут на рабочую область главного окна. Единственное что приходит в голову - это развернуть окно на весь экран превращая его в «рабочий стол» и по нему уже расставлять другие окна. Но это какой-то «крайний случай»…

Всем спасибо!

Здравствуйте,

Мне требуется, чтобы диалоговое окно работало в модальном режиме, т.е. захватывало управление и не позволяло получать фокус другим окнам до момента своего закрытия. Можно ли такое поведение реализовать в X11? Самое просто, что приходит в голову это всем другим окнам приложения установить режим Disabled, но, как я понимаю, тут такого нет. Мои попытки использовать XGrabPointer() и XGrabKeyboard() вообще не дают какого-то результата - при щелчке по другому окну фокус ввода уходит к нему. Есть версия, что надо закрыть весь рабочий стол прозрачным окном типа InputOnly, чтобы оно принимало все сообщения будучи невидимым. И через него передавать события модальному окну. Либо закрыть все другие окна приложения такими же окнами с такими же размерами, чтобы они блокировали ввода имитирую Disabled. Но, честно говоря, такое «шаманство» как-то уж очень напоминает «костыли», на мой взгляд. В общем как это делается в X11?

Здравствуйте

Имеется окно, у которого нет заголовка и бордера. Всё изображение внутри окна рисуется через OpenGL, включая собственный заголовок и кнопки типа развернуть/свернуть. И всё вроде бы более-менее работает, но есть большая проблема с тем, чтобы поставить окно в нужное место на экране. В первую очередь это необходимо, чтобы тащить окно мышью за собственный заголовок, но не тут-то было. Окно при перетаскивании дребезжит по всему экрану, хотя и перемещается в нужную сторону. Само перемещение делается сейчас так:

// Изменение положения окна на рабочем столе
void GPlatformUnixOGL::SetWindowRect(CMagicRect* rect)
{
    int wi=rect->Width();
    int he=rect->Height();

   XMoveResizeWindow(display, window, rect->left, rect->top, wi, he);

    XFlush(display);
}

Попытки делать что-то типа override_redirect=True; приводят к тому, что окно нельзя свернуть, хотя дребезга и становится меньше.

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

Само окно создается так:

int glxAttribs[]={
GLX_RGBA,               // Используем режим RGBA
GLX_DOUBLEBUFFER,       // Двойная буферизация
None                    // Завершаем список атрибутов
};

// Выбираем визуальный формат
XVisualInfo* visualInfo=glXChooseVisual(display, screen, glxAttribs);

Window rootWindow=RootWindow(display, screen);
XSetWindowAttributes windowAttributes;
windowAttributes.colormap=XCreateColormap(display, rootWindow, visualInfo->visual, AllocNone);
windowAttributes.background_pixmap=None;  // ОТКЛЮЧАЕМ очистку фона!
windowAttributes.backing_store=Always;    // Просим X11 сохранять буфер окна

window=XCreateWindow(
display,
rootWindow,
wx, wy, view_width, view_height, // Позиция и размер окна
0,                               // Без границы
visualInfo->depth,               // Глубина цвета
InputOutput,                     // Тип окна
visualInfo->visual,              // Визуальный формат
CWColormap | CWEventMask,        // Устанавливаем атрибуты окна
&windowAttributes
);


// Указываем тип окна NORMAL
Atom wmWindowType = XInternAtom(display, "_NET_WM_WINDOW_TYPE", False);
Atom wmWindowNormal = XInternAtom(display, "_NET_WM_WINDOW_TYPE_NORMAL", False);
XChangeProperty(display, window, wmWindowType, XA_ATOM, 32, PropModeReplace, (unsigned char *)&wmWindowNormal, 1);

// Отключаем рамки и заголовок
Atom motifHints = XInternAtom(display, "_MOTIF_WM_HINTS", False);
struct {
long flags;
long functions;
long decorations;
long input_mode;
long status;
} hints = { 2, 0, 0, 0, 0 };
XChangeProperty(display, window, motifHints, motifHints, 32, PropModeReplace, (unsigned char *)&hints, 5);

XSizeHints *h = XAllocSizeHints();
h->flags = PPosition | PSize | PResizeInc | PBaseSize;
h->x = 100;          // Координаты X
h->y = 100;          // Координаты Y
h->width = 640;      // Ширина окна
h->height = 480;     // Высота окна
h->base_width = 640; // Базовая ширина
h->base_height = 480; // Базовая высота

XSetWMNormalHints(display, window, h);
XFree(h);

Здравствуйте

К сожалению, не могу обойтись без wxWidgets. На Debian, Mint и Fedora всё более-менее работает, но стоит взять какую-нибудь менее известную OS типа Peppermint OS (X11), как приложение схлопывается в момент создания wxGLCanvas. Сообщение гласит следующее: «Assert failure» failed in InitVisual():Failed to get an EGLConfig for the requested attributes.

Я использовал атрибуты по умолчанию, которые выглядят вот так:

int attr[]={WX_GL_RGBA, WX_GL_DOUBLEBUFFER, 0};

Но пробовал и варианты типа:

int attr[] = { WX_GL_RGBA, WX_GL_MIN_RED, 8, WX_GL_MIN_GREEN, 8,  WX_GL_MIN_BLUE, 8, WX_GL_MIN_ALPHA, 8, WX_GL_DOUBLEBUFFER, 0 };

Эффект нулевой. Может быть дело в том, что я всё на вируталке гоняю, но вроде пример от OpenGL с «вращающимися шестеренками» вполне работает.

Мне просто непонятно, я это виноват или может этот wxWidgets где-то работает, а где-то не считает нужным. Ставить все разновидности Linux-а с разными дисплейными менеджерами это всё же перебор. У меня сейчас запускается в 50% случаев (имеется в виду на разных OS), причем ошибка вылезает везде одна и та же, что настораживает.

P.S. Хотел скриншот добавить, но не понимаю, как это сделать и можно ли вообще это сделать.

Здравствуйте,

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

Я делаю следующее. Этот файл при установке пакета автоматически копируется в /usr/share/mime/packages

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
	<mime-type type="application/x-manual-mmn">
		<comment>Magic Manual File</comment>
		<glob pattern="*.mmn"/>
	</mime-type>
</mime-info>

Также автоматически копируются иконки в:

/usr/share/icons/hicolor/16x16/mimetypes/application-x-manual-mmn.png
/usr/share/icons/hicolor/32x32/mimetypes/application-x-manual-mmn.png
/usr/share/icons/hicolor/48x48/mimetypes/application-x-manual-mmn.png

Пробовал поставить nautilus - иконка выглядит такой же пустой.

Рядом с моими настройками лежат настройки codeblocks-а и иконки лежат там же, но я создал файл с расширением cbp и на нем тоже пустая иконка. Сам codeblocks почему-то схлопывается после запуска.

Экспериментирую на новой Mint-64 на виртуалке.

В чем может быть дело ?

Здравствуйте,

Не могу понять, как подключить wxWidgets без его установки в систему. На сайте авторов нашел только пример с подключением либо через CMake строками типа:

find_package(wxWidgets REQUIRED COMPONENTS gl core base)
if(wxWidgets_USE_FILE) # not defined in CONFIG mode
	include(${wxWidgets_USE_FILE})

либо в Code::Blocks-е я пишу особые флаги для сборки. Для линковщика:

`wx-config --libs std,gl`

а для компилятора:

`wx-config --cflags`

Да, это всё отлично работает, но мне бы сильно упростило жизнь ситуация, когда можно просто таскать этот wxWidgets с собой.

Если я собираю динамические библиотеки и пытаюсь их подключить, то проблема возникает уже на этапе подключения заголовков, потому что требуемый файл setup.h вообще отсутствует в папке include. Да, там по разным папкам раскидано несколько setup.h, но непонятно какой брать и можно ли так вообще делать. Я с одним попробовал, но опять вылезла ошибка причем компилятор упёрся в текст:

#error "No Target! You should use wx-config program for compilation flags!"

Я понимаю, что там есть некая программа wx-config, но я не понимаю, как её применить для моего случая.

Вопрос касается как Unix-ов, так и MAC-а (проблема абсолютно одинаковая). С Windows-ом всё заработало, а здесь…

Проверял на Debian-64, до этого пытался на Fedora-64.

Здравствуйте,

Имеется программа, которая вполне уже работает. Разработка делалась на Windows, но хотелось бы всё это запустить и на Linux-ах с Mac-ом. Пришлось озаботиться созданием пакетов на Linux-е.

Сейчас использую Fedora-64 на вируталке. Нашел инструкцию по созданию deb-пакетов. Пакет вроде как создался, но при попытке его установить через sudo dpkg -i mdev_0.1_amd64.deb получаю сообщения, что нужные пакеты freetype и wxwidgets отсутствуют.

dpkg: dependency problems prevent configuration of mdev:
 mdev depends on freetype; however:
  Package freetype is not installed.
 mdev depends on wxwidgets; however:
  Package wxwidgets is not installed.

Однако команда rpm -qa показывает, что пакет freetype уж точно установлен:

freetype-2.6.5-9.fc25.i686

Да и wxWidgets тоже есть, иначе бы программа не запускалась.

В файле control пакета я, действительно, вписал строчку:

Depends: freetype, wxWidgets

Но как бы они же установлены.

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

Короче, я не понимаю принцип, как это надо делать правильно. Или надо делать под каждый пакетный менеджер отдельно ? В общем хотелось бы получить хоть какое-то универсальное решение.

Здравствуйте,

Имеется скрипт sh, который сначала запускает CMake, а потом make, собирая таким образом пусковой файл проекта. Всё это вполне хорошо работало ровно до того момента, пока я не поместил этот скрипт в автозапуск через crontab. В результате таким способом проект не собирается, так как CMake выдает ошибку в стиле «некорректная конфигурация». Непонятно, каким образом рабочая конфигурация при автозапуске становится некорректной. Везде стоят абсолютные пути, пауза на запуск скрипта в 30 секунд имеется, дабы OS успела стартануть (пробовал ставить паузу полторы минуты, но толку нет).

CMake версии 3.30.3. В качестве OS используется Fedora на виртуалке. Результат в виде лога с ошибкой, который выдает CMake, можно увидеть здесь: https://www.astralax.com/temp/CMakeOutput.log

Сам CMakeLists.txt выглядит так:

cmake_minimum_required(VERSION 3.8)

set(CMAKE_C_FLAGS "-m64")
set(CMAKE_CXX_FLAGS "-m64")

project("mgcore")


SET(SOURCE "Backup.cpp" "Component.cpp" "Core.cpp" "Editor.cpp" "Graphics.cpp" "Magl.cpp" "Root.cpp" "stdafx.cpp" "Surface16.cpp" "Surface32.cpp" "Theme.cpp" "ThemeWindows.cpp" "utils.cpp" "VirtualDrive.cpp" "font/Font.cpp")

SET(HEADER "Backup.h" "Component.h" "Core.h" "dcrt.h" "Graphics.h" "Magl.h" "mgdv.h" "Root.h" "stb_image.h" "stb_image_write.h" "stdafx.h" "Surface16.h" "Surface32.h" "targetver.h" "Theme.h" "ThemeWindows.h" "utils.h" "VirtualDrive.h" "font/Font.h" "font/ft2build.h")

add_library(${PROJECT_NAME} ${SOURCE} ${HEADER})

include_directories(include)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED on)
add_definitions(-D_LIB -D_UTF8_ -DFREETYPE -DMD_APPLICATION -DMD_UNIX -DMD_CMAKE -DMD_X64)

target_compile_definitions(${PROJECT_NAME} PRIVATE
PUBLIC
$<$<CONFIG:Debug>:MD_DEBUG _DEBUG>
$<$<CONFIG:Release>:MD_RELEASE>
$<$<CONFIG:RelWithDebInfo>:MD_DEBUG _DEBUG>
$<$<CONFIG:MinSizeRel>:MD_RELEASE>
)
target_include_directories(${PROJECT_NAME} PRIVATE ./ font)

target_link_directories(${PROJECT_NAME} PRIVATE ${CMAKE_SOURCE_DIR})

Здравствуйте,

Пытаюсь открыть папку командой: execlp(«xdg-open», «xdg-open», «/root/Desktop/mtest/Project/DATA», NULL); Но почему-то вылезает MessageBox с сообщением «Malformed url» При этом если напечатать в Терминале: xdg-open /root/Desktop/mtest/Project/DATA , то папка отлично открывается.

В идеале нужно ещё не просто папку открывать, а выделить в ней нужный файл, но это уже вторая задача.

Пробую на Fedora-64, но нужно, чтобы везде работало, ну или почти везде.

Добрый день

Пытаюсь добиться сборки 32-битного варианта приложения (64 бита собирается без проблем). Использую CMake, который генерирует проект для GCC.

В файл CMake-а добавляю строку: set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS «-m32» LINK_FLAGS «-m32») На это CMake выдает ошибку: CMake Error at CMakeLists.txt:8 (set_target_properties): set_target_properties Can not find target to add properties to: mgcore

Как я понимаю, нет пакета для сборки в 32-битном режиме. Нахожу совет за 2023 год конкретно для Fedora, т.е. недавний: sudo dnf install gcc-multilib На это получаю сообщение об отсутствии такого пакета.

Разные вариации вариантов типа: sudo apt install gcc-multilib или sudo apt install g++-multilib тоже не работают, потому что apt на Fedore не хочет работать в принципе, а попытка подсунуть вместо него yum или apt-get также ведут к ошибке типа «такого пакета нет».

В Windows назначить иконку exe-шнику не вызывает вопросов, так как картинки можно поместить внутрь файла. В Unix-е же я вижу, что нужно использовать некий файл .desktop, который надо поместить в определенное место, потом внутри прописать путь к файлу иконок (не понимаю, почему путь только один, ведь иконок может быть много для разных размеров). И как бы очевидно, что для всего этого нужна установка программы. Кроме того, как я понимаю, всё это опять же привязывается к конкретному пути, по которому находится программа и если папку переместить, то опять всё перестанет работать. Видимо ответ на мой вопрос «нет», но на всякий случай решил уточнить.

Есть OS Fedora на виртуалке. Собираю свой проект, который использует библиотеку freetype. Сам freetype установлен, но мне надо, чтобы использовалась именно libfreetype.so, которая помещена мною в каталог проекта. Проблема в том, что когда проект собирается, то линковщик действительно ищет эту библиотеку в папке проекта, но при запуске собранного файла ему мой libfreetype.so становится не нужен. Я пробовал переименовывать эту свою libfreetype.so в 1.so и тогда проект не собирается, т.е. надо внести изменения и в проект, т.е. тоже там вписать 1.so. Тогда сборка проходит, но после этого 1.so можно вообще удалять - программа всё равно запускается. И я не понимаю, в чем тут дело. Конечно есть варианты: либо у меня эта so каким-то образом является статической, либо она-таки «смотрит» на установленную версию freetype-а.

Если кто-то знает, как это всё в тонкостях работает на linux-ах, то буду рад послушать. Кстати, если кто-то знает, как корректно удалить установленный freetype с Fedor-ы, то это тоже полезная информация.