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.

Открыл пакет - попробовал. Понравилось - распаковал в реальную ФС... :roll:

Однако, получатся, пакеты для опробования... :roll:

Автор:  Иван Горячев [ Понедельник, 23 Июнь, 2008 03:33 ]
Заголовок сообщения:  Re: Репозитарий "полезных" примочек

Иван Горячев писал(а):
Не нова, не нова. Подождите до понедельника - их есть у меня


Закинул на SVN небольшую кучку правок. В том числе вложенные меню и объединение одинаковых меню

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/