Double Commander

[Sniper]

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

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

У них система версий строится так
alpha 1,2,3 - добавляется любая функциональность(разумеется всё глючит и падает)
beta 1,2 - объявляется полный feature freeze никакая фича не может быть добавлена, только исправляются баги и ошибки перевода.
RC1, RC2, RC3 - последняя доводка и исправление критичных багов (не всех вообще, а только критичных для данного релиза так как если исправлять все баги сейчас, то релиз никогда не состоится)
Final - собственно релиз
Сейчас, как ты заметил у нас версия 0.1 Alpha.

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

Меня уже в ПМ Alexx спросил про мои взгляды на feature list

[Alexx2000]

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

Ну своё собственное-то есть, я надеюсь?

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

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

Вот здесь http://sourceforge.net/docman/display_d ... _id=188452 можно посмотреть план работ.
Разумеется он будет дополнятся в процессе разработки.
Ибо невозможно сразу описать все функции современного файлового менеджера,
их сейчас достаточно много.
Также могу сказать, что программа будет иметь архитектуру схожую с TC (основное ядро и плагины).

[ev]

такс... пора раздельчик выделенный делать на форуме?

[Romtek]

Все ли согласны, что стоит выделить код просмотрщика, редактора, мультипереименование в отдельные библиотеки (dll, so)? На мой взгляд, придерживаясь модульности, проще всего добавлять новые возможности и отлаживать код.

Текущие задачи:

* Поиск и исправление текущих ошибок - обязательно!
* Полная реализация текущих функций - каких?
* Полная поддержка архиваторных плагинов TC - пока необязательно
* Выпадающее контекстное меню (как в Explorer) - обязательно
* Система внутренних команд и возможность их использования в меню, панели инструментов, горячих клавишах - пока необязательно
* Настраиваемые горячие клавишы - пока необязательно
* Расширение функций панели инструментов - необязательно
* Расширенный поиск - обязательно
* Добавить следующие настройки интерфейса: - желательно
o вид окна приложения;
o содержимое файловых панелей;
o цвета.

[shade]

Все ли согласны, что стоит выделить код просмотрщика, редактора, мультипереименование в отдельные библиотеки (dll, so)? На мой взгляд, придерживаясь модульности, проще всего добавлять новые возможности и отлаживать код.

Я, вобщем согласен, но тут есть вопросы: как, например, "ядро" будет передавать команды таким плагинам, о которых вообще ничего не знает? Можно было бы предположить, что такая библиотека "объявляет" набор функций-действий (TModAction = procedure (Context: TContex)), но кто будет их вызывать, как подготавливать Context (наверняка потребуется передать какие-нибудь параметры, например список файлов)....

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

[Sniper]

Что для вас является "ядром"? Какой в нём набор функций?
Да и ещё. Язык на котором пишем комменты в SVN и вообще на sf русский?
Текущие задачи реализуются в одной версии Dcmd (DDcmd) или разбиваются на две(если на две, то как?)?

[Attid]

ой а вы уже разделом разбогатели пока я приболел молодцы!
дайте мне критику Romtek покритиковать :

Все ли согласны, что стоит выделить код просмотрщика, редактора, мультипереименование в отдельные библиотеки (dll, so)? На мой взгляд, придерживаясь модульности, проще всего добавлять новые возможности и отлаживать код.

вот только про просмотщик не знаю, а редактор вообще бы выкинул может тогда и форму поиска ? даст возможность фонового поиска чего не хватает ТС ??

* Полная поддержка архиваторных плагинов TC - пока необязательно

про полную может и не обязательно но если я не смогу пользоваться свободно архивами zip\rar\tar\bzip2 то меня это растроит 30% запуска МС у меня только для того чтоб распоковать что-нибуть =) привычка страшная сила, и таких людей я думаю много и списки необходимых архиваторов различается

* Система внутренних команд и возможность их использования в меню, панели инструментов, горячих клавишах - пока необязательно

это закладывается в фундамент и по этому есл не сделать сразу потом прийдется переделывать все по 2 раза

shade
так как это будут не плагины а просто вынос компонет приложения, их можно просто прописать жестоко в коде .


Sniper

Что для вас является "ядром"? Какой в нём набор функций?
Да и ещё. Язык на котором пишем комменты в SVN и вообще на sf русский?
Текущие задачи реализуются в одной версии Dcmd (DDcmd) или разбиваются на две(если на две, то как?)?

ну при таком разделении ядру остается показывать панельки, передвигать курсорчик, копировать\удалять\переносить ну и я больше не понимаю пока коменты вроде на прошлой странице решили на интернациональном, хотя по англицки читать могу писать не очень, но есть переводчики пусть потом мучаются и иностранцы и русские :/

хотя имхо только в коде пусть будут английские а в остальных местах рус\енг что роднее

версий пока я думаю хватит одной, потом уже придумаем как разбивать.

[shade]

А может лучше сделать поддержку "встраиваемых плагинов", т.е., чтобы они компилировались со всем остальным, для многих небольших функций использование dll/so просто нерационально, а так на стадии компиляции отобрал что нужно....

[Attid]

ну по поводу не больших это как посмотреть люди целые проэкты пишут
хотя учитывая опыт тогоже ТС просмоторщики\редакторы часто заменяются на альтернатывные поэтому может их вообще не надо просто иметь предустановленый плагин(приложение) на просмотр\редактирование ? переименование тоже запросто, вот от поиска уже наверно так не избавишься, хотя надо подумать ...

[Romtek]

Контроль версий

В общем, думаю, что контроль версий, на мой взгляд, должен быть таким: X.Y.Z (а не как в Мозилле)
X - кардинальные изменения
Y - небольшие изменения
Z - bug fixes.

Допустим, должна выйти в свет первая версия командера, она будет 0.1.0. Все исправления глюков будут отражаться в версиях 0.1.1, 0.1.2 и т.д.
Этот проект небольшой и некоммерческий, поэтому не стоит равняться на проект Мозиллы.


Ядро и плагины

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

• содержание свойств файлов, директорий
• VFS (виртуальная файловая система) - для FTP, архивов, Samba shares и т.д. За счёт этой части ядра будет обеспечиваться поддержка многих плагинов.
• операции просмотра содержимого, копирования, удаления, переименования, перемещения файлов и директорий, запуск программ.

по моему, это минимум. То есть, меню, панель с файлами и терминал для запуска команд.
Если есть дополнения, прошу высказаться.

[Romtek]

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

Соглашусь с Attid насчёт необходимости заранее продумать систему горячих клавиш и команд, а также необходимости VFS для поддержки плагинов архивов (насчёт именно TC - не уверен).

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

[Alexx2000]

В моем видении ядро должно выполнять следующие функции:

Ну разумеется отображение, сортировку, выделение файлов и каталогов в панелях
Операции копирования, перемещения, удаления, переименования файлов/каталогов
Запуск программ
Интерфейс для работы с плагинами
Настройки самой программы и плагинов
Что-то еще...

С выделением других функций в отдельные модули проблем быть не должно,
ибо фактически они и сейчас не зависят от ядра, происходит лишь вызов
функции с передачей списка файлов в качестве параметров.
И так решаем, что есть ядро и в каком виде будут оформлены остальные функции.
В виде dll/so модулей или как предложил shade

А может лучше сделать поддержку "встраиваемых плагинов", т.е., чтобы они компилировались со всем остальным, для многих небольших функций использование dll/so просто нерационально, а так на стадии компиляции отобрал что нужно....

[Sniper]

Этот проект небольшой и некоммерческий, поэтому не стоит равняться на проект Мозиллы..

у Мозиллы тоже небольшие и не коммерчесике проекты

[shade]

Поясню на счет dll/so/unit:
я не предлагаю ограничится каким-то одним вариантом, напротив, использовать оба. Выборочное подключение unit-ов для простых модулей типа сравнения директорий и отдельных dll/so плагинов для сложных случаев (честно говоря не приходит в голову ни одного примера...)

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

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

по моему, это минимум.

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

[shade]

Компоненты со скрипом, но вроде поставил, а проект все равно не открываться, пишет мол: "Close component frmCopyDlg: tfrmCopyDlg?"...