DRAKON.SU

Разница в том, что DrakonHub бесплатный, ДраконПро платный.
Доцент С.Д. Гусев выбрал DrakonHub потому что он бесплатный.

Владимир Даниэлович,
Вот мы опять подошли к интересной но самой скользкой, "денежной", теме.

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

За вклад в развитие "драконов", предлагаю учредить местное подобие Нобелевской премии: пусть ежегодно Степан и/или Владимир Даниэлович, Геннадий Николаевич распределяют несколько бесплатных годовых и "пожизненных" аккаунтов ДраконПро.

Прежде всего, в рамках этого подфорума, хотелось бы видеть мнение Степана Митькина. Вопросы следующие:

1. Годовой лимит личных бесплатных аккаунтов «ДРАКОНПРО», предназначенных для вознаграждения наиболее отличившихся или потенциально-ценных форумчан: за вклад в развитие визуальных технологий. Это нецелевые аккаунты; каждый призёр будет их тратить как пожелает.
2. Годовой лимит тех же аккаунтов для конкретных экспериментов. Например, на эксперимент обучения студентов-медиков.

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

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

Добавлю к этим аргументам а) возможность работы в команде: коллективное редактирование и чтение блоксхем. б) Сократить время и трудозатраты на установку серверного пакета ДраконПро: временно даём специалисту доступ к пустому сайту. За небольшую плату он сам всё правильно установит.
И главное: в) существует широкая перспектива строительства backend-приложений:

1. Визуально программировать обработку событий. Например, сложные форумные уведомления.
2. Дистанционно управлять работой серверных скриптов (php, и прочие)

Был ли хоть один такой разговор на страницах этого форума? Или где-то ещё?

--


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

Деньги -- это не только рубли или доллары. Уже появляются локальные деньги сайтов (например, киберрубли конференции iXBT). А ещё деньгами можно считать форумные баллы экспертности = профессионально-тематический рейтинг участников обсуждений. Эти баллы можно будет

• перекидывать от одного форумчанина к другому;
• накапливать;
• оценивать ими информацию; и применять в особых голосовалках, где подсчитывается не количество голосов, а суммарный рейтинг проголосовавших за тот или иной пункт опроса.

Это перспективное направление программирования. Но с политическим подтекстом...

Этот вопрос решает только С.Б. Митькин. Больше никто. Кстати, этой программой можно пользоваться бесплатно при определенных условиях. Условия Степан опубликовал.
Программа Г.Н. Тышова только платная.

Продолжим дискуссию. Я вынесу несколько вопросов, которые мы с Единичкой обсуждали в личной переписке, думаю это будет полезно увидеть всем участникам дискуссии.
Во-первых, я возвращаюсь к своим вопросам, заданным ранее:
1. Какова технология составления пазл-схемы?
2. Каким образом пазл-схема отмечает развилки, циклы, переключатели и преобразует силуэты в примитивы?
3. Каков принцип именования элементов пазл-схем? Какие символы в них используются, что обозначает + перед и после имени блока пазл-схемы?
4. Пусть чертёжнику понадобилось изменить иконы "адрес" и "имя ветки". Как он их найдёт на миникарте и как он их найдёт на пазл-схеме?

Теперь вернусь к новым вопросам. Они по сути продолжают мои прошлые вопросы. За это время идея пазл-схем всё-таки несколько развилась и я теперь догадываюсь, что на миникарте фиксированного размера можно двигать курсором, реализуя движение по ней, и нажав на конкретную иконку, переместиться именно к иконке на схеме. При этом пропадает необходимость красной рамки. И может быть я бы согласился с использованием схем, но так и не вижу самого главного, о чём спрашивал раньше.
Новый вопрос более конкретный. Перед вами дракон-схема, абстрактная, но это не мешает выполнению. Представьте её в виде пазл-схемы, пожалуйста.
В целом, как вы себе представляете её изображение на мини-карте и в виде пазл-схемы?
Второй вопрос: в нашей переписке Единичка упоминал, что в "тривьюшках" (это новое полюбившееся название после аэровида) можно обеспечить сворачиваемость узлов. Как представить сворачиваемость узлов для развилок №№ 3, 7, 5, 14, 15?

Я бы на месте него

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

Другой, более продвинутый способ: "механизм гиперссылок".

Кликаем на любой иконе → и перемещаемся либо на минисхему, либо на "пазлы", либо – к текстовой тривьюшке; либо – на просторы Интернета (обычная гиперссылка отправит нас к соответствующей веб-страничке...).
А чтобы объяснить программе, куда именно мы хотим перейти "по клику" – предварительно жмём комбинацию клавиш-модификаторов: [Ctrl],[Shift],[Alt]. Вряд ли наберётся более четырёх вариантов перехода; поэтому, наверное, будет достаточно нажатия только на одну из этих клавиш.

В этом способе заложен принцип похожести идентификаторов объектов: id-шники любой иконы будут иметь одинаковый числовой фрагмент. Например, в тривьюшке ID какой-нибудь конкретной иконы_35 = "t_35" , а на схеме – "_35".

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

Но это ладно, обсуждение этого ещё подождёт. Самые лакомые вопросы остались без ответа, будем ждать от вас его

По этой тривьюшке скоро уже можете рисовать пазл-схему.

Пазл-схема – это повёрнутая тривью. Образец здесь: https://co50581.tmweb.ru/intb3/ntbpro/d ... tion/#p413

Некоторые имена листьев имеют особый цвет – это внутренние гиперссылки-псевдонимы. Только в этот раз я их для наглядности ещё и оранжевым цветом пометил.
В следующих гипертекстовых treeview можете поэкспериментировать (кликая на этих же листьях мышкой):
• ⋱Свернул частично
• ⋱Свернул всё
• ⋱Без вспомогательных икон

• 2
• 2
• 2
• 5
• 9
• 13

На тривью-рисунке вспомогательные узлы отмечены тёмным цветом.
Без них тривьюшка (и пазл-схема) получается более правильная и понятная:

Как видите, на самом деле, на икону№2 передача управления идёт из трёх мест. А в силуэте это заметить трудно.

Если уж записывать вспомогательные адресные иконки, то парами: "адрес" и "имя" каждой ветки надо было обозначить уникальными (разными) числами.
Алексей же, по привычке, отметил по сути разные иконы одним и тем же id-числом.

id-шниками

На обычной схеме они у Митькина не показаны, так хоть на минисхемах отобразить. Мини- и обычную- схемы синхронизировать выделением соответствующих икон (а не только по цвету...).

Так и ссылаться проще. Даже хэштеги в гиперссылках не нужны.
Просто где-нибудь на форуме пишешь:

Цитата:
.............................№13.

И сразу всем понятно, о какой иконке речь.

Административный вопрос:

Как здесь, на форуме, получить права модератора темы?

Внештатная модерация имеет много преимуществ...
Заодно, покажу, как использовать те же тривьюшки для навигации по форумам: ⋱сложное оглавление для нескольких родственных тем, сразу по нескольким сайтам...

Это не моя привычка, а особенность редактора. Ведь я отправляю не id икон, а их текст. А содержимое икон "имя ветки" и "адрес" должны совпадать. Как бы иначе вы поняли, куда идёт передача управления? Ладно это пример с тремя соснами, в них не заблудишься, а если бы я дал схему из 10 веток с веточными циклами, где все иконы просто уникально пронумерованы?


Ну в том-то и дело. Раньше кстати в ваших идеях не было id, у вас буквами обозначались блоки. Сейчас числами. Но и прикол-то в том, что так ссылаться не проще. Если мне представить вот это дерево из чисел, я не пойму куда кликать, например, чтобы мне попасть на икону "Действие", на цифру 5, 7 или 10. То есть мне сперва, чтобы сослаться на икону из схемы, надо открыть эту икону, посмотреть её id. Потом написать на форуме - "да, в этой схеме есть икона 13, откройте её с помощью пазл-схемы". Потом читатели форума должны открыть это тривью и искать в нём эту 13.

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

О! В тумане философского кумара появились проблески реальности! Посмотрели в ТГ-канале Дракона мой примерчик отладки программ в gdb по исходному языку, транслированному в С?
Для отладки по графической диаграмме как раз потребуется уникальный идентификатор у каждого графического элемента. Ну что, кто сделает блок объявления переменных в Дракон-программе, плюс взаимодействие с gdb, которые превратят Дракон из игрушки интеллектуальных онанистов в полноценную визуальную среду программирования и отладки? В том примерчике как раз было показано выполнение программы по шагам исходного языка, в данном случае по одному элементу Дракон-диаграммы. Также можно было ставить точки останова на блоках, отображать текущие значения переменных в программе, в общем, всё то, что есть для полноценной отладки в gdb.

Для чего на диаграмме цвет, когда есть форма? Если уж очень хочется цвета, то перед выбором цветов почитайте рекомендации медиков. Очень уж тут много синевы, что вредно для глаз.