Ada_Ru форум

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

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

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

Сообщения

Maxim Reznik wrote:

 

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

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

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

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

 

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

 

Те же локали будут очень разные: от gettext, через Windows ка-то-там, до файлов ресурсов X Window.

 

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

кодогенератору создать всю необходимую навесуху.

 

 

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

всеми реализациями мы не хотим?

Конечно! Тем самым мы навязываем свой подход, от которого мы как раз и хотим сбежать!

 

А как тогда? Кормить грид

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

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

заранее не известными структурами?

Кто объявляет эти структуры данных? Программист? Так пусть и объясняет конкретному Grid-у или Tree как преобразовать структуру данных программы в представление Grid-а или Tree.

 

Как сделать грид для

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

 

Передав объект-результат выполнения SQL запроса :) Обычно любая

бибилиотека SQL клиента позволяет извлечь все необходимы данные.

 

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

 

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

А завтра: Long_Float, Timestamp, National_Character,

Geographical_Coordinates и ещё неведомо что? ;)

 

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;

Но в принципе, если тебе такой способ удобен, то можешь смело им

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

 

--

Vadim Godunko

Hello Vadim,

 

Monday, August 8, 2005, 5:40:08 PM, you wrote:

 

Maxim Reznik wrote:

...

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

всеми реализациями мы не хотим?

Конечно! Тем самым мы навязываем свой подход, от которого мы как раз и хотим сбежать!

 

Народ, я вот тут подумал: от универсального типа мы отказались, ага? А вот ежели надо задизеблить все контролы на форме типа:

 

for i in 1..Components_Count loop

Components(i).Enabled := false;

end loop;

 

то без универсального типа как? Или будут разные реализации под

разными платформами? Тоже, вроде, не очень хорошо получается :(

 

 

--

Best regards,

Vladyslav

Vladyslav Kozlovskyy wrote:

 

Народ, я вот тут подумал: от универсального типа мы отказались, ага? А вот ежели надо задизеблить все контролы на форме типа:

 

for i in 1..Components_Count loop

Components(i).Enabled := false;

end loop;

 

то без универсального типа как? Или будут разные реализации под

разными платформами? Тоже, вроде, не очень хорошо получается :(

 

Однозначно разные. :)

 

В Motif, например, достаточно отключить чувствительность общего родителя. :)

Hello Vadim,

 

Tuesday, August 9, 2005, 6:35:50 PM, you wrote:

Vladyslav Kozlovskyy wrote:

 

Народ, я вот тут подумал: от универсального типа мы отказались, ага? А вот ежели надо задизеблить все контролы на форме типа:

 

for i in 1..Components_Count loop

Components(i).Enabled := false;

end loop;

 

то без универсального типа как? Или будут разные реализации под

разными платформами? Тоже, вроде, не очень хорошо получается :(

 

Однозначно разные. :)

 

В Motif, например, достаточно отключить чувствительность общего родителя. :)

В Windows, кажется тоже.

 

Пример не очень удачный (может такой лучше: отключить, например, только все checkbox-ы)

 

Но тут получится, что логика тоже становится зависимой от платформы. Фактически надо будет всегда пересматривать не только интерфейс но и всю логику, которая его поддерживает.

 

 

А что, если сделать так:

 

1. Описываем суперсет контролов, атрибутов и ивентов, какие только могут быть при описании

GUI на разных платформах (конечно это процесс итерационный и протяженный во времени, но со

временем можно будет собрать наиболее полную коллекцию)

 

2. Кучкуем их по выполняемым действиям и даем им одно имя (тут

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

н.п.

Виджеты:

CheckBox

EditBox

Label

...

 

XWinExtendWidget

DataTimePicker

SimpleGrid

ComplexGrid

 

Атрибуты:

Enable - разрешить взаимодействие с контролом/виджетом

Show - показать на екране

Hide - спрятать и т.д.

 

Ивенты:

OnClick

OnDblClick

OnEnter

OnLeave

...

 

(напомиманю, работаем пока только с именами, а не с реальными

обьектами)

 

3. Напротив каждого имени проставляем название платформы, на которой этот виджет/атрибут/ивент имеет смысл:

 

CheckBox => All (NCurses, Win, Mac, XWin, ... )

CheckBox.Enabled => All

CheckBox.OnClick()=> All (но могут быть разные сигнатуры параметров) CheckBox.Color => All (но могут иметь разные по структуре)

CheckBox.Font => All Graphics ( all except NCurses );

 

...

XWinExtendWidget => XWin

DataTimePicker => Win32

SimpleGrid => Win32, Mac, XWin

ComplexGrid => Mac, XWin

...

PictureButton => All Graphics ( all except NCurses)

PictureButton.OnClick => All Graphics

 

и т.д...

какие-то атрибуты/виджеты/ивенты будут иметь смысл только в одной из систем, другие будут доступны на всех платформах

 

4. Для каждой платформы пишется свой ОО слой, реализующий

обьекты/атрибуты/ивенты согласно списку (чем тоньше, тем лучше). Для некоторых дописывается свои расширения (ActiveX/COM/ADO для Win32, например)

 

Причем все иерархии для каждой из платформ могут быть НЕЗАВИСИМЫМИ в своем описании (каждая наследуется от своего root-класа). Сходство только статическое (по имени)

 

Use Motif;

 

...

 

cbEnablePasswordCheck : CheckBox; // derived from Motif.MotifWidget

b := cbEnablePasswordCheck.Enabled;

 

a := cbEnablePasswordCheck.MotifSpecificAttribute;

 

...

 

-----------

 

Use Win32;

 

...

 

cbEnablePasswordCheck : CheckBox; // derived from Win32.Wi32Control

b := cbEnablePasswordCheck.Enabled;

 

a := cbEnablePasswordCheck.Win32SpecificАttribute;

 

...

 

 

Use NCurses;

 

...

 

cbEnablePasswordCheck : CheckBox; // derived from NCurses.NCursesControl

...

 

База данных, собранная на етапах 1..3 доступна GUIBuilder-у таким образом выбрав одну из платформ получаешь полный набор

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

 

Желательно было бы использовать стандартные типы Ады и придерживатся схожих сигнатур параметров для одноименных методов/ивентов, если

только так получится...

 

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

 

 

 

Можно еще, правда, делать унифицированную реализацию на скриптовом языке (типа: "disable all checkboxes"), а потом его парсить под определенную платформу, но тут

тоже много подводных камней...

 

 

--

Best regards,

Vladyslav

Народ! Вы фигнёй страдаете. Смотрите реализацию look&feel для Metal, Motif, WindowsXP, Aqua в Java Swing/JFC. Там уже нет тормозов.

 

Vladyslav Kozlovskyy пишет:

iZEN wrote:

Народ! Вы фигнёй страдаете. Смотрите реализацию look&feel для Metal, Motif, WindowsXP, Aqua в Java Swing/JFC. Там уже нет тормозов.

 

Немного не понял... А причём здесь look&feel?

 

Уточню, что здесь идёт о разработке инфраструктуры для создания

интерфейсов пользователя, причём обеспечивающей независимость ядра приложения от конкретной платформы интерфейса.

 

 

--

Vadim Godunko

Vladyslav Kozlovskyy wrote:

 

Но тут получится, что логика тоже становится зависимой от платформы. Фактически надо будет всегда пересматривать не только интерфейс но и всю логику, которая его поддерживает.

 

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

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

 

1. Описываем суперсет контролов, атрибутов и ивентов, какие только могут быть при описании

GUI на разных платформах (конечно это процесс итерационный и протяженный во времени, но со

временем можно будет собрать наиболее полную коллекцию)

 

Не согласен, однако предложение имеет смысл в части формирования списка виджетов, поддерживаемых каждой из платформ.

 

Завтра обязуюсь подготовить таковой для Motif.

 

 

Можно еще, правда, делать унифицированную реализацию на скриптовом языке (типа: "disable all checkboxes"), а потом его парсить под определенную платформу, но тут

тоже много подводных камней...

 

Надо подумать...

 

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

 

Как пример:

 

- создание статических иерархий всплывающих/выпадающих меню. Задача достаточно типовая, можно попробовать унифицировать решение.

 

- контроль за локализацией приложения. Задача так же достаточно типовая.

- очень интересно придумать что-то для создания компонента управления состоянием виджетов в рамках диалога. Ещё более интересная задача - верификация разработанного решения.

 

 

--

Vadim Godunko

On Tue, Aug 09, 2005 at 10:36:28PM +0400, Vadim Godunko wrote:

Vladyslav Kozlovskyy wrote:

1. Описываем суперсет контролов, атрибутов и ивентов, какие только могут быть при описании

GUI на разных платформах (конечно это процесс итерационный и протяженный во времени, но со

временем можно будет собрать наиболее полную коллекцию)

 

Не согласен, однако предложение имеет смысл в части формирования списка виджетов, поддерживаемых каждой из платформ.

 

Завтра обязуюсь подготовить таковой для Motif.

 

 

Хочу предложить общий формат для описания компонент разных

тулкитов. Это позволит построителю GUI как-то обрабатывать

файлы даже для не родных платформ.

 

Я бы предложил вести это дело в XML. Вот с таким DTD:

<!ELEMENT toolkit (descr*, class*) >

<!ATTLIST toolkit

name CDATA #REQUIRED >

 

<!ELEMENT descr (#PCDATA)>

<!ATTLIST descr

lang CDATA #REQUIRED >

 

<!ELEMENT class (property*, event*, descr*, class*) >

<!ATTLIST class

name CDATA #REQUIRED >

 

<!ELEMENT property (descr*) >

<!ATTLIST property

name CDATA #REQUIRED

type CDATA #REQUIRED

access (r|w|rw) "rw" >

 

<!ELEMENT event (descr*) >

<!ATTLIST event

name CDATA #REQUIRED >

 

Т.е. тулкит - это описание классов компонент.

Класс содержит описания свойств, событий и

порожденных классов. Порожденный класс наследует

все свойства и события предка. Свойства имеют

тип данных и режим доступа чтение и/или запись.

В любой элемент можно вставлять краткие описания

descr.

 

Если чего-то не будет хватать, расширим.

 

--

Maxim Reznik

Вот попробовал собрать в кучу

 

Описание построителя GUI

 

Назначение построителя GUI заключается

- в облегчении

разработки приложений со сложным интерфейсом

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

платформах (Motif, Gtk, NCurses, Web).

- в облегчении портирования приложений

между поддерживаемыми платформами.

 

В виду сильной зависимости реализации интерфейса

от целевой платформы, довольно трудно обеспечить

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

скрывающий платформенные

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

В системах с универсальным набором компонент

внешний вид программы на разных платформах

может сильно отличаться от принятого на

этих платформах.

 

С другой стороны зачастую программе не нужно

знать всех тонкостей реализации интерфейса, а

достаточно предоставить данные для отображения

и среагировать на реакцию пользователя.

Строго оговорив взаимодействие программы и

интерфейса, в дальнейшем, каждая составляющая

может развиваться независимо от другой.

Например интерфейс может быть усовершенствован

или портирован на другую платформу без

изменения текста логики программы.

 

Программе удобнее предоставлять данные для

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

При этом сами типы зачастую довольно точно

зарактеризуют данные, обрабатываеммые приложением.

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

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

вводимых пользователем значений.

 

Четкая спецификация интерфейса программы может

быть использована для автоматизации тестирования

логики и реализации интерфейса.

 

Интерфейс программы удобно рассматривать ввиде

набора компонент интерфейса. Компоненты

могут содержаться друг в друге, и, таким образом,

объединяются в иерархии (дочерние компоненты

содержатся в родительских). Компоненты имеют

свойства меняющиеся в процессе выполнения

программы. Интерейс может представлять

собой статический набор компонент либо

компоненты могут создаваться и уничтожаться

со временем.

 

Рассмотрим принципы построения

спецификации интерфейса.

 

Такая спецификация интерфейса может быть

выражена в виде спецификации пакета на

языке Ада.

 

Чтобы отделить пакеты спецификации интерфейса

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

GUI. Компоненты верхнего уровня (не имеющих

родителей) описываются в отдельных пакетах.

Если в процессе работы предпологается существование

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

в пакете определяется тип - ссылка на компонент.

С помощью значений данного типа программа может

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

Тип должен быть прямым наследником типа

GUI.Component. Работа с компонентом осуществляется

при помощи примитивных операций данного типа.

Создание и удаление компонента, изменение его

атрибутов.

 

Если предпологается существование единственного

екземпляра, тип не применяется и работа

с компонентом ведется при помощи обычных подпрограм

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

 

Чтобы предоставить интерфейсу методы оповещения

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

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

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

 

Спецификация интерфейса задает дает большой простор

для его реализации. Описание реализации интерфейса

под конкретную платформу хранится в отдельном файле

в своем формате.

 

Процесс построения приложения может прозодить так:

1) Построение описания интерфейса в виде спецификации

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

2) Построение реализации интерфеса для одной из

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

3) Генерация исполняемого кода по файлу реализации

интерфейса

4) Сборка прикладной части программы с кодлм интерфейса

 

Предопределенный пакет GUI:

 

package GUI is

type Component is private;

private

...

end;

 

пакет_описания_интерфейса :=

context_clause package_declaration

| context_clause generic_package_declaration;

 

1) Д.б. в иерархии GUI.

2) package_declaration должен быть пустым

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

3) не содержит private части

4) basic_declarative_item только элемент_описания

5) generic_formal_part_item только реакция_интерфейса

 

элемент_описания :=

-- описание типа ссылки на компонент

type Component_Type is new GUI.Component;

-- установка свойств

| procedure Name (Object : Component_Type; Value : User_Type);

| procedure Name (Value : User_Type);

-- чтение свойств

| function Name (Object : Component_Type) return User_Type;

| function Name return User_Type;

-- создание компонента

| function Create return Component_Type;

| function Create (Object : Component_Type) return Component_Type; -- Управление компонентом

| procedure Name (Object : Component_Type);

| procedure Name;

 

реакция_интерфейса :=

with procedure Name

| with procedure Name (Object : Component_Type);

 

 

--

Maxim Reznik

Hello Maxim,

 

Wednesday, August 10, 2005, 1:54:05 PM, you wrote:

 

Вот попробовал собрать в кучу

 

Описание построителя GUI

 

Назначение построителя GUI заключается

- в облегчении

разработки приложений со сложным интерфейсом

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

платформах (Motif, Gtk, NCurses, Web).

- в облегчении портирования приложений

между поддерживаемыми платформами.

 

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

разработать не что иное, как патеррн(ы) унифицированного построения GUI интерфейса? а билдер так, для прикрытия? :)

 

 

 

--

Best regards,

Vladyslav

On Wed, Aug 10, 2005 at 03:47:29PM +0300, Vladyslav Kozlovskyy wrote:

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

разработать не что иное, как патеррн(ы) унифицированного построения GUI интерфейса? а билдер так, для прикрытия? :)

 

 

Где почитать про такой патеррн?

 

--

Maxim Reznik

Hello Maxim,

 

Wednesday, August 10, 2005, 4:23:58 PM, you wrote:

 

On Wed, Aug 10, 2005 at 03:47:29PM +0300, Vladyslav Kozlovskyy wrote:

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

разработать не что иное, как патеррн(ы) унифицированного построения GUI интерфейса? а билдер так, для прикрытия? :)

 

 

Где почитать про такой патеррн?

 

 

А его и нету :))) Мы его сами выдумываем :)))

 

--

Best regards,

Vladyslav

Vladyslav Kozlovskyy wrote:

 

>Где почитать про такой патеррн?

 

А его и нету :))) Мы его сами выдумываем :)))

 

Ну вот... А я уж подумал мы велосипед изобретаем... :(

 

Хотя, чем дальше в лес, тем всё больше я не понимаю - то ли мы такие умные, то ли что-то здесь ни так. Ну почему нет подобных готовых решений?

 

--

Vadim Godunko

Maxim Reznik wrote:

 

Тут я не понял.

Если программа будет взаимодействовать с интерфейсом в обход

описания интерфейса, так зачем тогда нам это описание?

Если реалиация как-то обрабатывает какие-то действия

пользователя самостоятельно, так это ее право, и на

"основную" часть это влиять не будет.

 

Остановимся пока на generic. ОК?

 

 

Я хотел формализировать правила описания интерфейса.

Я с этим согласен :)

 

 

Нам нужно как-то ограничить содержимое пакета описания тем,

что наши билдеры в состоянии построить автоматически.

Если юзера начнут пихать в описания всякие задачи и

протектед объекты, билдер этого явно не поймет.

 

Задачи и защищенные объекты - однозначно нафиг.

 

В принципе можно разрешить в описании любые конструкции

не требуещие completion плюс подпрограммы. Может так

будет лучше?

 

Вполне.

 

 

--

Vadim Godunko

Hello Vadim,

 

Wednesday, August 10, 2005, 9:45:31 PM, you wrote:

 

Vladyslav Kozlovskyy wrote:

 

>Где почитать про такой патеррн?

 

А его и нету :))) Мы его сами выдумываем :)))

 

Ну вот... А я уж подумал мы велосипед изобретаем... :(

 

Хотя, чем дальше в лес, тем всё больше я не понимаю - то ли мы такие умные, то ли что-то здесь ни так. Ну почему нет подобных готовых решений?

 

 

Есть уже билдеры дизайн паттернов? Кажись нету :(

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

А то че мы тут пытаемся соорудить (каждая GUI платформа сама по себе, но схожие идеи организации программы) есть ничто иное, как дизайн паттерн.

 

Паттерн, так паттерн:

 

Я пока вижу такие его части (которые мы пытаемся свести вместе):

 

I. Есть данные приложения в терминах приложения;

II. Есть проекция данных на GUI форму в терминах GUI;

III. Есть некий промежуточный уровень (Ёнтерфейс?) между I и II;

IV. Есть некий монитор (машина состояний?) следящий/управляющий GUI формой (enable/disable елементов формы, контроль вводимых

пользователем данных, подсказки пользователю, динамическое изменение GUI формы и т.д.) Его цель - непротиворечивые и неделимые данные.

Я вижу такой порядок работы подобного паттерна:

1. Создание GUI форм(ы)

2. Цикл:

а. Инициализация форм(ы) исходными данными;

б. GUI-транзакция взаимодействия с пользователем. Цель транзакции - получить непротиворечивые данные на выходе интерфейса;

в. получение новых данных из форм(ы) в программу;

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

 

Судя по обсуждениям сейчас обсуждается только вопрос II и, частично, III. Тогда, как для действительно полного интерактивного взаимодействия с пользователем надо, на мой взгляд больше внимания обратить на вопрос IV.

На мой взгляд для реализации монитора в этом паттерне не вредно

обратить внимание на такие особенности Ады, как защищенные типы и задачи.

 

Специалисты, агоу! Ваше слово!

 

--

Best regards,

Vladyslav

On Wed, 10 Aug 2005 22:45:31 +0400, Vadim Godunko <vgodunko@...> wrote:

 

Vladyslav Kozlovskyy wrote:

 

Где почитать про такой патеррн?

 

А его и нету :))) Мы его сами выдумываем :)))

 

Ну вот... А я уж подумал мы велосипед изобретаем... :(

 

не исключено.

 

 

Хотя, чем дальше в лес, тем всё больше я не понимаю - то ли мы такие

умные, то ли что-то здесь ни так. Ну почему нет подобных готовых решений?

 

всяких разных специализированных языков существовало еще в 70е несколько

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

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

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

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

 

 

Давайте лучше сразу отделим мух от котлет :)

Вообще, я смотрю что последнее время в стандарт Ады тянут вообще

все подряд что смогут найти и прикрутить(в тч и вредные "новинки"),

кроме разве что того что совсем не клеится или ухудшает надежность...

Наверное, так и должно быть - все-же язык делается один на все случаи,

да и иногда это полезно, хотябы в целях совместимости с другими языками...

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

Намек понятен? ;)

Проще говоря, не следует думать что если что-то сделано на Аде

и даже стандартизированно это самое лучше и правильное решение - скорее

наоборот, просто сделано в целях совместимости с существующими де-факто

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

библиотек.

Тоесть предлагаю обсуждая что-то не путать разные вещи и сразу

разделять и указывать об чем речь - как сделать "сдесь и сейчас из того

что есть под рукой" и "как это вообще должно бы быть и чего хочется".

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

что какой-то из них более лучший или более правильный - может быть

и одинаково, в этом случае просто выбрать какой-то один для стандартности)

 

 

Насколько я понял, реч шла о том чтобы сделать некую

стандартизированную надстройку над разными вариантами GUI библиотек.

В этом случае говорить о чем-то "более правильном" не имеет смысла,

а задачу придется решать на основе того что есть. Тоесть "снизу вверх",

и из этого получиться не что-то "более правильное", а просто что-то

совместимое со всеми. (нет смысла что-то выдумывать такое, что не сможет

выполнить целевая платформа) В общем тут можно только выделить общую

часть из всех библиотек и попытаться на этом слепить что получиться.

(ну кое-какие функции можно еще дополнить в самой библиотеке если

их нет, но опять-таки через те что есть. Так что если чем-то готовые

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

что-то написать свое, IMHO)

 

Вот со стороны самого описания интерфейса привязка не столь жесткая,

тут есть возможность попробовать придумать что-то более правильное

и удобное. (Тоесть фактически попробовать придумать какой-то язык

более высокого уровня для описания интерфейсов или тп)

Тоесть тут имеет смысл начать "сверху вниз"(ну потом

конечно с оглядкой на возможность реализации) и попробовать

определиться с тем что же на самом деле хочется, тоесть тут можно

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

чем использование существующих библиотек. Думаю понятно что этот

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

 

 

Vladimir

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

On Sun, Aug 14, 2005 at 09:50:55PM +0600, teplouhov@... wrote:

Тоесть предлагаю обсуждая что-то не путать разные вещи и сразу

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

Так мы этим и занимаемся, тк. то что есть это совсем не то, что

хочется 8-)

 

 

Насколько я понял, реч шла о том чтобы сделать некую

стандартизированную надстройку над разными вариантами GUI библиотек.

Как я понял речь шла совсем в обратном направлении, чтобы

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

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

который будет запускаться одни раз при портировании с X на Y,

и создавать какое-то жалкое подобие интерфейса, основу

для последуующего улучшения.

 

[skip]

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

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

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

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

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

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

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

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

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

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

 

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

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

 

 

 

 

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

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

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

 

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

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

который просто выстраивал такую иерархию из заданного набора

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

зависимой частью осталось бы какое-нибудь окошко "preview".

Ну и трансляторы из этого формата в Ада программу конечно.

 

Кроме этого нужно придумать способ описания реализации заданного

интерфейса с программой. Простейший способ - юзер сам пишет

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

Чтобы "продвинутый" пользователь наредактировал потом этот

файл и пристовал с дурацкими вопросами "почему все сломалось"?

 

 

Vladimir

 

--

Maxim Reznik

On Sun, 14 Aug 2005 21:40:05 +0300, Maxim Reznik <yeo@...> wrote:

On Sun, Aug 14, 2005 at 09:50:55PM +0600, teplouhov@... wrote:

Тоесть предлагаю обсуждая что-то не путать разные вещи и сразу

разделять и указывать об чем речь - как сделать "сдесь и сейчас из того

что есть под рукой" и "как это вообще должно бы быть и чего хочется".

Так мы этим и занимаемся, тк. то что есть это совсем не то, что

хочется 8-)

 

 

ну дак значит надо начать с другого варианта - попробовать понять

что бы вообще хотелось(тоесть что можно сделать не так как сейчас

сделано во всех платформах). Тоесть как бы хотелось чтобы это

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

 

Основное требование к ЯВУ - именно удобство и понятность для

программиста. Ну а дальше уже надо сопоставить желания и реальности

и выбрать что-то оптимальное...

 

(ну это вмысле подумать над чем-то принципиально другим,

что-то мне например имеющиеся либы не показались удобными

и понятными. Может какой-то спецязык описания интерфейса,

может наоборот что-то вроде старого генератора меню для

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

 

 

 

Может имеет смысл упростить использование при написании?

Не понимаю почему использование гуя сложнее чем обычный

текстовый ввод.

Меня например и на паскале несколько напрягало писать

кучу writeln('введите то-то'); readln(s) и обработок

чего там юзер ввел не так... Мне это показалось сложно,

и у меня была либа по-проще :) Тоесть пишешь типа

"хачу вот это значение такого-то типа", и все. Тоесть

типа GetPrm(i) или EditStr(s), и все, ну а внутри процедуры

кроме редактора строки еще и что-то вроде калькулятора

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

простое выражение и она сама его посчитает. Можно

и с переменными, тогда после ввода выражения еще и спрашивала

чему равны эти переменные - но это делала сама процедура

и в программе было пофиг, та получала готовое что хотела

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

 

Может что-то на эту тему со стороны программы, тоесть

чтобы проще было писать? Ну а недостающие можно и потом

дописать или по умолчанию установить параметры и пускай

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

окон, например)...

 

Кстати не вижу проблем скрестить гуй и режим командной

строки. Тоесть программой может вызываться одна процедура

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

и в зависимости от ключей при запуске, драйверов и погоды

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

либо в окне гуя, либо ваще через RS232 для embedded

применений. Для программы пофиг - она вызывает одну и ту-же

процедуру типа ХачуВводаЗначенияЦелогоТипа(), например, и все.

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

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

размера и координат окон, цветов и тд и тп - вот это наверно

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

и не мешало думать над логикой программы, а не размером окон)

 

Так-же можно где-то в файле сохранять не только размеры

и цвета окон, но и введенные последний раз значения

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

по умолчанию чтобы не вводить по новой и тд и тп...

(в общем напрашивается идея что гуй или редактор строки

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

или процесса, с которым идет взаимодействие программы.

Тут в общем надо позаботиться только об единой идентификации

параметров чтобы не было путанницы, и все, других проблем

нет - они все в другом модуле ;) )

 

 

 

Насколько я понял, реч шла о том чтобы сделать некую

стандартизированную надстройку над разными вариантами GUI библиотек.

Как я понял речь шла совсем в обратном направлении, чтобы

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

 

это не избежно - либо использовать только общее,

либо переделывать и сами платформы.

 

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

который будет запускаться одни раз при портировании с X на Y,

и создавать какое-то жалкое подобие интерфейса, основу

для последуующего улучшения.

 

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

высокого уровня, по которому уже генерить реализации. Но это

если только такой язык даст какие-то значительные улучшения,

иначе нет смысла плодить лишнии сущности.

 

По-простому портироваться будет только общая часть.

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

 

 

[skip]

чем использование существующих библиотек. Думаю понятно что этот

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

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

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

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

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

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

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

 

я бы не стал это связывать с Адой - у нее наоборот нет кривых фич,

они-то как раз и выкинуты ;)

 

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

 

вот надежность и тп это уже другое дело, но тоже не сильно

связанное именно с Адой. Скорее только с кривыми руками

(и мозгами ;) ).

 

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

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

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

 

в компьютере могут существовать только коды.

Любой тип все равно будет преобразован в коды.

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

сделает сам компилятор или надо руками)

 

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

 

зато у Цников хорошо развито понимание кодирования данных.

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

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

как-то закодировать реальные объекты этими байтами, и все,

дело в шляпе.. ну тоесть в компютере :)

 

Любой другой язык делает то-же самое - других способов

просто нет. Тоесть тут разница не большая - либо

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

общий пакет где это сделает компилятор, и все, другой

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

 

Кодом может быть как адрес процедуры, так и явный

код-идентификатор какого-то пункта меню или параметра.

Можно и так и так, но я что-то склоняюсь ко явному

коду-идентификатору. Тоесть например:

 

можно так(а):

 

InputVarA();

InputVarB();

и тд.

 

а можно так(б):

 

InputVar(Var_A_ID, ...)

InputVar(Var_B_ID, ...)

 

 

Если на одной машине то без разницы, но второй вариант

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

по сети или RS232 на другую машину с гуем, а там

идентификация по адресу процедуры уже не доступна...

 

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

выбора меню - при выборе передавать только этот

код и нет проблем. (можно еще подумать насчет

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

пункта, но что-то мне это не очень нравиться)

 

От Ады тут пожалуй можно использовать только вот

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

а сделать тип перечисление и использовать один

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

символьные значения...

 

 

У глобального идентификатора есть большой

плюс - можно уже потом как угодно кроить

даже структуру самого меню - например,

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

в другое, и все будет работать тк коды

не изменяться...

 

 

 

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

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

 

 

для автогенератора фичи Ады нафиг не нужны - он может

хоть напрямую генерить машинный код или двоичные данные.

Всякие фичи в Аде только для удобства программиста - вроде

возможности указать явно имя и '=>' и тд и тп. Автогенератору

пофиг абсолютно - он и так не перепутает последовательности

параметров. Каких-то фич другого типа я что-то не припомню ;)

(ну всмысле чтобы это давало какие-то преимущества если

использовать)

 

 

 

 

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

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

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

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

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

 

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

Хотелось бы определится с форматом реализаций GUI.

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

 

вот чего бы мне хотелось глядя на существующую иерархию меню - это

поисковик по меню. Тоесть догадаться что например в оркаде пункт

записи файла засунули в подменю quit думаю мало кто сможет

(я например не смог - пол-часа шарился по менющкам, а нашел

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

хотя с точки зрения скорости это наверно и более правильно...

Поисковик по всем пунктам меню и описаниям помог бы кардинально :)

 

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

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

который просто выстраивал такую иерархию из заданного набора

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

зависимой частью осталось бы какое-нибудь окошко "preview".

Ну и трансляторы из этого формата в Ада программу конечно.

 

генерить надо только связку с кодами-идентификаторами,

движок может и вообще отдельно работать и никогда не меняться.

 

 

Кроме этого нужно придумать способ описания реализации заданного

интерфейса с программой. Простейший способ - юзер сам пишет

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

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

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

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

 

движок можно вообще написать один раз и забыть.

(несколько вариантов под разные платформы)

Кстати можно наверно и через веб-морду так меню рисовать

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

будет так-же как будто все на одном компютере...

 

 

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

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

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

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

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

 

пофиг. Обе части должны использовать одну таблицу

кодов, и только. (кстати можно коды вроде exit/save/auto/

stop и тп вообще стандартизировать - тогда в случае

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

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

режим управления. Актуально при разбивании экрана

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

например. Или перейти на другой пульт управления по сети

или в режим текстовых команд. Кстати надо подумать еще

насчет совместимости гуя и текстовых команд)

 

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

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

 

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

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

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

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

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

 

Чтобы "продвинутый" пользователь наредактировал потом этот

файл и пристовал с дурацкими вопросами "почему все сломалось"?

 

дак я на что и намекаю - должно быть несколько частей описания.

Часть вообще защищенная от любых изменений(особенно вумными

препроцессорами :) ), другая редактируемая, ну и похоже должна

быть еще одна вообще с переменными где сохраняются параметры

окон пользователя и тп настройки.

По вкусу :) можно писать в любой части - в зависимости от того

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

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

"сделай сам себе меню" вплоть до того что нельзя переопределить

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

Ну а ломаться тут не чему - максиум что может быть, это что

пользователь задвинет окно куда-нить за зону видимости или

(кстати я бы еше хотел чтобы все внутренние структуры данных

были доступны для просмотра и/или редактирования чем-то

вроде встроенного HexEditor или лучше отладчика - тогда будет

ваще круто - можно будет как "двигать мышой", так и сразу задать

координаты или код цвета числом)

раскрасит текст и фон в один цвет - вот тут не знаю, или это

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

на диапазоны параметров ввести... Главное чтобы коды были одни,

а там пускай хоть через гуй из вводит, хоть с ИК пульта через

RS232 - его проблемы, пускай сам выбирает источник и вид управления.

 

Vladimir

PS Единственное хорошее свойство окон - пофиг что там было

на экране до этого - всегда можно вызвать оконную программу,

она сохранит и восстановит экран за собой после выхода...

Все остальное какой-то раздутый изврат - из ничего сделали

такую большую и кривую муху :)

 

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

teplouhov@... wrote:

 

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

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

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

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

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

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

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

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

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

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

 

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

 

 

Vladimir

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

Указанное свойство Win98 негативно сказывается именно на безопасности использования, а не на надежности. Кстати, это проблема любых многооконных оболочек. Даже таких проверенных монстров, как X Window.

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

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

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