Russian Qt Forum

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

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

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

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

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

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

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

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

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

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

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

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

Ерунда.

Полный бред.

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

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

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

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

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

Спасибо всем за ответы! Было бы здорово получить какие-то конкретные советы по динамическому проектированию, а еще лучше примеры. В составе Qt Creator пока ничего похожего найти не удалось. Или, все-таки, разбить приложение на несколько основных форм, а внутри них уже организовать динамику? Это было бы самым логичным, имхо, но начальство уже на этапе выбора режима работы приложения- первая форма с двумя кнопками: режим 1, режим 2- хочет одну форму :(

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

Ну вот, пошла "архитектура", "слабая связанность и компактность" и.т.п. :)  А какие собственно проблемы делать все в 1 форме? Удачные обобщения наверняка найдутся, вообще что здесь "страшно-архитектурного"?  :)

Есть термин "динамическое программирование", классический пример
Это не то что Вы хотели - но тоже (зато) интересно

Susenin в самом начале дал дельные советы, к которым я тоже рекомендую прислушаться. У вас уже есть функциональное ядро программы, к которому надо прилепить GUI? Или начальство хочет в динамический интерфейс динамический функционал вставить? :) Если хотите конкретики, то нарисуйте хоть на бумаге набор необходимых форм, тогда будет понятно, как много там всего меняется, и как лучше это реализовать. И здесь примеры предоставьте, чтобы могли конкретные советы давать.
Вообще, похоже, то что вы хотите получить, реализовано в QML, который использовать нельзя :). Думаю, в любом случае, пригодится погуглить "state machine gui".

Я тут подумал, что можно сделать так:

1. Создаем минимально необходимый пул виджетов, которые нужны для проектирования.
Т.е. если форм всего 10, и на каждой не больше 2-х кнопок, значит в пуле всего 2 кнопки.

При старте приложения заполняем пул.

2. Нужно создать классы-описания формы. Если при стандартном подходе эти классы генерит uic из *.ui файлов, тот тут их нужно создать самим. Первое что приходит в голову - копипастой.
И заменить в методе динамическое создание виджетов на выбор их из пула. Самое ценное, что есть в файлах, созданных uic, это настройка виджетов.
Для этого:
Создаем вспомогательный проект. В нем создаем столько *.ui файлов, сколько форм в приложении. Редактируем их в Дизайнере до полного удовлетворения.
После прохода uic по *.ui файлам получаем несколько ui_<имя_ui_файла>.h файлов. Далее копируем их в свой проект, изменяем создание виджетов на выбор из пула.

Я бы просто в методе просто удалил строки с new. Выбор из пула сделал бы в конструкторе.

Пока выглядит несложно.

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

Спасибо! А у меня сегодня появилась такая идея (частично реализованная):
свой класс лейаут (на основе грида): у него 3 раздела- заголовок, центральная изменяемая часть и управление (2 кнопки)
потом много классов виджетов: виджет создается, устанавливается для центральной части, потом удаляется, создается след., опять устанавливается и т.д. И соответственно, меняются управлящие кнопки: их слоты, заголовки. Это должно работать для одной ветви проекта, потом надо как-то реализовать переключение между ветвями. Вообщем, заранее спасибо за любые идеи-примеры, как это сделать правильно (вкл. создание своего класса лейаут)

Ну это вряд ли  :)

Полностью согласен

Совершенно не согласен. Не нужна тонна файлов что наколбасил дизайнер. Гораздо лучше задействовать QFormBuilder и грузить прямо ui файл. Тогда легко сделать общую часть, напр

C++ (Qt)
QPushButton *button = parentWidget->findChild<QPushButton *>("button1");

Смысл - одна переменная для всех форм, а имя "button1" обеспечим в дызайнере.