OberonCore https://forum.oberoncore.ru/ |
|
Репозитарий "полезных" примочек https://forum.oberoncore.ru/viewtopic.php?f=47&t=1033 |
Страница 1 из 1 |
Автор: | Евгений Темиргалеев [ Вторник, 17 Июнь, 2008 22:43 ] |
Заголовок сообщения: | Репозитарий "полезных" примочек |
Все писали или пишут разные полезные примочки (одна-несколько команд) для себя. Вроде WorkWindows или Info21_sysEdit. И для других -- тех, кто тоже сочтет их полезными. Основная проблема -- как попробовать без лишнего напряга. У Зина, например, такие примочки сидят в подсистеме Cpc. Но с установкой-удалением приходится возиться в меню, строковых ресурсах и т.п. А хочется: - скопировал папку - потыкал-попробовал, не нравится -- удалил. Появилась такая идея: - каждую примочку (одна или несколько команд) помещать в отдельную подсистему. Договориться об префиксе имени для этих подсистем, например "Ext_". - команды примочек сидят в общем меню "Ext" или в каком-то из существующих, если по смыслу туда больше подходят. - сделать модификацию HostMenus, которая будет команды из описаний меню с одинаковыми именами и контекстом помещать в одно меню (хотя бы для описанию меню из подсистем "Ext_"). (стандартное поведение: отдельное описание меню = отдельное меню). Получаем - большой плюс: желаемое скопировал-удалил; - плюс: удобство разработки-опробования, учитывая независимость разработчиков и мнений; - плюс-минус: удобство выбора-централизация (ущерб независимости разработки) - нужен общий репозитарий, где будут согласовываться названия после "Ext_" и указываться назначение примочек. - минус: будут плодиться подсистемы. С последним можно примириться (если примочки удобные -- можно потерпеть) и бороться (общепризнаные примочки, сходные по функционалу, объединять в одну подсистему). Что скажете? |
Автор: | Евгений Темиргалеев [ Вторник, 17 Июнь, 2008 22:48 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Однако, у меня такое чувство, что идея с объединением меню может быть не нова... |
Автор: | Иван Горячев [ Среда, 18 Июнь, 2008 00:27 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Евгений Темиргалеев писал(а): Однако, у меня такое чувство, что идея с объединением меню может быть не нова... Не нова, не нова. Подождите до понедельника - их есть у меня |
Автор: | Valery Solovey [ Среда, 18 Июнь, 2008 10:17 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Не знаю, как разобраться со строковыми ресурсами, но с меню можно разобраться так: 1. Для начала, не плодить подсистемы, а складывать всё в одну. 2. Элементы меню хранить в отдельных файлах для каждой примочки. С именем файла пока не определился, но подошло бы что-то вроде ExtMenus<имя модуля примочки>. 3. Написать примочку : ), которая ищет в Rsrc данные файлы и вставляет их содержимое в Menus. Тут возможно два варианта: либо после окончания работы примочки файл с пунктами меню удалить, либо в самом начале работы команды очищать Menus. 4. Добавить запуск команды примочки в "Обновить меню" (единственный раз, когда придётся копаться в меню самостоятельно). |
Автор: | Евгений Темиргалеев [ Среда, 18 Июнь, 2008 11:24 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
К сожалению, такой подход не дает главного: скопировал/распаковал (1 раз)=поставил, удалил (1 раз)=удалил. Ведь чтобы удалить, надо пройтись не только по меню/строкам, но и по папкам Mod/Code/Sym. А если примочка из нескольких модулей да с ресурсами-формами? |
Автор: | Александр Ильин [ Среда, 18 Июнь, 2008 13:28 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Команды инсталляции и удаления файлов можно включать в ReadMe к примочке. В примочечной подсистеме достаточно создать сервисный модуль, который будет по списку имён модулей производить удаление соответствующих символьных и прочих файлов (в идеале - включая и сам ReadMe). |
Автор: | Евгений Темиргалеев [ Среда, 18 Июнь, 2008 14:01 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Можно, да не хочется. И, сдаётся, не только мне... У Зина в Cpc вроде есть средства для дописывания к меню и строковым ресурсам. Но вот чтобы народ там еще и скрипты делал, которые чикают свои строки из файлов ресурса и команды из меню -- не припомню Было дело пробовал разные подсистемы из CPC. Шоб одну установить, надо еще установить 5 штук, которые она использует, те еще чего-то используют, в каждой прочитай Quick-Start из 5 пунктов да подави командеры. Там конечно не просто примочки, вопрос посложнее, но суть одна - хочется чтобы инсталяция/деинсталяция = распаковка/удаление (папки). Для меня лично как для юзера этот пункт главный; и совсем не интересно, что там можно, а что нельзя. P.S. После ББ-подсистем виндовые инсталяции (да и вообще всякие инсталяции) у меня вообще отвращение вызывают. "Подготавливается операция", куча дерьма прописывается в реестр,.... После анинсталла половина остается. Тьфу! Ставил раз ТурбоДелфи и какие-то хрени от .NET, которые она требовала. Сожралось около 2 ГБ. После анинсталла делфы и примочек освободилось около 700 МБ. Куда делся 1ГБ -- хз. В линухах тоже мёдом не намазано. Упорядочивание, стурктура какая-то есть стандартная в корневой ФС, но при установке продукт размазывается по всей этой структуре... Вот так я понимаю ентот процесс (если что не так, от ликбеза не откажусь). |
Автор: | Евгений Темиргалеев [ Среда, 18 Июнь, 2008 14:14 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Мне интересна именно проблема инсталяция/деинсталяция = распаковка/удаление (папки) и пути её решения для ББ. Для начала хотя бы для каких-то простых средств-примочек. При этом я не упираю на своём предложении. Должны быть и другие способы... |
Автор: | Иван Горячев [ Среда, 18 Июнь, 2008 15:03 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Евгений Темиргалеев писал(а): Мне интересна именно проблема инсталяция/деинсталяция = распаковка/удаление (папки) и пути её решения для ББ. В такой форме проблема нерешаема. Если конечно не требовать, чтобы в архиве присутсвовали кодовые и символьные файлы. Всё равно придётся выполнить какую-нибудь команду для установки. Скрипт во вычищению меню и ресурсов в принципе несложен. Но его же тоже нужно будет вызвать перед удалением В общем требуется система пакетов для ББ. Причём полноценных пакетов (с внутренними и внешними модулями) без крутой переделки среды/компилятора/языка сделать не получится. |
Автор: | Евгений Темиргалеев [ Среда, 18 Июнь, 2008 16:56 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Иван Горячев писал(а): ...придётся выполнить какую-нибудь команду для установки. Скрипт во вычищению меню и ресурсов в принципе несложен. Но его же тоже нужно будет вызвать перед удалением Я за простоту установки/удаления не только для пользователя, но и для разработчика. Согласен, не сложно раз тыкнуть по командеру после копирования для установки и раз перед удалением. Вопрос в том, откуда эти командеры возьмутся:- для установки (например) будет командер DevCompiler.CompileThis, которым разработчик и так пользуется - или специально для этого написанная команда (процедура) = лишняя возможность ошибиться. Иван Горячев писал(а): В такой форме проблема нерешаема Мне кажется, что частично она уже решена. Главный лозунг подсистем - "Всё свое ношу с собой" ("Keep all constituents of a component in one place"). Если при этом речь идет о подсистеме, которая: - использует только стандартные модули/подсистемы; - не требует правки Config; - поставляет новые средства через свое меню, то её достаточно скопировать, скомпилировать (тыкнув командер) и нажать UpdateMenus. Для удаления - удалить папку. Установка/удаление требует дополнительных действий, если (1) несколько независимых мелких компонентов (для которых жалко заводить по отдельной подсистеме) объединены в одну подсистему (проде Cpc) (общие Menus, Strings ...) (2) компоненты подсистемы требуют для функционирования не стандартные компоненты (т.е. установку других подсистем). Мне кажется, что решение этих вопросов возможно и без серьезных переделок (компилятора и языка). Самая сложная проблема в этом вопросе -- добиться полной децентрализации (избавиться от Config и подобного). (2) решается просто, если нет (1). Может все-таки не такая бредовая идея -- "каждому независимо разрабатываему компоненту по подсистеме"? |
Автор: | Евгений Темиргалеев [ Четверг, 19 Июнь, 2008 08:42 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Евгений Темиргалеев писал(а): Я за простоту установки/удаления не только для пользователя, но и для разработчика. Если решать вопрос все-таки дописыванием в меню/строки, тогда нужен стандартный интерфейс а-ля носитель/курьер. Носитель подключился (загрузил) описания меню/строк заданной подсистемы, курьеры позволяют читать/дописывать меню/команды/строки и т.п. Тогда скрипты по установке будут простыми. И будут работать как под нашей 1.6 так и под Оминковской.
|
Автор: | Илья Ермаков [ Четверг, 19 Июнь, 2008 11:12 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
От Config избавиться можно, если ввести соглашение, что у компонента должен быть определённый модуль с обработчиком сообщений среды: типа сообщение OnBlackBoxStart и т.п. |
Автор: | Евгений Темиргалеев [ Четверг, 19 Июнь, 2008 11:24 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Кажется, стоит включить такой механизм в наш 1.6 в дополнение к стандартному Config. Не особо большие изменения среды нужно, чтобы это обеспечить. Задача (2) разрешается (при условии независимости подсистем и наличии готовых кодовых/символьных файлов) командой типа ???Cmds.DecodeThis "path" Sub1 Sub2 MySub. |
Автор: | Иван Горячев [ Четверг, 19 Июнь, 2008 12:07 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Илья Ермаков писал(а): От Config избавиться можно, если ввести соглашение, что у компонента должен быть определённый модуль с обработчиком сообщений среды: типа сообщение OnBlackBoxStart и т.п. Вообще да. Только это потребует глубокого продумывания стартового механизма (сейчас в Configе можно расставлять произвольые стартовые команды в произвольном порядке, автоматика должна быть не менее гибкой) |
Автор: | Иван Горячев [ Четверг, 19 Июнь, 2008 12:14 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Евгений Темиргалеев писал(а): Кажется, стоит включить такой механизм в наш 1.6 в дополнение к стандартному Config. Не особо большие изменения среды нужно, чтобы это обеспечить. Задача (2) разрешается (при условии независимости подсистем и наличии готовых кодовых/символьных файлов) командой типа ???Cmds.DecodeThis "path" Sub1 Sub2 MySub. Я бы не опирался на готовые символьные/кодовые файлы - сейчас они едины, но если ББ будет развиваться, появятся ещё как минимум 64-битные версии. В общем, задача стоит так: создать систему управления пакетами для ББ. Пакеты должны обеспечивать простоту установки и удаления компонент, отслеживание зависимостей и конфликтов версий компонент. В идеале на установку/удаление пакета от пользователя должно требоваться не больше одной команды. |
Автор: | Илья Ермаков [ Четверг, 19 Июнь, 2008 12:36 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Мы тут это обдумывали года полтора назад - планировалось пристегнуть под курсовой кому-нибудь... Но задание лоботрясам не по зубам оказывалось (особенно учитывая, что основной язык у них таки С++, а ББ ещё осваивать надо). В общем, может, на мысли наведёт (хотя, конечно, попроще надо бы): Цитата: ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на подсистему Metasystems Package Manager для BlackBox Component Builder (название директории подсистемы - Mtpm) Mtpm представляет собой механизм распространения набора модулей и произвольных файлов внутри одного общего файла, контроля просихождения и безопасности октрываемых пакетов, доступа к файлам путем временного монтирования в файловую систему соответствующего виртуального фрагмента с контролем и разрешением конфликтов имен, загрузки модулей в память, а также полной выгрузки модулей и отмонтирования файлов после завершения работы с пакетом. 1. Устройство пакета Возможны два варианта: а) пакет представляет собой бинарный файл собственного формата, содержащий в себе все файлы пакета и другую необходиму информацию. Для работы с пакетом в BlackBox инсталлируется специальный конвертор (Convertres.Converter), который позволяет пользователю выбрать открываемый пакет с помощью диалога открытия файла. Далее открывается диалог с информацией о пакете, контроле безопасности и вариантами дальнейших действий. Затем может быть открыт некоторый стартовый документ из пакета. б) пакет представляет собой отображение, хранящее в себе все данные пакета, и внедряемое в некоторый документ, с которым пакет и распространяется. Пользователь открывает документ обычным образом, после чего сценарий действий аналогичен (а). Примечание: отображение при своей загрузке, очевидно, не считывает данные пакета в память, а всего лишь запоминает тот файловый курьер, через который ведется загрузка (reader(Stores.Reader).rider(Files.Reader)), как это делает, например, TextModels.Model. Следует принять и реализовать один из данных вариантов (возможно, что даже оба). 2. Контроль происхождения и безопасности Загрузчик пакетов должен каким-то образом определять происхождение пакета и его безопасность. Видимо, приемлемым будем механизм сертификации пакетов с помощью цифровых подписей. Вместе с пакетом распространяется информация о создателе пакета и URL, по которому может быть запрошен открытый ключ ассиметричного алгоритма шифрования RSA. Загрузчик пакета проверяет корректность цифровой подписи относительно данного открытого ключа. Пользователь может принять решение о подлинности информации о пакете и его безопасности на основании своего доверия/недоверия к тому источнику, который опубликовал данный открытый ключ. Данными вопросами следует заняться во вторую очередь, после того, как будет реализована остальная функциональность. 3. Монтирование виртуальной файловой системы пакета Пакет содержит в себе виртуальную файловую систему, которая монтируется в Framework через модуль Files. Полностью аналогично работе HostPackedFiles. 4. Загрузка модулей в память Выполняется средой обычным образом, для файлов, монтированных в п.3. 5. Контроль и разрешение конфликтов имен Ключевым моментом является контроль конфликтов имен для стадий (3) и (4). Имена подсистем/файлов/модулей, входящих в пакеты различных разработчиком, могут и неизбежно будут пересекаться. Поэтому при открытии пакета должна выполняться проверка уникальности имен его подсистем/модулей файлов. Могут возникнуть конфликты двух родов: 1) между загружаемым пакетом и другим пакетом, загруженным ранее. В таком случае пользователю должно быть сообщено о невозможности совместной работы двух пакетов и предложено на выбор три варианта дальнейших действий: а) менеджер пакетов выгрузит предыдущий пакет и загрузит требуемый; б) менеджер пакетов запустит второй экземпляр среды, в котором открыет требуемый пакет; в) загрузка пакета будет отменена. 2) между загружаемым пакетов и постоянными подсистемами/файлами/модулями той среды, в которой открывается пакет. В таком случае пользователю должна быть сообщена информация о проблеме и предложены два варианта: а) конфликтующие модули будут выгружены. Конфликтующие объекты файловой системы будут перекрыты виртуальными. б) загрузка пакета будет отменена. 6. Выгрузка пакета Должно быть предоставлено средство, позволяющее пользователю просматривать информацию о загруженных пакетах и выгружать их. Также у пакета есть некоторый главный документ, при закрытии которого начинается его выгрузка. При выгрузке пакета: а) закрываются все окна, в которых открыты документы из пакета (в т.ч. формы); б) выгружаются все модули пакета; в) отмонтируется виртуальная файловая система. |
Автор: | Евгений Темиргалеев [ Четверг, 19 Июнь, 2008 12:58 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Илья Ермаков писал(а): попроще надо бы Без 5-6.Открыл пакет - попробовал. Понравилось - распаковал в реальную ФС... Однако, получатся, пакеты для опробования... |
Автор: | Иван Горячев [ Понедельник, 23 Июнь, 2008 03:33 ] |
Заголовок сообщения: | Re: Репозитарий "полезных" примочек |
Иван Горячев писал(а): Не нова, не нова. Подождите до понедельника - их есть у меня Закинул на SVN небольшую кучку правок. В том числе вложенные меню и объединение одинаковых меню |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |