OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 22:33

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 18 ] 
Автор Сообщение
 Заголовок сообщения: Репозитарий "полезных" примочек
СообщениеДобавлено: Вторник, 17 Июнь, 2008 22:43 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Все писали или пишут разные полезные примочки (одна-несколько команд) для себя. Вроде WorkWindows или Info21_sysEdit. И для других -- тех, кто тоже сочтет их полезными. Основная проблема -- как попробовать без лишнего напряга.

У Зина, например, такие примочки сидят в подсистеме Cpc. Но с установкой-удалением приходится возиться в меню, строковых ресурсах и т.п. А хочется:
- скопировал папку
- потыкал-попробовал, не нравится -- удалил.

Появилась такая идея:
- каждую примочку (одна или несколько команд) помещать в отдельную подсистему. Договориться об префиксе имени для этих подсистем, например "Ext_".
- команды примочек сидят в общем меню "Ext" или в каком-то из существующих, если по смыслу туда больше подходят.
- сделать модификацию HostMenus, которая будет команды из описаний меню с одинаковыми именами и контекстом помещать в одно меню (хотя бы для описанию меню из подсистем "Ext_"). (стандартное поведение: отдельное описание меню = отдельное меню).

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

С последним можно примириться (если примочки удобные -- можно потерпеть) и бороться (общепризнаные примочки, сходные по функционалу, объединять в одну подсистему).

Что скажете?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Июнь, 2008 22:48 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Однако, у меня такое чувство, что идея с объединением меню может быть не нова...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Июнь, 2008 00:27 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Евгений Темиргалеев писал(а):
Однако, у меня такое чувство, что идея с объединением меню может быть не нова...


Не нова, не нова. Подождите до понедельника - их есть у меня


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Июнь, 2008 10:17 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Не знаю, как разобраться со строковыми ресурсами, но с меню можно разобраться так:
1. Для начала, не плодить подсистемы, а складывать всё в одну.
2. Элементы меню хранить в отдельных файлах для каждой примочки. С именем файла пока не определился, но подошло бы что-то вроде ExtMenus<имя модуля примочки>.
3. Написать примочку : ), которая ищет в Rsrc данные файлы и вставляет их содержимое в Menus. Тут возможно два варианта: либо после окончания работы примочки файл с пунктами меню удалить, либо в самом начале работы команды очищать Menus.
4. Добавить запуск команды примочки в "Обновить меню" (единственный раз, когда придётся копаться в меню самостоятельно).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Июнь, 2008 11:24 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
К сожалению, такой подход не дает главного: скопировал/распаковал (1 раз)=поставил, удалил (1 раз)=удалил. Ведь чтобы удалить, надо пройтись не только по меню/строкам, но и по папкам Mod/Code/Sym. А если примочка из нескольких модулей да с ресурсами-формами?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Июнь, 2008 13:28 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Команды инсталляции и удаления файлов можно включать в ReadMe к примочке. В примочечной подсистеме достаточно создать сервисный модуль, который будет по списку имён модулей производить удаление соответствующих символьных и прочих файлов (в идеале - включая и сам ReadMe).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Июнь, 2008 14:01 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Можно, да не хочется. И, сдаётся, не только мне... :) У Зина в Cpc вроде есть средства для дописывания к меню и строковым ресурсам. Но вот чтобы народ там еще и скрипты делал, которые чикают свои строки из файлов ресурса и команды из меню -- не припомню :)

Было дело пробовал разные подсистемы из CPC. Шоб одну установить, надо еще установить 5 штук, которые она использует, те еще чего-то используют, в каждой прочитай Quick-Start из 5 пунктов да подави командеры. Там конечно не просто примочки, вопрос посложнее, но суть одна - хочется чтобы инсталяция/деинсталяция = распаковка/удаление (папки). Для меня лично как для юзера этот пункт главный; и совсем не интересно, что там можно, а что нельзя.

P.S. После ББ-подсистем виндовые инсталяции (да и вообще всякие инсталяции) у меня вообще отвращение вызывают. "Подготавливается операция", куча дерьма прописывается в реестр,.... После анинсталла половина остается. Тьфу!

Ставил раз ТурбоДелфи и какие-то хрени от .NET, которые она требовала. Сожралось около 2 ГБ. После анинсталла делфы и примочек освободилось около 700 МБ. Куда делся 1ГБ -- хз.

В линухах тоже мёдом не намазано. Упорядочивание, стурктура какая-то есть стандартная в корневой ФС, но при установке продукт размазывается по всей этой структуре... Вот так я понимаю ентот процесс (если что не так, от ликбеза не откажусь).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Июнь, 2008 14:14 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Мне интересна именно проблема инсталяция/деинсталяция = распаковка/удаление (папки) и пути её решения для ББ. Для начала хотя бы для каких-то простых средств-примочек.

При этом я не упираю на своём предложении. Должны быть и другие способы...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Июнь, 2008 15:03 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Евгений Темиргалеев писал(а):
Мне интересна именно проблема инсталяция/деинсталяция = распаковка/удаление (папки) и пути её решения для ББ.


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

В общем требуется система пакетов для ББ. Причём полноценных пакетов (с внутренними и внешними модулями) без крутой переделки среды/компилятора/языка сделать не получится.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Июнь, 2008 16:56 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Иван Горячев писал(а):
...придётся выполнить какую-нибудь команду для установки. Скрипт во вычищению меню и ресурсов в принципе несложен. Но его же тоже нужно будет вызвать перед удалением
Я за простоту установки/удаления не только для пользователя, но и для разработчика. Согласен, не сложно раз тыкнуть по командеру после копирования для установки и раз перед удалением. Вопрос в том, откуда эти командеры возьмутся:
- для установки (например) будет командер 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 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Евгений Темиргалеев писал(а):
Я за простоту установки/удаления не только для пользователя, но и для разработчика.
Если решать вопрос все-таки дописыванием в меню/строки, тогда нужен стандартный интерфейс а-ля носитель/курьер. Носитель подключился (загрузил) описания меню/строк заданной подсистемы, курьеры позволяют читать/дописывать меню/команды/строки и т.п. Тогда скрипты по установке будут простыми. И будут работать как под нашей 1.6 так и под Оминковской.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Июнь, 2008 11:12 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
От Config избавиться можно, если ввести соглашение, что у компонента должен быть определённый модуль с обработчиком сообщений среды: типа сообщение OnBlackBoxStart и т.п.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Июнь, 2008 11:24 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Кажется, стоит включить такой механизм в наш 1.6 в дополнение к стандартному Config. Не особо большие изменения среды нужно, чтобы это обеспечить.

Задача (2) разрешается (при условии независимости подсистем и наличии готовых кодовых/символьных файлов) командой типа ???Cmds.DecodeThis "path" Sub1 Sub2 MySub.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Июнь, 2008 12:07 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Илья Ермаков писал(а):
От Config избавиться можно, если ввести соглашение, что у компонента должен быть определённый модуль с обработчиком сообщений среды: типа сообщение OnBlackBoxStart и т.п.


Вообще да. Только это потребует глубокого продумывания стартового механизма (сейчас в Configе можно расставлять произвольые стартовые команды в произвольном порядке, автоматика должна быть не менее гибкой)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Июнь, 2008 12:14 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Евгений Темиргалеев писал(а):
Кажется, стоит включить такой механизм в наш 1.6 в дополнение к стандартному Config. Не особо большие изменения среды нужно, чтобы это обеспечить.

Задача (2) разрешается (при условии независимости подсистем и наличии готовых кодовых/символьных файлов) командой типа ???Cmds.DecodeThis "path" Sub1 Sub2 MySub.


Я бы не опирался на готовые символьные/кодовые файлы - сейчас они едины, но если ББ будет развиваться, появятся ещё как минимум 64-битные версии.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Июнь, 2008 12:36 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Мы тут это обдумывали года полтора назад - планировалось пристегнуть под курсовой кому-нибудь... Но задание лоботрясам не по зубам оказывалось (особенно учитывая, что основной язык у них таки С++, а ББ ещё осваивать надо).

В общем, может, на мысли наведёт (хотя, конечно, попроще надо бы):

Цитата:
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на подсистему 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 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Илья Ермаков писал(а):
попроще надо бы
Без 5-6.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 23 Июнь, 2008 03:33 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Иван Горячев писал(а):
Не нова, не нова. Подождите до понедельника - их есть у меня


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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 18 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB