On Sun, Jun 15, 2008 at 10:48:03PM +0200, Boris Faure (aka billiob) wrote: > 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.) Yes, really easy.. if you have in your .edj file some group with name "etk.button" or whatever, then you can override the look of etk/ewl with the same .edj file! :) but maybe you need to do something like etk.settheme or whatever, not sure about that yet.. but I know for sure (I asked) that it's easy to do and easy to make it custom for 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. > true, but then that's the choice to the user... if a user wants his QT buttons/checkboxes/windows instead of the efl non-desktop-integrated buttons/windows, but would still want to see a different theme (like the WLM one), he should be able to do it! In the end, as I said in the previous mail.. what really matter are those stupid dialog boxes... :s and.. most probably the politics of people who want "their toolkit".. > > > > > 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. > yeah too early still but it doesn't hurt to talk about 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. > whatever the core can do, the plugins can do by calling the same abstracted gui API the core uses... > > 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 :) > ROFL! > -- > 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
