On Sun, Jun 15, 2008 at 21:26, Wesley S. <[EMAIL PROTECTED]> wrote: > Hello everyone, > > I wanted to discuss some ideas I had about user interface theming and > plug-ins.
1st, Welcome! > 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?) It's one of the main ideas behind efl! (@Kkrt, i'm wonder if it'll be easy to change etk themes for just one application.) > * 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. With a theming engine for QT4, it'll look less desktop-integrated imo. I think the desktop integration thing is more about having the same buttons everywhere, having the same dialog boxes, the same filechooser everywhere... If you have a dark theme, you'll have the same dark buttons/grey background. You might loose the "perfect integration" if for example, the user have a dark theme, the login window is bright due to the theming. > > 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. We already have that in amsn : http://www.amsn-project.net/wiki/Dev:Plugin_Developer_Guide#Configuration Having something like that will be good. It should also be XML-based like your example. Also add a combobox to the widget items. I think it's a bit too early to think about the plugin system but i've got a lot of ideas for it. > 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. This very tricky. We'll need a very good design for that. > 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! His answer will be longer :) -- Boris FAURE (aka billiob) ------------------------------------------------------------------------- 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
