Ada_Ru форум

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

Язык описания GUI

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

Сообщения

Vadim Godunko
Язык описания GUI
2005-08-03 06:22:32

Доброе утрое!

 

Хочу продолжить разговор о UI.

 

Следуя идее отделения логики от внешнего вида предлогаю использовать два различных файла: файл описания интерфейса и файл описания реализации.

 

Файл описания интерфейс удобно было бы сделать в Ada-like стиле. Напротив, описание реализации вполне можно сотворить в XML.

 

Описание интерфейса должно включать:

 

- компоненты (окна верхнего уровня, диалоги и т.д.)

 

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

 

- операции компонентов (то, что программа может вызвать у компонента)

 

- "импортируемые" подпрограммы программы (то, что может вызвать реализация интерфейса в программе)

 

Описание реализации должно включать:

 

- дерево виджетов конкретного toolkit-a

 

- свойства этих виджетов

 

- все формализованные взаимосвязи по упарвлению

 

- сегменты пользовательского кода

 

Генератор (давайте не будем использовать слово "препроцессор", оно здесь не очень уместно) принимает оба файла, проверяет, что описание интерфейса соответствует фактическому Ada коду, и генерирует код на основании описания соответствующей реализации.

 

Комментарии?

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Следуя идее отделения логики от внешнего вида предлогаю использовать два различных файла: файл описания интерфейса и файл описания реализации.

можешь набросать примерчик файла описания и файла реализации. Что-то не очень ясно

 

 

Файл описания интерфейс удобно было бы сделать в Ada-like стиле. Напротив, описание реализации вполне можно сотворить в XML.

Реализация под конкретную платформу? А причем здесь XML? Почему нельзя обойтись тоже Адой?

 

Генератор (давайте не будем использовать слово "препроцессор"

Догласен. Есть еще одно название - precompiler (прекомпиллер) (из ESQL, помните? Есть в поставке GNADE. Прикольная штучка, использовать - супер удобно, только ее IDE-шки не поддерживают :( ) Фактически все такие генераторы (прекомпиллеры) есть нечто иное, как еще один слой front-end-а. Я вижу, как минимум, четыре такие дополнительные слоя:

прекомпиллеры

SQL/XML

COM/CORBA

PERSISTENT OBJECTS (примерная реализация см. ODB - Object

Persistency Framework for Ada 95)

GUI

 

Фактически они - расширители языка - добавляют native поддержку вещей, не внесенных в стандарт языка.

 

ODB, например так описывает persistent object:

 

type Object is persistent record

Name : attribute Unbounded_String;

Players : attribute Reference;

Maze : attribute Maze_Type ;

end record ;

 

А GNADE записывает запрос так:

 

declare

 

EXEC SQL DECLARE MyDataBase DATABASE ;

 

EXEC SQL BEGIN DECLARE SECTION ;

Deptno : INT

EXEC SQL END DECLARE SECTION ;

begin

 

EXEC SQL AT MyDataBase

SELECT DEPTNO INTO :Deptno FROM EMPLOYEES

WHERE NAME = 'Erdmann' ;

 

Ada.Text_IO.Put_Line( " Deptno => " & Deptno'img );

end;

 

 

Может в этом направлении копать?

 

 

--

Best regards,

Vladyslav

Vladyslav Kozlovskyy wrote:

Следуя идее отделения логики от внешнего вида предлогаю использовать два

различных файла: файл описания интерфейса и файл описания реализации.

 

можешь набросать примерчик файла описания и файла реализации. Что-то

не очень ясно

 

Попробую. :) Например так:

 

Описание:

 

with Program_Callbacks; -- модуль программы

 

package UI is

 

procedure On_Quit is in Program_Callbacks;

-- Подпрограмма, завершающая выполнение программы.

 

procedure On_Shutdown is in Program_Callbacks;

-- Подпрограмма, завершающая выполнение программы и выключающая компьютер. :)

 

interface QuitConfirmationDialog is

 

procedure Show;

 

end QuitConfirmationDialog;

 

end UI;

 

Реализация (в Ada стиле):

 

package implementation UI on Motif is

 

interface implementation QuitConfirmationDialog is

 

widget Dialog is new Xm_Template_Dialog with

widget Ok_Button is builtin OK_BUTTON;

widget Cancel_Button is builtin CANCEL_BUTTON;

widget Form is new Xm_Form with

widget Label is new Xm_Label_Gadget with

for Xm_N_Left_Attachemnt use Xm_Attach_Form;

for Xm_N_Right_Attachment use Xm_Attach_Form;

for Xm_N_Top_Attachment use Xm_Attach_Form;

for Xm_N_Bottom_Attachment use Xm_Attach_Widget;

for Xm_N_Bottom_Widget use Shutdown_Toggle;

end Label;

widget Shutdown_Toggle is new Xm_Toggle_Button_Gadget;

end Form;

end Dialog;

 

procedure Show is

begin

Xt_Manage_Child (Dialog);

end Show;

 

end QuitConfirmationDialog;

 

end UI;

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Реализация (в Ada стиле):

 

package implementation UI on Motif is

 

interface implementation QuitConfirmationDialog is

 

widget Dialog is new Xm_Template_Dialog with

widget Ok_Button is builtin OK_BUTTON;

widget Cancel_Button is builtin CANCEL_BUTTON;

widget Form is new Xm_Form with

widget Label is new Xm_Label_Gadget with

for Xm_N_Left_Attachemnt use Xm_Attach_Form;

for Xm_N_Right_Attachment use Xm_Attach_Form;

for Xm_N_Top_Attachment use Xm_Attach_Form;

for Xm_N_Bottom_Attachment use Xm_Attach_Widget;

for Xm_N_Bottom_Widget use Shutdown_Toggle;

end Label;

widget Shutdown_Toggle is new Xm_Toggle_Button_Gadget;

end Form;

end Dialog;

 

procedure Show is

begin

Xt_Manage_Child (Dialog);

end Show;

 

end QuitConfirmationDialog;

 

end UI;

 

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

 

--

Best regards,

Vladyslav

Vladyslav Kozlovskyy wrote:

Реализация (в Ada стиле):

 

package implementation UI on Motif is

^^^^

Это есть указание toolkit-а

 

 

interface implementation QuitConfirmationDialog is

 

widget Dialog is new Xm_Template_Dialog with

widget Ok_Button is builtin OK_BUTTON;

widget Cancel_Button is builtin CANCEL_BUTTON;

widget Form is new Xm_Form with

widget Label is new Xm_Label_Gadget with

for Xm_N_Left_Attachemnt use Xm_Attach_Form;

for Xm_N_Right_Attachment use Xm_Attach_Form;

for Xm_N_Top_Attachment use Xm_Attach_Form;

for Xm_N_Bottom_Attachment use Xm_Attach_Widget;

for Xm_N_Bottom_Widget use Shutdown_Toggle;

end Label;

widget Shutdown_Toggle is new Xm_Toggle_Button_Gadget;

end Form;

end Dialog;

 

procedure Show is

begin

Xt_Manage_Child (Dialog);

end Show;

 

end QuitConfirmationDialog;

 

end UI;

 

 

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

 

Да.

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Vladyslav Kozlovskyy wrote:

>Реализация (в Ada стиле):

 

>package implementation UI on Motif is

^^^^

Это есть указание toolkit-а

 

 

interface implementation QuitConfirmationDialog is

 

widget Dialog is new Xm_Template_Dialog with

widget Ok_Button is builtin OK_BUTTON;

widget Cancel_Button is builtin CANCEL_BUTTON;

widget Form is new Xm_Form with

widget Label is new Xm_Label_Gadget with

for Xm_N_Left_Attachemnt use Xm_Attach_Form;

for Xm_N_Right_Attachment use Xm_Attach_Form;

for Xm_N_Top_Attachment use Xm_Attach_Form;

for Xm_N_Bottom_Attachment use Xm_Attach_Widget;

for Xm_N_Bottom_Widget use Shutdown_Toggle;

end Label;

widget Shutdown_Toggle is new Xm_Toggle_Button_Gadget;

end Form;

end Dialog;

 

procedure Show is

begin

Xt_Manage_Child (Dialog);

end Show;

 

end QuitConfirmationDialog;

 

>end UI;

 

 

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

 

Да.

И из чего эта реализация должна генерится? Я ничего подобного в

описании не видел (кнопки, лабелки и т.д.) что-то я не доганяю :(

--

Best regards,

Vladyslav

Vladyslav Kozlovskyy wrote:

 

interface implementation QuitConfirmationDialog is

 

Начало описания иерархии и свойств

 

widget Dialog is new Xm_Template_Dialog with

widget Ok_Button is builtin OK_BUTTON;

widget Cancel_Button is builtin CANCEL_BUTTON;

widget Form is new Xm_Form with

widget Label is new Xm_Label_Gadget with

for Xm_N_Left_Attachemnt use Xm_Attach_Form;

for Xm_N_Right_Attachment use Xm_Attach_Form;

for Xm_N_Top_Attachment use Xm_Attach_Form;

for Xm_N_Bottom_Attachment use Xm_Attach_Widget;

for Xm_N_Bottom_Widget use Shutdown_Toggle;

end Label;

widget Shutdown_Toggle is new Xm_Toggle_Button_Gadget;

end Form;

end Dialog;

Конец описания иерархии и свойств

 

> И из чего эта реализация должна генерится? Я ничего подобного в

описании не видел (кнопки, лабелки и т.д.) что-то я не доганяю :(

 

Конструкция вида widget <имя> is new <базовый тип виджета> и есть описание иерархии:

 

<widget> ::=

 

widget <identifer> is new <widget_class_identifier> with

<children_or_properties>

end <identifier>;

 

<chidren_or_property> ::= <children>* | <property>*

 

<children> ::= <widget>

 

<property> ::= for <property_identifier> use <value>

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

 

********************************************************************

This email and any attachments are confidential to the intended

recipient and may also be privileged. If you are not the intended

recipient please delete it from your system and notify the sender.

You should not copy it or use it for any purpose nor disclose or

distribute its contents to any other person.

********************************************************************

Vladyslav Kozlovskyy wrote:

 

И из чего эта реализация должна генерится? Я ничего подобного в

описании не видел (кнопки, лабелки и т.д.) что-то я не доганяю :(

 

Помему я не понял вопроса. :(

 

Описание UI состоит из двух частей: описание интерфейса и описание реализации.

 

описание интерфейса (первый пример) - общее для всех реализаций.

 

описание реализации (второй пример) - необходимая и достаточная информаци об обустройстве UI для генератора кода.

 

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

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Описание UI состоит из двух частей: описание интерфейса и описание реализации.

 

описание интерфейса (первый пример) - общее для всех реализаций.

описание реализации (второй пример) - необходимая и достаточная информаци об обустройстве UI для генератора кода.

 

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

 

Слишком сложно. Если я не знаю Иксов и пишу под Win32, кто напишет Motif-based часть моей программы? А как же переносимость?

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

 

Может моя программа должна вообще работать на символьных терминалах. А че - в символьном режиме можно представить почти все, кроме рисунков (иконок) и rich

text (и то, подчеркивание и цвет там могут иметь место). Я раньше пробовал - прикольно получается :)

 

 

Мне больше такой подход:

 

Я рисую/пишу GUI (формочки, кнопочки и т.д.)

Я подцепляю к ним нужные мне функции (калбеки)

Я выбираю платформу

и нажимаю кнопку "Готово!" :)

 

А реализацию (например такую, как ты описал для Motif) пускай за меня кто-то другой напишет :)

 

 

--

Best regards,

Vladyslav

Vladyslav Kozlovskyy wrote:

Описание UI состоит из двух частей: описание интерфейса и описание

реализации.

 

описание интерфейса (первый пример) - общее для всех реализаций.

 

описание реализации (второй пример) - необходимая и достаточная информаци об обустройстве UI для генератора кода.

 

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

 

 

Слишком сложно. Если я не знаю Иксов и пишу под Win32, кто напишет

Motif-based часть моей программы? А как же переносимость?

Часть реализации не переносится на другую платформу. Для каждой платформы нужно самостоятельно писать собственную реализацию интерфейса.

 

Задача разработки интерфейса конкретной платформы должна выполняться в основном builder-ом.

 

А очень надеялся на хорошего дядечку (прекомпилятор), который сделает

это за меня. А посему на вход я хочу подать нечто кросс-платформенное,

не зависящее от платформы.

 

Все имеющиеся подобные реализации не лишены недостатков. Речь как раз идёт об отказе от подобной практики.

 

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

 

Может моя программа должна вообще работать на символьных терминалах. А

че - в символьном режиме можно представить почти все, кроме рисунков (иконок) и rich

text (и то, подчеркивание и цвет там могут иметь место). Я раньше пробовал -

прикольно получается :)

 

Так подставляй собственный интерфейс на основе NCurses и вперёд!

 

PS. А что, может NCurses тоже добавим в список планируемых поддерживаемых платформ?

 

 

Мне больше такой подход:

 

Я рисую/пишу GUI (формочки, кнопочки и т.д.)

Не спорю.

 

Я подцепляю к ним нужные мне функции (калбеки)

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

 

Я выбираю платформу

и нажимаю кнопку "Готово!" :)

 

А реализацию (например такую, как ты описал для Motif) пускай за меня

кто-то другой напишет :)

 

Эээх... Если-бы так можно было! :(

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

 

Задача разработки интерфейса конкретной платформы должна выполняться в основном builder-ом.

Который и сохраняет разработтаный интерфейс в своем унифицированном формате (xml?)

 

Зачем тогда отдельный язык для реализации?

 

Почему бы тогда билдеру и не генерить оптимальный код на чистой аде под конкретную платформу. КОНКРЕТНЫЙ билдер должен это уметь?

 

 

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

 

Все имеющиеся подобные реализации не лишены недостатков. Речь как раз идЈт об отказе от подобной практики.

 

Но все же должно же быть и что-то общее. Иначе и портировать то ничего не удастся. Базовые понятия, принципы должны быть общими у всего

семейства билдеров.

 

 

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

 

Может моя программа должна вообще работать на символьных терминалах. А че - в символьном режиме можно представить почти все, кроме рисунков (иконок) и rich

text (и то, подчеркивание и цвет там могут иметь место). Я раньше пробовал - прикольно получается :)

 

Так подставляй собственный интерфейс на основе NCurses и вперЈд!

Уже пробовал :)

 

 

PS. А что, может NCurses тоже добавим в список планируемых

поддерживаемых платформ?

Обязательно. Без этого никак :)

 

 

 

Мне больше такой подход:

 

Я рисую/пишу GUI (формочки, кнопочки и т.д.)

Не спорю.

 

Я подцепляю к ним нужные мне функции (калбеки)

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

выражений, ещЈ чего-либо).

Типа Ада-скрипта?

 

 

Я выбираю платформу

и нажимаю кнопку "Готово!" :)

 

А реализацию (например такую, как ты описал для Motif) пускай за меня кто-то другой напишет :)

 

Эээх... Если-бы так можно было! :(

 

--

Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

 

 

--------------------------------------------------------------------------------

YAHOO! GROUPS LINKS

 

Visit your group "ada_ru" on the web.

 

To unsubscribe from this group, send an email to:

ada_ru-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

 

--------------------------------------------------------------------------------

 

 

--

Best regards,

Vladyslav

--- In ada_ru@yahoogroups.com, Vadim Godunko <godunko@s...> wrote:

 

ÄÐÙÛ ÞßØáÐÝØï ØÝâÕàäÕÙá ãÔÞÑÝÞ ÑëÛÞ Ñë áÔÕÛÐâì Ò Ada-like áâØÛÕ.

° ÒÞâ ÕáÛØ ÕÓÞ ãÔÐáâáï áÔÕÛÐâì Ò çØáâÞÙ °ÔÕ,

âÞ ÜÞÖÝÞ ÒÞáßÞÛì×ÞÒÐâìáï ASIS-ÞÜ ÔÛï ÕÓÞ ÐÝÐÛØ×Ð Ø

ÝÕ ßØáÐâì áØÝâÐÚáØçÕáÚØÙ ÐÝÐÛØ×ÐâÞà áÐÜÞÜã.

 

½ÐßàÞâØÒ, ÞßØáÐÝØÕ àÕÐÛØ×ÐæØØ ÒßÞÛÝÕ ÜÞÖÝÞ áÞâÒÞàØâì Ò XML.

 

¾ßØáÐÝØÕ ØÝâÕàäÕÙáÐ ÔÞÛÖÝÞ ÒÚÛîçÐâì:

 

- ÚÞÜßÞÝÕÝâë (ÞÚÝÐ ÒÕàåÝÕÓÞ ãàÞÒÝï, ÔØÐÛÞÓØ Ø â.Ô.)

Ï×ëÚ ÞßØáÐÝØï ØÝâÕàäÕÙáÐ ÑãÔÕâ ÞÓÞÒÐàØÒÐâì

ÒÞ×ÜÞÖÝëÕ ÒÐàØÐÝâë ÚÞÜßÞÝÕÝâ? ÇâÞ âãÔÐ ÕéÕ ßÞßÐÔÕâ

ÚàÞÜÕ ÞÚÞÝ Ø ÔØÐÛÞÓÞÒ? ºÞÜßÞÝÕÝâë ÒÒÞÔÐ ×ÝÐçÕÝØÙ?

³àØÔë? ´ÐÒÐÙâÕ ÝÐÑàÐáÐÕÜ áßØáÞçÕÚ, ßÞâÞÜ ÑÕÔãÜ àÐáèØàïâì,

ÕáÛØ ßÞÝÐÔÞÑØâáï.

 

 

- ÐâàØÑãâë ÚÞÜßÞÝÕÝâÞÒ (ÐâàØÑãâë ÔÞÛÖÝë Ñëâì âØßØ×ØàÞÒÐÝÝëÜØ á

ßàØÒï×ÚÞÙ

Ú âØßÐÜ ÔÐÝÝëå Ada ÚÞÔÐ)

Ï×ëÚ ÞßØáÐÝØï ØÝâÕàäÕÙáÐ ÑãÔÕâ ÞÓÞÒÐàØÒÐâì

ÒÞ×ÜÞÖÝëÕ ÐâàØÑãâë ÔÛï ÚÐÖÔÞÓÞ ÒØÔÐ ÚÞÜßÞÝÕÝâ?

 

 

- ÞßÕàÐæØØ ÚÞÜßÞÝÕÝâÞÒ (âÞ, çâÞ ßàÞÓàÐÜÜÐ ÜÞÖÕâ Òë×ÒÐâì ã ÚÞÜßÞÝÕÝâÐ)

ÍâÞ ÚÐÚ-âÞ ßÕàÕÚÛØÚÐÕâáï á ßàÕÔØÔãéØÜ ßãÝÚâÞÜ,

ÝÐÒÕàÝïÚÐÚ çâÞÑ ãáâÐÝÞÒØâì ÚÐÚÞÙ-âÞ ÐââàØÑãâ

ÝãÖÝÞ Òë×ÒÐâì ÚÐÚãî-âÞ ÞßÕàÐæØî...

 

- "ØÜßÞàâØàãÕÜëÕ" ßÞÔßàÞÓàÐÜÜë ßàÞÓàÐÜÜë (âÞ, çâÞ ÜÞÖÕâ Òë×ÒÐâì àÕÐÛØ×ÐæØï ØÝâÕàäÕÙáÐ Ò ßàÞÓàÐÜÜÕ)

 

ÁßØáÞÚ áÞÑëâØÙ, Ú ÚÞâÞàëÜ ÜÞÖÝÞ ßàÕÔÞáâÐÒÛïâì ßÞÔßàÞÓàÐÜÜë

âÞÖÕ ÑãÔÕâ ÞßàÕÔÕÛïâáï Ò ï×ëÚÕ ÞßØáÐÝØï ØÝâÕàäÕÙáÐ?

 

¸ÛØ Ú çÕÜã ÚàÕßØâáï ßÞÔßàÞÓàÐÜÜÐ - íâÞ Ò àÕÐÛØ×ÐæØØ?

 

¾ßØáÐÝØÕ àÕÐÛØ×ÐæØØ ÔÞÛÖÝÞ ÒÚÛîçÐâì:

 

- ÔÕàÕÒÞ ÒØÔÖÕâÞÒ ÚÞÝÚàÕâÝÞÓÞ toolkit-a

 

- áÒÞÙáâÒÐ íâØå ÒØÔÖÕâÞÒ

 

- ÒáÕ äÞàÜÐÛØ×ÞÒÐÝÝëÕ Ò×ÐØÜÞáÒï×Ø ßÞ ãßÐàÒÛÕÝØî

 

- áÕÓÜÕÝâë ßÞÛì×ÞÒÐâÕÛìáÚÞÓÞ ÚÞÔÐ

¼ÞÖÕâ ÚàÞÜÕ áÕÓÜÕÝâÞÒ ÚÞÔÐ ßàÕÔãáÜÞâàÕâì ÕéÕ ÚÐÚÞÙ-âÞ

ßáÕÒÔÞÚÞÔ ÔÛï ÜÐÝØßãÛØàÞÒÐÝØï áÞ áÒÞÙáâÒÐÜØ ÒØÔÖÕâÞÒ?

´Ûï âÞÓÞ çâÞÑë ÕáÛØ ã àÐ×Ýëå àÕÐÛØ×ÐæØÙ Õáâì ÒØÔÖÕâë

á ÞÔØÝÐÚÞÒëÜØ áÒÞÙáâÒÐÜØ, âÞ íâÞâ ßáÕÒÔÞ ÚÞÔ ßÕàÕÝÕáÕâáï

Ø× ÞÔÝÞÙ àÕÐÛØ×ÐæØØ Ò ÔàãÓãî ÑÕ× Ø×ÜÕÝÕÝØÙ. ÂØßÐ

"ÕáÛØ î×Õà ÝÐÖÐÛ ÚÝÞßÚã Clear" ßáÕÒÔÞÚÞÔ =>

²ØÔÖÕâ Input_Text áÒÞÙáâÒÞ Text = "".

ÀÕÐÛØ×ÞÒÐâì âÞÛìÚÞ ÚÞßØàÞÒÐÝØÕ/ãáâÐÝÞÒÚã áÒÞÙáâÒ Ø

ÜÞÖÕâ ÕéÕ ãáÛÞÒÝëÕ ÞßÕàÐæØØ ÝÐ ÞáÝÞÒÕ ×ÝÐçÕÝØï áÒÞÙáâÒ.

 

 

ºÞÜÜÕÝâÐàØØ?

 

 

µéÕ âÐÚÞÙ ÒÞßàÞá. ½ãÖÝÞ ÝÐÜ ÞßØáÐÝØï âÞÛìÚÞ ÚÞÝÚàÕâÝëå íÛÕÜÕÝâÞÒ, ØÛØ ßÞÝÐÔÞÑïâáï ÕéÕ "âØßë" íÛÕÜÕÝâÞÒ, ÔÛï ßÞáÛÕÔãîéÕÓÞ

áÞ×ÔÐÝØï ÝÕáÚÞÛìÚØå íÚ×ÕÜßÛïàÞÒ ÞÔÝÞÓÞ âØßÐ. ½ÐßàØÜÕà

¾ßØáëÒÐÕèì ÞÚÝÞ ßàÞáÜÞâàÐ ÔÞÚãÜÕÝâÐ, Ð ßÞâÞÜ î×Õà Øå

ÞâÚàëÒÐÕâ áâÞÛìÚÞ, áÚÞÛìÚÞ ÝãÖÝÞ Ø Øå Ò ßàÞÓàÐÜÜÕ ÞÔÝÞÒàÕÜÕÝÝÞ

áãéÕáâÒãÕâ N-Õ ÚÞÛ-ÒÞ. °ÝÐÛÞÓØçÝÞ ßÛÐÔïâáï, áÚÐÖÕÜ

áâàÐÝØçÚØ(ÒÚÛÐÔÚØ) Ò ÞÚÝÕ, ØÛØ ßãÝÚâë ÜÕÝî Ò ÜÕÝî

"ÞâÚàëàëÕ ÞÚÝÐ".

 

 

 

--

Vadim Godunko

 

 

--

Maxim Reznik

Vladyslav Kozlovskyy wrote:

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

основном builder-ом.

 

Который и сохраняет разработтаный интерфейс в своем унифицированном формате (xml?)

 

XML или Ada подобный - предстоит обсудить. На Ada-подобном легче было пример привести :)

 

Зачем тогда отдельный язык для реализации?

 

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

 

Почему бы тогда билдеру и не генерить оптимальный код на чистой аде

под конкретную платформу. КОНКРЕТНЫЙ билдер должен это уметь?

 

Да, используя соответствующие модули компилятора.

 

 

Но все же должно же быть и что-то общее. Иначе и портировать то ничего

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

семейства билдеров.

 

Базовыми понятиями как раз и будут импортируемые (из программы в интерфейс) подпрограммы, типы данных, подпрограммы интерфейсов.

 

Ясное дело, что большинство графических toolkit-ов построены так или иначе, но схоже. И портировать из Motif в Windows вполне возможно. А как портировать из Windows в HTML? Или из Gtk в NCurses? По ходу реализации и эксплуатации проекта я думаю мы сами найдём ответы на вопросы автоматизации протирования. :)

 

PS. А что, может NCurses тоже добавим в список планируемых поддерживаемых платформ?

 

Обязательно. Без этого никак :)

 

Добавил.

 

 

Я подцепляю к ним нужные мне функции (калбеки)

 

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

 

оТип аАд-аскрипт?

 

аВозможн. (о.Т. едл яначал абыл об ынеплох)

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

reznikmm wrote:

--- In ada_ru@yahoogroups.com, Vadim Godunko <godunko@s...> wrote:

 

Файл описания интерфейс удобно было бы сделать в Ada-like стиле.

А вот если его удастся сделать в чистой Аде, то можно воспользоваться ASIS-ом для его анализа и

не писать синтаксический анализатор самому.

 

Возможно... Но надо подумать...

 

 

Напротив, описание реализации вполне можно сотворить в XML.

 

Описание интерфейса должно включать:

 

- компоненты (окна верхнего уровня, диалоги и т.д.)

 

Язык описания интерфейса будет оговаривать

возможные варианты компонент? Что туда еще попадет

кроме окон и диалогов? Компоненты ввода значений?

Гриды? Давайте набрасаем списочек, потом бедум расширять,

если понадобится.

 

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

 

Язык описания интерфейса будет оговаривать

возможные атрибуты для каждого вида компонент?

 

Нет. Язык только описывает интерфейс между программой и UI. Т.е. импортированные из программы в UI типы данных, подпрограммы; и экспортируемые из UI в программу реализации компонентов.

 

 

Список событий, к которым можно предоставлять подпрограммы

тоже будет определятся в языке описания интерфейса?

 

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

 

Или к чему крепится подпрограмма - это в реализации?

 

Угу.

 

 

Может кроме сегментов кода предусмотреть еще какой-то

псевдокод для манипулирования со свойствами виджетов?

Придётся.

 

Для того чтобы если у разных реализаций есть виджеты

с одинаковыми свойствами, то этот псевдо код перенесется

из одной реализации в другую без изменений. Типа

"если юзер нажал кнопку Clear" псевдокод =>

Виджет Input_Text свойство Text = "".

Реализовать только копирование/установку свойств и

может еще условные операции на основе значения свойств.

 

Мне кажется, что этот язык родится самостоятельно. :)

 

 

Еще такой вопрос. Нужно нам описания только конкретных элементов,

или понадобятся еще "типы" элементов, для последующего

создания нескольких экземпляров одного типа. Например

Описываешь окно просмотра документа, а потом юзер их

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

существует N-е кол-во. Аналогично пладятся, скажем странички(вкладки) в окне, или пункты меню в меню

"открырые окна".

 

Я думаю, что компонент будет всегда эквивалентен классу. Т.е. можно создать столько его экземпляров, сколько хочется программе.

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

On Wed, Aug 03, 2005 at 04:57:36PM +0400, Vadim Godunko wrote:

reznikmm wrote:

--- In ada_ru@yahoogroups.com, Vadim Godunko <godunko@s...> wrote:

>Файл описания интерфейс удобно было бы сделать в Ada-like стиле.

 

А вот если его удастся сделать в чистой Аде,

то можно воспользоваться ASIS-ом для его анализа и

не писать синтаксический анализатор самому.

 

Возможно... Но надо подумать...

 

 

Может быть типа такого:

- файл описания интерфейса - это пакет на Аде.

- для каждого компонента верхнего уровня

(у кого нет предка/контейнера: окна/диалоги)

создается вложенный пакет.

- если можно иметь много экземпляров окна/диалога

то в пакете тип и операции к нему, если нет,

то просто операции в пакете.

- доступ к (видимым) вложенным компонентам

через функции типа или пакета.

- колбеки через формальные параметры

настраиваемых пакетов.

 

with Ada.Calendar;

with User_Types;

 

package My_UI is

 

generic

with procedure Commit;

with procedure Rollback;

package Input_Dialog is

 

-- Типа нет - значит диолог м.б. только один

 

-- implicit compoment Sale_Time

function Get_Sale_Time return Ada.Calendar.Time;

procedure Set_Sale_Time (Data : Ada.Calendar.Time);

 

-- implicit component Amount

function Get_Amount return Used_Types.Amount;

procedure Set_Amount (Data : Used_Types.Amount);

 

procedure Show;

end Input_Dialog;

 

end My_UI;

 

Типы, описанные в пакете (соответствующие компонентам)

можно сделать неограниченными, лимитированными дабы

запретить создание и присваивание вне пакета My_UI

 

package Input_Dialogs is

 

type Input_Dialog (<>) is limited private;

 

procedure Create_Dialog;

function Cound_Dialog return Natural;

function Get_Dialog (Index : Positive) return Input_Dialog;

procedure Free_Dialog (Index : Positive);

 

end;

 

 

declare

Dlg : Input_Dialog renames Get_Dialog (I);

Amt : Amount;

begin

Show (Dlg);

Amt := Amount (Dlg);

Free_Dialog (I);

return Amt;

end;

 

--

Maxim Reznik

Maxim Reznik wrote:

 

Может быть типа такого:

- файл описания интерфейса - это пакет на Аде.

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

 

- для каждого компонента верхнего уровня

(у кого нет предка/контейнера: окна/диалоги)

создается вложенный пакет.

Ок

 

- если можно иметь много экземпляров окна/диалога

то в пакете тип и операции к нему, если нет,

то просто операции в пакете.

Ок

 

Как-то нужно "маркировать" то, что этот пакет есть реализация GUI. Может предположить, что все типы порождаются от вполне конкретного

родительского типа?

 

Тогда можно сделать этот тип пустым "контейнером" (smart pointer), просто хранящим ссылку на реализацию.

 

- доступ к (видимым) вложенным компонентам

через функции типа или пакета.

Наверное не столько компонентам, сколько данным?

 

- колбеки через формальные параметры

настраиваемых пакетов.

 

Хитрая идея... А на сколько это реально?

 

 

Типы, описанные в пакете (соответствующие компонентам)

можно сделать неограниченными, лимитированными дабы

запретить создание и присваивание вне пакета My_UI

 

Мне больше нравится smart pointer на действительно limited private with unknown discriminant part (правда, все tagged - have unknown

discriminant part)

 

 

--

Vadim Godunko

On Fri, Aug 05, 2005 at 06:55:20PM +0400, Vadim Godunko wrote:

Maxim Reznik wrote:

 

Может быть типа такого:

- файл описания интерфейса - это пакет на Аде.

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

 

 

Кроме того момента, что мы сможем парсить этот файл

при помощи ASIS-а, хорошо еще и то, что этот

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

внутри нашей программы.

 

А GUI-транслятор будет нам генерить тело для

этого пакета по файлу описания реализации XML.

 

 

Как-то нужно "маркировать" то, что этот пакет есть реализация GUI.

А зачем ? :-)

 

Может

предположить, что все типы порождаются от вполне конкретного

родительского типа?

 

Если надо маркировать пакет самого верхнего уровня, то это

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

предопределенного пустого пакета, типа "package GUI".

Но ты пишешь про типы, я не совсем понял про какие.

Это те которые по сути указатели на компоненты?

Да, можно сделать им общий корень, по идее.

 

 

Тогда можно сделать этот тип пустым "контейнером" (smart pointer), просто хранящим ссылку на реализацию.

 

- доступ к (видимым) вложенным компонентам

через функции типа или пакета.

Наверное не столько компонентам, сколько данным?

Да, к свойствам компонент.

 

 

- колбеки через формальные параметры

настраиваемых пакетов.

 

Хитрая идея... А на сколько это реально?

А что тут не реального? Нормальный Адский прием.

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

данные пользователя, тогда прийдется сделать

еще механизм с передачей объекта.

 

 

 

Типы, описанные в пакете (соответствующие компонентам)

можно сделать неограниченными, лимитированными дабы

запретить создание и присваивание вне пакета My_UI

 

Мне больше нравится smart pointer на действительно limited private with unknown discriminant part (правда, все tagged - have unknown

discriminant part)

 

Тут меня терзают смутные сомненья. Дал ты юзеру smart pointer,

потом по логике приложения этот элемент больше не нужен и

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

юзера есть на него ссылка. А потом юзер пытается что-то сделать,

активировать этот ненужный/почти удаленый элемент, мы что ему на

это скажем? Ну тот же пример с меню открытых окон, окно закрыли,

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

 

--

Maxim Reznik

Maxim Reznik wrote:

 

>- колбеки через формальные параметры

настраиваемых пакетов.

 

 

>Хитрая идея... А на сколько это реально?

 

А что тут не реального? Нормальный Адский прием.

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

данные пользователя, тогда прийдется сделать

еще механизм с передачей объекта.

 

Вот хотелось бы уйти от передачи данных приложения в процедуры обратного вызова.

 

 

Тут меня терзают смутные сомненья. Дал ты юзеру smart pointer,

потом по логике приложения этот элемент больше не нужен и

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

юзера есть на него ссылка. А потом юзер пытается что-то сделать, активировать этот ненужный/почти удаленый элемент, мы что ему на это скажем? Ну тот же пример с меню открытых окон, окно закрыли, пункт меню удалился, а у юзера на него (пункт меню) smart pointer, и он его захочет активировать, как быть?

 

После удаления объект переходит в состояние Destroyed. Попытка вызова любой его подпрограммы приведёт к возбуждению исключения. :)

 

А поскольку код реализации генерируется, то шанс обойти это поведение минимален.

 

 

--

Vadim Godunko

On Sat, Aug 06, 2005 at 09:46:47PM +0400, Vadim Godunko wrote:

Вот хотелось бы уйти от передачи данных приложения в процедуры обратного вызова.

 

Хорошо, пока не будем.

Вот еще один вопрос, который меня интресует. С простыми

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

более мение понятно. Хотя тоже, наверное нужено дать

юзеру способ указать функцию преобразования

числа/перечисления в строку. Тоже через формальную

функцию настраиваемого пакета? Или может через

переименование? Типа

 

with User_Data;

package My_GUI is

 

function Float_Format (X : My_Float) return Wide_String

renames User_Data.My_Format;

 

А вот как быть с более сложными типами для таких

хитрых виджетов, как Tree_View и Grid?

 

--

Maxim Reznik

Maxim Reznik wrote:

Вот еще один вопрос, который меня интресует. С простыми

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

юзеру способ указать функцию преобразования

числа/перечисления в строку. Тоже через формальную

функцию настраиваемого пакета? Или может через

переименование? Типа

 

with User_Data;

package My_GUI is

 

function Float_Format (X : My_Float) return Wide_String

renames User_Data.My_Format;

 

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

 

Например, может когда-то и будет разработан пакет поддержки I18N (или хотя бы I10N) для Ada, но пока его нет придётся или самому что-то писать или использовать стандартные функции. В той же Windows всё это есть часть операционной системы, а следовательно изобратать самостоятельно - глупо. В Linux поддержка почти есть, но устроенна она совершенно по другому. Для Web задача значительно усложняется, а именно, использовать стандартные функции никак не удасться, поскольку они, как правило, ориентированны на использовании только одной локали в рамках одного процесса, а ведь Web сервером могут пользоваться одновременно много пользователей из разных стран и с разными установками предпочтений.

 

А вот как быть с более сложными типами для таких

хитрых виджетов, как Tree_View и Grid?

 

Хотел оставить этот вопрос на засыпку... Но ты меня опередил.

 

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

 

А вот как быть с "поисковыми" формами? Когда открывается пустая форма, пользователь задаёт критерии, по которым производится поиск и в той же форме отображаются найденные данные?

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

On Mon, Aug 08, 2005 at 11:37:46AM +0400, Vadim Godunko wrote:

Maxim Reznik wrote:

function Float_Format (X : My_Float) return Wide_String

renames User_Data.My_Format;

 

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

 

Да, с числами - плохая идея. А может быть такой механизм

нужен для перевода литералов перечислимых типов в строки?

True/False - Да/нет, пользовательских перечислимых

типов. Или это сделать тоже через локализацию?

 

А вот как быть с более сложными типами для таких

хитрых виджетов, как Tree_View и Grid?

 

Хотел оставить этот вопрос на засыпку... Но ты меня опередил.

 

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

 

Т.е. описывать универсальный тип, который будет пониматься

всеми реализациями мы не хотим? А как тогда? Кормить грид

любыми массивами структур? Это хороший вариант для

заранее определенных типов данных, но тогда как быть с

заранее не известными структурами? Как сделать грид для

select * from aaa если структура aaa заранее не известна?

 

В Аде я бы для этого делал так:

 

type Data_Kinds is (String, Integer, Date, Float);

type Cell (Kind : Data_Kinds) is

case Kind is

when String => Text : Unbounded_String;

when Integer => Int : Integer;

...

type Cell_Array is array (Cell_Index range <>, Positive range <>) of Cell;

---- Наполнение грида:

procedure Add_Data_To_Grid (Data : Cell_Array);

 

Ой, мне уже страшно представить как подумаю писать такой умный

транслятор. :-o

 

Деревья, наверное, по сути теже гриды только со ссылкой

на родительскую запись. Наверное наполнение будет аналогично

гридам.

А вот как быть с "поисковыми" формами? Когда открывается пустая форма, пользователь задаёт критерии, по которым производится поиск и в той же форме отображаются найденные данные?

 

 

А что тут особенного? Колбек будет наполнять грид

найденными данными, аналогично тому как это будет

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

 

--

Maxim Reznik

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

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