Board.KolibriOS.org

На форуме в свое время уже была тема посвященная KFM - Kolibri File Manager, которая "откинула копыта" года два назад. Впрочем нет смысла ворошить прах истории.

Итак что планируется:
1) Использование библиотеки Box_Lib - вероятно будут написаны два новых компонента progressbar и quick_chain (не знаю как оно официально там называется быстрый выбор директорий в пути).
2) Использование библиотеки LibIO, если смогу ее допилить. Также еще окончательно не решил делать распараллеливание доступа к файловой подсистеме на уровне ядра или все-же в библиотеке. Последний способ хоть и гибкий, но требует переписывания всех приложений Колибри, чтобы это действительно работало.
3) Допилить код который получил дизассемблированием Kpack, чтобы был у нас еще и упаковщик в формат 7Zip, кроме уже существующих функций распаковки в библиотеке kfar_arc. Пусть только пока LZMA, но это уже было бы хорошо.
4) Реализация предпросмотра графических файлов - это потребует допиливания библиотек от zSea.

Процесс естественно не быстрый, но мне нужно было хотя бы самому обозначить свои мысли (хотя бы и для себя - чтобы не забыть), что собственно и сделал.

Да, и поскольку вопрос многократно понимался - что старый код KFM, что новый будет выложен под BSD подобной лицензией. Все что я пишу сам будет под этой лицензией - абсолютная свобода для всех и никаких обязательств.

1.) Поддерживаю.
2.) Ну даже если перепишешь все программы на использование библиотеки, то кто помешает кому-либо написать приложение, которое будет работать с файловой системой напрямую. По-моему лучше делать распараллеливание доступа к ФС в ядре.
3.) Вообще это ты конечно огромную работу проделал, получайте новый уровень . Запаковка однозначно нужна.
4.) * в сторону * Такой большой набор библиотек для просмотра изображений, а для записи изображений так и нет ни одной библиотеки.

Как я уже говорил рад, что KFM ожидает дальнейшее развитие.

Для BMP сделать не составляет особой сложности. Другой вопрос, что у меня пока не было такой необходимости, но вообще в планах при реализации zSea было. Если потратить некоторые усилия и время можно и PNG кодер сделать. А вот с GIF и JPEG уже сложнее.

Спасибо.

Вопрос немного не в тему, но по KFM: Почему исходники KFM, Life2 и некоторых других программ не присутствуют в SVN, но находятся в ZIP-файле исходников в последней ночной сборке Diamond-а? http://diamond.kolibrios.org/nightbuild/
Я могу их добавить в SVN, или есть какая-то причина, что они не там?

Могу ответить только относительно KFM.
1) У меня не было желания размещать исходники KFM на SVN по ряду субъективных причин.
2) То что есть в дистрибутиве это не последние исходники - я в свое время начал некоторую работу, но не закончил. Потому не стал выкладывать. Потому до сих пор KFM не умеет копировать вложенные директории и файлы.
3) Никто не запрещает ничего делать с исходниками KFM - я уже несколько раз говорил что BSD подобная лицензия никого ни в чем не ограничивает. Однако поскольку программа будет полностью переписана ,то смысла заливать текущую версию нет, ибо желающих ее дорабатывать нет и вряд ли они появятся.

Просто я привык работать с SVN, ну и там есть Change log - когда кто и что поменял.
А когда исходники просто так валяются, то непонятно, какая это версия, есть ли новее, и т.д.
Ну тогда я попрошу у mike.dld аккаунт, и залью всё, что найду в исходниках, но нет на SVN.

Вообще-то я не рекомендовал бы это делать без согласия авторов кода. Относительно KFM я уже определил свое мнение, но относительно других программ стоит узнать таки мнение авторов, если они доступны для опроса. В конечном счете, если лицензия кода прямо не оговорена, то мнение авторов имеет смысл знать.

[offtop&imho]
На svn имеет смысл заливать софт который будет развиваться, а то что либо переделано будет в будущем(Mario я в тебя верю) или то что выполняет все свои требования - смысла нету.
[/offtop&imho]

Спасибо большое за ответы, но тогда я чего-то не понимаю:

Если исходный код есть в свободном доступе (не на SVN) - значит автор уже разрешает на него смотреть и его менять? Тогда какой будет ущерб, если его залить на SVN? Вот, допустим, исходный код zSea нигде не доступен, тогда логично, что на SVN его тоже нет. Но исходный код KFM находится в свободном доступе и так, SVN не делает этот доступ "более" свободным, а просто позволяет более легко просматривать его, вносить изменения (если нужно), быстро получить список изменений и их даты, и т.д. Ничего этого невозможно получить, если просто иметь ZIP файл для скачивания. Опять же, если изменение, сделанное одним человеком, приводит к багу, то другой человек сможет это сразу увидеть и исправить, что невозможно, если файл просто доступен для скачивания.

yogev_ezra
Я же написал, что ничего не запрещаю. Просто выразил свое мнение. Новый код будет абсолютно другим.
Есть желание заливай, но опять-же говорю только за KFM.

В ревизии 1792 KFM был добавлен на SVN, товарищем yogev_ezra и далее немного попилен CleverMouse для приведения некоторых названий файлов из заглавных в строчные символы.

SVN r. 1851
KFM
1) Добавлен текст лицензии к kfm.asm
2) Теперь используется стандартный macros.inc
3) Добавлен скрипт build.sh для сборки в Linux
4) Скорректирован kfm.ini

SVN r. 2148
Небольшая оптимизация процедуры поиска собственного слота в оконном стеке (старая процедура выполнялась долго) и допилен build.bat

SVN r. 2345-2346
Клавиша Backspace (стрелка влево над клавишей Enter) для выхода на уровень вверх из текущей директории в родительскую.

Круто же!

Неа, просто забывал все время добавить (вспоминаешь только когда Колибри загрузишь, а как выгрузишь забываешь), а тут сделал усилие над собой.