DRAKON.SU

Я и еще буду пробовать и вскоре своих студентов направлю на этот сайт! Очень уж привлекательна кроссплатформенная реализация!
Так что замечания появятся в большом количестве.

В Windows контекстное меню открывается при клике на правой клавише мыши.

Степан, почему в DRAKON Editor 2 открытие контекстного меню сделали при клике на левой клавише мыши?

Это веб-приложение. Перефразирую нашего дорогого Александра Сергеевича, скажу:
Вебка должна быть немного тупой.

Не помню, чтобы я такое говорил.

Главное — мы помним.
http://bibliotekar.ru/encSlov/15/173.htm

Цитирую раздел 11 из моей статьи:
"АЛГОРИТМИЗАЦИЯ МЕДИЦИНЫ И РЕФОРМА МЕДИЦИНСКОГО ЯЗЫКА" viewtopic.php?f=132&t=5569

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

В разные дни потихоньку буду публиковать эти временные недостатки: мои наблюдения и мысли о перспективных свойствах кросс-броузерного дракон-редактора)

1. Отсутствие параллельности.
Понятно, что в том виде, в каком параллельность присутствует в дракон-нотации, она мало кому нужна: для её применения не хватает внутрисхемных меток и логических элементов (). Но, вообще говоря, средства булевой логики очень перспективны, т.к. и в бытовых и в профессиональных вопросах параллельность иногда позволяет в десяток раз сократить количество ‘лапши’… А количество, как известно, диалектически переходит в качество: с использованием параллельных потоков можно будет применять дракон-конструкции с такой эффективностью и в таких задачах, о решении которых сегодня и говорить-то не хочется: слишком сложны.
Я в практике программирования лишь однажды вплотную столкнулся с необходимостью использовать ‘ булеву логику’, и тот случай запомнился надолго. Опыт у меня маленький: программирование не входило в мои профессиональные обязанности.

--

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

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

Чтобы любую чужую схему можно было так транслировать, давно предлагаю организовать хранение данных табличным способом. Препятствий для этого нет: Фабула использует XML, который, вроде-бы, все СУРБД понимают. А редактор Тышова использует csv-формат, и в этом формате табличные данные очень компактно хранятся (и тоже предусмотрен их импорт-экспорт в БД).

2. Для реляционного хранения схем потребуются две таблицы:
1) структуру схемы хранить следующим способом: [ID первой иконки] - [ID второй иконки] - [ID линии связи от первой иконы ко второй]
2) все параметры икон (или линий связи) предлагаю хранить в табл.Объект: [ID] … [… и все остальные объектные атрибуты: форма, положение, цвет, текст, тип иконы, … и т.д.]






Компактность схем позволит использовать их повсеместно.
Где могут пригодится блок-схемы кроме сложных многоходовых платежей или диаграмм в органайзерах? Да везде, где есть информация и потребности в обмене! Я считаю, что любая UML-диаграма — это блок-схема. И дракон-схемы в том числе. Указанный табличный формат позволяет хранить любую информацию: он есть основа Универсальной БД.

Дополнительная информация: Интересно выглядит перспектива применения блок-схем для макро-программирования

Понятно же, что веб-схемами надо как-то обмениваться. Именно схемами, а не только их графическими копиями. Даже если схема создана в онлайн-редакторе, полезно иметь её файловый дубликат. Для хранения схем предлагаю основным форматом использовать всё те же две таблицы, зашитые в csv.

Именно к этому формату Геннадий Николаевич сможет ‘подтянуть’ свой *.drt (чтобы была совместимость).

Преимущества реляционной модели данных:

1. Практически не существует проблемы кодогенерации. Например, реляционная модель говорит: листинг программы и различные варианты её блок-схем — это 'одно и то же'.
2. Даёт методы автоматического составления схем и их преобразований друг в друга (например, преобразование примитива в силуэт).
3. Сетевое дерево полезно для навигации и для понимания структуры программ, схем и алгоритмов. Но эта нормализованная сетевая структура может быть построена только из базы данных. Это архисложная задача, и другими методами её никто ещё не решил.
4. Возможности самопрограммирования основаны на методе дополнений: в таблице связей [Протокол] намеренно оставляются пустые поля. И это позволит дополняющим записям автоматически находить друг друга… Это действо будет похоже на искусственный интеллект.
5. Реляционный (табличный) метод записи алгоритмов, программ и схем позволяет однозначно задать начало и последовательность их сравнения. То есть, даже теоретически, задачи сравнения дракон-схем всегда решены.
6. Типовая нормализация таблицы связей (методом сетевой сортировки) позволит не только сравнивать готовые программы, но и находить в них одинаковые части, что приведёт к унификации программного кода и возможностям автоматического интернет-поиска его аналогов. Полного решения этой задачи пока нет. Есть только догадки.
7. Семантическая запись программ способствует применению в одной программе сразу нескольких языков программирования. Это позволит реализовать полезные возможности каждого языка. Например, логические элементы проще всего реализуется на ассемблере. Возможно, появится универсальный язык программирования, который вберёт в себя все полезные возможности других языков.
8. Динамичная компоновка программ: они могут быть сколь угодно сложными. Но для понимания каждого конкретного блока программисту достаточно иметь возможность последовательного чтения: все взаимосвязи будут расположены максимально близко друг к другу. Динамичный силуэт иллюстрирует эти возможности... Динамичная компоновка требует индексированного поиска (фильтрации) и быстрых методов сортировки, а это свойственно реляционным БД.

А вот и недостатки: (). По каждому из этих пунктов у меня есть возражения… Можно интересно поспорить (лучше, наверное, для этого создать специальную тему?).

Динамичные стили цветового оформления икон

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

2) «Общая судьба» – это дополнительная классификация. Например, подзадачи, оформляемые ветками силуэта, раскрашивать в свой цвет.
3) Внутренние ссылки – гиперссылка и соответствующая гиперметка должны динамично выделяться особой цветовой парой при передаче курсорного фокуса (или при выделении) любой из них. Focus и Select — это главные операции при работе с любыми объектами (в разных программах).
4) Цветовая индикация активности:

==

И вот этими вот четырьмя кнопками стили можно переключать (для одной и той же схемы).

Мобильность требует аскетичности )
да и в обычных схемах иногда полезны "мобильные" режимы для некоторых блоков...

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

Мобильные схемы должны обладать аскетичными размерами. Отсюда – частое преобразование Обычная схема <-> схема-слепыш (или даже пазл-схема, которая ещё в десять раз мельче). Задавать режим просмотра вручную, или использовать адаптивный дизайн — это уже на усмотрение пользователя.

--

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

--

Ну, и оффлайн-режим работы тоже не помешает, ибо, Интернет есть не всегда (когда он нужен)).

Степан, как вставить икону Вставка?

"Вставки" пока нет. Но скоро будет.

Это прорыв!


То есть вы изобрели нечто. Но что именно, пока не знаете?

< от Степан Митькин:

Пазл-схемы — это производные от сетевых деревьев:

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

по горизонтали: надписи заменить буквенными индексами, и поместить их внутрь иконок
по вертикали: ‘лесенки’ иконок превратятся в ‘полоски’

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

‘Плюсики’ в пазл-схемах останутся: они обозначают входящие и исходящие ветвления, и показывают, какие из узлов работают как ссылки и метки.

https://drakon-editor.com/
1. Добавлено несколько новых икон.
2. Мелкие исправления.

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

dvuugl Это годится лично для вас. Может быть, еще для двух или трех человек. Но не более того.

Моя цель — сделать язык ДРАКОН доступным для миллионов.
Годятся ли Ваши предложения для такой цели?
В чем преимущества вашей нотации?

-"Применительно к лени рисования и экономии места. В аскетичных карандашных набросках." В планшетах наконец. Принимая во внимание современные возможности свёртки текста, "фолдинг". Каждая свёртка равносильна иконе "действие".
Там описка, действия пишутся СПРАВА от вертикалей конечно. ДРАКОН уже доступен для миллионов. Если конечно это им надо: упорно издаются учебники иллюстрированные древними блок-схемами как будто ДРАКОН не существует как общественное достояние больше 15 лет как минимум.
Пусть будет доступен и для нескольких лентяев, они тоже люди. И не всегда плохие Там и треугольник который вниз показывает можно выбросить, применяя слегка подправленное правило Р-схем: "Если условие истинно, то выполняются действия на вертикали СЛЕВА ПОД условием". Оставить только треугольник вправо, как меняющий это правило наоборот, "выполняются действия на вертикали СПРАВА ПОД условием".

Эту мысль надо взять на вооружения. Получается ДРАКОН-микросхема. Вместо полного текста в иконах показывать первую букву текста.
Такую микросхемку можно поместить в угол редактора для навигации.
Или на экране мобильника.