Hello everyone, I wanted to discuss some ideas I had about user interface theming and plug-ins.
1) user interface theming. This is my idea: * If the user wants system/desktop integration he'll use either the Qt 4, Cocoa or Gtk+ style (or EFL if the user runs E17). * If the user wants to use a theme/skin, he'll have to use the EFL interface, because I believe that one is 100% themable in an easy way. (KaKaRoTo, can you confirm this?) * Alternatively, I would also like to create my own small skinning engine for the Qt 4 interface, based on Qt StyleSheets and the QUiLoader. I will talk more about this in a minute. But are there any complaints for the fact that there will be 2 completely different theming engines? Who thinks that I should just drop my theming idea and leave it all to EFL? Now, about my Qt 4 theming system. I would like to use custom Qt StyleSheets to provide the general style of the application (it's a lot like CSS, but for widgets!) and supplement that with user-created forms in Designer. The reason for this is simple: Designer is a very easy tool in which you can design forms, and it has a very good integrated Qt StyleSheet system. Normally, you would compile the user interface to .py files, but I want to take a different route. Partially because of security concerns, and also because of implementation defails. Using QUiLoader I want to load in the .ui interface on the fly and do sanity checks for the widgets etc. (I will also provide a test_theme.py script for theming development purposes). When the .ui file passes the sanity check, my theming system will make the needed connections between the widgets and the code and that's all there will be to it. Theme designers for the Qt 4 interface will only have to do a few things: * Design a theme (the layouts, buttons, etc) using the very good Qt Designer tool * Optionally use Qt StyleSheets in the theme to make it actually look themed * Make sure that all the needed controls are on the form and have the right name (otherwise the sanity check will fail and the system will fall back to the default theme) I don't know if all this is the best way to do it (and I don't know for sure if it's technically possible, because I haven't tested it yet, but it should work...) but from my perspective it's the best way to create custom themes for the Qt 4 interface. What do you guys think? Here are two examples of what could be done with QSS theming (these two examples have the exact same layout and widget placement, but using the aforementioned technique I want to make that configurable as well) Example 1: Something with round corners and stuff.. http://85.17.105.113/~wesley/images/amsn_preview0_qt4_frontend.png Example 2: Windows Live Messenger look-a-like.. http://85.17.105.113/~wesley/images/amsn_preview3_qt4_frontend.png I'm very interested in your thoughts about this. Please tell me whether you think 2 theming engines would be a waste of time or not, and if you think they can both (EFL themes + Qt 4 themes) live happily together, please tell me what you think about my theming engine idea for the Qt 4 interface. 2) plug-ins. This is a challenging concept. Why? Because we have multiple GUI's now. One thing is certain: all plug-ins have to work on all user interfaces. I think the best way to implement a plug-in system is to actually "force" the plug-in developers to create their plug-ins in pure python without using any GUI toolkit. For the configuration of the plug-in, the plug-in developers should make an XML file that describes which options to configure and how they have to be configured. This XML file can then be read in and processed by the aMSN core. The aMSN core will then tell the GUI interface which plug-ins there are available and what the options of each plug-in are. This is just an example of how it could go: <plugin> <name>Some example plug-in</name> <description>This is an example plug-in</description> <config> <bool default=True>Something that can be on or off</bool> <string default="">A line of text that the plug-in needs</string> </config> </plugin> This XML file is read in by the core and the core sends something like: addPlugin(PluginData) to the GUI. The GUI will then for example add the plug-in information to some tab in it's configuration window and create a checkbox for the bool value and an editable line of text for the string value. Upon changing these values (and clicking apply or ok) the new PluginData will be sent back to the core. Of course this is very conceptual and doesn't take everything into account yet.. For example, what to do if the plug-in wants to provide an extra button or something in the actual GUI? This can probably be done as well, by extending the XML so plug-in developers can add things like "<gui><chatwindow><addbutton location="topright" value="Send buzzer!">buzzer</addbutton></chatwindow></gui>" but this would be a bit messy, I believe. Anyway, the core will retrieve that name "buzzer" and send the needed stuff to the GUI and set up a signal so that when the GUI informs the core that the button is clicked, the needed action is performed. Well... I hope you can share some of your ideas about all this with me. I believe that my idea for the plug-in system could be a lot better than this. So please, if you know something better.. share it with us! PS: I think I rivalled KaKaRoTo's mail length! -- Wesley Stessens <[EMAIL PROTECTED]> Human Knowledge Belongs To The World - Antitrust (2001) http://wesley.debianbox.be ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
