Hello, Allow me to highlight the comments by KDE developer Dirk Schoenberger in response to the comment "I suggest you look at XUL or QtDesigner files for a better alternative."
Dirk responds: XUL: nice schema, appropriate for static GUI descriptions. No way to easily do the dynamic stuff (react to button clicks, enable/disable elements if another element changes, open other windows). The existing Mozilla XUL requires you to embed Javascript into the XUL files, which sounds exactly like the above "any configuration file format will eventually end up being a programming language". Other XUL dialects somewhat lift this requirement, they may allow to use other scripting languages (or perhaps even Java). I have not seen a XUL application which can be programmed in pure C++. QtDesigner files are designed to be used with QtDesigner. Ever tried to write a .ui file manually? The used schema is IMHO one of the worst cases of the generic key-value style serialization anti-pattern. I don't want to store keys and values, I want to store GUI descriptions. Beside, QtDesigner is designed for code generation (and adding dynamic functionality via inheritance. You may load .ui files at runtime, but I don't think this way is really recommended. Additionally, QtDesigner explicitly models the used components and their properties. If you want a QButton, you get a QButton, if you want a QMenu, you get a QMenu. In order to use KDE components, you have to register them at QtDesigner and make sure that they are also registered on a users machine. This makes distributing .ui files cumbersome. I would prefer a solution where I only specify "give me a menu", and the framework decides if I get a KMenu if I start the application under KDE. XMLGUI (and the KAction framework) IMHO elegantly solve the static-dynamic contradiction. All really static parts of the GUI are stored explicitly in the XMLGUI description. Possible dynamic parts like buttons, text input fields and such, are only referenced by name (via the <Action> tag). In your application, you create the actions, connect them and let the XMLGUI framework decide how they are visualized. Basically you are implementing a controller, instead of directly manipulation the view. Given a number of proper action classes and their language bindings, this would allow for true cross-language GUI development (if you define a action in Python or Ruby, C++ or Javascript is irrelevant). Source: http://article.gmane.org/gmane.comp.kde.devel.koffice/6476 What's your take? Is the QtDesigner XML UI format for machines only? Do you think KDE's XMLGUI is a better alternative? Do you know of any other XML UI language formats in the KDE world? - Gerald ------------------- Gerald Bauer XUL Alliance | http://xul.sourceforge.net United XAML | http://xaml.sourceforge.net Interested in hiring Gerald Bauer? Yes, I'm available. If you know of an opportunity, please contact me today. ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ xul-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xul-talk
