Double Commander

[Alexx2000]

alexs в RxDBGrid, ты что-нибудь сделал, для ускорения этого дела или все также плохо, и надо просить разработчиков чтоб оптимизировали?

[alexs]

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

[shade]

Решил всё-таки начать писать свой файловый менеджер - mxcmd. Куча наворотов мне не нужна, зато нужен некоторый базовый функционал, в частности поддержка функций svn-клиента.

В частности решил сначала поэкспериментировать с Subversion Client API. Портировал часть заголовочных файлов svn и apr на паскаль
см. svn://shamangrad.net/mxlib/trunc/subversion и svn://shamangrad.net/mxlib/trunc/apr
Начал с браузера репозитария, что из этого вышло см. http://download.shamangrad.net/mxcmd/rc ... ux.tar.bz2



Так что если кто-то захочет реализовать поддержку svn-клиента в Double Commander, то можете позаимствовать код

[Attid]

shade
про апи это конечно хорошо. а вот менеджер ? зачем ?
мне рапидсвн хватает , вот только жаль что у него функционал под венду хуже. причем на таких глупостях =(

я понимаю еще в лазарь встроить, а так ?

[shade]

про апи это конечно хорошо. а вот менеджер ? зачем ?
мне рапидсвн хватает , вот только жаль что у него функционал под венду хуже. причем на таких глупостях =(

А мне вот не хватает
Вообще все гуевы svn-клиенты пол линух которые я видел, выглядят как браться близнецы... и мне совершенно не подходят. В частности ни в одном svn-клиенте под линух не видел репо-бразузера - типа того, что есть в Тортиле. Я почти год работал на связке Total Commander + TortoiseSVN, перейдя на Linux мне очень их не хватает - к хорошему быстро привыкаешь. Вот и решил сделать гибридную тулзу - двух панельный файл менеджер и svn-клиент в одном флаконе. Короче я понял, что файл менеджер и svn-клиент должны быть одной тулзой или по крайней мере тестно связанными...

Да и вообще, пока так и не смог найти себе номрального гуевого коммандера под линух... так и пользуюсь mc - уже надоело. А Double Commander у меня пока доверия не вызывает, да и внешний вид отпугивает. Можно, конечно, и дальше ковыряться и разабираться в его сорсах, но мне проще написать свой путь и ограниченный, но удовелетворяющий всем моим требованиям коммандер. Короче пишу чисто для себя и меня совершенно не беспокоит факт будет ли он ещё кому-нибудь нужен или нет.

[bw]

> Да и вообще, пока так и не смог найти себе номрального гуевого коммандера под линух... так и пользуюсь mc - уже надоело.
Как я тебя понимаю . Та же проблема.

..bw

[Attid]

**А Double Commander у меня пока доверия не вызывает, да и внешний вид отпугивает.

в трекер, в трекер =)

**Я почти год работал на связке Total Commander + TortoiseSVN,
а если ТС в вайне и плагин для свн.

**Короче я понял, что файл менеджер и svn-клиент должны быть одной тулзой или по крайней мере тестно связанными.
а в чем прелесть то раскажи, может оно и правда удобно а я не в курсах =)

[B4rr4cuda]

Доброго времени суток.
Сразу хочу сказать: спасибо за работу над гуевым файл-менеджером под лин .
Я думал, мне одному так не хватает Тотала.

Теперь по теме:
Во первых хочу спросить, какие у вас планы насчет встроенной консоли?
Если в винде консоль иногда нужна, то в лине без неё вообще никак.
Оптимально будет наличие миниконсольки вместо комстроки + полноэкранная консоль (крусайдеровсий вариант).

Еще рекомендую почитать нижеследующие ветки форума wincmd.ru. Среди флейма и полемики высказаны очень здравые мысли, которые можно применить в разработке.
Интерфейсные плагины
Мечтаем об идеальном файловом менеджере
Обсуждение возможных улучшений работы с консолью для TC7.5

[Attid]

Мечтаем об идеальном файловом менеджере

просит пароль, региться лень, в двух словах что там ?

Во первых хочу спросить, какие у вас планы насчет встроенной консоли?

если в трекере нет, то никаких, добавляй туда как руки дойдут так и посмотрим =) это же опенсурс =)

[Alexx2000]

Мечтаем об идеальном файловом менеджере

просит пароль, региться лень, в двух словах что там ?

В двух словах не выйдет, там 7 страниц рассуждений

Во первых хочу спросить, какие у вас планы насчет встроенной консоли?

если в трекере нет, то никаких, добавляй туда как руки дойдут так и посмотрим =) это же опенсурс =)

Конечно хотелось бы, но планов действительно пока нет

[Attid]

Конечно хотелось бы, но планов действительно пока нет Sad

ты как-то не правельно выразился, планов про консольку нет, а по проэкту есть, чтоб работал =) даже помнится роадмеп составляли =)

[Alexx2000]

Конечно хотелось бы, но планов действительно пока нет Sad

ты как-то не правельно выразился, планов про консольку нет, а по проэкту есть, чтоб работал =) даже помнится роадмеп составляли =)

Это я и хотел сказать

[B4rr4cuda]

Позволю себе процитировать здесь самые важные на мой взгляд цитаты с вышеназванных топиков. Но как вы понимаете, это всего лишь несколько цитат. Читать желательно весь тред, тк многие идеи не выдрать из контекста беседы.

По большому счету, нормальный ФМ сегодня должен быть только ядром, которое будет обеспечивать связь между тремя видами плагинов -
1. Хранение данных (файловые системы, архивы)
2. Отображение данных (панели, быстрый простмотр, метаданные)
3. Функциональные (копирование, MRT, поиск)
Еще должен быть пристойный внешний интерфейс.
Ну можно и скриптовый язычок добавить.

Главное - АПИ нормальные, "для всего". Внутренняя поддержка всех фич NTFS тоже необходима, как и команды с параметрами и нормальные хоткеи (чтоб ВСЕ переопределяемыми были)

При этом необходимо сделать так, чтобы плагины могли использовать встроенные диалоги (копирования и т.д.), - реализовывать надо через команды с параметрами.
...
Например, какие плюсы и минусы встроенной работы с zip? Так ли необходимо создание *.lnk, crc, uue, разбиение на файлы именно в самом тотале? Ведь для этого легко создать плагины...
Вот если реализовать плагин по типу утилиты NTFS links, только создающий действительно все типы линков, т.е. *.lnk, софт-, хард- и новейшие какие-то там, Lefteous'ом на оффоруме перечисленные? А вдруг юзеры будут от этого монстра использовать только создание *.lnk? Это ведь достаточно редкое действие - может, юзеры потерпят? Или оно достаточно частое, и надо его реализовать в ядре ФС (как один из встроенных плагинов копирования, который, в силу использования команд с параметрами, можно всё равно будет вызывать по хоткею, как сейчас)?
...
Хмм, вот копирование на/с FTP тоже меняет явно состояние ФС, но, видимо, работа с фтп может быть вполне реализована через wfx+wdx.

Обсуждается добавление WDX апи к WFX.

========
Цитата:
Поэтому был выбран путь более сложный для плагинописателей, но более понятный для пользователей, и, к тому же, не несущий в себе потенциальных проблем совместимости плагинов
==========
Но и более тупиковый. Сейчас куски API начали, опасно размножаться. Первым звоночком была функция FsGetPreviewBitmap, которая нагло приперлась из листерных плагинов, и расселась, как у себя дома, а уж когда я увидел как меня окружает стая FsContentХХХ, злобно щелкая челюстями...

Например, Гислер говорил, что доступ ТС к FTP сделан в виде "внутреннего плагина". А чего бы не сделать в виде внешнего? Другой пример - стоит у меня диск с Линуксом. Почему не иметь возможность вставить плагин для его разделов не на уровне WFX, а на том же уровне где организована работа в FAT или NTFS? И тогда, чтобы посмотреть картинку мне не нужно будет копировать ее на раздел FAT.

Теперь пару своих мыслей:
1. Плагин-АПИ. Это отлично если Тоталовские плаги будут работать. НО, у тоталовского апи очень много ограничений. Оптимально было бы поддерживать Тоталовский апи в режиме совместимости и добавить свой расширенный апи интерфейс. А потом когда какой-нить плаг будет стабилен и соответствовать условиям лицензии, его можно будет включить в фм.

2. Мелькнула мысля о тоталовских листер плагинах. Среди них есть очень хорошие вещи. И если в винде их можно будет пользовать напрямую, то в линуксе.. хм.
Хочу спросить, возможна ли реализация листер плагина-обертки используя winelib?

3. Плаг cpio. При компиляции три ошибки,
строка 156 и 164 заменяем

Код: Выделить всё

Val(tmp_buf, value, code);

на

Код: Выделить всё

Val(StrPas(tmp_buf), value, code);

и переименовываем cpio.res в cpio.RES (либо в коде меняем с {$R *.RES} на {$R *.res}).
Компилится нормально, но показывает пустые архивы. В коментах автор указал что имена путей начинающиеся с / (те линуховые) не обрабатываются. Дальше уже не копал.

[Alexx2000]

Позволю себе процитировать здесь самые важные на мой взгляд цитаты с вышеназванных топиков. Но как вы понимаете, это всего лишь несколько цитат. Читать желательно весь тред, тк многие идеи не выдрать из контекста беседы.

По большому счету, нормальный ФМ сегодня должен быть только ядром, которое будет обеспечивать связь между тремя видами плагинов -
1. Хранение данных (файловые системы, архивы)
2. Отображение данных (панели, быстрый простмотр, метаданные)
3. Функциональные (копирование, MRT, поиск)
Еще должен быть пристойный внешний интерфейс.
Ну можно и скриптовый язычок добавить.

1. Уже есть, только надо доработать интерфейс плагинов ФС
2. С этим будут проблемы
3. Реализовать не сложно, остается разработать API

Главное - АПИ нормальные, "для всего". Внутренняя поддержка всех фич NTFS тоже необходима, как и команды с параметрами и нормальные хоткеи (чтоб ВСЕ переопределяемыми были)

Команды с параметрами сделать тоже просто.

Теперь пару своих мыслей:
1. Плагин-АПИ. Это отлично если Тоталовские плаги будут работать. НО, у тоталовского апи очень много ограничений. Оптимально было бы поддерживать Тоталовский апи в режиме совместимости и добавить свой расширенный апи интерфейс. А потом когда какой-нить плаг будет стабилен и соответствовать условиям лицензии, его можно будет включить в фм.

Я уже думал об этом, пару функций к WCX интерфейсу добавить надо, для работы в несколько потоков.

3. Плаг cpio. При компиляции три ошибки,
строка 156 и 164 заменяем

Код: Выделить всё

Val(tmp_buf, value, code);

на

Код: Выделить всё

Val(StrPas(tmp_buf), value, code);

А у меня и так компилируется, при условии если стоит режим совместимости с Делфи

и переименовываем cpio.res в cpio.RES (либо в коде меняем с {$R *.RES} на {$R *.res}).

И правда надо, а раньше и так нормально было

Компилится нормально, но показывает пустые архивы. В коментах автор указал что имена путей начинающиеся с / (те линуховые) не обрабатываются. Дальше уже не копал.

Проверял на пакетах которые у меня есть, все нормально было.
А обработку путей подправлял немного.

[B4rr4cuda]

2. С этим будут проблемы

Хм, не было бы проблем, Гислер давно бы это написал и не приходилось бы писать для Тотала хаки. До сих пор содрогаюсь, вспоминая, как TotalConsole писал...
Но это настолько основополагающий фактор гибкости и удобства, что задуматься над этим необходимо. Во Фрегате этот вопрос частично решили. Просто продуманая архитектура интерфейсных плагов (или модулей, код все таки открыт) позволит избежать постояных "поломок" при попытке добавить какую либо часть интерфейса. Да и удобнее будет это делать.

Я уже думал об этом, пару функций к WCX интерфейсу добавить надо, для работы в несколько потоков.

Это будет замечательно. Вопрос вызывает только unrar.dll. Либо её переписывать под мультитредовость либо мультипроцессинг использовать...
Да и использование рар-плага под лин вызывает вопросы.

А у меня и так компилируется, при условии если стоит режим совместимости с Делфи

По моему, лучше исключить такие несовместимости, тем более это не требует трудо\время затрат.
Т.к Лазарус только начинаю осваивать, подскажи плиз, где этот режим совместимости включать\отключать.

И правда надо, а раньше и так нормально было

Линукс, на мой вкус, чересчур чувствителен к регистру.

Проверял на пакетах которые у меня есть, все нормально было. А обработку путей подправлял немного.

А давно? А то у меня свн срез недельной давности...