DRAKON.SU

Текущее время: Пятница, 24 Сентябрь, 2021 02:38

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




Начать новую тему Ответить на тему  [ Сообщений: 107 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
 Заголовок сообщения: 5-е техтребование от С. Тарасенко
СообщениеДобавлено: Пятница, 07 Май, 2010 22:19 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
С. Тарасенко писал(а):
. В принципе, это могла бы быть и простая фигура "Вывод", но она тоже несовершенна, и это может исправить только автор: со стрелкой должна быть ближняя фиура, тогда она указывает на дальнюю, протыкая её. А здесь дальняя указывает куда-то в сторону, а ближняя в форме квадрата на неё наслаивается, и запросто можно перепутать, где значение, а где приёмник. Владимир Паронджанов предполагал, чтобы в верхней строке фигуры писалось только ключевое слово ("Сообщение" и т.п.), но такие слова именно и засоряют внимание, а вот поважнее было бы указать в ней сам приёмник. Причём приёмником могла бы быть не только переменная, но и файл, и область памяти, и программа, которой передаётся внутреннее сообщение, - всё зависит от ключевого слова перед именем приёмника. В таких случаях знак равенства был бы противопоказан, а вот фигурой "Вывод" или пока хотя бы "Запоминателем" - вполне возможно и притом с прекрасным визуальным эффектом.

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


Под "в принципе" разумею, что Стас хотел бы для общего случая (или в каких-то частных, напр. показывая сдвиг элементов массива) использовать дракон-икону Вывод, а не гном-икону Запоминатель, как визуализацию присваивания - что не считаю правильным.
В комментарии к 4-му техтребованию уже предлагал икону Полка. Эргономически это даёт нужный эффект - следуя по шампуру, мы берём значение из текста верхнего поля-"этажа" (как говорит Стас, ЧТО; точнее говорить ОТКУДА, т.к. это необязательно литерал, т.е. значение "как есть" - чаще это переменная или константа) и помещаем это значение в переменную (набор переменных допустимых типов) по тексту нижнего "этажа" (КУДА; здесь только имена без вариантов).


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

Для обмена со внешней памятью считаю необходимым ввести отдельные иконы, как показано в этом подпункте.

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

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

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

Насчёт компоновки икон Ввод и Вывод. Есть одна штука в понимании сопряжения импер- и деклар-моделей, а также исполнителя этих моделей и внешней среды. Проиллюстрирую свой взгляд на примере ФЛОКСа.
Владимир Паронджанов писал(а):
12. Дам еще одно пояснение.
Для этого приведу пример. На стр. 41 указан идентификатор силовой команды
КС1УФ.ОТКЛЮЧИТЬ.ФИДЕР.УМ1

13. На какой объект указывает этот идентификатор?
На этот вопрос следует дать два принципиально разных ответа.

14. С точки зрения прибористов и комплексников этот идентификатор указывает на объект, НАХОДЯЩИЙСЯ ВНЕ КОМПЬЮТЕРА. А именно на команду, которая выскакивает из бортового компьютера Бисер, бежит по проволоке через прибор «устройство обмена» и в конечном итоге попадает в прибор «силовой коммутатор».

Результатом выдачи этой команды является тот факт, что прибор «силовой коммутатор» образует нужный силовой фидер (то есть нужную шину электропитания).
Зачем комплексник выдает эту команду? Чтобы образовать нужный ему фидер питания.

15. С точки зрения программиста дело обстоит совершенно по другому. Программист отлично понимает, что идентификатор указывает на какие-то объекты, находящиеся в оперативной памяти Бисера.

Какие же это объекты?
Ответ не прост.

Чтобы образовать фидер, надо выдать из компьютера не одну команду, а серию посылок по определенной циклограмме.
Эта операция достигается путем сложного взаимодействия программ центрального процессора и программ процессора ввода-вывода (канала ввода-вывода).
Из рисунка на стр. 41 Извлечения следует, что Бисер имеет 8 процессоров ввода-вывода.


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

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


Последний раз редактировалось Владислав Жаринов Вторник, 18 Май, 2010 04:23, всего редактировалось 3 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: 6-е техтребование от С. Тарасенко
СообщениеДобавлено: Пятница, 07 Май, 2010 22:21 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
С. Тарасенко писал(а):
Проект Владимира Даниловича имеет много недостатков, в том числе лексические. Названия схем - Примитив, Силуэт, Гном - нужно запоминать и учить, как школьный параграф. Ни малейшей ассоциации! Где же пресловутая эргономика? Вот я и предлагаю варианты более эргономичные, и то, что другой проект уже утвердили, не может быть аргументом. Лучшему нет конца.
А ещё лучше каждую ветку силуэта назвать не "ветка", а "древо".Тогда не будет путаницы с "ветвями развилки"; к тому же, если "ветви развилки" имеют горизонталь, то "ветки силуэта" всегда вертикальные, как древо, а ветка вертикальной быть не может. И тогда схему "Силуэт" можно прозвать "Лес". То есть, схема с несколькими древесами. А "примитив " - просто "Дерево". Заметьте: схема называется "дерево", а шампур-ветка - "древо". Хотя тоже может возникнуть путаница, тут ещё нужно продумать. Может, будут советы ещё у кого.
Или схему Примитив можно назвать "Прямая схема"... В общем, думать надо, анализировать, а не отметать с корня все возможные варианты!

А если вспомнить о лианах, то силуэт можно назвать "джунгли" :D

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


Последний раз редактировалось Владислав Жаринов Воскресенье, 16 Май, 2010 04:23, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: 7-е техтребование от С. Тарасенко
СообщениеДобавлено: Пятница, 07 Май, 2010 22:24 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
С. Тарасенко писал(а):
Кстати, текст без рамки (в моей редакции) можно отодвинуть клавишами Альт-стороны на середину, тогда это будет как бы действие, но текст написан прямо на схеме и даже другим цветом (тем же, что и пути). Для комментария такой вид исключительно подходит. А то в Драконе фигура Комментарий - самая броская из всех возможных, в двойной разноцветной рамке, в то время как она должна быть самой скромной и самой экономной, ведь там обычно пишется много текста.

Аргументы:
Владимир Паронджанов рассчитывал на фигуры с формальным текстом; в таких схемах дейстивтельно комментарий должен быть броским. Но Геннадий Николаевич внедрил совершенно неожиданную великую идею: раз уж есть два дракона, формальный и нет, почему бы их не объединить? И конечно, внутри каждой фигуры лучше писать нормальный русский текст, а уже в приложении - программную ахинею. Гениально! Но при этом нужно и фигуры изменить. Теперь комментарий должен быть самым скромным, потому что все действия и вопросы тоже по сути есть комментарии, лишь содержащие скрытую информацию, не более.
(Конец части.)

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: 8-е техтребование от С. Тарасенко
СообщениеДобавлено: Пятница, 07 Май, 2010 22:25 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
С. Тарасенко писал(а):
9. Нельзя почему-то выбрать несколько фигур и расширить, сузить или сместить их одновремемнно. Добавьте обязательно! Иначе выбор левой кнопкой несколькихз фигур вообще не нужен, так как сбрасывается при повторном нажатии на любую фигуру (в том числе из выбранных)

Согласен.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: 9-е техтребование от С. Тарасенко
СообщениеДобавлено: Пятница, 07 Май, 2010 22:25 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
С. Тарасенко писал(а):
10. Набирая текст, нажимаешь Shift, чтобы получить большую букву, и экран уплывает чёрти-куда. Ведь Shift имеет значение двигать экран. Лучше бы это был Ctrl. Его и нажимать удобнее (он всегда снизу). Тогда уже и тащить объекты лучше с Контром.

Наверное, можно и так...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: 10-е техтребование от С. Тарасенко
СообщениеДобавлено: Пятница, 07 Май, 2010 22:26 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
С. Тарасенко писал(а):
11. Очень неудобно, что дракон не работает в Win98. Может, нужно просто изменить настройки при создании ЕХЕ-файла? Если надо глубже вникать в код, тогда, пожалуй, не надо, хотя сейчас ещё достаточно пользователей Windows Millenium, который грузится пятнадцать секунд (а двухтысчячный две минуты) и все программы открывает моментально.

Да, надо, чтобы работал - хотя стоп, у меня запускался вроде... только неустойчиво. И на менее мощной аппаратуре, чем заявлено, должен "летать".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: 11-е техтребование от С. Тарасенко
СообщениеДобавлено: Пятница, 07 Май, 2010 22:27 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
С. Тарасенко писал(а):
12. Если нет схемы, на которую переходим по вставке, она должна создаваться автоматически.

Само собой :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: 12-е техтребование от С. Тарасенко
СообщениеДобавлено: Пятница, 07 Май, 2010 22:27 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
С. Тарасенко писал(а):
13. И конечно, надо что-то думать с проектом. Я бился-бился и так и не смог придумать, как перевести схему в кодовый язык. Это же наказание: создать Гном-схему, создать в ней фигуру Сборка текста, нажать Файл – Командная строка…, написать вручную номер схемы и фигуры сборки текста (как будто трудно найти её автоматически, если учесть, что чаще всего она одна), и что дальше? В файл записывается только тексты фигур. Так где же структуры if? Только в четвёртом пояснении схемы. Смыкни туда, скопируй текст, вставь в редактор… И что? Это текст одной только схемы. А если их десять? Короче, полный швах. А вы собираетесь картинки рисовать к командам. Да тут вспахать и засеять нужно, а не картинками заниматься!

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: 1-е техтребование от меня
СообщениеДобавлено: Пятница, 07 Май, 2010 22:28 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Полноценный редактор должен вести как импер-, так и деклар-визуализацию, о чём в очередной раз напомнил igor в этом сообщении.
Также необходимы другие языки, в частности, иной язык схематизации документа вместо ГНОМ.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: 2-е техтребование от меня
СообщениеДобавлено: Пятница, 07 Май, 2010 22:29 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Документ в РДП-среде должен представлять совокупность рабочих листов, организованных нижеследующим образом (обращаю внимание - хотя написано будет сравнительно много, но всё относится к одному объекту - поэтому не следует делить на разные вопросы, излагаемые в отдельных сообщениях).

1. Языковое обеспечение РДП-среды полностью доступно в рамках РДП-документа и организовано следующим образом:
    * метаязык представления содержания документа - совокупность языка разметки листов и визуальных языков графового и примитивного типов в алфавитах элементов-автофигур с атрибуцией элементов только текстом, а в отдельных случаях - также таблицами и/или графикой (автофигурами, граф-схемами, внешними изображениями);
    * предполагаемый язык описания (спецификации) документа - XML;
    * базовым языком организации содержания документа (схематизации) служит визуальный язык информатизованных синтдиаграмм в соответствии с определением в п/р 5.2 Приложения 2 (рабочее; подлежит дополнению и уточнению) с учётом предложений по силуэтизации его схем в этом подпункте и рабочей детализации в этом сообщении.

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

2. На листе содержатся и отображаются объекты двух категорий:
    * схемы - наборы графоэлементов из алфавита языка схемы, связанных по правилам этого языка;
    * внесхемная графика - отдельные графоэлементы.
Имеется в виду, что элементы схем связываются различным образом; как правило, схемы являются графами, где вершины связаны дугами; но возможно, что схема - это рисунок или чертёж, элементы которого связаны через соотношения координат их базовых точек (для параметризованного объекта) или просто по признаку группировки (как в любом редакторе рисунков, но группа становится самостоятельным объектом, который также имеет название и некие общие свойства).
К внесхемной графике прежде всего относятся элементы КогниСтиль (предлагаемый алфавит см. в п. 1.2.1 Приложения 1).
NB. В указанном пункте на самом деле совмещены определения алфавитных знаков и конструкций из них, что нетрудно установить.
По логике внесхемная графика может трактоваться как схемы из одного элемента.

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



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

4. Должны обеспечиваться следующие физические организация и свойства объектов:
    * формат листа измеряется в метрических единицах и выбирается из ряда А<n>. Рабочей областью считается пространство за вычетом полей, настраиваемых вручную (желательно задавать формат и поля отдельно для каждого листа документа).
    NB. Видно, что при наличии лист-силуэта удобно использовать форматы листа в альбомной ориентации и с полем подшивки по длинной стороне - лучше используется место.
    * на одном листе м.б. расположены одна и более схем; их число ограничивается только вместимостью в рабочую область (с учётом сказанного в п.6);
    * каждая схема занимает на листе область-прямоугольник, описанный вокруг её содержимого с минимальными внутренними отступами от наиболее выступающих с данной стороны элементов;
    NB. Вообще-то хотелось бы поддержки более сложной конфигурации области схемы как многоугольника, "обтекающего" контуры содержимого, но понятно, что это сложно будет автоматизировать.
    * элемент имеет параметры форматирования, аналогичные доступным для автофигур в графредакторах офисных пакетов, как правило, настраиваемые индивидуально вручную;
    NB. Для текста каждого графоэлемента (поля иконы, ячейки таблицы) д.б. доступны все возможности "машинной вёрстки" - возможность выбора стиля абзаца и знака, колонки, вставка таблиц и изображений; возможно, следует поддерживать индексируемые заголовки.
    * для элементов схем м.б. заданы как часть правил языка схемы "шаблоны" сочетания параметров форматирования текста и графики, фиксированные или настраиваемые (по сути выполняют роль "подсветки" синтаксиса - разные типы элементов форматированы по-своему, как напр. тексты операторов в Драконографике);
    * для элементов внесхемной графики возможны два уровня глубины - "перед схемами" или "за схемами"; в пределах уровня эти элементы располагаются независимо от схем и могут накладываться друг на друга (т.е. на каждом уровне существуют подуровни, т.н. планы); глубиной управляет оператор командами относительного перемещения выбранного элемента (так же, как в редакторах офисных пакетов);
    * схемы в глубину занимают один уровень, т.е. наложение их областей друг на друга не допускается; NB. Возможно, следует ввести подуровни для схем с управлением глубиной каждой схемы.
    * устанавливается сетка для икон/линий по обеим координатам (с возможностью привязки и внесхемных графоэлементов);
    NB. Общая идея - линии схем идут по линиям привязки, а иконы схем можно смещать на выбранный шаг привязки относительно линий поперёк их хода и передвигать вдоль (с укорочением звена спереди по направлению и удлинением звена сзади); шаг сетки выбирается из ряда кратных некоему минимальному шагу, который измеряется в метрических единицах и устанавливается оператором (для документа, а лучше - отдельно для каждого листа); .
    * в редакторе определяется (отдельно от документа, как часть шаблонов РДП-среды) вызываемая рамка/штамп листа, причём сменная, в т.ч. по ЕСКД, IDEF или ещё чему-то;
    * объект, связанный логически (см. п. 3) с другим объектом (элементом), располагается в пределах его контура по тем же правилам привязки, что на листе (т.е. для подчинённых объектов габарит главенствующего элемента становится рабочей областью).
Из последнего следует, что логическую связь целесообразно устанавливать не абы как, а с определёнными типами полей.

5. Машинная форма РДП-документа - один файл. Если по техническим соображениям желательно более одного файла, то они образуют единый файл-архив документа, автоматически раскрываемый в РДП-редакторе (как файлы инфордоков семейства Open Document Format).

6. Для целей компоновки содержания под твёрдую копию площадь листа считается составленной из дольных ячеек того же ряда форматов; число ячеек выбирается оператором из ряда степеней двойки (неотрицательных :); сверху ограничивается минимальным получаемым форматом ячейки - считаю, это д.б. А4|A4L). При этом:
    * при числе ячеек более одной ячейки располагаются согласно схеме раскладки по ГОСТ ЕСКД "Форматы и основная надпись". При этом внутри листа образуются рабочие подобласти, разделённые внутренними полями; их границы показываются оператору обычным образом (в тонких блёклых линиях; при нулевом внутреннем поле соответствующие линии подобластей соседних ячеек сливаются в одну);
    * между подобластями появляются внутренние поля ячеек, не совпадающие с полями листа; они служат для склейки твёрдых копий ячеек в формат (при ненулевой и практически удобной для этого величине) и настраиваются вручную отдельно от внешних полей;
    * попадание любых элементов на внешние поля листа не допускается (блокируется автоматически или указывается оператору для исправления вручную - что будет проще реализовать); через внутренние поля линии граф-схем могут проходить из ячейки в ячейку, а другие элементы в эти поля попадать не могут;
    * формат ячейки автоматически устанавливается по формату страницы, выбранному в системе для текущего устройства твёрдой копии, и м.б. изменён вручную.

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

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

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

P.S. Обновлено содержание; всё связанное с операциями переносится в 6-е техтребование.


Последний раз редактировалось Владислав Жаринов Пятница, 28 Май, 2010 04:41, всего редактировалось 8 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: 3-е техтребование от меня
СообщениеДобавлено: Пятница, 07 Май, 2010 22:30 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Понравилась идея И. Е., чтобы вводить схему как текст с клавиатуры. Считаю, можно реализовать для дракон-программы в целом на конкретном гибридном языке (исходно - ДРАКОН-Оберон) примерно таким образом. В области текстового ввода сочинитель пишет Оберон-текст, причём редактор предлагает автозаполнение по первым буквам ключевого слова языка (подставляет шаблон оператора); по корректном вводе (для принятого шаблона - по заполнении полей величин) оператор раскладывается на маршрутную часть (икону) и немаршрутную (её текст) и так добавляется в область текущей схемы. Т.о. получается задача, обратная трансляции схемы в текст (и потому, IMHO, возможность реализовать это м.б. критерием, насколько корректно в среде реализована прямая задача).
С этим взаимосвязано требование 4 (см. в отд. сообщении).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: 4-е техтребование от меня
СообщениеДобавлено: Пятница, 07 Май, 2010 22:31 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
В РДП-среде должны вестись каталоги объектов различного рода. В частности, каталогизации подлежат:

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

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


Последний раз редактировалось Владислав Жаринов Понедельник, 24 Май, 2010 09:06, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: 5-е техтребование от меня
СообщениеДобавлено: Пятница, 07 Май, 2010 22:32 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Реализовать режим сочинения, в котором выбор вместо неформального языка одного из формальных означает, что каждая шампур-икона схемы неформального языка рассматривается как своеобразная "икона Область" (описана в этом подпункте) - т.е. её нужно независимо детализировать иконами с формальным текстом - нешмапур-иконы же (ветвления) остаются самими собой, но требуют формальной записи логвыров от величин формального текста. Т.о., получается вторая схема одного процесса, композиция частей которой задаётся первой схемой.
Если в РДП-среде определена многоуровневая иерархия формальности языков, то имеем ряд схем, полученных последовательно детализацией икон предыдущей (хотя больше трёх уровней смысла не вижу - допустим, текстовая-математическая-прогязыковая, а в конкретике, скажем: русскоязычная - словесно-формульная - Оберон-2+пультовые языки устройств, в т.ч. непрограммируемых сочинителем для данной задачи).
Реально, разумеется, можно разрабатывать то одну, то другую схему, поскольку процессы взаимозависимы - и при каждом изменении высокоуровневой в среде перестраивается непустое содержание низкоуровневых (а пустое можно показывать вершинами более высоких уровней с указанием, что они на этом уровне ещё не определялись). Разными языками вообще могут пользоваться разные люди (на разных, но связанных по данным АРМ) - файл модели просто передаётся между ними.
    Можно заметить, что есть детализация икон на "управленческом" уровне и на "программном" - но это разные т. зр. на одну и ту же вершину в одной схеме. Это должно дополнять иерархию разных схем - но, возможно, смыслы приложений здесь потребуется уточнить (у меня не вызывает сомнений именно управленческий, т.к. смысл любого оператора, конечно, определяется в первую очередь какими-то нормативными документами).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: 6-е техтребование от меня
СообщениеДобавлено: Пятница, 07 Май, 2010 22:33 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
1. РДП-документ должен обрабатываться в одном из следующих режимов:
    * сочинения - полноэкранного редактирования содержания;
    * исполнения - полнофункциональной интерпретации содержания лист-силуэтной структуры маршрутов;
    * демонстрации - ограниченной интерпретации содержания маршрутов.
    Режим устанавливается командой оператора; д.б. предусмотрено введение запрета смены режима (только по вводе пароля) либо для данного документа, либо для приложения в целом (можно, развив реализацию Ты-среды, делать РДП-приложение только для демонстрации).
    Требования к реализации режима сочинения:
      *все объекты одинаково доступны для просмотра и редактирования, что показывается их изображением в нормальном цвете и яркости (конечно, объекты текущего выделения показываются особо);
      * линии лист-силуэта и иконы Имя строки без термина и Адрес строки можно показывать блёклыми, чтобы не отвлекали;
      * навигация клавишами курсора (по маршрутам схем) и мышью (произвольная);
      * можно исполнить любую дракон-схему (модель) по выбору оператора;

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

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

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

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

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

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

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

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


Последний раз редактировалось Владислав Жаринов Понедельник, 24 Май, 2010 10:19, всего редактировалось 7 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Май, 2010 09:20 

Зарегистрирован: Четверг, 04 Июнь, 2009 15:08
Сообщения: 100
Владимир Паронджанов писал(а):
Если ты хочешь нарисовать действия, нарисуй их, чтобы я мог их увидеть. Сейчас я их не вижу.
Геннадий Тышов: И в очередной раз - как было бы эффективно делать пометки в КогниСтиле... не где-то "на стороне", а в самом дракон-редакторе...
Владимир Паронджанов: Чтобы исправить схему, надо хотя бы в одно плечо каждой иконы вопрос
вставить икону действие или вставку.

Компьютер, на который возможно установить Дракон (п.ч. Win2000) в другой комнате, зато он не подключён к Интернету, и не очень-то набегаешься с дискетами туда-сюда.
Владимир Паронджанов писал(а):
3. Ошибка в том, что у обоих икон вопрос выходы да и нет
соединяются между собой. Это означает, что в данной схеме две
иконы вопрос должны быть изъяты, так как они не выполняют никаких
функций.

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

Пожалуйста:


Вложения:
Крестовинный узел с действиями.gif
Крестовинный узел с действиями.gif [ 30.58 КБ | Просмотров: 11670 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Май, 2010 09:23 

Зарегистрирован: Четверг, 04 Июнь, 2009 15:08
Сообщения: 100
Драконограф писал(а):
Считаю реализацию Геннадия в этом случае (мышь+контекст-меню) как минимум не менее удобной - что не отменяет Ф-ввода, это тоже очень удачная находка. Нужно оставить и так, и так.

Мне пришлось вывести их в строку меню, иначе Ф-клавиши не работали.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Май, 2010 09:27 

Зарегистрирован: Четверг, 04 Июнь, 2009 15:08
Сообщения: 100
Драконограф писал(а):
С неудобством восприятия текстового присваивания соглашусь - но так вроде уже устоялось в информатике. А для визуализации было предложено записывать присваивание через икону Полка -
Она не визуальна. В полке указываются лишние СЛОВА, против которых и выступает Владимир Даниилович как против сора, захламляющего восприятие. Иногда и без неё не обойтись, но простое присваивание вида а=б или ряд(н)=ряд(н+1) лучше, думаю, всё-таки писать в Запоминатель. Хотя у него и другая функция, согласен.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Май, 2010 09:32 

Зарегистрирован: Четверг, 04 Июнь, 2009 15:08
Сообщения: 100
Драконограф писал(а):
Разумею под "приёмником" фигуры "Вывод" порт вывода ...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: 2-е техтребование от меня
СообщениеДобавлено: Вторник, 11 Май, 2010 09:38 

Зарегистрирован: Четверг, 04 Июнь, 2009 15:08
Сообщения: 100
Драконограф писал(а):
Документ в РДП-среде должен представлять совокупность рабочих листов, организованных нижеследующим образом (обращаю внимание - хотя написано будет сравнительно много, но всё относится к одному объекту - поэтому не следует делить на разные вопросы, излагаемые в отдельных сообщениях).
.......

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Май, 2010 11:33 

Зарегистрирован: Четверг, 04 Июнь, 2009 15:08
Сообщения: 100
Драконограф писал(а):
Считаю реализацию Геннадия в этом случае (мышь+контекст-меню) как минимум не менее удобной

Но уж во всяком случае список фигур должен выскакивать СРАЗУ после нажатия мыши, а не залезая в лишнее меню "Добавить". Конечно, все фигуры не помастятся, но хорошо: самые редкие фигуры можно поместить в доп. меню, но не все!

Вот, откопал у себя старую версию Дракона, которую я когда-то подресторатил. Именно так: в контекстном меню сразу почти все команды, не исключая пересадок лианы.
Правда, лексически эта версия неудачна (правил года два назад), к тому же лиана почему-то не заземляется. И главное - клавиши не работают! Но в качестве аргумента - пожалуйста:
http://files.mail.ru/03B4WG


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 107 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

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


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

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


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

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