On Sun, Jun 15, 2008 at 10:37:22PM +0100, [EMAIL PROTECTED] wrote: > 2008/6/15 Boris Faure (aka billiob) <[EMAIL PROTECTED]>: > > > 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<http://85.17.105.113/%7Ewesley/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<http://85.17.105.113/%7Ewesley/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. > > > I agree; if someone is using GTK, QT or Cocoa, it's because they want the > app to fit in with with their desktop :) That's the strength of those > toolkits. If they want flashing lights and a sexy UI, they can use EFL :) It > might be possible to make a theme that fits in automatically with an > Enlightenment user's desktop; I don't know much about that though. > yeah but as I said in the other two mails, it will mostly be politics, the people would want the name of their favorite toolkit to be used... some people would even hate to use a XUL app because it "replicates" their toolkit without it being a true implementation... wtf! Also people want integrated dialog boxes, menus and buttons/entries/checkboxes/etc... and that can still be delivered by the toolkit/front end no matter whether they support themes or not... I guess! and if someone doesn't want ... cat stupid_user_complaint > /dev/nulll < /dev/default_theme
> > > > > > > > > > > > > 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 > > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
