freepascal.ru

Предлагаю в данной теме обсуждать все, что касается разработки (и не только) Double Commander.
Double Commander - это кроссплатформенный open source файловый менеджер, разрабатываемый на FPC/Lazarus.

Загрузить последнюю версию Double Commander можно со страницы загрузок проекта.

Исходники можно скачать из SVN командой:

svn co https://doublecmd.svn.sourceforge.net/s ... ecmd/trunk doublecmd

SVN клиент для Windows можно скачать отсюда:
http://tortoisesvn.net/downloads

Официальный сайт http://doublecmd.sourceforge.net
Адрес проекта http://sourceforge.net/projects/doublecmd

З.Ы. Кто желает присоединиться к проекту пишем в личку.

Чего не хватает проекту:

1. продуманной архитектуры (самый важный пункт).
   Имеется мильён модулей на все случаи жизни. Давайте хорошенько подумаем чего мы хотим получить от файлового менеджера и том насколько имеет смысл делать клон TotCmd, а также извлечём ошибки из других неудавшихся проектов по клонам TC.
2. документации (следует из пункта а): структура проекта, взаимосвязь между его компонентами.
3. организованности.
   Кол-во участников в проекте может существенно увеличиться в том случае, если каждый сможет заняться своей частью проекта, при этом не мешая другим. Одни работают над "ядром" проекта, а другие - над его компонентами, будь то просмотрщик или какой-то плагин.
   Не будем плодить новые ошибки при наличии старых, унаследованных от своего потомка.
4. системы отслеживания "жучков", тобишь багов. То есть нужна взаимосвязь с пользователями-реальными тестерами.
5. гибкой системы настройки

По поводу пункта а хочу сказать следующее: главная фишка TC в том, что у него довольно неплохо продуманная модулярная архитектура: программа состоит из частей, каждая из которых выполняет свою задачу и не старается сделать всё одновременно.

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

Считаю, что нужно отделить файловый менеджер от его компонентов. Он должен быть независимым от просмотрщика, редактора файлов и плагинов. Отсутсвие оных не должно влиять на работу, а только ограничивать его функциональность.
Главная задача менеджера - это некий аналог Windows Explorer, Nautilus, Konqueror, т.е. броузер файлов и операции над ними: копирование, перемещение, удаление и запуск программ. Остальное - дело наживное.

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

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

Sniper
берешь исходники компилишь
заводишь акаунт на sf.net
пишешь в личку Alexx2000
берешь/добавляешь задания в багтрекере ну и исправляешь что нужно.

Romtek
так то так в теории все, а на практике "just for fun"
теперь по полочкам

*продуманной архитектуры (самый важный пункт).
проэкт не с нуля а на основе так что сильно не изменешь
хотя на том же tuxcmd где вроде как все встало в тупик из-за архитиктуры, имхо глупость, при желании развивать можно все.


* насколько имеет смысл делать клон TotCmd
под вендой он меня как и многих устраивает полностью
так что если он в конечном счете приблизится
по функциональности к ТС ничего плохо не будет только у DC будет выигрыш за счет GPL

*а также извлечём ошибки из других неудавшихся проектов
ну это конечно не плохо хотя я бы лучше от туда взял лучшее чем искать неудачное

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


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


*системы отслеживания "жучков", тобишь багов.
есть на sf.net, а вот реальные пользователи возможны только после как разработчики при запуске не будут видеть ошибки, а пока их море


*гибкой системы настройки
это к первому пункту про архитектуру



ЗЫ. это все мое личное мнение и я не претендую на то чтоб это стало девизом проэкта

ну так просмотров много может каждый просмотревший пару строчек напишет чем именно ему нравится тот же TC или аналоги или чем не устраивает тот или иной менеджер разговор в основ про гуи менеджеры так что far\vc\mc не в счет

Насчет архитектуры, чем не подходит архитектура TC, цитата:

Romtek писал(а): главная фишка TC в том, что у него довольно неплохо продуманная модулярная архитектура: программа состоит из частей, каждая из которых выполняет свою задачу и не старается сделать всё одновременно

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

Romtek писал(а):
документации (следует из пункта а): структура проекта, взаимосвязь между его компонентами.

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

Насчет пунктов c,d ну для этого и используется SourceForge. Там вроде есть все необходимое.

Romtek писал(а):
гибкой системы настройки

Думаю будет.

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

Далее, касательно

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

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

Стоит собрать основу функционала в одном файле.

Комментарии в коде: почему они на русском языке? Почему в виде "// пока нереализовано" ? Что это:
{Alexx2000}
{/Alexx2000}
??

Вместо {$IFNDEF WIN32} наверно стоит написать {$IFDEF UNIX}

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

документации не для пользователя, а для разработчика. Я, конечно, понимаю, что любой русский разработчик должен уметь работать в неорганизованной среде, но почему ограничиваться только русскоговорящими?

Вот вы сейчас имеете план работы? Какие у вас ближайшие цели? Что первостепенно, а что не так важно?

Romtek писал(а):Не знаю как в такой мешанине модулей можно быстро освоиться. Хочу построить граф зависимостей модулей, чтобы понять откуда ноги растут. А пока я как ёжик в тумане.

На самом деле не все так страшно

Комментарии в коде: почему они на русском языке? Почему в виде "// пока нереализовано" ? Что это:
{Alexx2000}
{/Alexx2000}
??

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

Вместо {$IFNDEF WIN32} наверно стоит написать {$IFDEF UNIX}

Наверное стоит.

документации не для пользователя, а для разработчика. Я, конечно, понимаю, что любой русский разработчик должен уметь работать в неорганизованной среде, но почему ограничиваться только русскоговорящими?

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

Вот вы сейчас имеете план работы? Какие у вас ближайшие цели? Что первостепенно, а что не так важно?

В процессе, надо учесть мнение других.

В процессе, надо учесть мнение других.

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

Потом показать скриншоты народу, описать возможности.
А ещё нужно создать полноценную домашнюю страницу с приглашением желающих принять участие в проекте.

Romtek писал(а):Мне кажется, что первая цель - не расширять функциональность, а выпустить стабильную версию для как минимум одной ОС с уже имеющимися функциями.

Проблема в том, что если выпустить такую стабильную версию (для Windows) то она окажется никому не нужна... для Linux есть Krusader, так что лучше набить в него функциональности и оттестировать недели две.
Причём набить функциональности можно без привнесения новых багов.

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

shade
Почему?
Я например хочу добавить(уже в процессе) выбор цвета в панелях, курсора -вобщем большую часть страницы настроек Цвета в TC (не думаю что можно в этом месте наоставлять багов...)
Я в общем думаю что стоит перенять способ разработки у Mozilla.

Кстати, кто из нас более менее знаком с программированием под Linux?

Sniper писал(а):Я в общем думаю что стоит перенять способ разработки у Mozilla.

А в чём он заключается?

Sniper писал(а):Кстати, кто из нас более менее знаком с программированием под Linux?

Я не знаком, но готов попробовать. Можно взять книгу по программированию на Fpc под UNIX как настольный справочник. В общем, если не найдётся ни одного хорошо знающего UNIX человека, то не имеет смысла выпускать глючные версии под него. Лучше делать одну вещь, но хорошо.

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