roboforum.ru

Как эти железочки решают проблему описания GUI и стыковки GUI с функциональностью девайса?

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

А если требуется простое и быстрое решение - GUI очень просто описывается на XML. Один раз компилится на микроконтроллере в байткод, а дальше гоняет его с большей скоростью. Более удобного описания для GUI чем XML - не видел.

Повторяю.

forum7/topic10378-15.html#p216684

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

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

- GUI не отделен от программирования, хотя и отделен от основного функционала.

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

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

Что тут непонятного?

Так в чем проблема на XML описать и прописать нужные callback'и?

Это один из подходов. Он не единственный.
Недостатков у него полно - выше писал - почитайте. К тому же одними коллбэками обойтись точно не удастся.

Да читал, только вот "полно недостатков" не нашел. Так что все-таки нужно: простой язык описания GUI или скриптовую систему, которая заменит программирование GUI + логику работы самого устройства на основе native API?

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

С тем же успехом отделить от основного функционала можно и обычный Си код.

2. Чистый язык описания интерфейса. Все функции делает встроенное ПО, которое загружает с карточки только параметры предопределенных объектов.

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

Супер-вариант - воткнуть Андроид на устройство. =)

Michael_K писал(а):Интерфейс нужно не только описать, нужно иметь механизм, который связывает интерфейс с остальными функциями

Так где отделение то? Тут как раз связывание. Сделать на Lua и не морочить людям голову!
Dixi

Strijar писал(а):Сделать на Lua и не морочить людям голову!

Виталий писал(а):С тем же успехом отделить от основного функционала можно и обычный Си код.

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

Виталий писал(а):2..
Это хороший вариант, но только в случае если язык описания интерфейса будет общепринятым... например HTML (пусть и ограниченный). Кроме того логика работы устройства частично регулируется переходами между страницами.

Это, действительно, хороший вариант, но интерфейс сразу получаетсятся _очень_ жестким.
И организация взаимодействия кода с интерфейсом очень невнятна.
В HTML, например, взаимодействие сервера со страницей делается всякими чужеродными "костылями"
(аджаксы, объекты типа флэш-плейер, экшн-скрипты и т.п.).

Аналогия сервер-клиент - очень хороша.
С той лишь разницей, что в случае единого девайса можно пользоваться преимуществами типа общей памяти и т.п.
Это именно то, в чем загвоздка - где провести границу между "клиентом" и "сервером".

Добавлено спустя 32 минуты 12 секунд:
Вот, кстати, девайс, если интересно (качество, правда, телефонное)

В HTML, например, взаимодействие сервера со страницей делается всякими чужеродными "костылями" (аджаксы, объекты типа флэш-плейер, экшн-скрипты и т.п.).

Да, поэтому придуман XAML - там есть биндинги.

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

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

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

Там же где проведена граница в http://ru.wikipedia.org/wiki/Model-View-Controller
Это вопрос архитектуры.

Виталий писал(а):Супер-вариант - воткнуть Андроид на устройство. =)

Как это решит проблему?
Я не знаю, как устроен API к GUI в андроиде - может быть там что-то интересное есть?

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

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

Добавлено спустя 3 минуты 1 секунду:

Виталий писал(а):

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

Там же где проведена граница в http://ru.wikipedia.org/wiki/Model-View-Controller
Это вопрос архитектуры.

Правильно.
Но от общих слов, все же хочется двинуться к реализации
Кроме того, в общем виде "Отображение" это все-таки программа, которая оперирует данными "Модели",
а значит дизайнеру интерфейса нужно дать язык программирования. Этого очень хотелось бы избежать.

С андроидом все просто, там есть браузер с полноценным HTML/Javascript, там есть Flash - можете нанять любого дизайнера.

Добавлено спустя 1 минуту 9 секунд:

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

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

Виталий писал(а):С андроидом все просто, там есть браузер с полноценным HTML/Javascript, там есть Flash - можете нанять любого дизайнера.

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

Виталий писал(а):надо подробно смотреть назначение прибора, способ его применения и т.д.

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

Я могу более-менее описать те элементы (объекты, контролы) GUI,
которые _вероятно_ понадобятся, хотя они довольно разнородные.