Страница 2 из 35

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

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

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

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

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

СообщениеДобавлено: 17.02.2007 20:27:03
Alexx2000
Romtek писал(а):
В процессе, надо учесть мнение других.
Ну своё собственное-то есть, я надеюсь?

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

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

СообщениеДобавлено: 17.02.2007 20:36:47
ev
такс... пора раздельчик выделенный делать на форуме?

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

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

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

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

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

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

СообщениеДобавлено: 18.02.2007 17:31:41
Attid
ой а вы уже разделом разбогатели пока я приболел :) молодцы!
дайте мне критику Romtek покритиковать :

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

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

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

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

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

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


Sniper

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

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

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

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

СообщениеДобавлено: 18.02.2007 17:33:47
shade
А может лучше сделать поддержку "встраиваемых плагинов", т.е., чтобы они компилировались со всем остальным, для многих небольших функций использование dll/so просто нерационально, а так на стадии компиляции отобрал что нужно....

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

СообщениеДобавлено: 18.02.2007 18:58:17
Romtek
Контроль версий

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

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


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

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

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

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

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

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

СообщениеДобавлено: 18.02.2007 21:46:46
Alexx2000
В моем видении ядро должно выполнять следующие функции:
    Ну разумеется отображение, сортировку, выделение файлов и каталогов в панелях
    Операции копирования, перемещения, удаления, переименования файлов/каталогов
    Запуск программ
    Интерфейс для работы с плагинами
    Настройки самой программы и плагинов
    Что-то еще...

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

СообщениеДобавлено: 18.02.2007 22:42:37
Sniper
Romtek писал(а):Этот проект небольшой и некоммерческий, поэтому не стоит равняться на проект Мозиллы..

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

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

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

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

Romtek писал(а):по моему, это минимум.

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

СообщениеДобавлено: 18.02.2007 23:12:19
shade
Компоненты со скрипом, но вроде поставил, а проект все равно не открываться, пишет мол: "Close component frmCopyDlg: tfrmCopyDlg?"...