Russian Qt Forum

Здравствуйте!
   
    Передо мной стоит задача разработки комплекса программg под Linux, состоящего фактически из двух основных приложений - консольное приложение (Ядро), реализующее основную задачу, и графическое приложение (Конфигуратор), позволяющее создавать профили для работы Ядра. Профиль представляет собой файл, содержащий настройки модулей Ядра. Необходимо сделать так, чтобы Конфигуратор мог не только создавать профиль, но и загружать уже имеющийся для редактирования. В связи с этими требованиями я пришел к выводу, что наиболее удобно будет представлять профиль в виде xml файла. В таком случае Конфигуратор будет фактически графическим представлением профиля: для каждой настройки Ядра есть свое текстовое поле, ползунок или другой контрол. В связи с этим для реализации Конфигуратора я выбрал платформу Qt. Учитывая очень простую логику работы Конфигуратора, я хотел бы использовать RAD подход для его разработки, чтобы сконцентрироваться на разработке Ядра, благо в Qt возможности просто потрясающие!
    Вот и появилась мысль, о том, что должен в Qt существовать способ автоматического отображения состояния контролов программы в XML файл и загрузки из него. То есть, как я себе представляю, для каждому контролу, согласно его имени, в файле присутствует тег. Теги контролов-потомков лежат между открывающим и закрвающим тегами контрола-родителя. В "листьях" лежат уже фактические значения.
    Прошу прощения за многословность, просто хотелось максимально описать архитектуру, поскольку я нахожусь в самом начале цикла разрабоки и имею возмножность без особых потерь что-то поменять, поэтому буду рад любым предложениям и советам!

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

/* я так понимаю, идея Конфигуратора сродни идее dialog'а или форм Kommander'а ? */

Я вплотную занялся Qt недавно, пока слабо ориентируюсь в возможностях. Имею некоторый печальный опыт работы с MFC, где все было "через одно место" - вручную создавал объекты, прописывал в код загрузки, сохранения значения, генерации профиля, обновления формы и тд.. Добавление текстового поля превращялось в сумасшедшее ковыряние кода и приводило к большому количеству багов. Хочется переложить подобную работу на Qt, чтобы потом добавление нового контрола требовало только рисование этого поля и задания его имени, возможно, чего-то еще. В идеале, чтобы в код вообще не надо было лезть.
Можно по подробнее об этом? Как такое сделать? Уверен, что это как раз то, что надо.
Не совсем понял, что Вы имеете в виду под Kommander'ом. Пока что я представляю себе Конфигуратор (уже сделал некоторый прототип ;)) в виде системы вложенных toolbox'ов, на нижнем уровне которых лежат сами настройки в виде
Label[Имя_параметра1]    Edit[Значение_параметра1]
.....
Label[Имя_параметраN]    Edit[Значение_параметраN]
В итоге я думаю, что мне понадобятся только TextEdit, RadioButton, CheckBox, Table.

The QUiLoader class allows standalone applications dynamically create user interfaces at run-time using the information stored in .ui files or specified plugin paths...

http://doc.trolltech.com/main-snapshot/quiloader.html

Можно пойти еще дальше :) http://techbase.kde.org/Development/Tutorials/Using_KConfig_XT

Из документации по QUiLoader я понял, что он позволяет загрузить конфигурацию, но не сохранить, хотя штука интересная.
Насчет KConfig XT есть подозрения, что это приведет к непереносимости программы на другие ОС, например, Windows:( Я выбирал Qt в том числе и из-за того, что в будущем не будет проблем с портированием хотя бы этой части комплекса :D

KDE4 в порядке эксперимента портировали на WinNT и MacOSX. Я не предлагаю использовать kdelibs в проекте, но возможно стоит рассмотреть аналогичное решение, чтобы избежать проблем в собственной реализации.

Для сохранения см. QFormBuilder

Всем спасибо за помощь! Нашел подход к решению с использованием метода children(). Надеюсь, получится довести реализацию до ума:)