DRAKON.SU

Сейчас сделаны некоторые доработки, выложим возможно через день, два.
Над текстами надо конечно работать.

Улучшенная версия от 01.06.10


Думаю, каждый пользователь должен прочитать книгу (и/или иное описание языка визуализации), чтобы знать его - кто "слыхом не слыхивал" о кнопках, линейках прокрутки и т.п., разве сможет работать в оконном интерфейсе?
Терминология тоже д.б. стандартной - пока по согласованию её не изменим. Просто описание языка, технологии и средств поддержки должно наглядно определять все термины. И тут опять-таки для пояснения на примерах без внесхемной графики КогниСтиль не обойтись...

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

О подсказках - м.б. для сложных сущностей стоит делать по принципу "Что это такое?" с переходом на докэлемент Справки по контексту.

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

ВЫВОД: Пока лучше текстовое окно оставить. Будет найдено общее "принципиальное решение" - будем думать.

Громоздко. Всплывачка удобнее. Ничего делать не надо, сама вылазит! Стоит только задуматься на несколько секунд, что это такое - и вот вам объяснение.

"Что это такое" - само собой, для сложных команд более подробно. Но если пользователь ЧИТАЛ книгу "Как улучшить работу ума", то это не нужно. Всё и так понятно.

Гораздо важнее формулировать команды так, чтобы было понятно с первого раза. Если же использовать лексику Владимира Даниловича - тогда уж точно нужна подробная справка.

В принципе Вы правы.
Можно так, как предлагал для дракон-синт-икон Ввод (от оператора) и Жёсткое поле - рядом с иконой (а не жёстко в стороне) выскакивает окошко редактирования (поверх всего), а в икону вводится его содержимое по команде завершения ввода (кнопке ввода).
Ещё можно подгонять высоту иконы (поля) под текст только по команде оператора - а до тех пор введённое будет "выпирать" - так тоже делается.

Взамен сообщения: viewtopic.php?p=47249#p47249 (т.к. оно так и не стало доступно для редактирования)

В РДП-среде должны вестись каталоги объектов различного рода. В частности, каталогизации подлежат:

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

2. Источники, на которые ссылается содержание документа. Нужно вести биббазу данных либо по АРМ, либо по пользователям. В конкретном РДП-документе формируется обычный перечень источников по номерам, но содержание пункта перечня берётся по ссылке на запись из биббазы (т.е. описания источников пополняются в ней, а не в документе). Формат записи скорее всего д.б. как установлено в библиотечном деле ("машинная карточка" издания; пример можно найти на этой странице, выполнив поиск), а для перечня берутся отдельные поля (значения которых составляются в слитный текст пункта).

3. Области (непустые, выборочно по указанию сочинителя). Удобно вести каталоги областей как отдельные листы РДП-документа, для которых сочинитель выбрал особый тип "каталог". По сути это то же, что страница-палетта в DesignIDEF, смысл - на ней допустимо помещать иконы Область, логически не входящие ни в какую схему как варианты либо как декомпозиты к.-л. фрагмента.
Очевидно, что поля объектов в текстах икон такой области также абстрагируются - становятся переменными-"иксами" (получают условные имена; одному имени в исходной схеме соответствует одно имя по каталогу); при использовании в конкретной схеме сочинитель должен указать имя из числа употребляемых в этой схеме вместо каждого условного для обратной конкретизации.

Если область является шампур-блоком, то можно поставить ей в соответствие в каталоге некоторую шампур-икону с текстом; объекты этого текста также ставятся в соответствие объектам текстов икон, входящих в область. Тем самым вводится обобщение области для более высокого уровня детализации схем на данном гибридном техноязыке. Эту операцию, очевидно, должен выполнять сочинитель.

Лист-каталог, по-видимому, д.б. одноязыковым; он сохраняется и открывается отдельно (или в составе отдельного РДП-каталога, где наверно м.б. листы для разных языков РДП). Сочинитель может создавать столько каталогов, сколько ему нужно. В принципе это то же, что лист-шаблон; см. п.4.

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

4. Листы РДП-документа (по указанию сочинителя, для использования в качестве шаблонов). Удобно объявлять некоторые листы шаблонными и сохранять их отдельно, а затем загружать в текущий РДП-документ (либо при создании нового листа допускать указание шаблонного как образца, по которому создавать).

Взамен сообщения: viewtopic.php?p=47251#p47251 (т.к. оно так и не стало доступно для редактирования)

1. РДП-документ должен обрабатываться в одном из следующих режимов:

* сочинения - полноэкранного редактирования содержания;
* исполнения - полнофункциональной интерпретации содержания лист-силуэтной структуры маршрутов;
* демонстрации - ограниченной интерпретации содержания маршрутов.
Режим устанавливается командой оператора; д.б. предусмотрено введение запрета смены режима (только по вводе пароля) либо для данного документа, либо для приложения в целом (можно, развив реализацию Ты-среды, делать РДП-приложение только для демонстрации).

Требования к реализации режима сочинения:
*все объекты одинаково доступны для просмотра и редактирования, что показывается их изображением в нормальном цвете и яркости (конечно, объекты текущего выделения показываются особо);
* линии лист-силуэта и иконы Имя строки без термина и Адрес строки можно показывать блёклыми, чтобы не отвлекали;
* навигация клавишами курсора (по маршрутам схем) и мышью (произвольная);
* можно исполнить любую дракон-схему (модель) по выбору оператора;

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

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

О структуре документа см. 2-е техтребование от меня.

2. Оператору д.б. предоставлены следующие возможности работы с документом (команды описываются пунктами с заглавной буквы).

Управление документами:

* Открыть существующий документ (видимо, следует для этого запускать новую копию РДП-редактора как отдельную задачу).
* Создать новый документ (по образцу структуры, описанному в этом сообщении).
* Закрыть документ (с запросом на сохранение изменений).
* Выбрать лист по названию (с переходом для этого к началу обзора содержания документа в индексном разделе) или по номеру (в окне команды).
* Выбрать схему по названию (из обзора в индексе документа).
* Выбрать масштаб отображения листа в широких пределах (возможно, ступенчато из списка с проходом ряда через 100%).
* Переместить окно отображения по листу колесом мыши или прокруткой по линейкам (так, как принято в основных офисных пакетах, в DesignIDEF).
* Открыть прогтекст на исходном языке из числа поддерживаемых прогязыков (в формате компилятора с этого языка, используемого совместно с РДП-системой согласно 9-му требованию от меня).

Редактирование текущего документа:

* Добавить содержательный раздел перед/после текущего (как пустой лист с заготовкой лист-силуэта).
* Пополнить текущий раздел вводом строки перед/после текущей (удобно реализовать как команду контекст-меню иконы Имя строки). По мере пополнения содержания раздела в него автоматически добавляется новый лист с заготовкой.
* Добавить схему (заготовку) внутрь синт-иконы Жёсткое поле, дракон-синт-иконы Комментарий, внесхемного графоэлемента (что означает и логическую привязку схемы к этому объекту).
* Добавить икону/макроикону в строку листа (из подалфавита инфор-синт-языка) либо в привязанную схему (из алфавита языка этой схемы) по шампур-методу, т.е. используя точку ввода.
* Добавить графоэлемент в произвольный рисунок (не в граф-схему).
* Выбрать шаблон оформления листа (рамку и штамп) из набора определений шаблонов (м.б. отд. файлов).
* Переместить внесхемный объект, привязанный рисунок внутри объекта, икону в граф-схеме, графоэлемент в рисунке (буксировкой или стрелкой).
* Пересадить лиану по шампур-методу (в схеме типа силуэта - также заземлить).
* Ввести текст заголовка схемы (раздела или любой другой) взамен заполнителя (автоматически добавляется в состав имён схем в индексе документа).
* Вставить таблицу в текущую позицию текста синт-иконы Жёсткое поле, дракон-синт-иконы Комментарий, внесхемного графоэлемента.
* Редактировать форму таблицы (подразумевается набор команд, как в меню/на панели Таблица офисных пакетов).
* Ввести текст любой другой вершины, ячейки таблицы; желательно, чтобы для формального языка текста (напр. дракон-программ) в редакторе был определён шаблон текста.
* Копировать/вырезать текущее выделение в буфер.
* Снять в графбуфер пиксельный образ ("скриншот") общего выделения (напр., тем самым делается внесхемный элемент-копия фрагмента схемы, чтобы включить в описание этого фрагмента);.
* Вставить из буфера в текущую точку ввода (если содержимое - фрагмент схемы на том же граф-языке) либо в текущий графоэлемент (если содержимое - текст, таблица или изображение, в т.ч. из другого приложения).
* Оттранслировать открытый из файла прогтекст как дракон-схему (-модель) на текущий РДП-лист; при этом каждой дракон-схеме автоматически отводится новая строка с одним жёстким полем (для начала деление листа на ячейки не учитывается); все имена включаются в каталог имён РДП-документа, типы - в систему определений типов (деклар-схему программы).
* Оттранслировать ввод с клавиатуры при нахождении графкурсора на точке ввода некоторой схемы (доступно, если текущая схема является исходным чертежом) как прогтекст оператора с добавлением как иконы в эту точку (автоопределяемого по совпадению ввода с ключевым словом на прогязыке этого чертежа).
* Оттранслировать комплект исходных чертежей (модель из схем, объединённых общим именем и содержащих данные по одной дракон-программе) в прогтекст на языке комплекта.
* Включить в тезаурус текущее выделение в тексте объекта; при этом ищутся все остальные его вхождения "как выделено" (м.б. команда должна иметь параметр "с учётом регистра"); все имена включаются в каталог имён РДП-документа.
* Поставить тег-закладку в любом месте текста иконы (ячейки вставленной в неё таблицы) для последующих ссылок на закладку.
* Навести ссылку из текущего выделения на закладку, иной индексированный элемент данного или другого РДП-документа, файл, веб-узел.
* Копировать выбранную область на лист-каталог (в указанное сочинителем место).
* Поставить для выбранной области в соответствие некую икону с текстом как обобщение содержания области.
* Вставить область из каталога в текущую (указанную) точку ввода. При этом, если область имеет более одного шампура, сочинитель выбирает нужный (сразу входящий в схему), а остальные входы и выходы он подключает далее (пересадками лиан); затем он должен указать конкретные имена для подстановки вместо условных.
* Загрузить лист-каталог (допуская, что он представлен отдельным файлом).
* Сохранить лист-каталог (в отдельном файле).

3. Общие требования к реализации операций:

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

Когда говорится об офисных пакетах - имеется в виду прежде всего OpenOffice.org (а в нём - редактор Draw). Как использовать возможности форматирования графики - см. документы Draw, доступные в составе архивов в Разд. Загрузки ресурса на этой странице, и прежде всего - графчасть к Задаче 1.1.1 из Приложения 4.
Как пример реализации функций моделирования обычно привожу DesignIDEF; сам пакет доступен в одноимённом пункте на этой странице, тут же есть проект русскоязычного описания к нему (п. Описание DesignIDEF).

Возможно, это будет изменено и дополнено.