Прощай GnomeVFS, привет GIO/GVFS

> По моему скромному мнению наиболее правильным архитектурным решением для них является стена.

О! Вы являетесь крупным специалистом по архитектуре современных DE или аналитиком в области ИТ с мировым именем? ;)

> Простите, вырвалось :)

Не пей столько! ;)

>Ровно то же самое можно сказать насчёт glib, gtk, xmllib, libxslt, gconf, atk ,glade, cairo, pango с отрывом друг от друга. ;)

glib можно юзать без остальных,

glib+atk можно юзать без остальных

glib+gtk можно юзать без остальных

libxml2 зависит от perl, libc и sgml-base

glade зависит от gtk+glib+atk+xml+pango+cairo

pango зависит от cairo и glib

gconf - glib и xml*

cairo - от иксовых либ

так что можно, ага.

И все эти либы вместе - не будут GNOME'ом :)

>Начните с себя, делающие такие заявления про Arts. ;)

Не-е-е, кто первым написал в етом треде слово KDE?

> Никто не мешает вытащить ваш файл из архива в /tmp, если это поддерживает архиватор. FUSE для этого горидить не нужно.

Ну а ради списка файлов мне тоже всё распаковывать в /tmp? Мне нужна единообразная работа с архивом, а не "нужен список - используй tar jtf, нужен файл - используй xf"

>Какой версии? geek, ты давно из анабиоза? ;)

а на какой версии kde3.5.8? :)

>kioclient cp myfile sftp://whatever

гг. ты не в курсе, что ты kioclient без qt и kdelibs работать не будет? =)

>> Так почему бы просто не распаковать iso в /tmp или ramdisk и забыть про проблемы?

>Проблемы в скорости. Вариант с полной распаковкой медленнее. (В случае, если надо извлечь _все_ файлы - он будет только чуток быстрее)

Если архиватор поддерживает выдергивание одного файла - вытащите только его, в чем проблема? :)

Все абсолютно одинаково - что в случае userspace, что в случае userspace fuse, в последнем случае только дополнительная ядерная обвязка, а в первом случае библиотека для обработчика файлов (mc, nautilus, whatever).

>> Только в случае с MC и userspace vfs layer система не упадет из-за ошибки, если же ошибка в ядерной части fuse...

>Ядерную часть уже единожды написали. А то, что выполняется в юзерспейсе систему не порушит.

И переписали после этого... Если все будет хорошо, то нам повезет, и система не обрушится.

>Какие допущения, какая энтропия? Вы видели официальные требования на сайте KDE?

http://www.kde.org/info/requirements/3.5.php

требований openexr,avahi,jasper не нашёл

>Чужое решение, когда всё собирается именно так, как задумывалось в mainstream, меня, обычно, устраивает.

это не как "задумывалось в mainstream", а попустительство

>> Никто не мешает вытащить ваш файл из архива в /tmp, если это поддерживает архиватор. FUSE для этого горидить не нужно.

>Ну а ради списка файлов мне тоже всё распаковывать в /tmp? Мне нужна единообразная работа с архивом, а не "нужен список - используй tar jtf, нужен файл - используй xf"

Для этого и пишут библиотеки vfs - как в mc, как в total commander, как в "интернет эксплорер" и т.п.

Более того, та библиотека, которую будет загружать fuse для обработки файлов и _есть_ та самая библиотека vfs о которй я вам говорю весь сегодняшний день! Просто вызывать ее надо не из ядерных обвязок, а из файлобродилок, и все...

> glib+gtk можно юзать без остальных

Да ну? libatk >= 1.9.0 нужен для libgtk+2-2.12.1-alt1

> glade зависит от gtk+glib+atk+xml+pango+cairo

Красивый списочек. :)

P.S. В общем, связей куча и по-человечески не раздерёшь. ;)

>Ну а зачём всё так сложно, зачем вводить какой-то модуль, который будет определять что-то через /bin/file?

fuse и так дергает юзерспейс утилиты и монтировку. Почему бы и не па?

>Пользователю надо смонтировать архив как каталог - он монтирует. если потом в смонтированом окажется ещё один архив - его так же легко можно будет смонтировать.

зачем калькулятор, когда есть моск. Ну да, в принципе верно

>Описанное, наверно, для того, как представлять путь к файлу в строке адреса браузера/файлменеджера? Так?

или в них. Или в mutt. Или в cat/tail и прочем. :)

> Не-е-е, кто первым написал в етом треде слово KDE?

Не считая автора новости:

Боян, в Roadmap это еще с версии 2.18 было. Да и KDE тут совершенно ни при чем... ;)

cruxish (*) (27.11.2007 11:23:42)

>гг. ты не в курсе, что ты kioclient без qt и kdelibs работать не будет? =)

КК. В курсе. А gio без glib & gnome-libs таки будет?

>О! Вы являетесь крупным специалистом по архитектуре современных DE или аналитиком в области ИТ с мировым именем? ;)

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

> а на какой версии kde3.5.8? :)

А при чём тут KDE? Ты не отмазывайся, раз обосрался. ;)

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

Вот и выявили смутьяна.

>Да ну? libatk >= 1.9.0 нужен для libgtk+2-2.12.1-alt1

ну да, забыл.

>Красивый списочек. :)

ну так glade использует практически всё

>P.S. В общем, связей куча и по-человечески не раздерёшь. ;)

чего не раздерешь? Перечисленного достаточно для написания полноценного приложения. И это приложение не будет прибито гвоздями к гному. Ферштейн? =)

какими наборами можно юзать - я расписал.

хотя распаковка файлов через fuse все таки уродство, но это не единственное применение fuse

О! Ми рад! Ми чует будет флейм. ми принес попкорн. Ми ждет, хоть ми и пропустил начало.
<maslo_v_ogon'>GNOME - SUX</maslo_v_ogon'>

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

Троллим потихоньку? Используйте одну библиотеку во всех файлобродилках.

>А при чём тут KDE? Ты не отмазывайся, раз обосрался. ;)

вообще-то речь про кде и шла. Ы?

В общем, просуммировав тред скажу: Мне надо:

1. удобно бродить по архиву/образу диска/ftp/sftp/мобильнику из файлового менеджера

2. удобно запускать оттуда любое приложение, не обученное работать с gnome vfs или kio, и чтобы оно файл открыло.

3. удобно монтировать архив из скрипта и ходить по нему чем угодно без накладных расходов и лишних разборов типа "вот список файлов, вот эти из них мне не нужны, а вот эти я распакую, ой только б места хватило". Т.е. _одной_ командой(fusermount, например)

4. без распаковки лишних файлов(по возможности)

5. быстро

Решение я виду только одно: fuse-модули для архивов

>КК. В курсе. А gio без glib & gnome-libs таки будет?

таки будет.

> Глядя на грандиозные решения гномеров (использовать ядро для распаковки архивов) не нужно быть ни тем, ни другим, чтобы сделать вывод о развитии этого проекта :)

Вообще-то те, кто ходил по ссылкам (хотя это моветон на LOR) могли прочесть, что будет нужна FUSE, а не ядро само. Про FUSE сами почитаете?

в том то и дело, что каждая файлодробилка имеет свои странные зависимости, и в итоге, посмотрев на все остаётся только два варианта: юзать fuse, писать свою vfs.

+ мир не ограничивается одними файлобродилками.

>таки будет.

тьфу, без gnome-lib будет

openexr и jasper опциональны, включаются в ./configure

>Вообще-то те, кто ходил по ссылкам (хотя это моветон на LOR) могли прочесть, что будет нужна FUSE, а не ядро само. Про FUSE сами почитаете?

А вы в курсе, что mountpoint и структуру VFS для FUSE (т.е. возможность смотреть на что угодно как на замонтированную в какую-то директорию файловую систему) представляет ядро? По крайней мере в Linux.

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

>В общем, просуммировав тред скажу: Мне надо: >1. удобно бродить по архиву/образу диска/ftp/sftp/мобильнику из файлового менеджера >2. удобно запускать оттуда любое приложение, не обученное работать с gnome vfs или kio, и чтобы оно файл открыло. >3. удобно монтировать архив из скрипта и ходить по нему чем угодно без накладных расходов и лишних разборов типа "вот список файлов, вот эти из них мне не нужны, а вот эти я распакую, ой только б места хватило". Т.е. _одной_ командой(fusermount, например) >4. без распаковки лишних файлов(по возможности) >5. быстро

>Решение я виду только одно: fuse-модули для архивов

Это решение будет медленнее, а также будет содержать больше ошибок, чем просто использование этих самых fuse-модулей (которые есть библиотеки) из ваших файловых бродилок.

Сколько бреда из-за какой-то ху**ы!

>в том то и дело, что каждая файлодробилка имеет свои странные зависимости, и в итоге, посмотрев на все остаётся только два варианта: юзать fuse, писать свою vfs.

VFS уже есть в mc, нужно только сделать это прямее. Userspace для подобного рода приложений всегда лучше ядра, т.к. фатальность ошибки несравнимо меньше, а скорость выше.

>> Решение я виду только одно: fuse-модули для архивов

> Это решение будет медленнее, а также будет содержать больше ошибок, чем просто использование этих самых fuse-модулей (которые есть библиотеки) из ваших файловых бродилок.

То есть, против использования тут fuse Вы уже ничего не имеете?

Про глючность реализации давайте не будем, в gvfs и kio в сумме будет больше ошибок.

Медленнее - уже сто раз объясняли, что нет. В случае _полной_ распаковки архива будет примерно одинаково по времени.

Кроме того, тема пункта 2(два) не раскрыта.

openexr, mDNSresponder(avahi) - автоопределение, как и jasper наверное

>2.1. чтобы стороннее приложение, запущенное из файлобродилки при клике по файлу могло видеть все остальные файлы в том же каталоге и подкаталогах, а желательно и выше по иерархии.

В mc так и есть, сюрприз... Хотя выше не будет видеть, т.к. ментально не в состоянии проникнуть в мозг пользователя и узнать, чтобы он _хотел_ там видеть.

Впрочем, fuse тоже не умеет этого - нужно руками/скриптами монтировать, а следовательно можно распаковывать (или вытаскивать только список файлов :) vfs'ной библиотекой.

>>2.1. чтобы стороннее приложение, запущенное из файлобродилки при клике по файлу могло видеть все остальные файлы в том же каталоге и подкаталогах, а желательно и выше по иерархии.

> В mc так и есть, сюрприз...

Нет, не так. Попробуйте ввести в терминале, зайдя в архив 'ls * | grep jopa' и прочтите "невозможно исполнять команды на не локальных фс".

> Впрочем, fuse тоже не умеет этого - нужно руками/скриптами монтировать, а следовательно можно распаковывать (или вытаскивать только список файлов :) vfs'ной библиотекой.

Ну да, с вылезанием наверх я погорячился...

>> Это решение будет медленнее, а также будет содержать больше ошибок, чем просто использование этих самых fuse-модулей (которые есть библиотеки) из ваших файловых бродилок.

>То есть, против использования тут fuse Вы уже ничего не имеете?

Не fuse, а обработчиков файлов, которые в любом случае нужно вызывать - будь то из fuse (из ядра) или из vfs библиотеки (как в mc).

>Про глючность реализации давайте не будем, в gvfs и kio в сумме будет больше ошибок.

Только из-за них система не умрет.

>Медленнее - уже сто раз объясняли, что нет. В случае _полной_ распаковки архива будет примерно одинаково по времени.

Всегда будет медленнее, т.к. в ядро залезть и из ядра вылезти нужно время потратить. Согласен, что разница на некоторых типах приложений будет мала, но на других (например, где нужно работать с маленькими кусками файлов) будет очень заметно.

>Кроме того, тема пункта 2(два) не раскрыта.

Из мозиллы запускали читалку pdf? Суть одно и то же - файл во временной директории или файл во временной директории, созданной fuse.

> Впрочем, fuse тоже не умеет этого - нужно руками/скриптами монтировать, а следовательно можно распаковывать (или вытаскивать только список файлов :) vfs'ной библиотекой.

Опять поторопился. Fuse-фс, после монтирования выглядит как обычный каталог, и в нём пожелание "чтобы стороннее приложение, запущенное из файлобродилки при клике по файлу могло видеть все остальные файлы в том же каталоге и подкаталогах" выполняется. Монтировать-размонтировать можно автоматически из файлобродилки по входу/выходу из каталога.

>Нет, не так. Попробуйте ввести в терминале, зайдя в архив 'ls * | grep jopa' и прочтите "невозможно исполнять команды на не локальных фс".

Потому что не допилено... Я не ставлю mc vfs в пример, просто это одна из (кривых) реализаций. Если бы mc распаковывал архив (по мере надобности доставал файлы из него) во временную директорию, этих проблем бы не было.

Все дело в кривости vfs библиотеки.

>VFS уже есть в mc, нужно только сделать это прямее. Userspace для подобного рода приложений всегда лучше ядра, т.к. фатальность ошибки несравнимо меньше, а скорость выше.

фс fus'а и так работают в юзерспейсе, в ядре находится только основные части. Чем его код отличается от остального ядра линукса, из за чего вдруг надежность ядра резко падает?

плюс, все таки мир не ограничивается "файлобродилками", мне может удобно некоторые операции в консоли делать, а некоторые в ФМ. И тут никакая встроенная в фм vfs не спасёт.

Agree. А avahi требовался для более грамотной и современной замены kdnssd.

кстати, на мой взгляд, mc's vfs редкостное глюкалово. Да и не допилено наверное оно в силу кривости by design.

необоснованые доводы поскипаны.

>>Медленнее - уже сто раз объясняли, что нет. В случае _полной_ распаковки архива будет примерно одинаково по времени.

> Всегда будет медленнее, т.к. в ядро залезть и из ядра вылезти нужно время потратить. Согласен, что разница на некоторых типах приложений будет мала, но на других (например, где нужно работать с маленькими кусками файлов) будет очень заметно.

В обычной задаче(извлечь 5 файлов из 1000) fuse будет быстрее. Быстро просмотреть десяток разнотипных архивов - опять же fuse бытсрее.

Быстрота критична - откажитесь от fuse и пишите всё ручками. Но в обычной десктопной жизни это не поравдает надежд: писать долго, быстрее сходить через fuse.

>> Кроме того, тема пункта 2(два) не раскрыта.

> Из мозиллы запускали читалку pdf? Суть одно и то же - файл во временной директории или файл во временной директории, созданной fuse.

Причём тут мозилла? Мозилла не использует fuse.

При использовании fuse, файл будет находиться в примонтированной директории, а уж что она из себя представляет - это нам неведомо.

>Fuse-фс, после монтирования выглядит как обычный каталог, и в нём пожелание "чтобы стороннее приложение, запущенное из файлобродилки при клике по файлу могло видеть все остальные файлы в том же каталоге и подкаталогах" выполняется. Монтировать-размонтировать можно автоматически из файлобродилки по входу/выходу из каталога.

Кстати, даже в mc есть скрипты, вызываемые для обработки разных типов файлов :)

> Кстати, даже в mc есть скрипты, вызываемые для обработки разных типов файлов :)

это и есть реализация mc-vfs для архивов. убогая реализация.

>кстати, на мой взгляд, mc's vfs редкостное глюкалово. Да и не допилено наверное оно в силу кривости by design.

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

Те, кто для распаковки архивов, пользуются fuse к таковым не относятся.

>Думаю, вам заметна разница в реализации на уровне Glib, и на уровне kdelibs (которые этот самый Glib пользуют... ;)).

По-твоему Glib - это GNOME Library? Мальчег, ты ашибаишся. Во-первых, не Glib, а glib, а во-вторых, glib - это GNU Library.

GIO в идеале будет встроен в Glib. Тогда можно будет использовать единый VFS API и для консольных утилит вроде mc, и для легковесных DE вроде Xfce, и для GNOME.

И вообще, сравнивать маленькую библиотеку Glib с тулкитом Qt - это оригинально... ;)

>В обычной задаче(извлечь 5 файлов из 1000) fuse будет быстрее. Быстро просмотреть десяток разнотипных архивов - опять же fuse бытсрее.

>Быстрота критична - откажитесь от fuse и пишите всё ручками. Но в обычной десктопной жизни это не поравдает надежд: писать долго, быстрее сходить через fuse.

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

Повторю, если вам лень это делать: вам не обязательно читать все файлы из архива, если нужны только 5, и архив поддерживает частичную разархивацию - вы можете вытащить ваши 5 файлов во временную директорию и запустить с ними внешнее приложение. А потом вытащить следующие. А затем удалить директорию. И это будет быстрее fuse. Просто используйте правильную vfs библиотеку - для ядерных задач ядро, для распаковки архивов - чистый userspace.