Ada_Ru форум

Добрый день!

 

Исследую устойчивость потребительского спроса :)

 

Периодически возникаю дебаты на тему GUI. А посему вопрос: есть ли желающие хотябы косвенно участвовать в разработке GUI Builder для Ada?

 

Начальные требования к GUI Builder-у таковы:

 

1. Максимально независимая от архитекруты разработка (см. примечание)

 

2. Поддержка Gtk, Motif, Windows

 

Примечания.

 

1. Поскольку совершенно избавиться от зависимости не удалось ещё никому, предлагается изменить подход и разработать фактически несколько GUI Builder-ов, по одному для каждой архитектуры. Каждый builder будет позволять максимально использовать характерные для платформы возможности. Это кажется противоречащим требованию 1, однако если избавиться от непосредственного ручного программирования, а все подпрограммы обратного вызова формировать как обычные подпрограммы, с задаваемым пользователем набором параметров (а не типовые "виджет", "событие", "данные пользователя"), то, на мой взгляд, как раз можно достичь максимальной независимости от архитектуры.

 

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

 

3. Хорошо бы было подключить сюда и Web интерфейс, но не знаю как.

 

 

-- Vadim Godunko

Hello Vadim,

 

Tuesday, August 2, 2005, 8:49:02 PM, you wrote:

 

VG> Добрый день!

 

VG> Исследую устойчивость потребительского спроса :)

 

VG> Периодически возникаю дебаты на тему GUI. А посему вопрос: есть ли VG> желающие хотябы косвенно участвовать в разработке GUI Builder для Ada?

Есть.... и даже начинал вот клепать, правда далеко особо не ушел :( ... http://argo-khabarovsk.ru/guiAda.rar

 

 

 

 

--

Best regards,

Alexey mailto:lial@...

On Tue, Aug 02, 2005 at 08:56:35PM +1100, Alexey V. Litvinov wrote:

Hello Vadim,

 

Tuesday, August 2, 2005, 8:49:02 PM, you wrote:

 

VG> Добрый день!

 

VG> Исследую устойчивость потребительского спроса :)

 

VG> Периодически возникаю дебаты на тему GUI. А посему вопрос: есть ли VG> желающие хотябы косвенно участвовать в разработке GUI Builder для Ada?

Да, кстати, я бы поучаствовал...

 

--

Maxim Reznik

Hello Vadim,

 

Tuesday, August 2, 2005, 12:49:02 PM, you wrote:

 

Исследую устойчивость потребительского спроса :)

 

Только всеми рукамих - ЗА!

 

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

 

 

Я, кстати, полагаю, что с приходом эры GUI Аде пора обзаводиться

стандартной GUI библиотекой (консольный ввод/вывод ведь есть, не так ли?)

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

И еще я считаю, что GUI-библиотека Ады не должна строиться по принципу минимальной функционалности, а по принципу емуляции (релаизации

стредставами библиотеки) недостающих частей на отдельных платформах.

Пример: RTL Ады.

 

 

Это было б здорово!

 

--

Best regards,

Vladyslav

Hello Vladyslav,

 

Tuesday, August 2, 2005, 9:20:43 PM, you wrote:

 

VK> И еще я считаю, что GUI-библиотека Ады не должна строиться по принципу VK> минимальной функционалности, а по принципу емуляции (релаизации VK> стредставами библиотеки) недостающих частей на отдельных платформах. VK> Пример: RTL Ады.

VK> Это было б здорово!

 

В принципе Qt насколько я знаю так же сделана...

 

 

--

Best regards,

Alexey mailto:lial@...

Hello Alexey,

 

Tuesday, August 2, 2005, 1:40:42 PM, you wrote:

 

Hello Vladyslav,

 

Tuesday, August 2, 2005, 9:20:43 PM, you wrote:

 

VK>> И еще я считаю, что GUI-библиотека Ады не должна строиться по принципу VK>> минимальной функционалности, а по принципу емуляции (релаизации VK>> стредставами библиотеки) недостающих частей на отдельных платформах. VK>> Пример: RTL Ады.

VK>> Это было б здорово!

 

В принципе Qt насколько я знаю так же сделана...

 

и wxWidgets тоже. Но это не Ада. хотя идеи из этих библиотек надо "одалживать". уж больно удачно сделаны в них некоторые фичи.

 

:)

 

--

Best regards,

Vladyslav

Maxim Reznik wrote:

 

Да, кстати, я бы поучаствовал...

Итак, кворум собрался ;)

 

На повестке дня вопросы:

 

1. "Как Вы яхту назовёте, так она и поплывёт"... Как назвать?

 

2. Какие toolkit-ы поддерживать?

 

2.1. Потребности

 

Мне необходимо X/Motif.

 

2.2. Возможности

 

Смело могу взяться за X/Motif, с интересом - за Gtk.

 

3. Общая архитектура

 

Предлагаю сделать что-то типа языка описания, для обеспечения возможности генерации из него всего "глупого" кода. Создавать унифицированный язык - бесполезно. Можно остановиться на однотипных (ну что бы хоть синтаксис сходился) языках по одному для каждого поддерживаемого toolkit-а.

 

Из языка следует транслятор. Скорее всего - компилятор. Но уж точно что бы был независим от платформы, т.е. сгенерировать исходники под Windows можно было сидя в Linux. Своеобразнак кросс-компиляция.

 

Дизайнер. По одному для каждого toolkit-а. Точнее один, но с plugin-ами. :)

 

Библиотеку RTL. По возможности минимальную, но так не получится. Посему предлагается сначала сделать только то, без чего не обойтись - виджет. Библиотеку строить меньше всего заботясь о производительности, больше всего - об удобстве. Например, не оперировать ссылками, а облачать их в "умные" сслыки и т.д.

 

Пока всё :(

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Vladyslav Kozlovskyy wrote:

 

VK>> И еще я считаю, что GUI-библиотека Ады не должна строиться по принципу

VK>> минимальной функционалности, а по принципу емуляции (релаизации

VK>> стредставами библиотеки) недостающих частей на отдельных платформах.

VK>> Пример: RTL Ады.

VK>> Это было б здорово!

 

В принципе Qt насколько я знаю так же сделана...

 

и wxWidgets тоже. Но это не Ада. хотя идеи из этих библиотек надо

"одалживать". уж больно удачно сделаны в них некоторые фичи.

 

Я писал изначальное сообщение как раз после просмотра wxWidgets. Не потянуть нам такую сложную библиотеку, да и её возможностей никто и никогра реально использовать не будет.

 

То, что закладывается в подобные библиотеки значительно разумнее возложить на UI Builder. А если этот builder знает все тонкости нижележащей архитектуры, то он в состоянии сгенерировать почти идеальный код и вспомогательные файлы (ресурсы, локализации и др.)

 

В результате у программы можно достаточно спокойно поменять "фронтмордие" просто перерисовав внешний вид. И не только фронтмордие, но и вообще интерфейс, например, с Gtk на HTML.

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

On Tue, Aug 02, 2005 at 02:45:18PM +0400, Vadim Godunko wrote:

 

Смело могу взяться за X/Motif, с интересом - за Gtk.

 

Несмело могу поковырять GtkAda или за web,

интерестно было бы попробовать что такое Qt,

но страшно 8-)

3. Общая архитектура

 

Предлагаю сделать что-то типа языка описания, для обеспечения

возможности генерации из него всего "глупого" кода.

 

Это в чем будут сохранятся результаты тыканья мышкой

в GUI Builder-e?

 

Создавать

унифицированный язык - бесполезно.

Можно остановиться на однотипных (ну

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

поддерживаемого toolkit-а.

 

Ту я как-то не пойму. Нам по сути надо отписать иерархию

объектов, свойства каждого объекта и реакцию объекта

на действия пользователя. Это IMHO можно легко отписать

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

 

А может попробовать описать набор виджетов и их свойства?

Например чтоб набор виджетов для разных платформ был один

и их основные свойства, а то что спецфично для платформы,

пометить как платформозависимые свойства.

 

Ну типа меню, кнопочки, лейбы и тд.

 

 

Из языка следует транслятор. Скорее всего - компилятор. Но уж точно что бы был независим от платформы, т.е. сгенерировать исходники под Windows можно было сидя в Linux. Своеобразнак кросс-компиляция.

 

Дизайнер. По одному для каждого toolkit-а. Точнее один, но с plugin-ами. :)

 

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

 

Библиотеку RTL. По возможности минимальную, но так не получится. Посему предлагается сначала сделать только то, без чего не обойтись - виджет. Библиотеку строить меньше всего заботясь о производительности, больше всего - об удобстве. Например, не оперировать ссылками, а облачать их в "умные" сслыки и т.д.

 

Пока всё :(

--

Vadim Godunko

 

--

Maxim Reznik

Maxim Reznik wrote:

 

3. Общая архитектура

 

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

Это в чем будут сохранятся результаты тыканья мышкой

в GUI Builder-e?

 

Да.

 

Ту я как-то не пойму. Нам по сути надо отписать иерархию

объектов, свойства каждого объекта и реакцию объекта

на действия пользователя. Это IMHO можно легко отписать

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

 

Где-то так.

 

А может попробовать описать набор виджетов и их свойства?

Например чтоб набор виджетов для разных платформ был один

и их основные свойства, а то что спецфично для платформы,

пометить как платформозависимые свойства.

 

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

 

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

 

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

 

(PS Не забывайте, в отличии от C-шников, у нас есть ещё и ASIS, выловить которым платформозависимые вызовы - элементарно просто)

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

On Tue, Aug 02, 2005 at 03:12:26PM +0400, Vadim Godunko wrote:

 

То, что закладывается в подобные библиотеки значительно разумнее возложить на UI Builder. А если этот builder знает все тонкости нижележащей архитектуры, то он в состоянии сгенерировать почти идеальный код и вспомогательные файлы (ресурсы, локализации и др.)

 

В результате у программы можно достаточно спокойно поменять

"фронтмордие" просто перерисовав внешний вид. И не только фронтмордие, но и вообще интерфейс, например, с Gtk на HTML.

 

 

Сделать у описания интерфейса спецификацию/реализацию,

как у Ада модулей?

 

Чтобы в спецификации перечислить все от чего зависит

код/логика программы, а реализацию сделать подставляемой,

зависимой от платформы, генерящейся билдером?

 

Типа вот вам диалог для ввода значений, на котором

будут поля ввода даты, категории товар и цены и

программе больше ничего знать не надо, как хотите

так их и рисуйте, где хотите там и распологаяте.

--

Maxim Reznik

Hello Vadim,

 

Tuesday, August 2, 2005, 10:33:32 PM, you wrote:

 

VG> Многие примочки и способы решения задач настолько платформо зависимы, VG> что реализуются совершенно по разному. Пример: форма в Motif и Windows. VG> В Motif это ядрёный менеджер геометрии, пересчитывающий на лету VG> взаиморасположение виджетов. В конечном счёте в грамотной Motif VG> программе никогда не бывает каких либо значений положения и размеров VG> виджетов. В Windows - явно противоположная стратегия - необходимо задать VG> координаты и размер всех компонентов.

Никто нам не мешает написать для Win такой же менеджер... причем во всех ГУИ библиотеках он есть и для Win... и им очень удобно

пользоваться. То что его нету в WinAPI имхо упущение Мелкософта.

Вовсяком случае мое ИМХО закрывать глаза на его существование в Win-порте бессмыслено.

 

--

Best regards,

Alexey mailto:lial@...

Hello Vadim,

 

Tuesday, August 2, 2005, 3:04:56 PM, you wrote:

 

Maxim Reznik wrote:

 

Сделать у описания интерфейса спецификацию/реализацию,

как у Ада модулей?

 

Ну ты, блин, даёшь!

 

Я до столь простого и логичного формального опредления так и не додумался. ;)

 

 

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

Вот вам и ASIS пригодился как нельзя кастати. :)

 

Таким образом действительно можно создать нечто легкое и мощное одновременно.

--

Best regards,

Vladyslav

Maxim Reznik wrote:

 

Сделать у описания интерфейса спецификацию/реализацию,

как у Ада модулей?

 

Ну ты, блин, даёшь!

 

Я до столь простого и логичного формального опредления так и не додумался. ;)

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Hello Vladyslav,

 

Tuesday, August 2, 2005, 3:04:49 PM, you wrote:

 

Hello Vadim,

 

Tuesday, August 2, 2005, 3:04:56 PM, you wrote:

 

Maxim Reznik wrote:

 

Сделать у описания интерфейса спецификацию/реализацию,

как у Ада модулей?

 

Ну ты, блин, даёшь!

 

Я до столь простого и логичного формального опредления так и не додумался. ;)

 

 

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

Вот вам и ASIS пригодился как нельзя кастати. :)

 

Таким образом действительно можно создать нечто легкое и мощное одновременно.

 

Правда некто пару дней назад сильно возмущался вненшими

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

 

 

--

Best regards,

Vladyslav

Maxim Reznik wrote:

 

Чтобы в спецификации перечислить все от чего зависит код/логика программы, а реализацию сделать подставляемой,

зависимой от платформы, генерящейся билдером?

 

Типа вот вам диалог для ввода значений, на котором

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

так их и рисуйте, где хотите там и распологаяте.

Два момента.

 

1. Выделяем понятие спецификации интерфейса.

 

2. Сам интерфейс делим на три слоя:

 

- уровень реализации спецификации

 

- уровень управления состоянием

 

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

 

Реализация спецификации - самый верхний слой.

 

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

 

Вспомогательные коспоненты - те же компоненты, но с расширенными функциями. Например текстовое поле, но с подключенным фильтром ввода.

 

Как реализовывать второй и третий уровни для HTTP - не знаю. :(

 

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

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Vadim Godunko пишет:

 

Добрый день!

 

Исследую устойчивость потребительского спроса :)

 

Периодически возникаю дебаты на тему GUI. А посему вопрос: есть ли желающие хотябы косвенно участвовать в разработке GUI Builder для Ada?

 

Начальные требования к GUI Builder-у таковы:

 

1. Максимально независимая от архитекруты разработка (см. примечание)

 

2. Поддержка Gtk, Motif, Windows

 

Есть GLADE (однофамилец - http://glade.gnome.org/ ). Вроде работает и с GNAT.

 

-- С уважением,

Алексей Ю. Уласевич

(A.STAKANOV)

http://www.livejournal.com/users/a_stakanov/

Aleksey Ulasevich wrote:

 

Есть GLADE (однофамилец - http://glade.gnome.org/ ). Вроде работает и с GNAT.

 

К сожалению он поддерживает только Gtk. А интерес составляет как раз поддержка _любого_ toolkit-а.

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Hello Vadim,

 

Tuesday, August 2, 2005, 11:27:38 PM, you wrote:

 

VG> Как реализовывать второй и третий уровни для HTTP - не знаю. :(

за счет скриптов (сгнерерированых или идущих в комплекте GUI билдера) на JavaScript'е; силами одного HTML это не реализуешь.

 

 

 

--

Best regards,

Alexey mailto:lial@...

Hello Vadim,

 

Tuesday, August 2, 2005, 11:27:38 PM, you wrote:

 

 

VG> Как реализовывать второй и третий уровни для HTTP - не знаю. :(

пример в догонку

http://www.activewidgets.com/

 

 

 

--

Best regards,

Alexey mailto:lial@...

Мечта идота:

 

Window.ags (ada-gui-specification)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

with gui.label; use gui.label;

 

package Window is

 

Title : string := "Hello, Ada!"; -- препроцессор зацепится

-- за названия переменных

width : size := 400; -- Title, width, height

height : size := 200;

 

procedure MessageClick(...);

message : label := (left => 10,

top => 10,

caption => "Hello, Ada!",

OnClick => MessageClick,

others => <>); -- классная фича ADA-0Y :)

-- других процедур и атрибутов не указываем - препроцессор сам добавит -- недостающие и сгенерит пару: Windows.ads Windows.adb

--

-- Не удивлюсь, если препроцессор сгенерит на основе этого

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

end Window;

 

...

 

Window.agb (ada-gui-body)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

package body Window is

 

procedure MessageClick(...)is

begin

...

end MessageClick;

 

end Window;

 

...

 

main.adb

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

With Gui;

With Window;

 

procedure Main is

begin

Window.Show;

end Main;

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Что-то типа такого. Сильно не пинайте - три месяца, как слез с Delphi :)

а генрить всю эту хрень - например - guimake main

 

 

*.ags, *.agb должны легко парсится ASIS, я так полагаю...

 

 

Понимаю, что много недодумано, но - эдакие первые наброски для особо ленивых :)

 

 

--

Best regards,

Vladyslav