Russian Qt Forum
Сентябрь 21, 2024, 13:43 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: Сохранение состояния программы в xml  (Прочитано 8467 раз)
codergeneration
Гость
« : Март 01, 2009, 18:19 »

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

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

/* я так понимаю, идея Конфигуратора сродни идее dialog'а или форм Kommander'а ? */
Записан
codergeneration
Гость
« Ответ #2 : Март 01, 2009, 20:06 »

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

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
Записан
Rcus
Гость
« Ответ #4 : Март 01, 2009, 20:46 »

Можно пойти еще дальше Улыбающийся http://techbase.kde.org/Development/Tutorials/Using_KConfig_XT
Записан
codergeneration
Гость
« Ответ #5 : Март 01, 2009, 21:02 »

Из документации по QUiLoader я понял, что он позволяет загрузить конфигурацию, но не сохранить, хотя штука интересная.
Насчет KConfig XT есть подозрения, что это приведет к непереносимости программы на другие ОС, например, Windows:( Я выбирал Qt в том числе и из-за того, что в будущем не будет проблем с портированием хотя бы этой части комплекса Веселый
Записан
Rcus
Гость
« Ответ #6 : Март 01, 2009, 21:10 »

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

Сообщений: 2901



Просмотр профиля WWW
« Ответ #7 : Март 01, 2009, 21:40 »

Из документации по QUiLoader я понял, что он позволяет загрузить конфигурацию, но не сохранить, хотя штука интересная.

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

Цитировать
void QAbstractFormBuilder::save ( QIODevice * device, QWidget * widget )   [virtual]

Saves an XML representation of the given widget to the specified device in the standard .ui file format.
Записан

Integrated Computer Solutions, Inc. (ICS)
http://www.ics.com/
codergeneration
Гость
« Ответ #8 : Март 04, 2009, 12:09 »

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


Страница сгенерирована за 0.049 секунд. Запросов: 23.