Существует ли универсальный способ вызвать диалог выбора файла/папки в Linux?

xdg-open не? Или с вялым не работает? И вообще папка у тебя один, как и мамка, не надо папку вскрывать.

Универсального нет. Насчёт tinyfiledialogs - ты проверял что она действительно не привязана к конкретному DE? Запусти свою прогу в чистых иксах (startx /path/to/program из ядерной консоли) и посмотри как будет работать.

ты проверял что она действительно не привязана к конкретному DE?

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

GTK не предлагать?
А то есть https://github.com/btzy/nativefiledialog-extended.

Зачем нужно xdg-desktop-portal?

Работает не идеально - окно появляется не модальное, но пользоваться вполне можно

Это скорее всего работает только в DE, иначе этот диалог просто некому открывать, да и dbus нормальные люди блокируют.

tinyfiledialogs не очень-то любит этот wayland.

Ты даже не сказал какой у тебя юзкейс. Из нативного GUI приложения нужно вызвать, скрипта, или откуда? Если нативного, используй средства тулкита который используешь. Если тулкит это не умеет, смени тукит. Если скрипта, используй тот же zenity. Другой вариант я не могу даже придумать. TUI в котором хочется диалог открытия файла? Тогда никогда в жизни больше не пытайся писать код.

а использует zenity, которая опять использует кого-то там.

Zenity использует GTK. Ещё есть kdialog (KDE-Qt).

GTK не предлагать?

GTK меня устроит, потому что его можно поставить при установке пакета, даже если его нет. Не могли бы вы уточнить, наличие GTK это достаточно условие, чтобы всё работало правильно даже под Wayland ? Просто я постоянно натыкаюсь на варианты, которые работают лишь иногда.

Ты даже не сказал какой у тебя юзкейс.

Я же не для себя лично пишу программу, иначе бы и вопросов не было. Поэтому окружение может быть формально любым, но желательно, чтобы принятые решения работали если не всегда, то почти всегда. Конкретно я сижу на Fedora (одна на x11+plasma, вторая на wayland+gnome).

Из нативного GUI приложения нужно вызвать, скрипта, или откуда?

Из нативного приложения на C++

Если нативного, используй средства тулкита который используешь.

Я сейчас не использую никакой toolkit, хотя видимо придется прицепиться к gtk если нет другого универсального способа открыть диалог для выбора файлов.

Если скрипта, используй тот же zenity.

Насколько я вижу, zenity в wayland не работает, вроде бы он хочет именно XWayland.

TUI в котором хочется диалог открытия файла?

Мне только текстового варианта выбора файла не хватало в 21 веке

Тогда никогда в жизни больше не пытайся писать код.

Я обязательно глубоко обдумаю ваши слова

Не могли бы вы уточнить, наличие GTK это достаточно условие, чтобы всё работало правильно даже под Wayland ?

Не могу, не использую Wayland. В nativefiledialog-extended есть много тестов, в том числе с SDL2.

Я сейчас не использую никакой toolkit, хотя видимо придется прицепиться к gtk

В FLTK 1.4 добавили поддержку Wayland.

самый универсальный способ - по дыбасу через XDG Desktop Portal FileChooser. Не зависит от иксов с вяленым, но требует наличия этого самого xdg desktop portal

У пользователя на экране папки

Я же не для себя лично пишу программу, иначе бы и вопросов не было. Поэтому окружение может быть формально любым, но желательно, чтобы принятые решения работали если не всегда, то почти всегда. Конкретно я сижу на Fedora (одна на x11+plasma, вторая на wayland+gnome).

Я не спрашивал про твоё окружение, я спросил про задачу.

Я сейчас не использую никакой toolkit, хотя видимо придется прицепиться к gtk если нет другого универсального способа открыть диалог для выбора файлов.

Чем ты тогда вообще рисуешь в окне?

Насколько я вижу, zenity в wayland не работает, вроде бы он хочет именно XWayland.

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

самый универсальный способ - по дыбасу через XDG Desktop Portal FileChooser. Не зависит от иксов с вяленым, но требует наличия этого самого xdg desktop portal

Именно поэтому он не «самый универсальный», а «нерабочий».

Не могу, не использую Wayland.

Хорошо. И на том спасибо!

самый универсальный способ - по дыбасу через XDG Desktop Portal FileChooser.

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

Я не спрашивал про твоё окружение, я спросил про задачу.

Тогда выражайтесь яснее. Задача очевидна - в любом приложении (кроме Калькулятора) данные сохраняются в файлы и читаются из файлов. Вот я и спрашиваю, как этот вопрос решается в Linux.

Чем ты тогда вообще рисуешь в окне?

У меня свой GUI. Рисую всё изображение на поверхности, а потом копирую в окно.

Но если так и так тянуть gtk, то конечно лучше себе в приложение

Так мне пока этот GTK только и нужен для того, чтобы файлы выбирать. Поэтому и хочу обойтись.

Именно поэтому он не «самый универсальный», а «нерабочий».

Почему «нерабочий», если этот xdg desktop portal устанавливается как пакет ? Его же можно в deb/rpm пакет добавить как зависимость, и он автоматом установится вместе с приложением.

У меня свой GUI. Рисую всё изображение на поверхности, а потом копирую в окно.

Тогда не получится ли так, что сегодня тебе понадобился диалог выбора файла, завтра выбора каталога, послезавтра выбора шрифта, через неделю выбора цвета? Что в GTK, что в QtWidgets – каждая свои диалоги для этого тащит.

Можешь рассказать про свой GUI, чем существующие тулкиты не устроили?

Тогда не получится ли так, что сегодня тебе понадобился диалог выбора файла, завтра выбора каталога, послезавтра выбора шрифта, через неделю выбора цвета?

Ваш вопрос логичен. Но кроме выбора файлов или каталогов все остальные диалоги достаточно легко переписываются (я бы может и выбор файлов переписал, но там возникают дичайшие проблемы с оформлением, потому что используются иконки для разных расширений файлов, а также всякие штуки типа «Сетевое окружение», короче это неподнимаемо в том виде, к которому привык пользователь на своей машине). А так… выбор цвета у меня свой есть, а выбор шрифта с настройками типа Bold, Italic и т.д. - это у меня стандартный компонент.

Можешь рассказать про свой GUI, чем существующие тулкиты не устроили?

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

Насколько я вижу, zenity в wayland не работает, вроде бы он хочет именно XWayland.

И как это видно?

И как это видно?

В моем случае он просто зависает внутри себя в строке:

while ( fgets ( p , sizeof ( lBuff ) , lIn ) != NULL )

Я не много не про это. Могу я без удаления xwayland узнать что ему это не нужно?

Дело в том что zenity это часть gnome, и у меня в Fedora 42 заявлено что gnome полностью поддерживает wayland.

Вот я и думаю как мне проверить.

Ну, как я уже сказал, у меня на Fedora+Gnome+Wayland tinyfiledialogs не работает, а он действует через zenity.

Рабочий, просто у некоторых подгорает от любых новых решений. Хотя, справедливости ради, стоит заметить, что у XDG-порталов заслуженно не очень хорошая репутация, и часто их рекомендуют удалить. За последние года три лично я не менее двух раз маскировал (у меня GNOME, удалить не выйдет) эти сервисы, чтобы решить проблему с долгим запуском некоторых приложений. Ну и xdg-documents-portal иногда тормозит выключение компьютера. Так что неприязнь к ним не на ровном месте, но никаких альтернатив тоже нет.

За tinyfiledialogs, не скажу. Но zenity это тулза для управления диалогами и прочим из шелла. И по скольку gnome в fedora полностью работает под wayand и эта тулза тоже работает, с чего ей не работать то.

Почитал про эту tinyfiledialogs, это левая либа на си… вроде может юзать gnome, но хз какой версии.

Мне дипсик на вопрос о модальности ответил:

Чтобы сделать окно выбора файлов (XDG file chooser) модальным, необходимо указать родительское окно и установить флаг модальности. Вот как это можно реализовать в разных контекстах:

1. Использование порталов через D-Bus (низкоуровневый метод) При вызове D-Bus метода org.freedesktop.portal.FileChooser передайте параметры:

parent_window: идентификатор родительского окна.

options: словарь с ключом «modal» и значением true.

И пример на питоне:

import dbus

# Получение XID окна (пример для X11)
parent_xid = "x11:12345678"  # Замените на реальный XID

bus = dbus.SessionBus()
portal = bus.get_object('org.freedesktop.portal.Desktop', '/org/freedesktop/portal/desktop')
file_chooser = dbus.Interface(portal, 'org.freedesktop.portal.FileChooser')

options = {
    "modal": dbus.Boolean(True),
    "multiple": dbus.Boolean(False)
}

# Вызов диалога
request = file_chooser.OpenFile(parent_xid, "Open File", options)

На самом деле в выдаче были и другие варианты, но я не стал их копировать. Для ответа на вопрос модальности и этого вроде достаточно.

Сам не проверял, т.к. у меня Hyprland и в общем виде такого понятия как модальность не особо есть, либо придется правила прописывать и куча другой мороки. Да и родителя у меня нет, чтобы xid подставить.

А вот дополнение про вяленд:

4. Для низкоуровневых приложений (без тулкита) Если вы работаете напрямую с libwayland:

struct wl_surface *surface = ...; // Ваша поверхность
uint32_t surface_id = wl_proxy_get_id((struct wl_proxy*)surface);
char parent_window[64];
snprintf(parent_window, sizeof(parent_window), "wayland:%u", surface_id);

Важные замечания Окно должно быть видимым — Surface ID создаётся только после отображения окна (window.show()/present()).

Только для Wayland — На X11 продолжайте использовать x11:{xid}.

Динамическое изменение — При каждом пересоздании поверхности (например, после скрытия/показа) ID может измениться.

Безопасность в Wayland — Идентификаторы поверхностей динамичны и работают только в рамках текущей сессии.

Можете в консоле набрать:

zenity --file-selection

Важные замечания Окно должно быть видимым — Surface ID создаётся только после отображения окна (window.show()/present()).

Тут вот гугл что то намутил видео с гдиска дают смотреть а качать нет. Я в консоле разраба глянул там в оно идет кусочками по 2 и менее мегабайт (XHR):(

Лень с этим разбираться было и я поставил просто тупой записыватель экрана и …

Ну так вот к чему я это, у меня wayland и когда нажимаешь кнопку захват он спрашивает какой экран будем хватать и показывает только мой один экран ;)

zenity –file-selection

(zenity:2572): Gtk-WARNING **: 07:51:24.847: Unknown key gtk-modules in /home/supervisor/.config/gtk-4.0/settings.ini

Но, к моему удивлению, диалог выбора файлов появился.

zenity просто морда. У меня ничего не пишет, просто кажет. Кстати у тебя написано почему у вас варнинг.

Мне кажется, что deekseek немного ошибается насчет surface_id. Я вот так пробовал его получить:

void handle_exported_handle(void* data, struct zxdg_exported_v2* exported, const char* handle)
{
    fulldesktop_parent_id="wayland:";
    fulldesktop_parent_id+=handle;
}

Приходит в handle какой-то «текстовый мусор», который при использовании не дает эффекта. Мне, честно говоря, просто надоело это подбирать и я пока забросил.

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

Window 561e50147b80 -> Изменить комментарий, группа Вкладки окна — Яндекс Браузер:

Вот это вот 561e50147b80 я думаю и есть искомый айдишник.

Сам проверить не могу, т.к. в Hyprland вообще особо нет такого понятия как модальность. По крайней мере, если это не своё дочернее окно.

Хотя, справедливости ради, стоит заметить, что у XDG-порталов заслуженно не очень хорошая репутация, и часто их рекомендуют удалить. За последние года три лично я не менее двух раз маскировал (у меня GNOME, удалить не выйдет) эти сервисы, чтобы решить проблему с долгим запуском некоторых приложений.

А не является ли это linux-аналогом windows-проблемы, когда ты в её Проводнике нажал ПКМ и долго-долго ждёшь отрисовки контекстного меню, поскольку ему надо опросить кучу shell extensions?