DRAKON.SU

Думаю, что подтверждение, в данном случае, лишнее. Вроде бы Shift+Delete ничем не должно отличаться от Ctrl+X.

При работе с мышью вырезка и удаление практически одна и та же операция. Отличаются только тем, что при щелчке ЛКМ в точку - вставляется блок, при щелчке по свободному пространству - очищается буфер. В обоих случаях блок уже удалён из схемы.


Вот через пару недель интересно было бы послушать мнение студентов - удобна ли им работа мышью в предлагаемом варианте.


В следующей версии для работы с клавиатурой будет введена поддержка Del для удаления блоков.

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

Тут такая дилемма.
Или быстрый вход ("въезд") и всю оставшуюся жизнь щёлкать ПКМ, елозить по контекстному меню, ища пункт "Удалить".
Или почитать как удалить блок и всю оставшуюся жизнь летать : )

Надеюсь практика покажет, что лучше.

Во-первых, Shift+Del используется для вырезания, а не для удаления. Копия информации помещается в системный буфер обмена.
Во-вторых, при удалении файлов Windows всегда выдает диалог с просьбой подтвердить удаление файлов, подчёркивая там, что удаление будет произведено не в Корзину, а безвозвратно.

С этим и связан плач пользователей, которые воспользовались Shift+Del для удаления, после чего захотели вернуть файлы. Это древний как мир плач по утилите поиска и восстановления удалённых файлов, который к нашей теме не имеет отношения вообще никакого.

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

Дилеммы нет. Противопоставление искусственное. Не союз ИЛИ должен быть, а И. И так чтобы можно было удалить, и эдак.

В Фабуле огромное количество горячих клавиш, но не хватает нескольких программируемых: чтобы на них можно было назначить любое действие. Вот, например, клавишу [Del] можно сделать программируемой. Пусть пользователь сам решает, какое действие она будет выполнять. Это удобная клавиша, её можно нажимать не глядя. По умолчанию запрограммировать на удаление выделенных объектов схемы.

Из своего опыта скажу, что программировать можно и медиа-клавиши. На клавиатуре их ряд расположен дан функциональными. В MS Word клавишу [Refresh] я перепрограммировал для вставки спойлеров. В моём случае спойлер - это текстовая кнопка, которая показывает/скрывает фрагменты документа (например, из маленькой табличной ячейки появляется целая страница с рисунками. Один спойлер может управлять сразу несколькими фрагментами, расположенными разрозненно (где угодно).

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

Согласен.

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

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

После связывания Адрес получает цвет Имени ветки.

Мне этот обмен мнениями непонятен.

Основополагающая идея, заложенная в язык ДРАКОН — безошибочность.

По-моему, такого не может быть, так как подобные "нехорошие" ошибки должны выявляться и устраняться автоматически. ДРАКОН позволяет выявлять и устранять подобные ошибки автоматически.

Зачем это? Зачем нужен адрес без текста?
Зачем создавать потенциально опасное место, провоцирующее появление ошибки?

На мой взгляд, это противоречит постулату безошибочности.

Ошибки в программах — это одна из главных проблем программирования.

Мне кажется, не надо отказываться от постулата безошибочности.

Когда создаётся новая схема всегда имеется Адрес без текста. Его нужно заполнить. И всё. Речь идёт о процессе редактирования. Уважаемый __1__ предложил пустой Адрес выделять "тревожным" цветом. Возможно он прав.

Заполнить иконку [имя ветки] текстом недостаточно, чтобы сбросить её тревожный цвет. Чтобы его сбросить, нужно, чтобы на неё пунктиром указывала хотя бы одна иконка [адрес ветки].

В сегодняшней версии Фабулы возможна ситуация, когда все иконки [адрес ветки] заполнены текстом (то есть, имеют какие-то связи с другими ветками). И все иконки [имя ветки] заполнены текстом. Но некоторым веткам "не досталось" ни одной входящей пунктирной линии. Вот, для этих веток и нужно иконку [имя ветки] раскрашивать тревожным цветом.

--

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

Но чтобы строить сетевые деревья, нужно записывать схему (или программу) в реляционном виде. То есть, придётся изменить фундамент дракон-редактора: нужно начинать писать саму Фабулу почти заново.

Согласен



Не согласен. И вот почему.

Человек начинает рисовать схему. Естественно, у него поначалу появляются адреса без текста. А мы его сразу — бац! по голове тревожным цветом. Так нельзя. Это может раздражать людей. Они будут испытывать дискомфорт.

Надо действовать ненавязчиво и деликатно.

Например, так: когда пользователь захочет закончить сеанс и выйти из программы Фабула, вывести на экран соответствующее напоминание (без всякого тревожного цвета), как это обычно делается при выходе из программы с несохраненными данными:

Текст, конечно, несколько иной. Какой именно? Надо подумать.

Можно и по-другому. Главное — без тревожного цвета. И не сразу. А с разумной задержкой.

Чтобы не раздражала, выбрать подходящий цвет. Пусть цветовая маркировка не раздражает, а помогает, подсказывает.

--

Например, одинаковым цветом можно отображать иконки, имеющие "общую судьбу". Что же в этом плохого и раздражительного?

Так нельзя. Это может раздражать людей. Они будут испытывать дискомфорт.
Кроме того, это нелогично и непонятно. И методически неверно.
Вот посмотрите: я работаю. Мне надо сделать перерыв. Для чего сохранить текущее состояние независимо от его правильности.

Есть вариант специальной кнопки для валидации. Но это плохой вариант, потому что кнопка необязательна.

Есть вариант делать проверку автоматически при генерации кода. Но это плохой вариант, потому что не все занимаются генерацией кода из Дракона.

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

Хорошо, сохраняйте.

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

А зачем его раньше отвлекать и беспокоить?

Тоже верно!
Отключать маркировку ошибок можно специальной кнопкой на панели инструментов.

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

==

Отсюда вывод:

Если уж вводить маркировку цветом, нужно предусматривать возможность её отключения (отдельно для каждого класса маркируемых объектов).

--

Может быть, тогда и пересечения линий не запрещать строго-настрого? ) Оно ограничивает полёт мысли, и тоже реально раздражает. )))

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

Вот именно в этот момент пользователю это совершенно не нужно. И даже вредно, потому что можно пропустить или ответить не так и в результате не сохранить.

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

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

Разумеется, визуальную разметку можно и нужно делать временно отключаемой. Но по умолчанию (при старте и после завершения транзакции редактирования) она должна быть включена автоматически.


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

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

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

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

Спасибо!