add fuse backend

[unxed]

Кому-нибудь известна нормальная документация по API FUSE в клиентской части? Чтобы монтировать/размонтировать не вызовом сторонних приложений, а как положено. Все, что попадается -- это как написать свою файловую систему.

Тогда FUSE можно было бы достаточно дешево интегрировать: написать аналоги GvfsService и GvfsServiceMonitor и добавить соответствующие методы в MountPoint. Ну и еще как-нибудь организовать выбор: что использовать для монтирования. Очевидный вариант -- по схеме в URL.

...

sshfs [...] Оттуда больше подходит
https://github.com/libfuse/libfuse/blob/master/util/fusermount.c

С выбором по схеме на первый взгляд можно так: sftp -- gvfs, sshfs -- fuse. А в идеале так: "показываешь" URL некоему методу на основе библиотечных. Если библиотека может его обработать -- используем ее, нет -- пробуем другую. Совершенно прозрачно для пользователя.

elfmz/far2l#247 (comment)

[unxed]

По поводу API vs console - справедливо, если API работает стабильно (а в случае с gio, я так понимаю, какие-то глюки в принципе не устранимы из-за не решенных проблем на стороне gio). А вот вероятность того, что популярная тулза командной строки попадёт в релиз дистрибутива не работающей или с глюками на типовых сценариях использования - имхо, существенно меньше. Ну и если это не такой API, в котором никто, кроме разработчиков собственного консольного клиента, так и не смог разобраться, как использовать его правильно :)

И ещё одна штука. Опции монтирования (в пользовательском интерфейсе), которые могут быть доступны или не доступны в зависимости от бекенда. Скажем, те же доп.опции fuse, которые sshfs даёт задавать, а gvfs нет. Как должен себя вести прозрачный автовыбор бекенда, если для шары заданы опции, которые поддерживает только конкретный бекенд? Отказываться монтировать другими способами? Монтировать, но предупреждать пользователя, что из-за отсутствия, скажем, нужных пакетов в системе монтируем как можем, а не как прошено?

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

[asimonov]

not sure I am following... do you want essentially create a plugin with interface like SFTP (saved credentials/urls -> open -> work with files), but instead of sftp use fuse underneath?

if so, that would be brilliant!

[unxed]

@asimonov far-gvfs is already doing this, and doing almost well, using gio. This issue is about adding another backend, sshfs, for systems which do not have gvfs available, for example.

[cycleg]

Что-то у разработчиков Гнома дела совсем туго идут. Уже год не могут починить сайт документации, потому что сгинули сопровождающие:
https://gitlab.gnome.org/Infrastructure/library-web/issues/12
И что теперь, руками документацию из исходников собирать? А она наверняка под какое-то их окружение заточена.
Старую ошибку и не думают исправлять.

[unxed]

Насколько смелым будет предложение рассмотреть в качестве варианта бэкенда kio или как-там-его-зовут-кдешную-альтернативу?

Не знаю за всю KDE, но Qt как-то в последнее время выглядит более перспективным тулкитом.

[cycleg]

Насколько я понимаю, у KIO другая идеология: "This framework implements almost all the file management functions you will ever need". Т.е. KIO -- это и есть менеджер файлов, по сути. Если отбросить его поддержку GUI, то остается пачка классов, которая реализует операции над файлами, в том числе, по сети: KIO::directorySize(), KIO::del(), KIO::copy() и т. д.

Интеграция KIO в far2l -- это выкинуть все реализованные в far2l манипуляции с файлами и файловыми системами, включая сеть, архивы и прочее, и оставить только пользовательский интерфейс. Будет Dolphin в стиле Norton Commander. :) С другой стороны, это решает массу проблем, например, предоставляет почти халявную кроссплатформенность, поскольку KIO писана поверх Qt.

Но тогда это уже будет не порт Far Manager, а совершенно самостоятельное Qt-приложение, которое копирует внешность Far Manager, ибо от кода far2l сохранится не многое.

[unxed]

Ну, я-то всяко имел в виду не это)) ок, ясно)