Ada_Ru форум

Обсуждение языка Ада

Язык описания GUI. Страница 3

Оставить новое сообщение

Сообщения

Народ, a если так:

 

 

UI доописывается набором прагм:

(параметры взяты с потолка, гляньте на общую идею)

 

 

with Picture.BMP;

 

package Person_Type is

 

-- прагмы следом за описанием типов :

type marriage_status is (single, married, divorced, widow);

pragma ui_type_representation(type=>marriage_status, control=>"pulldown listbox");

--->

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

-- (таким образом все стандатные типы могут (и будут) иметь свою

-- репрезентацию во всех мыслимых UI)

 

type sex is (male, female);

pragma ui_type_representation(type=>sex, control=>"radiobox", caption=>"sex:");

--

-- +-- sex: -----+

-- | (*) male |

-- | ( ) female |

-- +-------------+

--

type age is range 0..150;

pragma ui_type_representation(type=>age, control=>"editbox", restrictions=>Only_numbers);

type naming is String(1..20);

pragma ui_type_representation(type=>naming, control=>"editbox");

type photo is new Picture.BMP.BMPPicture;

pragma ui_type_representation(type=>photo, control=>"custom", ... ?); -- фантазии не хватает :(

type Person is record

name : naming;

middle_name : naming;

surname : naming;

status : marriage_status;

person_age : age;

person_sex : sex;

person_photo : photo;

children_quantity: positive;

children_enabled : boolean; -- enabled-indicator

end Person;

pragma ui_type_representation(type=>Person,

control=>"DialogForm",

template=>"Form1",

control_package=>"PersonForm"

);

pragma ui_validator(type=>Person, validator=>isValid);

 

pragma ui_field_representation(field=>children_quantity,

control=>"editbox",

caption=>"Children:",

indicator=>children_enabled

);

-- indicator используется дле enable/disable (разрешить/запретить -- ввод) определенного поля (обычно показывается серым цветом если -- disable)

function isValid return boolean;

-- запускается после каждого

-- внесения изменения. управляет кнопкой OK (делает недоступной -- если даные невалидны) и изменяет enabled-индикаторы для разных -- елементов на форме

end Person_Type;

 

 

 

package MainMenu is

type menu is (file, edit, help);

type menu1 is (new, open, save, close, quit);

 

procedure NewEvent;

 

procedure OpenEvent;

 

procedure SaveEvent;

 

procedure CloseEvent;

 

protected

-- здесь (для експеримента) прагмы - одной кучей:

 

pragma ui_representation(type=>menu, control=>"menu", parent=>NULL); pragma ui_menu_event(menu=>"menu", item=>"file", submenu=>"menu1");

pragma ui_representation(type=>menu1, control=>"submenu", parent=>"menu");

pragma ui_menu_event(menu=>"menu1", item=>"new", event=>"NewEvent"); pragma ui_menu_event(menu=>"menu1", item=>"Open", event=>"OpenEvent"); pragma ui_menu_event(menu=>"menu1", item=>"Save", event=>"SaveEvent"); pragma ui_menu_event(menu=>"menu1", item=>"Close", event=>"CloseEvent");

pragma ui_menu_event(menu=>"menu1", item=>"Quit", event=>QuitApp); -- predefined value

end MainMenu;

 

К этому надо добаватиь свой make (сродни gnatdist) и набор над-UI пакетов для старта приложения/и/или/вызова отдельных форм для

редактирования даных.

 

н.п.:

 

with MainMenu;

with BaseUI;

 

procedure initialization is

m : MainMenu.menu;

begin

 

BaseUI.setMenu(m);

 

BaseUI.Run;

end;

 

вызов окна для редактирования:

 

procedure NewPerson(p : in out Person) is

begin

 

case EditPerson(p) is

when BaseUI.Canceled => ...

when BaseUI.Entered => ...

end case;

end NewPerson;

 

 

Получаем процесс:

 

1 разрабатываем пользовательские типы

2 цепляем прагмы

3 где-то (подксажите!) рисуем формы (н.п. form1 в примере)

4 как-то (тоже подскажите :) все это вызываем

5 генерим с помощью uimake (или gnatui) под определенную платформу 6 узаем

 

Фу! Родил. :) Бред какой то...

 

--

Best regards,

Vladyslav

Vladyslav Kozlovskyy wrote:

 

UI доописывается набором прагм:

(параметры взяты с потолка, гляньте на общую идею)

 

Здравая идея :) Я через неё тоже проходил.

 

Косяков с ней несколько:

 

- не всегда имеет смысл такие прагмы писать в пакете объявления типа, поскольку на его содержимое могут быть наложены определенные ограничения;

 

- всё же присутствует жесткая связь типа с классом виджета, что не есть хорошо, поскольку навязывает использование только определенного класса виджета (в примере, male/female не обязательно делать как radionbox, ведь можно и как toggle);

 

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

 

 

К этому надо добаватиь свой make (сродни gnatdist) и набор над-UI

пакетов для старта приложения/и/или/вызова отдельных форм для

редактирования даных.

 

Ох не хорошо использовать свой make. Тот же gnatdist создаёт при работе с большим проектом порядком больше головных болей, нежели gnatmake.

 

Соглашусь - удобно. Так может тогда пусть такая утилитка будет, но она будет только вызывать генераторы файлов реализаций, а собирать адскую часть будет уже gnatmake. :)

 

 

with MainMenu;

with BaseUI;

 

procedure initialization is

m : MainMenu.menu;

begin

 

BaseUI.setMenu(m);

 

BaseUI.Run;

end;

 

Да, здесь тоже надо определеиться. Я бы предложил что-то типа:

 

with BaseUI.Applications;

 

procedure X is

begin

BaseUI.Applications.Initialize;

-- инициализирует так, как надо.

 

BaseUI.Run (Allocate_Thread => False);

-- запускает UI, если задано Allocate_Thread, то в новой нити, если не задано - то в текущей.

.......

BaseUI.Shutdown (Wait_For_Completeion => True);

-- Завершает выполнение UI, если задан Wait_For_Completion, то ожидает действительного завершения всех действий с UI связанных.

 

 

Получаем процесс:

 

1 разрабатываем пользовательские типы

Обычно такие уже есть (если есть программа :)

 

2 цепляем прагмы

Лучше уж описываем интерфейс ядра и UI.

 

3 где-то (подксажите!) рисуем формы (н.п. form1 в примере)

В дизайнере платформы.

 

4 как-то (тоже подскажите :) все это вызываем

А за чем вызывать? Ведь вызывать-то ещё нечего? Или имеется в виду интерпретатор, способный помочь отладить то, что дизайнером созданно было?

 

5 генерим с помощью uimake (или gnatui) под определенную платформу

5.1 собираем всё gnatmake-ом

 

6 узаем

 

 

Фу! Родил. :) Бред какой то...

 

Нормально - нормально...

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Hello Vadim,

 

Monday, August 15, 2005, 3:11:31 PM, you wrote:

Vladyslav Kozlovskyy wrote:

 

UI доописывается набором прагм:

(параметры взяты с потолка, гляньте на общую идею)

 

Здравая идея :) Я через неё тоже проходил.

:)

 

 

Косяков с ней несколько:

 

- не всегда имеет смысл такие прагмы писать в пакете объявления типа, поскольку на его содержимое могут быть наложены определенные ограничения;

Согласен. не всегда. Тогда прагмы можно вынести в отдельный пакет:

with Person; use Person;

 

packet PersonUI is

 

pragma ui_type_representation(type=>sex, control=>"radiobox", caption=>"sex:");

pragma ui_type_representation(type=>age, control=>"editbox", restrictions=>Only_numbers);

pragma ui_type_representation(type=>naming, control=>"editbox"); pragma ui_type_representation(type=>Person,

control=>"DialogForm",

template=>"Form1",

control_package=>"PersonForm"

);

pragma ui_validator(type=>Person, validator=>isValid);

 

pragma ui_field_representation(field=>children_quantity,

control=>"editbox",

caption=>"Children:",

indicator=>children_enabled

);

end PersonUI;

 

- всё же присутствует жесткая связь типа с классом виджета, что не есть хорошо, поскольку навязывает использование только определенного класса виджета (в примере, male/female не обязательно делать как radionbox, ведь можно и как toggle);

может. Но чаще всего создавая структуры приложения способ

представления задается один и надолго (если не навсегда). Почему? А что б юзеру голову не морочить. Меня б задолбал бы интерфейс, где через окно используется то Toggle, то CheckBox, то Radiobox :)

 

 

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

В смысле "игнорируются"? Не выводятся отдельные поля? или

репрезентации уже раньше заданые игнорируются?

Можно "наследовать репрезентации:

 

pragma ui_type_representation(type=>positive, control=>editbox);

type new_positive is new positive;

-- ui_type_representation - то же что и в positive

 

Или я че не понял?

 

 

К этому надо добаватиь свой make (сродни gnatdist) и набор над-UI пакетов для старта приложения/и/или/вызова отдельных форм для

редактирования даных.

 

Ох не хорошо использовать свой make. Тот же gnatdist создаёт при работе с большим проектом порядком больше головных болей, нежели gnatmake.

Соглашусь - удобно. Так может тогда пусть такая утилитка будет, но она будет только вызывать генераторы файлов реализаций, а собирать адскую часть будет уже gnatmake. :)

Тут - согласен

 

 

 

with MainMenu;

with BaseUI;

 

procedure initialization is

m : MainMenu.menu;

begin

 

BaseUI.setMenu(m);

 

BaseUI.Run;

end;

 

Да, здесь тоже надо определеиться. Я бы предложил что-то типа:

 

with BaseUI.Applications;

 

procedure X is

begin

BaseUI.Applications.Initialize;

-- инициализирует так, как надо.

 

BaseUI.Run (Allocate_Thread => False);

-- запускает UI, если задано Allocate_Thread, то в новой нити, если не задано - то в текущей.

.......

BaseUI.Shutdown (Wait_For_Completeion => True);

-- Завершает выполнение UI, если задан Wait_For_Completion, то ожидает действительного завершения всех действий с UI связанных.

Нормально. Даже очень. :)

 

 

Получаем процесс:

 

1 разрабатываем пользовательские типы

Обычно такие уже есть (если есть программа :)

 

2 цепляем прагмы

Лучше уж описываем интерфейс ядра и UI.

поподробней, пжлста

 

3 где-то (подксажите!) рисуем формы (н.п. form1 в примере)

В дизайнере платформы.

согласен

4 как-то (тоже подскажите :) все это вызываем

А за чем вызывать? Ведь вызывать-то ещё нечего? Или имеется в виду интерпретатор, способный помочь отладить то, что дизайнером созданно было?

вызов по ходу работы программы (например для заполненния структуры данными или для изменения хода работы программы)

 

 

5 генерим с помощью uimake (или gnatui) под определенную платформу

5.1 собираем всё gnatmake-ом

Угу

 

 

6 узаем

 

 

Фу! Родил. :) Бред какой то...

 

Нормально - нормально...

я рад :)))

 

--

Best regards,

Vladyslav

Maxim Reznik wrote:

 

>чем использование существующих библиотек. Думаю понятно что этот >вопрос лучше рассматривать "вообще", а не в рамках Ады или чего-то еще. >(кстати в Аде много чего есть чего нет в других языках, и лучше

>бы этим без особой необходимости не пользоваться - в этом случае >если получиться что-то путнее, то можно попробовать продавать,

>ну а продаж под другие языки будет больше чем для Ады)

 

Я с этим не согласен. То что мы здесь обсуждаем - это

как конструировать GUI в духе языка Ада, как придать

этому процессу больше надежности и удобства при написанни

Ада программ. Для нас имеет к примеру смысл, чтобы

интерфейс обменивался с остальной программы используя

типы данных предметной области. В Си и подобных это

не имеет смысла, там типов всего - int да float 8-).

 

Если получится что-то путное мы будем этим пользоваться,

а продовать будем, то что с его помощью написали 8-)

 

Сложно что-то сказать о коммерческой ценности продукта. А вот об ИХ ценах замечу (если кто не знает), что типовая стоимость одной плавающей лицензии на CASE средство обычно составляет около $7_000. Если продать десяток... Не знаю как там, а у нас вполне сностно год прожить можно :)

 

Как описать взаимодейстие между GUI и программой мы вроде как обсудили. Хотелось бы определится с форматом реализаций GUI.

Может быть определить его как иерархию компонент с их свойствами?

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

 

Другое дело, что городить совсем универсальное предстваление я бы не стал. Ядро можно сделать типовое, а вот заполнять каждый раз нужным toolkit-ом.

 

PS. Кстати, предлагаемое универсальное решение тоже может оказаться полезно, в частности для портирования под иной toolkit.

 

Тогда, имея описание тулкита в универсальном виде (как я предлагал ранее) можно было бы построить такой себе независимый билдер,

Независимый билдер - ещё большая сказка, нежели независимый набор компонент :(

 

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

 

 

Кроме этого нужно придумать способ описания реализации заданного интерфейса с программой. Простейший способ - юзер сам пишет

тело для процедуры используя компоненты из реализации GUI.

Способ 2 - указать что такому-то параметру/возвращаемому

значению соответствует такое-то свойство такого-то компонента

и заставить транслятор генерить тело процедуры.

 

Не знаю как реализовать на практике, но второй вариант мне больше нравится.

Еще есть такой вопрос. Как должно проходить написание

GUI программы? Нужно ли ограничивать юзера тем, что

спецификация должна быть написана ранее реализации?

Или разрешить ему обратный порядок, чтобы он нарисовал

GUI реализацию а потом "экспортировал" нужные свойства

в описания/спецификацию интерфейса. Боюсь только, что

если это разрешит, все превратится в Делфи на Аде :-(

 

Криворукие товарищи к этому всё сведут :(

 

Однако зачастую разработка UYI идёт параллельно с разработкой программы. А на этапах анализа (когда как делать код ещё никто даже не

догадывается) использовать дизайнер очень удобно при общении с конечным пользователем. Жаль потом выкидывать столько наработок...

 

 

--

Vadim Godunko

teplouhov@... wrote:

 

Хотите описывать саму структуру меню как программу? Нафига?

Изврат. Проще как данные и логичнее... Может еще как-то,

но не как программу - из пушки по воробьям и не гибко.

 

50/50 в зависимости от ситуации.

 

PS. Если в текущем проекте я буду хранить меню в файле, то замучаюсь потом доказывать зачем это надо.

 

PS. Если хранить в файле, то большая часть toolkit-ов поддерживает загрузку иерархии на лету. Как пример - Mrm для Motif, GLADE (?) для Gtk. Т.е. всё уже готово - осталось только использовать.

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

teplouhov@... wrote:

 

Что, иксы тоже правилам хорошего тона не обучены, и не стучаться

к пользователю во время работы и прямо так и вваливаются со своим

дурацким вопросом поверх экрана пользователя(или еще хуже - еще и

переключают на совсем другой)? ;}

 

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

 

PS. Это не значит, что так делают все - просто наиболее модные Gtk/GNOME и Qt/KDE ведут себя именно так. А вот Motif/CDE можно настроить так, как тебе того надо :)

 

 

PS. О косорукости и кривоглазости поведения GNOME и KDE я просто промолчу... Очень жаль что эти ребята так и не научились понимать смысл документа ICCCM. :(

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Hello teplouhov,

 

Tuesday, August 16, 2005, 9:46:15 AM, you wrote:

 

On Mon, 15 Aug 2005 14:30:45 +0300, Vladyslav Kozlovskyy

<dbdeveloper@rambler.ru> wrote:

 

Народ, a если так:

 

 

UI доописывается набором прагм:

(параметры взяты с потолка, гляньте на общую идею)

 

Только не прагм - прагма в реализации компилятора самая

тонкая и замороченная вещь, на которую завязаны все фичи

компилятора - чтобы что-то изменить в прагмах(и при этом

не поломать сам компилятор :) ) надо уже знать все тонкости

конкретного компилятора, в общем проще с нуля написать

что-то чем туда лезти...

 

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

 

Vladimir

 

 

 

 

--

Best regards,

Vladyslav

On Mon, 15 Aug 2005 13:58:06 +0400, Vadim Godunko <godunko@...> wrote:

 

teplouhov@... wrote:

 

Кстати, что-то я так и не понял на чем остановились - тоесть

как должно быть описано само меню и что это - просто файл данных

или описание на каком-то спецязыке. В общем это может быть

спецязык со своим спецкомпилятором, какой-то препроцессор на базе

чего-то стандартного либо просто вызовы процедур из библиотеки.

Я бы сделал так - описание самих кодов окон или параметров

в виде общей текстовки(можно Ада-пакета, и нужна гарантия что

какой-то вумный препроцессор ее не будет трогать и ничего

не изменит), само меню и окошки в файле данных(доступного

так-же какому-то редактору окошек), ну а движок вообще в стороне :)

 

Детали реализации для каждой платформы будут различаться. Общее только

 

несколько движков + несколько описаний.

(общее описание - стиль/метод - в гуевой либе + подстройка

у пользователя)

 

Похоже все идет к какому-то общему описанию скелета и сильным

различиям даже во внешнем виде от платформы(у некоторых и у мыша

всего 1 кнопка - придется явно рисовать на экране все варианты

выбора что на других просто другой кнопкой вызываются и тд и тп)...

 

Если это описание получиться более общее и удобное, то это хорошо,

а если нет, то это лишнии сопли...

 

одно - реализация UI для конкретной платформы описывается на языке

(соответствующей платформы) в отдельно взятом файле(ах). Некий

компилятор генерирует всё необходимое (опять таки для конкретной

платформы) на основании этого файла/ов.

 

Другой вариант - портировать что-то одно на все варианты железа...

 

 

 

Vladimir

PS Кстати, если вспомнить об элементарных требованиях надежности,

то совсем не факт что существование GUI интерфейса вообще возможно,

по крайней мере в исполнии некоторых библиотек/недосистем :)

Например, если в результате всего этого огорода получиться GUI

как в win98, то точно сразу в морг - ее дурацкие переключения

окон когда ей вздумается и тд и тп(даже если не рассматривать

глюки и зависания вообще) точно не проходят ни по каким критериям

надежности. Можно ли это как-то отключить или переделать не знаю,

если нет то существование надежной программы на базе 98 просто

не возможно и надо хорошо подумать учитывать ли ее фичи и тп.

(с другой стороны поддержка вин особенно нужна всмысле объема

продаж коммерческого софта, так что поддержку поиметь бы хотелось.

Может как-то указывать уровень надежности чтобы не было путанницы?)

 

Не надо путать требования надежности с требованиями безопасности

использования.

 

возможно, но тогда нужен справочник по терминологии :)

 

 

Указанное свойство Win98 негативно сказывается именно на безопасности

использования, а не на надежности. Кстати, это проблема любых

многооконных оболочек. Даже таких проверенных монстров, как X Window.

 

Что, иксы тоже правилам хорошего тона не обучены, и не стучаться

к пользователю во время работы и прямо так и вваливаются со своим

дурацким вопросом поверх экрана пользователя(или еще хуже - еще и

переключают на совсем другой)? ;}

 

Vladimir

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Mon, 15 Aug 2005 14:30:45 +0300, Vladyslav Kozlovskyy <dbdeveloper@...> wrote:

 

Народ, a если так:

 

 

UI доописывается набором прагм:

(параметры взяты с потолка, гляньте на общую идею)

 

Только не прагм - прагма в реализации компилятора самая

тонкая и замороченная вещь, на которую завязаны все фичи

компилятора - чтобы что-то изменить в прагмах(и при этом

не поломать сам компилятор :) ) надо уже знать все тонкости

конкретного компилятора, в общем проще с нуля написать

что-то чем туда лезти...

 

Vladimir

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Mon, 15 Aug 2005 16:11:31 +0400, Vadim Godunko <godunko@...> wrote:

 

Vladyslav Kozlovskyy wrote:

 

UI доописывается набором прагм:

(параметры взяты с потолка, гляньте на общую идею)

 

Здравая идея :) Я через неё тоже проходил.

 

Косяков с ней несколько:

 

 

Хотите описывать саму структуру меню как программу? Нафига?

Изврат. Проще как данные и логичнее... Может еще как-то,

но не как программу - из пушки по воробьям и не гибко.

 

Vladimir

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Народ а можно ли будет сделать в GUI так:

 

 

 

type base is tagged record ... end record;

 

type derived1 is new base with record ... end record;

 

type derived2 is new derived1 with record ... end record;

 

type base_class is base'class;

 

c : base_class = new derived2;

 

 

Edit(c); -- вызывается форма для derived2

 

c := new derived1;

 

Edit(c); -- вызывается форма для derived1

 

????

 

 

--

Best regards,

Vladyslav

Vladyslav Kozlovskyy wrote:

 

Edit(c); -- вызывается форма для derived2

 

c := new derived1;

 

Edit(c); -- вызывается форма для derived1

 

Можно всё :) Насколько заморачиваться придётся - вот в чём вопрос.

 

Решения:

 

1. Edit - динамически диспетчеризуемая операция. Не подходит, т.к. должна быть описана вместе с типом.

 

2. Edit - перегруженная операция. Не подходит, т.к. имеет место быть надклассовый вызов.

 

3. Edit - диспетчер вида:

 

if C in Derived1 then

Edit_1 (C);

elsif C in Derived2 then

Edit_2 (C);

end if;

 

4. То же самое, но подпрограммы регистрируются как пары Tag/Access_To_Subprogram и производится выбор подходящей.

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

On Tue, 16 Aug 2005 10:05:05 +0400, Vadim Godunko <godunko@...> wrote:

 

teplouhov@... wrote:

 

Хотите описывать саму структуру меню как программу? Нафига?

Изврат. Проще как данные и логичнее... Может еще как-то,

но не как программу - из пушки по воробьям и не гибко.

 

50/50 в зависимости от ситуации.

 

PS. Если в текущем проекте я буду хранить меню в файле, то замучаюсь

потом доказывать зачем это надо.

 

даже на паскале не было проблем пристыковать оверлей или файл данных

прямо к самому .exe (менеджер оверлеев дак и вообще стандартно

понимал такой изврат и умел искать оверлеи в конце .exe).

 

Так-же нет проблем и засунуть данные в виде констант в программу.

(простейший утиль конвертнет данные в текст программы.

Кстати тот редкий случай когда include был бы полезен - чтобы

не трогать саму программу. Впрочем не проблема это через with/use

сделать)

 

 

Так что вопрос принципиальный - нужна такая сложность синтаксиса

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

с синтаксическим анализатором и тп или хватит просто стандартных

форматов данных, описанных в библиотеке (я думаю что хватит).

 

 

 

PS. Если хранить в файле, то большая часть toolkit-ов поддерживает

загрузку иерархии на лету. Как пример - Mrm для Motif, GLADE (?) для

Gtk. Т.е. всё уже готово - осталось только использовать.

 

 

Vladimir

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Приветствую.

Сейчас читаю книжку про программную архитектуру пользовательского интерфеса, и она навевает определённые мысли о эффективном "разделении труда" между логикой и ГУИ.

(если кому интересно, могу сказать название, она есть в продаже, на русском языке)

 

У нас задействованы следующие программные объекты:

+ Системная Очередь (SystemEventQueue) событий (нажатия клавиш, позиционирование и указания мыши и т.д.);

+ Объекты-события (EventObject's), которые формируются Очередью в ответ на любое действие пользователя;

+ Компонент виджета (Object), принимающий от Очереди оповещения о происходящих, обрабатывающий её Объекты-события;

+ Модель виджета (ObjectModel), инкапсулирующий логику поведения виджета, хранящий внутреннее состояние (например, взведён ли значёк, установлена ли радиокнопка, текст поля редактирования, текст метки, флаг нажата/отпущена кнопка и т.д.);

+ Отображение виджета (ObjectUI), инкапсулирующий визуальное отображение виджета в зависимости от состояния Модели (например, если влажок взведён, то рисуется галочка; если кнопка нажата, то рисуется "утопленная" кнопка, отпущена - "нормальная" кнопка; виджет неактивен - изображается сереньким цветом и т.д.)

+ Прикладной объект слушателя (ClientListener) с методами обратного вызова на соответствующие события.

 

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

 

0. Пользователь произвёл какое-то действие в интерфейсе.

1. Системная Очередь событий получает от системы оповещение о действии пользователя.

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

3. Компонент виджета получает оповещение от Системной Очереди событий и принимается "доставать" Объект событие из Системной Очереди событий и обрабатывать его.

4. Обработка Объекта события заключается в установлении нового состояния Модели виджета и оповещения Прикладных объектов слушателей о произошедшем событии.

5. Компонент виджета так же следит за состоянием Модели виджета и непосредственно управляет Отображением виджета в соответствии с этим состоянием.

6. Модель виджета при изменении своего состояния оповещает Компонент виджета о необходимости изменения Отображения виджета.

 

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

 

System -> SystemEventQueue

|

V

ObjectModel <-> Object -> ObjectUI

|

V

ClientListener

 

В схеме не показан UIManager, который управляет поведением (Feel) Модели и отображением (Look) Отображения.

 

Теперь опишу "статику" архитектуры.

 

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

 

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

 

Модель виджета представляет собой логическую модель поведения виджета, полностью исключая из себя знание о способах отображения виджета на дисплее. В ней сосредоточена модель поведения (Feel) конкретной системной оболочки (Motif, Windows, Mac или собственная уникальная).

 

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

 

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

 

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

 

Управление видом и поведением (LookAndFeel).

Управлением видом и поведением Компонентов виджетов занимается специальный Менеджер ГУИ (UIManager). Он может настроить поведение Модели виджета и Отображение виджета в соответствии с поведением (Feel) и отображением (Look) системного виджета оконного менеджера той или иной операционной системы. Соответственно, для адекватного предствления виджета в том или ином стиле необходимо написать лишь необходимые классы, описывающие поведение (логику, модель) и отображение (способ отрисовки, вид) каждого из виджетов в конкретной операционной системе. Таким образом можно получить независимый от операционной системы интерфейс и, главное, - ОДИНАКОВЫЕ способы работы с ним в приложениях.

 

P.S. Продолжаю читать дальше о нюансах отрисовок ГУИ и о том, как избежать лавинообразного создания Объектов событий.

teplouhov@... wrote:

 

даже на паскале не было проблем пристыковать оверлей или файл данных

прямо к самому .exe (менеджер оверлеев дак и вообще стандартно

понимал такой изврат и умел искать оверлеи в конце .exe).

 

Присоединить что-то к ELF файлу - уже не простая задача в виду отсутствия штатных средств.

 

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

 

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

 

Вывод: необходимо иметь поддержку обоих технологий, а выбор предоставить пользователю. ;)

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Hello iZEN,

 

Tuesday, August 16, 2005, 10:28:56 PM, you wrote:

 

Приветствую.

Сейчас читаю книжку про программную архитектуру пользовательского интерфеса, и она навевает определённые мысли о эффективном "разделении труда" между логикой и ГУИ.

(если кому интересно, могу сказать название, она есть в продаже, на русском языке)

Интересно. Назовите пожалуйста название книги, издательство и автора

 

--

Best regards,

Vladyslav

Hello iZEN,

 

Tuesday, August 16, 2005, 10:28:56 PM, you wrote:

 

Приветствую.

Взаимно :)

 

 

...

У нас задействованы следующие программные объекты:

+ Системная Очередь (SystemEventQueue) событий (нажатия клавиш, позиционирование и указания мыши и т.д.);

...

Очень нужная и познавательная информация, но мы здесь пока

пытаемся автоматизировать не конкретную реализацию ГУ╡ (крос или native платформенную) а скорее паттерн взаимодействия программы на Аде с GUI вообще. Основная идея: максимальное разнесение логики предметой

области и взаимодействие с пользователем (ввод/отображение). Это

позволит юзать разные UI от дистанционного пульта и командой строки до трьохмерных интерфейсов.

 

Я правильно понял основную идею, господа?

 

 

--

Best regards,

Vladyslav

Hello Vadim,

 

Wednesday, August 17, 2005, 10:16:19 AM, you wrote:

 

Vadim Godunko wrote:

Vadim Godunko wrote:

Vladyslav Kozlovskyy wrote:

 

 

Очень нужная и познавательная информация, но мы здесь пока

пытаемся автоматизировать не конкретную реализацию ГУИ (крос или native платформенную) а скорее паттерн взаимодействия программы на Аде с GUI вообще. Основная идея: максимальное разнесение логики предметой

области и взаимодействие с пользователем (ввод/отображение). Это позволит юзать разные UI от дистанционного пульта и командой строки до трьохмерных интерфейсов.

 

Я правильно понял основную идею, господа?

 

Не только правильно понял, но и впервые (!) абсолютно корректно её высказал.

 

Эээ... прошу прощения, впервые => первым в этой рассылке

:)))))

 

 

Цель поставлена. Ваши идеи!

 

 

--

Best regards,

Vladyslav

Vladyslav Kozlovskyy wrote:

 

Очень нужная и познавательная информация, но мы здесь пока

пытаемся автоматизировать не конкретную реализацию ГУ╡ (крос или native

платформенную) а скорее паттерн взаимодействия программы на Аде с GUI

вообще. Основная идея: максимальное разнесение логики предметой

области и взаимодействие с пользователем (ввод/отображение). Это

позволит юзать разные UI от дистанционного пульта и командой строки до

трьохмерных интерфейсов.

 

Я правильно понял основную идею, господа?

 

Не только правильно понял, но и впервые (!) абсолютно корректно её высказал.

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Vadim Godunko wrote:

Vladyslav Kozlovskyy wrote:

 

 

Очень нужная и познавательная информация, но мы здесь пока

пытаемся автоматизировать не конкретную реализацию ГУ╡ (крос или native

платформенную) а скорее паттерн взаимодействия программы на Аде с GUI

вообще. Основная идея: максимальное разнесение логики предметой

области и взаимодействие с пользователем (ввод/отображение). Это

позволит юзать разные UI от дистанционного пульта и командой строки до

трьохмерных интерфейсов.

 

Я правильно понял основную идею, господа?

 

Не только правильно понял, но и впервые (!) абсолютно корректно её высказал.

 

Эээ... прошу прощения, впервые => первым в этой рассылке

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Новое сообщение:
< Страницы: 1 2 3 4

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти