Управляемая сцена

Прогресс в офисных технологиях остановился, и это произошло потому, что
пользователь, способный написать примитивненькую программку не может:
*) отобразить 3-мерные данные в окне своей программы
*) передвигать 3-мерные объекты командами в чужой программе (в такой как
'Microsoft Office'), и видеть изменения на экране

Объеты могут быть нарисованы мышью самостоятельно, скачены из интернета,
получены как результат вычислений или как выходные данные с оборудования. В
любом случае нам нужен:
*) бинарный формат для файла, содержащего 3D-объекты, причем объекты должны
записываться в виде треугольников (которые понятны пользователям), а не на
языках 3DMLW, 3DXML, COLLADA, т.к. пользователь не осваивает формулирование и
рассмотрение своих задач на этих языках
*) движок внутри операционной системы, который:
o) позволяет загрузить в себя эти банарные файлы
o) по запросу объектов возвращает их в формате X11 [1], дабы программа,
обратившаяся к этому движку, могла отправлять полученные данные своему
X-серверу без каких-либо собственных вычислений или изменений (без обращения
к OpenGL, DirectX, которых пользователь никогда не освоит !!)
o) предоставляет два способа изменить координаты объектов (оба способа
порождают команды управления X-сервером в формате X11, которые немедленно
направляются X-серверу):
-) с помощью языка запросов (что позволяет программе изменять координаты)
-) принимая события в формате X11 [1], которые также являются командами
изменить координаты, но посланы мышью (что позволяет мыши изменить
координаты)

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

Это прорыв в офисных технологиях. Все ранее известные 3D-интерфейсы (3DMLW,
3DXML, COLLADA / OpenGL, DirectX) разработаны с расчетом на некие когнитивные
способности, которыми, как показывают эксперименты, средний человек на самом
деле не обладает. Tрудности, связанных с использованием 3D-объектов, возникает
из-за низкого качества интерфейса, а не из-за сложности трехмерной задачи.
Предлагаю назвать новый интерфейс 'управляемой сценой' и вмонтировать его в
стандартные операционные системы, дабы позволить пользователю наконец-то
выполнить работу и сделать его более продуктивным, и как результат - более
счастливым.

Что касается реализации, полагаю, что:
*) динамически линкуемая библиотека (например, dll-файл) в качестве такого
бинарного файла (координаты хранятся внутри нее и изменяются вызовом ее
функций) не подходит, т.к. скачивание ее нарушает безопасность компьютера и
повторит все проблемы скачивания ActiveX
*) подходят следующие варианты:
o) Java-библиотека в качестве бинарного файла, содержащего координаты; и
интерпретатор языка Java, получающий Java-текст так же, как интерпретатор
языка SQL (т.е. СУБД) получает SQL-текст
o) рудиментарное игровое или CAD приложение со встроенным языком
программирования и управления 3D-объектами; и файлы, в которых это
приложение сохраняет фигуры
o) рудиментарная СУБД, возвращающая 3D-объекты как результат оператора 'select'
и изменяющая координаты точек оператором 'update'

Вариант #1 самый плохой - Java наиболее трудный язык для пользователей. Язык
игровых и CAD приложений (вариант #2) промежуточен по трудности. Вариант #3
самый лучший - интервьюирование пользователей показывает, что вставка точек,
треугольников оператором 'INSERT' и изменение координат точек оператором
'UPDATE' наиболее легки для них (!); а перенос данных из СУБД в СУБД - хоженый,
обозримый, привычный процесс.

Автор изложил вариант #3 в отдельном документе [2] и заинтересован во мнениях,
комментариях и возможной реализации этих предолжений. 3D-конструкция представлена в нем как
иерархия точек, треугольников, фигур (групп треугольников), групп фигур, групп
групп, и т.д. Записи, содержащие эти объекты, должны быть связаны внешним
ключем. Для того, чтобы извлечь все треугольники фигуры или группы, нужно
оператором 'SELECT' выбрать не только запись, являющуюся данной фигурой или
группой, но и все записи, расположенные ниже нее в иерархии - вплоть до тех,
которые представляют 3D-точки. Для этого таблицы этих записей перечисляются
через точку - 'select * from group3.group2.group1.triangle.point' - как это и
принято в классических объектно-ориентированных языках [3]. Названия таблиц
значения не имеют, т.к. всегда точки предполагаются расположенными на самом
нижнем уровне иерархии каждой ветви дерева, треугольники - на один уровень выше,
а записи остальных уровней игнорируются [4]. Перед преобразованием в формат X11
невидимые треугольники будут удалены из результата запроса, а частично видимые
будут обрезаны до их видимых частей. Итого любая программа отображает содержимое
базы данных на экране функцией 'printg("select * from
group3.group2.group1.triangle.point")'.

Аналогично в операторе 'UPDATE' также можно указать всю иерархию записей от
фигуры или группы до 3D-точки - 'update group3.group2.group1.triangle.point set
...'. Итого любая программа изменяет положение объекта в базе данных и на экране
функцией 'requst("update group3.group2.group1.triangle.point set ...")' [5].

[1] или в формате Microsoft Window System, если движок работает в 'Microsoft
Windows'
[2] http://sql50.euro.ru/sql5.16.4.pdf
[3] соответственно схема должна быть отделена от названия таблицы не точкой, а
каким-то другим знаком, например '§': 'select * from
user§group3.group2.group1.triangle.point'
[4] как отсекать ненужные ветви дерева, подробно рассказано на страницах 118,
124, 127-129, 132-143 pdf-документа
[5] процедуры сдвига, растяжения и вращения предлагаю поставлять не как хранимые
в базе данных, а как встроенные в SQL, например сдвиг на 5 единиц по каждой
координате выглядел бы как 'update group3.group2.group1.triangle.point shift
(5,5,5)' - подробно о новых операторах 'update' и о триггерах для них рассказано
на страницах 14, 68-69 pdf-документа. Эти же триггеры могут быть вызваны мышью,
т.е. посылкой X11 данных, о чем рассказано на страницах 71-75

Тюрин Дмитрий