[hwd]

Выкладываю свой вариант шаблона оформления плагинов AutoCAD. В прикреплённом архиве находится упакованный архив чистого шаблона и CHM-файл, в котором подробно разжёвано всё, что касается работы с данным шаблоном. Если кратко, то в основу шаблона положены следующие моменты:

• Ориентация на коллективную работу
• Самодокументирование приложения
• Автоматическая синхронизация содержимого документации в соответствии с состоянием настроек
• Простая возможность расширения существующего перечня локализаций
• Возможность программной/пакетной обработки плагинов
• Получение исчерпывающей информации о приложении открытием файла readme.html
• Управление сразу всеми имеющимися версиями приложения (скомпилированными под разные AutoCAD)

Если ещё более кратко, то шаблон построен на связке XML + XSD + XSLT.

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

UPD. Обновил архив - исправил серьёзную опечатку и добавил пример группирования и отображения команд.

UPD2. Завернул в шаблон программу Александра Ривилиса. Прикреплён внизу как DwgConvert.zip. Нужно распаковать архив и открыть файл readme.html.

UPD3. Перезалил оба архива. Внёс в шаблон некоторые правки, касающиеся визуального отображения, добавил в оглавление readme.html ещё один раздел, с помощью которого можно попадать в каталог нужной версии программы. Внёс изменения в chm-файл мануала.

UPD4. Перезалил оба архива. Внёс в шаблон некоторые правки, касающиеся визуального отображения, а так же расширил логику динамического формирования панели навигации readme.html - теперь в него можно добавлять произвольное количество групп с произвольным количеством позиций (помимо уже существующих). Частично изменил структуру и содержимое каталогов, например - в каталоге ./support находится только то, что не требует изменения (т.е. разработчику туда можно не заглядывать). Внёс соответствующие изменения в chm-файл мануала. Соответственно изменённому шаблону модифицировал пример приложения, построенного в соответствии с шаблоном.

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

UPD6. Перезалил оба архива. В шаблонах внёс некоторые изменения в файлы XSD, а так же в файл versions.xml, для возможности корректного описания LISP-программ. В архив samples, по просьбам телезрителей добавил пример упаковки LISP-сборника. В тот же архив упаковал и ещё одно приложение от Александра Ривилиса. В примере упаковки LISP-программ я, в качестве опять же примера, в таблицу загрузок добавил несколько записей, указав, что загружать следует все файлы с расширениями lsp, fas и vlx, хотя на самом деле в примере имеются только lsp-файлы.

[hwd]

Сообщение от ShaggyDoc Правильная программа с инсталлятором сделает это сама

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

Инсталлятор невозможен в принципе Это самое большое твое заблуждение.

Инсталлятор приложения - это одно, а инсталлятор упаковки в шаблон любого плагинна - это совершенно другое. Я писал о невозможности второго. Невозможно написать для шаблона такой инсталлятор, который можно "натравить" на любой плагин так, чтобы произошла автоматическая упаковка этого плагина в шаблон. Что тут ещё может быть непонятного? Неужели и тут нужно разжёвывать почему нельзя?

А перечень "ключевых слов" будет выводиться при работе в командной строке и в контекстном меню.

в "командной строке" и в "контекстном меню" ключевые слова никому не нужны. Ключевые слова нужны для возможности поиска в справочной системе.

И в правильной программе имеется правильный файл справки, который не надо где-то разыскивать.

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

Правильная программа с инсталлятором

Шаблон - это то, в каком состоянии плагин должен находиться в уже установленном на компьютере виде. Кто мешает засунуть в msi результат упаковки, дабы получился инсталлятор? Не нужно мешать вместе мух и котлеты. Упаковка в msi - это следующий шаг. И шаг этот делается для плагина уже "завёрнутого в шаблон".

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

Вообще-то есть у меня такая практика. Поверьте, вы не единственный, кто умеет создавать msi, и совершенно не факт, что вы это делаете лучше меня.

ты пишешь "программки" да какие-то "плагины", а не приложения

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

Я думаю пока ты (или еще кто) не напишешь гуишку для "полуавтоматической" обертки такой "сопроводиловкой" + программу для автоматической установки/манипулирования софта(ом), на его основе, количество человек пользующимся твом шаблоном будет стремиться к единице.

Абсолютно согласен, и более того - это в ближайших планах. Шаблон и документацию я выкладывал для того, чтобы желающие могли детально ознакомиться с тем, как что устроено и что с чем взаимодействует. Имхо - помимо того, чтобы иметь возможность юзать GUI, желательно чтобы программист понимал, что там на самом деле за кулисами происходит. Именно это и разъясняется в выложенном мною CHM-файле.

[Дима_]

Сообщение от hwd Абсолютно согласен, и более того - это в ближайших планах. Шаблон и документацию я выкладывал для того, чтобы желающие могли детально ознакомиться с тем, как что устроено и что с чем взаимодействует.

Андрей, все что я скажу дальше ТОЛЬКО мое видение данного вопроса. Вот этот подход изначально губительный (я сам на нем попался, когда "документировал" формат настроек в одной "заказной" софтине, правда не имеющей никакого отношения к автокаду, но не суть). Ты сейчас задаешь формат и его открываешь, причем не просто открываешь, а декларируешь - мол давайте пользоваться, а завтра, например, ты решаешь, что можно еще добавить "скрины" софта, или подумаешь, что все данные о всех установленных программах лучше собирать (автоматом) на пользовательской машине в 1 XML и из него уже "рулить" (повторюсь - это только для примера). Да XML легко расширяется, но тебе "для совместимости" придеться тащить все "хвосты" старых версий (которые быть может в последствии, ты поймешь что хранить лучше в другом, более широком, формате, либо же они вобще "не приживутся") - то есть получатся либо ограничения, либо "пятикратное" дублирование одного и того же, в разных форматах, для всех предудущих версий. ИХМО правильно инкапсулировать внутри проги, а там вороти что хочешь, не зря начиная с 2010 версии автодеск свои настройки в xml зазиповал - нечего туда "врукопашную" лезть, есть гуишка, есть API (кстати тебе тоже вариант для размышлений). И программа "любой" версии будет без проблем вытаскивать в нужном формате заданную ее "сегодняшним" функционалом версии из любой обертки. То есть мое резюме такое - формат пряч - "ГУЙ" юзерам, АПИ программистам.

[hwd]

а завтра, например, ты решаешь, что можно еще добавить "скрины" софта

в шаблоне предусмотрено, что разработчик в качестве значений параметров может задавать разметку HTML. Соответственно, это даёт возможность отображения в браузере картинок, раскрывающихся списков, внедрения кода на JavaScript и, как следствие, некоторое взаимодействие с пользователем. Т.е. разработчик имеет некоторую степень свободы в плане того, как в браузере должна отображаться предоставляемая им информация. В CHM-файле я показывал примеры на эту тему.

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

Всё в нашей жизни меняется со временем, и представленный мною вариант не исключение. Но поскольку всё хранится в XML, то при необходимости можно написать конвертер, преобразовывающий старый вариант в более новый. Изначально, перед тем, как сесть за написание шаблона, я составил для себе список той информации, которая может потребоваться пользователю, программе-загрузчику и программе, выполняющей поиск по ключевым словам. Исходя из этого и был составлен шаблон. Не думаю, что в ближайшее время потребуется какая-то дополнительная информация. Если она и потребуется, то я предусмотрел возможность создания дополнительных файлов настроек, в которых эта информация может храниться. Содержимое такого файла может иметь иерархическую структуру любого уровня вложенности. Я продемонстрировал это в CHM-файле на примере создания дополнительного файла настроек, хранящего в себе информацию об используемых текстовых стилях. Т.о. в шаблон заложен некоторый механизм расширения. Причём всё это "расширение" так же попадает под проверку XSD на предмет валидности.

То есть мое резюме такое - формат пряч - "ГУЙ" юзерам, АПИ программистам.

В идеале каталог support конечно же должен быть представлен неким zip файлом, у которого изменено расширение дабы юзер в него не лез. Однако, насколько мне известно, в XML нельзя указать привязку к XSD и XSLT находящимся в архиве. Поэтому пока все эти "внутренности" собраны в отдельном каталоге. Юзеру нет нужды лезть туда. Всё что ему нужно находится в readme.html, который по сути и представляет собой GUI для юзеров. API разработчику будет представлено в виде GUI, где в диалоговом окне он будет заполнять данные, а те автоматом будут записываться в соответствующие XML файлы.

[Дима_]

Сообщение от hwd Но поскольку всё хранится в XML, то при необходимости можно написать конвертер, преобразовывающий старый вариант в более новый.

Вот это как раз то, что мне в последствии и пришлось делать - гемор эти конверторы, а если изначально декларировать только GUI/API доступ - то все конвертации делаются прозрачными для пользователя. Время которое все меняет течет на удивление быстро, а "беда" XML в том что он сколь угодно "масштабируеться" - но только в сторону увеличения.

[hwd]

Сообщение от Дима_ Вот это как раз то, что мне в последствии и пришлось делать - гемор эти конверторы... Время которое все меняет течет на удивление быстро, а "беда" XML в том что он сколь угодно "масштабируеться" - но только в сторону увеличения.

Всё зависит от того, насколько хорошо в шаблоне всё было изначально спланировано и продумано. Быстро возникающая потребность в модификации - следствие плохой предварительной проработки темы. Выложенная версия шаблона предусматривает всё что нужно для работы с плагином. Однако даже если мне и придётся со временем написать какой-нибудь конвертер, то пишется он очень просто, благодаря наличию технологии LINQ to XML. А вообще, волка бояться - в лес не ходить.

Сообщение от Дима_ а если изначально декларировать только GUI/API доступ - то все конвертации делаются прозрачными для пользователя.

Как я уже выше заметил - пока что потребность в модификации на горизонте не маячит. О каком API вообще речь? Отображение всей информации берёт на себя браузер. При этом он руководствуется технологией XSL. Что за API и как ты ему его укажешь, чтобы он в соответствии с этим API отображал информацию? Что-то я тебя не понял. Насчёт GUI я уже писал выше - он появиться для программиста для удобства заворачивания в шаблон уже готовых плагинов. GUI для юзера - это файл readme.html.

[Дима_]

Я имею в виду что по моему правильно, делать не формат, а прогу для заворачивания плагинов в некий формат, и прогу для просмотра этих "свертков", модифификации, автообновлении по версии, помощи, установке итд. - то есть для работы с ними - это GUI. А также, в идеале - сделать открытый API интерфейс, для "продвинутых" программеров, чтобы они не с твоей гуишкой "маялись", а сами парой строк кода все нужное установят.

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

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

[hwd]

Сообщение от Дима_ Я имею в виду что по моему правильно, делать не формат, а прогу для заворачивания плагинов в некий формат

Прежде чем заворачивать в какой-то формат, этот формат для начала должен быть определён.

Сообщение от Дима_ и прогу для просмотра этих "свертков", модифификации, автообновлении по версии, помощи, установке итд. - то есть для работы с ними - это GUI.

В данном случае программой для просмотра, т.е. GUI, является обычный браузер. Зачем изобретать велосипеды со своими программами просмотра, когда можно воспользоваться тем, что у всех имеется под рукой?

Сообщение от Дима_ А также, в идеале - сделать открытый API интерфейс, для "продвинутых" программеров, чтобы они не с твоей гуишкой "маялись", а сами парой строк кода все нужное установят.

"продвинутые" программеры уже получили этот API в виде подробных XSD схем, описывающих формат каждого XML файла. Программно они могут менять XML как хотят, главное, чтобы это соответствовало схеме. В каждом языке программирования свои инструменты работы с XML. Писать API в виде библиотек под каждый язык, в данном случае дело неблагодарное и невосстребованное. Для .Net я напишу такой API, благо что много времени на это не уйдёт, но для остальных языков - не вижу смысла в виду отсутствия интереса. А если интерес и появится, то под свой язык программист LISP напишет API гораздо грамотней, нежели это сделал бы я.

Сообщение от Дима_ я не думаю, что, например, автодеск плохо "продумывают", но тем не менее форматы у них "пляшут" (хотя причина безусловно не только в этом).

А я думаю, что причина как раз таки в этом.

[gomer]

Сообщение от hwd В данном случае программой для просмотра, т.е. GUI, является обычный браузер. Зачем изобретать велосипеды со своими программами просмотра, когда можно воспользоваться тем, что у всех имеется под рукой?

Обычный браузер - понятие гипотетическое

[hwd]

Сообщение от gomer Обычный браузер - понятие гипотетическое

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

[Дима_]

Немного оффтоп, но скажем так для направления мысли - есть "малоизвестный" офисный пакет, в котором файлы храняться в виде зазипованных XML'ов под разными именами docx, xlsx... и для их редактирования есть "GUI-шка", а для программеров - (хоть внутри и простой для программиста XML) есть свои API для обращения и работы с документами, а если кто и работает с их документами посредством разархивирования и вытягивания XML информации - либо "творцы" аналогичных пакетов (для совместимости), либо полные извращенцы.
Ставить обычный браузер для просмотра - конечно можно, но лично я бы, смотря вперед, подстраховался, и использовал хоть тот-же System.Windows.Forms.WebBrowser() - чтоб была возможность от него откреститься (если ВНЕЗАПНО станет понятно что html юзера в данном случае, несет дублирующею и хаотичную информацию - когда "програмная" разрастеться) или если чего - "довесить" нужную обработку - то есть если ставить html для просмотра - то контролируемый и "сгенерированный" програмой-же (чтоб для его создания не требовалось, "кучка" софта, который, кроме как для этого может быть и не нужен (тому-же листописателю), да еще и в нормальном функционале, может быть платный).

[gomer]

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

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

[bernata]

переходите уже на личности... читаю - читаю... а вы всё в рамках приличия

[hwd]

Сообщение от gomer у мну 3 браузера: ослик 6, опера и лис

добавь к этому списку хром и сафари - это и будет перечень обычно используемых браузеров.
2 Дима_
Честно говоря, я ничего не понял из написанного. Есть кое-какие идеи по поводу доработки шаблона. На выходных внесу некоторые изменения + дополнения... После чего обновлю документацию и пример. На след. неделе сделаю GUI, с помощью которого можно будет упаковывать плагины. документацию, шаблон и пример обновлю, дабы уже окончательный вариант находился по ссылкам. Поскольку тема интереса не заимела - на этом заканчиваю опубликовывать материал.

[gomer]

Сообщение от bernata переходите уже на личности... читаю - читаю... а вы всё в рамках приличия

не тюкайте

Сообщение от hwd тема интереса не заимела

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

[Do$]

Сообщение от hwd тема интереса не заимела

Не согласен. Мне это очень интересно! На выходных буду разбираться что к чему, пока банально нет времени . Ну вы тут особо не скучаете Тема самая динамично растущая в этой ветке, а говоришь нет интереса

[hwd]

Сообщение от Do$ Тема самая динамично растущая в этой ветке, а говоришь нет интереса

Основная масса контента в топике - споры ни о чём, так что размер в данном случае не показатель.

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

У меня корректное отображение наблюдается в Internet Explorer 8/9, Google Chrome, Opera и Safari.

FireFox игнорирует тэги форматирования и отображает их как текст. Браузеры никогда не отличались особой совместимостью (к сожалению).

[Salt]

Сообщение от hwd Браузеры никогда не отличались особой совместимостью (к сожалению)

Вот потому Дима_ и предлагает для просмотра, хотя бы той же readme.html, использовать System.Windows.Forms.WebBrowser(), т.е. просмотрщик, в основе которого всегда лежит IE (именно такой "самодельный" просмотрщик от Autodesk открывается, когда ты из автокада 2012(13), нажав кнопочку [x], переходишь на сайт Autodesk Exchange)
Но ИМХО, я бы отказался от XSLT (от трансформации в HTML) и написал просмотрщик (не веб-браузер), напрямую читающий и визуализирующий информацию из XML файлов, и включил бы его, в качестве обязательного компонента, в состав решения.

На след. неделе сделаю GUI, с помощью которого можно будет упаковывать плагины

Это как раз то второе, что хотелось Диме_. Т.е., в идеале, дать возможность не очень продвинутым авторам плагинов вообще не соприкасаться с лежащими в основе XML-форматами. А еще лучше, это GUI сделать единственным сертифицированным способом редактирования XML и, тем самым, изолировать пользователей (авторов плагинов) от возможных будущих изменений XML-форматов.

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

p.s.
ИМХО.
Плагин для автокада не должен требовать инсталлятора. Нужно брать папку с должным образом оформленным плагином, класть её в положенное место в сети или на локальном компьютере и на этом всё!. Об остальном, на основе имеющейся в папке информации, позаботится специализированный загрузчик.
Андрей Бушман принципиально делает всё правильно. Можно спорить лишь о деталях. Приложения из "магазина Autodesk" именно таким (похожим) образом и документируются/распространяются/инсталлируются. Но их (автодеск) конкретное решение непригодно для промышленной эксплуатации в рамках института, где трудится Андрей.

[gomer]

Сообщение от hwd Браузеры никогда не отличались особой совместимостью (к сожалению).

вот поэтому

Сообщение от gomer Обычный браузер - понятие гипотетическое

Сообщение от Salt Нужна еще третья вещь - загрузчик плагинов (насколько я в курсе, от у тебя готов, или почти готов). И тогда есть все шансы получить целостное, вполне промышленное решение. Этим решением, помимо тебя самого, сможет воспользоваться любой заинтересованный CAD-администратор.

Идея не нова, на лиспе такое было написано за царя гороха еще

[Salt]

Идея не нова, на лиспе такое было написано за царя гороха еще

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

[hwd]

Сообщение от Salt Вот потому Дима_ и предлагает для просмотра, хотя бы той же readme.html, использовать System.Windows.Forms.WebBrowser(), т.е. просмотрщик, в основе которого всегда лежит IE (именно такой "самодельный" просмотрщик от Autodesk открывается, когда ты из автокада 2012(13), нажав кнопочку [x], переходишь на сайт Autodesk Exchange)

Можно и так. Я подумаю над этим вариантом. Хотя можно и просто прописать в readme.html, что для его корректного отображения следует использовать такие-то браузеры.

Сообщение от Salt Но ИМХО, я бы отказался от XSLT (от трансформации в HTML) и написал просмотрщик (не веб-браузер), напрямую читающий и визуализирующий информацию из XML файлов, и включил бы его, в качестве обязательного компонента, в состав решения.

Категорически не согласен. XSLT позволяет абстрагировать визуализацию от содержимого. При необходимости, в XML файлах можно указать ссылку на др. XSLT и данные будут представлены совершенно иначе. С помощью XSLT данные можно представлять в любом формате, например в txt, xml (иной структуры), html, rtf, pdf, csv и т.п. Кроме того, разработчик может часть информации прописать не просто текстом, а в виде разметки html, дабы эта информация была оформлена некоторым особым видом. XSLT распознает это и корректно отобразит.
В шаблоне XSLT используется "за кулисами". Вчера мне пришла одна идея, в свете которой я начал модифицировать шаблон. Теперь он будет организован более "красиво". Например в каталоге ./support будут находиться только те файлы, которые необходимы для визуального представления, т.е. это файлы XSLT, XSD и "CSS" (т.е. XML вариант CSS контента). В этот каталог собраны статические файлы, содержимое которых не потребуется менять. Программисту нет необходимости лезть в тот каталог. Собственно собраны туда затем, чтобы случайно не изменили чего-нить. В файл readme.html будет добавлена некоторая дополнительная информация, полезная как пользователям, так и разработчикам...

Сообщение от Salt Сообщение от hwd На след. неделе сделаю GUI, с помощью которого можно будет упаковывать плагины Это как раз то второе, что хотелось Диме_. Т.е., в идеале, дать возможность не очень продвинутым авторам плагинов вообще не соприкасаться с лежащими в основе XML-форматами. А еще лучше, это GUI сделать единственным сертифицированным способом редактирования XML и, тем самым, изолировать пользователей (авторов плагинов) от возможных будущих изменений XML-форматов.

Не понял насчёт "сертифицированного". GUI однозначно будет построен таким образом, чтобы с его помощью можно было выполнять все действия, которые потребуются. Отдельный GUI будет для работы с файлами настроек (т.е. теми файлами которые хранятся непосредственно в подкаталоге "./settings".

Сообщение от Salt Плагин для автокада не должен требовать инсталлятора. Нужно брать папку с должным образом оформленным плагином, класть её в положенное место в сети или на локальном компьютере и на этом всё!.

Согласен на все 100%. Однако те, кому всё же не терпится - всегда могут результат упаковки засунуть в msi-пакет. Я этого делать не буду, т.к. моё видение таково, что админ должен просто скопировать плагин в определённое место на сервере (в репозиторий организации), а тот автоматом "раскатается" на локальные машины. Плагин автокада - это отдельный независимый модуль, как камешек в мозаике. Плагин самодостаточен и не должен влиять на работу др. плагинов, иначе начинает образовываться цепочка зависимостей плагинов друг от друга, что не есть хорошо. Плагин - это как маленькая функция в программировании, решающая свою конкретную задачу. Должна иметься возможность заменить один плагин другим, без фатального влияния на др. плагины. Это то, чего я придерживаюсь при написании плагинов под AutoCAD. Установка плагина должна быть как можно более простой. Нет более простого способа, чем просто скопировать шаблон в нужное место (имхо).

Сообщение от Salt Категорически нужна еще третья вещь - загрузчик плагинов (насколько я в курсе, от у тебя готов, или почти готов).

Та версия, которая работает сейчас, не ориентирована на использование плагинов, упакованных в данный шаблон. Поэтому я напишу другую. Я разделю задачи на несколько подзадач:

1. Отдельное внешнее exe приложение будет анализировать имеющиеся версии плагинов и в формате XML формировать сводную информацию о том, под какую версию AutoCAD имеются какие плагины и в каких каталогах они находятся.
2. Будет иметься отдельное exe приложение, имеющее GUI, с помощью которого юзер будет просматривать информацию о том, какие плагины имеются в наличии, под какие версии AutoCAD и каков их функционал. Напротив тех плагинов, которые ему интересны, юзер будет ставить галочку, тем самым пометив их в автозагрузку. Те плагины, которые администратором CAD помечены в автозагрузку как обязательные, будут подсвечены серым цветом, чтобы юзер не мог снять галочку. Информация записывается в XML, хранящийся в профиле пользователя. То, что помечено обязательным к загрузке - хранится в др. месте, дабы юзер не мог на это повлиять (управление у администратора CAD).
3. Далее на сцену выходит загрузчик - плагин AutoCAD, непосредственная автозагрузка которого происходит за счёт его регистрации в реестре. Автозагрузчик считывает ту информацию, которую юзер сформировал в предыдущем пункте и выполняет последовательную загрузку плагинов.
4. Будет иметься ещё одно внешнее exe приложение, в котором, с помощью GUI, юзеру будет динамически формироваться справочная система, объединяющая в себе справку всех плагинов, выполненных в соответствии с шаблоном. Приложение будет предоставлять пользователю и полный перечень имеющихся ключевых слов, собранных из всех плагинов. Т.о. поиск нужного контента будет осуществляться сразу во всех плагинах, построенных на основе шаблона.
5. Структура шаблона строилась сразу с заделом на то, что у программиста может возникнуть желание разместить свой плагин в магазин Autodesk. Для этого я вынес локализацию в отдельный каталог, чтобы добавлять новые локализации было очень просто.

Надеюсь, что ясно выразил свою идею.

Сообщение от Salt Сообщение от gomer Идея не нова, на лиспе такое было написано за царя гороха еще Речь идет о конкретном загрузчике от hwd, концептуально увязянном с тем, что описано в данной ветке.

gomer всё прекрасно понимает, просто очень любит "включать дурачка" с целью споров ни о чём. поэтому лично я не воспринимаю его всерьёз.