проектирование пользовательского интерфейса

[qt_newer]

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

[qt_newer]

работать должно на QT 4.8 (max), т.е. без QML

[Susenin]

Расскажите подробнее, что конкретно не понятно?

Пока такие советы:
1. Максимально отделить GUI от логики работы программы (ядра). GUI должен быть незатейливым проводником сигналов  между пользователем и ядром.
2. Возможно, требования к программе еще не до конца сформировались и будут меняться по ходу разработки программы. Надо предусмотреть эту возможность.  Если вы создадите динамическое изменение компонентов на одной форме, вас ждет много боли, когда требования к GUI будут меняться.
Пишите программу со стандартным подходом, не запариваясь на экономию памяти и остального. Вот когда напишете, протестируете, тогда и будете оптимизировать GUI. У вас
это легко получится, ведь вы GUI хорошо отделили от ядра по моему первому совету 

[qt_newer]

Спасибо за ответ, но начальство говорит заморачиваться, значит заморачиваться
Это мой первый проект на кьют (знания чисто теоретические), а программа уже существует на другой платформе (чужая, кода у меня нет)- просто перевести надо, начав с ГУИ.
Не понятно, как правильно сделать динамическое изменение элементов и классы спроектировать. Приложение выглядит примерно так: выбор режима просмотра- режим 1- ввод данных- ввод след. данных, возврат на главную страницу,
режим 2- ввод- проверка, изменение фона на красный для неверных данных- снятие отпечатков и т.п. и т.д. Много, много форм- переход между ними туда-обратно, еще куда-то в середину
Т.е. ответ, например, использовать QtStackedWidget, сделать несколько страниц с кнопками внизу и менять у них надписи, слоты по ходу дела (только как пример!).
Классы для кнопки, инпут бокса, текст ареа и т.п. создам, надеюсь, самостоятельно

[Bepec]

Не страдайте геморроем

Делать полностью динамический интерфейс можно, но это приведёт к перерасходу времени, нервов и денег.
Одна правка и у вас полетит всё/вся и вы будете страдать в прямом смысле этого слова.
Разделите всё на формы. Потом формы создавайте динамически на главном виджете. Вот и весь сказ.

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

[qt_newer]

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

[Susenin]

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

Сделайте тестовое приложение, две насыщенные формы. Поочереди их создавайте, показывайте и удаляйте. Замерьте время. Будут хоть какие-то данные.

[Igors]

Т.е. ответ, например, использовать QtStackedWidget, сделать несколько страниц с кнопками внизу и менять у них надписи, слоты по ходу дела (только как пример!).

Ну а почему бы и нет? Чем это "сложнее" расхристанных "форм" (какое мерзкое слово) у которых одинаковые эл-ты? Или просто так - ругать глупость начальства = хороший тон? 

[Bepec]

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

[Old]

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

Ерунда.

[_OLEGator_]

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

Полный бред.

[Bepec]

А чем вы руководствовались когда писали 2 последние реплики? Если без грамотной архитектуры гибкая система, то это капец. А тут как раз такой случай.

[Old]

А чем вы руководствовались когда писали 2 последние реплики? Если без грамотной архитектуры гибкая система, то это капец. А тут как раз такой случай.

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

[_OLEGator_]

А чем вы руководствовались когда писали 2 последние реплики? Если без грамотной архитектуры гибкая система, то это капец. А тут как раз такой случай.

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

[Bepec]

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

Вот моё утверждение Скажите ещё, что в монолитном больше ошибок будет Чем гибче, тем больше сценариев. Чем больше сценариев - больше обработчиков. Больше обработчиков - больше ошибок. По статистике