Вот что я предлагаю и что я уже сделал:

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

Вот ссылка на архив:  http://narod.ru/disk/12913098000/KOLMCK.7z.html

В следующем комменте я напишу список изменений, а пока небольшое дополнение:

Я решил это сделать потому что в каталоге все таки небольшой бардак. Я поставил целью переименовать файлы так чтобы они могли находится в одной папке и при этом можно было легко ориентироваться. Судя по устоявшейся традиции именования, я решил делать так:
- Все файлы относящиеся к KOL, но не к MCK - это либо файлы библиотеки, либо файлы адаптированные к ней я называл добавляя префикс KOL. Здесь самое ужасное, что я переименовал файл err.pas в KOLerr.pas. Все остальное думаю не страшно. К именам файлов которые инклудятся *.inc я добавил KOL_. Я поместил все в корневую папку, даже те файлы которые относятся к Addons и лежать в соот-щей папке (но это не относится к файлам-зеркалам). Потому что нет причины их туда прятать, но зато удобно добавить один путь для поиска.
- Все файлы, которые относятся к MCK я переименовал, добавив префикс mck. Те что Addons, остались в папке Addons. Тут самое страшное, я переименовал mirror.pas в mck.pas. Также все *.dpk в mckD<версия>.dpk
Все переименования проводил с помощью утилиты PowerGREP 3, причем осознано :), поэтому думаю проблем не должно быть, но все же требуется ваша ревизия :)

Что я предлагаю:
1) Все файлы относящиеся к KOL именовать так: добавлять префикс KOL. Буквы в верхнем регистре потому что так сложилось :)
2) К файлам MCK - добавлять префикс mck. Опять же, заметил что буквы в маленьком регистре уже устоялись.
3) если какой-либо модуль предназначен для определенной версии, то добавлять суффикс типа _D2006 или без подчеркивания, как я понимаю это больше для MCK-модулей
4) Ложить в SVN только файлы *.dpk, *.pas, *.res, *.txt - то есть те которые нужны и без лишних созданных IDE (.bdsproj, .cfg, .identcache, .local) :)
5) Адаптированные для KOL модули переименовывать добавляя KOL и ложить в корневую папку

Что осталось:
1) Ну самое первое что бы вы и автор библиотеки «дали добро» и все вместе довели все «до ума» :) – проверили не допустил ли я где-нибудь ошибку, просмотреть комментарии и файлы помощи, не осталось ли ссылок на старые файлы
2) В папку kol_old я поместил файлы которые возможно уже устарели, а некоторые просто бы перенести в отдельный модуль и поместить результат в корень библиотеки. Прошу обратить на них внимание, дело в том что там нет каких либо-уникальных функций. Может как-то организовать их?
3) В system поместить откомпилированные dcu. Занимают не так много, но для некоторых самостоятельная компиляция проблема :) И еще я туда поместил замену Variants, надо ли?
4) Убрать папку Addons Сейчас там и FontEditor.dpk и KOLSocket.dpk и addons.dpk. Организовать все так чтобы в итоге было для каждой версии делфи два dpk файла – 1) mckD2006.dpk – основные компоненты и 2) mckAddonsD2006.dpk – дополнительные компоненты. Причем следить чтобы не было «гуляющих» mck*.pas файлов с функцией register, т.е. такие файлы должны быть полюбому в одном из dpk-файле.
5) Сообщить разработчикам чьи труды есть сейчас в библиотеке об изминениях. Список email’ов не трудно взять из исходников, а возможно мастера знают их лично :) или они сами здесь часто бывают

В итоге у нас будет очень все понятно и «красиво», в корневой папке будет лишь одна подпапка «System». И файлы KOL*/mck* ну и часть файлов и папок от сторонних разработчиков, которые не зависят от KOL

1) Какой смысл создавать для MCK подкаталоги 2006, 2007 и т.д.?
2) Переименовал *.dpk в mckD...
3) Использую не D10, D11, D12, а D2006, D2007, D2009, D2010
4) Переименовал mirror.pas в mck.pas - переименовал везде где используется
5) Переименовал KOLmirrors.dcr в mck.dcr
6) Переименовал MirrorKOLPackage*.res в mckD...
7) KOLFontEditor* -> mckKOLFontEditor*
8) KOLSOCKPAK.dpk -> mckKOLSocket_D7.dpk
9) mckSocket.pas -> mckKOLSocket.pas
10) убрал addons.dpk - здесь хотел бы по подробней, предлагаю называть типа mckAddons_D2006, и еще нужно разобратся что сюда включать.Так как в папке Addons уже есть файлы *.dpk (например KOLFontEditor.dpk и KOLSOCKPAK.dpk), во избежание путаницы, лучше создавать только пакеты Addons*.dpk, и включать туда все компоненты из папки Addons. Так например сейчас в addons.dpk есть KOLFontEditor.pas, он же есть и в KOLFontEditor.dpk, зачем? причем KOLFontEditor.dpk для D7, что никак не указано.
Думаю над папкой Addons и пакетами для разных версий в виде mckAddons.dpk нужно поработать.
11) RegisterComponents('KOLAddons', [TKOLMHXP]); ->   RegisterComponents('KOL Addons', [TKOLMHXP]);
12) visual_xp_styles.inc -> KOL_visual_xp_styles.inc
13) Mmx.pas -> KOLMMX.pas
14) err.pas -> KOLerr.pas (Постарался заменить везде, также и не в коде а в комментах)
15) delphidef.inc -> KOL_delphidef.inc
16) delphicommctrl.inc -> KOL_delphicommctrl.inc
17) Не изменял CplxMath, он не требует KOL :) и некоторые другие подобные
18) ListEdit.pas -> KOLListEdit.pas
19) OLETable.pas -> KOLOLETable.pas
20) PCAsmTable.pas -> KOLPCAsmTable.pas
21) PCAsmUnit.pas -> KOLPCAsmUnit.pas
22) RAS.pas - > KOLRASdef.pas (т.к. есть KOLRAS.pas)
23) tinyJPGGIFBMP.pas -> KOLTinyJPGGIFBMP.pas - (используется например в GRushControls, постарался везде заменить)
24) tinyPNG.pas -> KOLTinyPNG.pas
25) XPMenus.pas -> KOLXPMenus.pas

Предлагаю:
1) Все файлы относящиеся к KOL именовать так: добавлять префикс KOL. Буквы в верхнем регистре потому что так сложилось :)
2) К файлам MCK - добавлять префикс mck. Опять же, заметил что буквы в маленьком регистре уже устоялись.
3) если какой-либо модуль предназначен для определенной версии, то добалят суффикс типа _D2006, как я понимаю это больше для MCK-модулей
4) Ложить в SVN только файлы *.dpk, *.pas, *.res, *.txt - то есть те которые нужны и без лишних созданных IDE (.bdsproj, .cfg, .identcache, .local) :)
5) Адаптированные для KOL модули переименовывать добавляя KOL и ложить в корневую папку

Я только "За": http://pda.delphimaster.net/?id=1238076620&n=10

Ща скачаю, гляну...

Ruzzz, сейчас смотрю архив.. оставь icq для связи.
Пока могу сказать вот что:
1) папки нужны для DCU разных версий (например установлена сразу 7 и 2007 версия и чтоб конфликта не было)
2) лучше KOLMCKD*
3) это точно за
4-5) как угодно
6) наверное есть смысл оставить один RES на все пакеты..
7) смысл переименования понятен, но вызывает каламбур с префиксами mckKOL..
8) несколько раз перепроверил - этого dpk у меня нет и на свн тоже... где его нашли не понимаю (или это только про версию в архиве?)
10) опять же этого dpk нету у мну..
......

теперь о предложениях:
1-3) за
4) максимум там можно было найти bdsproj и dproj, но с ними удобнее
5) не согласен.

После таких изменений получается каша в главной папке.. уже сложно понять где КОЛ, а где дополнения для него.. Нужно все обдумать..

D[u]fa, да по поводу "этого dpk у меня нет" возможно это уже я сам туда его засунул :) ну все равно смысл не меняется. По поводу того что не согласны, ну цель добавить префикс mck ко всему что касается MCK. Если автор назвал свой компонент допустим KOLMyComponent, ну пусть будет юнит зеркала называться также толко добавим mck. Получается очень красиво и удобно запомнить этот принцип. Префикс пишем в малом регистре - удобно и показывает что mck - вторично по отношению к KOL-компоненту, то есть как дополнение.

По поводу 2-го "лучше KOLMCKD" ну какой смысл KOL добавлять? а mck в нижнем регистре как-то оно и устоялось и как я уже говорил  - типа второстепенно по отношению к KOL.

6) наверное есть смысл оставить один RES на все пакеты - ну это вообще было бы отлично.

и самое главное, очень рад что вы откликнулись, надеюсь и остальные с нами, в том числе и автор. По поводу связи: у меня сейчас нет аськи, но есть GTalk/Jabber (тот который e-mail), но я предлагаю встретится во временно созданной (а там может и приживется) комнате IRC-чата, в этом случае сможем обсудить коллективно. Жду вашего решения.

Почитал я эту ветку, и так и не понял, зачем огород то городить?
Никого не хочется обидеть, но правда, не догнал что-то зачем, это нужно.
KOL&MCK можно хранить отдельной папкой, что достаточно удобно. Тем более, Владимир на все предложения по реорганизации библиотеки отвечает что-то типа: "...меня все устраивает и все и так хорошо, и ничего менять не буду". Так что все изменения KOL&MCK - это только до новой версии, и все заново править\переименовывать.
А по поводу "Addons" и т.п. то это тоже, личные предпочтения автора сборки. Я, например, основной массой компонент, присутсвующих там, ни разу не пользовался и даже не устанавливал. А про некоторые даже и не слышал. Так нафига они мне? А те, которыми пользуюсь, представлены более старыми версиями (не все конечно). С другой стороны, компоненты, которые я обычно использую, здесь не представлены....
Так что, по моему мнению, оставить все как есть. Отдельно архив KOL&MCK со всякими приблудами (err, koladd и т.д.). А доп. компоненты\библиотеки пускай каждый сам под себя подбирает и использует.

Было бы не плохо связаться в автором KOLMCK, и попросить его прокомментировать.

> ну цель добавить префикс mck ко всему что касается MCK


Это понятно и логично. Я не согласен конкретно с "и ложить в корневую папку". Если все аддоны сложить в корневую папку - будет каша полная..


> По поводу 2-го "лучше KOLMCKD" ну какой смысл KOL добавлять

mck без КОЛа работать не будет =)

D[u]fa  я уже сам подумал что аддоны действительно лучше ложить отдельно, все таки каша будет :)

ну а по второму пункту ну ведь и так ясно что kol, ведь сами говорите что mck без кола никак :) все таки эти dpk - отвечают за mck и никакого отношения к kol не имеют, мое мнение все же делать mckD2006 и так далее - кратко но емко

Может в чате сайта? Подожду вас там, ник такой же

Ща и я свои 20коп подкину...

Блин, ну, Ruzzz, Вы и намудрили с сообщениями. Значится так. Высказываю свое ИМХО:
По первому сообщению в теме:
1. Согласен
2. Не согласен. Чем же Вам так Mirror Classes Kit не угодил, что Вы его в нижний регистр?
3. Согласен
4. В общем-то скорее согласен
5. Адаптированные для KOL модули это какие? err.pas что ли? да таких модулей единицы. Не думаю, что это хорошая идея. Мне, например, нафиг не уперся файл HeapMM.pas в корневухе директории KOL. Он в KOL нигде не подключается, только в системных заменах.

У меня другое предложение, встречное так сказать:
Взяв за основу KOL.pas и mirror.pas - как основы KOL и MCK соответственно. определить их в корневуху, а далее добавлять в корень только ТО, ЧТО ВЫЗЫВАЕТСЯ из этих файлов!!! Так было всегда и это логично...

Далее. Продолжаем по первому сообщению в теме:
1. Не думаю, что кто-то из Авторов будет против. ВСЕ КТО "прошел" через KOL и этот форум - ЭНТУЗИАСТЫ. Работали исключительно за идею.
2. Совершенно не понял о чем Вы
3. Не согласен. Думаю лучше .pas файлы + батник
4. Здесь тоже не согласен. Что ж Вас так не прет на структурирование. Опять же у меня предложение:
По умолчанию, кроме MCK НИЧЕГО не добавлять в MCKDxxxx.dpk. Создать папку Addons (Components) и в этой папке создавать подпапки для каждого конкретного компонента. В этой подпапке необходимым требованием определить наличие: KOLxxxxxxx.pas, MCKxxxxxxx.pas, xxxxxxxDxxxx.dpk, MCKxxxxxxx.res.

А то скачав Ваш архив, чуть не рехнулся. Это Вы ЭТО называете удобно? Все компоненты в одной куче, их зеркала в папке Addons. Это не удобно, это бардак...хотя удобство понятие субъективное...
5. Читайте 1.

> Было бы не плохо связаться в автором KOLMCK, и попросить его прокомментировать.
Читайте что Вам mdw написал. Так Вам Владимир и ответит...

2 mdw
А я как и раньше, считаю что KOL давно надо "перетряхнуть" и "выбить" всю пыль из него... По мне слишком много кода ведет "в никуда" (тот же GTK) много кода никогда не используется, а если этот код даже удастся подключить дефайнами, то работать он не будет... А изменения которые внесет Владимир, легко можно перенаправить...

Я тоже считаю что библиотека имеет право быть. :)

Вот что я думаю:
1) По поводу каталогов - может стоит сделать в корне KOLMCK - офиц-ный и в подкаталоге Addons - дополнения? Еще останется System, хотя чесно говоря для меня не так уж это и важно

2) Но вот что важно!!! Это именование файлов. Не важен регистр mck/MCK важен сам префикс, также и с префиксом KOL. Также очень бы хотелось переименовать таки err.pas в KOLerr.pas и mirror.pas в mck.pas/MCK.pas - потому как err и mirror слишком уж общие названия. По поводу dpk-пакетов для MCK - также думаю что лучшее название это mckD2006.dpk/MCKD2006.dpk - хотя я все же за mck в нижнем регистре

Я не пользуюсь новыми версиями Delphi, максимум Delphi7, но иногда, в основном мне достаточно D6. Соответственно, никаких модулей или пакетов от D200X и Turbo в папке KOL у меня не лежит. Переименовывать существующие ИСХОДНЫЕ модули - категорически нежелательно, пакеты - как себе хотите, так и переименовывайте. В папке KOL все в одной куче, может это и не всегда удобно просматривать глазами, зато удобно прописывать Search Path в опциях проекта. А что там так уж рассматривать, это же не картина маслом и не стеллаж с морскими ракушками, эстетика особая не требуется. Если очень хочется получить место, из которого будут удобно доступны нужные файлы, отсортированные и разложенные по полочкам в удобном порядке, так давно уже изобретен html, и из него можно гиперссылки на файлы сделать, даже и картинками.

toALL: by theme of Refactoring.
I have a question on the use of Conctructor's. Who are uses of the USE_CONSTRUCTORS symbol?
Maybe this segment of code can be is removed?

> USE_CONSTRUCTORS symbol

I've never used. may be...

but it can be useful for someone, I don't know

По поводу переименования я отчасти согласен с Владимиром - проблем связанных с изменением имён может быть много, тем более что предыдущая версия KOL в моей достаточно большой программе не работала должным образом... Если переименовывать файлы, то некоторые. Например, имена пакетов. Т.е. переименование не ради красоты, а ради функциональности. Ведь KOL всё-таки придерживается минималистичных принципов.

KOLMCKD* мне не очень нравится, если MCK в верхнем регистре, то тогда лучше KOLMCK_D* для читаемости. Что до регистра, то лично мне всё равно.

Что касаемо упорядочивания папки Addons - да, такая папка должна быть и должна быть упорядочена, ибо на данный момент это куча. Сама идея сбора компонент в эту папку мне нравится, мне это кажется очень удобным. Однако, при изменении MCK-модуля GRUSH у меня возникли проблемы с перекомпиляцией пакета KOL, что тоже требуется довести до ума.

Однако более всего мне кажется разумным направить усилия не на упорядочивание самой папки KOL, а на правку KOL.pas. Действительно, этот модуль очень нуждается в основательной чистке и правке, но в строгом согласии с идеями автора. Ведь функциональность дороже всего. А пока что KOL слывёт очень глючной библиотекой, о которой рекомендуют в разработке программ, серьёзнее блокнота и калькулятора, забыть как о страшном сне :(

> А пока что KOL слывёт очень глючной библиотекой, о которой рекомендуют в разработке программ, серьёзнее блокнота и калькулятора, забыть как о страшном сне :(
Это откуда это? Это Ваше ИМХО?