On Sun, Jun 15, 2008 at 09:26:02PM +0200, Wesley S. wrote: > Hello everyone, > > I wanted to discuss some ideas I had about user interface theming and > plug-ins. > good, it's the right place to do so :p
> 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). I agree, the qt/gtk/cocoa front ends are for those who want it to be integrated with their desktop environment... > * 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?) Yep, it's really easy.. EVERYTHING is written on a canvas.. even the buttons/checkbox/entries/etc... are provided by a toolkit library (ewl or etk) which uses edje itself (the layout engine) and that can be customized too with the theme.. > * 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? I think any front end should (if the maintainer wants to) have its own themeing engine.. for example, current aMSN can be themed easily, and it's just a matter of changing the images (and a few options).. someone might want a different image set/configs... > > 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. > If you want to use stylesheets and have a big themeing system for qt, it's alright with me, you're the qt maintainer, you can decide whatever you think is best suited for your front end. In any case, it just adds more power to the user (which is amsn's philosophy) and if someone doesn't want that, he can just use the default theme. In any case, my best example is the current aMSN, it's Tk, yes.. but the contact list and chat window (the real two windows you'll really ever use/see) are all, completely done with canvases... there is absolutely 0% Tk widgets in there... (event the scrollbar is a custom widget drawing pixmaps on a canvas).. but what does everyone say, always about aMSN ? "it's ugly"... "tk is ugly", etc... so i have no fucking idea where they see this 'ugly tk' when everything is just a canvas... Either, it's just political (gnome lovers want gtk or nothing, kde lovers want qt or nothing), or if it's because of the menus (tk menus) and the preferences window, the dialogs, the "add contact" window, etc... anyways, what I want to say is that, even if you make your front end a canvas, fully themeable, etc.. the front end will still be qt/gtk/whatever because your menus, your dialogs, your "open file" window, etc.. will be in qt/gtk, so people will see an advantage to the themeing and will still like the front end because of the toolkit it uses... anyways, I guess you got my point. > 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? > Doing so will give you a great advantage, probably the same (or almost ) powerful themeing as the EFL front end! I think it's a great idea! and I didn't know QT was this good/advanced/themeable! > 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, > I think these are great, and I don't know what you mean by 2 theming engines... if it's EFL and QT4, then sure, no problem! I'll explain later my thoughts about themes and front ends.. If it can be left until the end, maybe it would be better, but if you think it's better to incorporate themes right away into the front end otherwise it would become a hassle to add them, then go for it. > 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. > ok, so my idea is to have 3 pseudo-'themes'.. first : a 'smiley set', currently, the smiley set is provided by the amsn skin, that wasn't such a good idea, so we would need smiley sets independent of the front end/theme/skin... second : a 'skin', which would be a directory containing a set of images/sounds... you don't need to change the theme if you want those buddy icons in the CL to become colored dots, etc... This 'skin' would be the same for any front end I suppose... maybe slight changes from one front end to the other might be necessary, we'll see in time. (for example 'skin/buddy_online.png skin/buddy_online.qt4.png skin/buddy_online.efl.png skin/dp_frame.png etc...' ) third : a 'theme'.. this will be front end specific, for EFL it would be a .edj, for QT4, it would be a set of .ui files and stylesheet options, etc... So.. if a front end doesn't do themes, then no themes for it, if it supports them, then it can have a front end specific theme for it... and we can still have 'skins' which are nothing more than a set of images with fixed filenames for the UI. In terms of design.. the core would ask the f/e to load a theme, the f/e accepts or rejects it. for skins, the core would use the front_end.image class to 'build' the image.. the core takes care of the skin being used, it fetches the appropriate filename and for each image will do an Image().loadFromFile(filename). > 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. > not necessarly.. someone might want to create a front end specific plugin... > 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. > sure, that would be silly otherwise considering the concept of amsn2... the plugin would be in python, would use the core and would do core._gui.whatever() if there's a need... the plugin could use the abstracted classes of the front end if it needs to build a UI or something... for example : class NudgePlugin(amsn2.core.plugins.BasePlugin) : def __init__(self, core): core.registerEvent("chatwindow_created", self._on_cw) ... def _on_cw(self, cw): buttonView = amsn2.core.views.ButtonView(image=self.nudge_image, command=self._on_click) cw.addButtonBarItem(buttonView) > 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. > This looks a bit like the plugin system of amsn.. we have a plugininfo.xml with all the info, the file to load, the function name to call on load/unload. The configuration is set by the plugin though (a variable named configlist)... this allows for 'bool/string/checkbox/frame'... the 'frame' is important because sometimes you want something really fancy (pop3 plugin for example) and you tell the core that you want a frame created for you and a callback gets called with the frame as argument, then you can do whatever you want with it... For such a case, maybe a 'toolkit' class of the front end should be made.. something really really simple, just button, checkbox, radiobutton, label, frame, combobox.. to allow creating a custom window with the toolkit abstraction... not important for now! The important thing is that the XML should have a 'front_end_compatible' field... which lists which front end it works with.. it can be 'all', or a list of front ends, for example a plugin which adds some 'fire' effect to the EFL windows by providing a .edj file would have just 'efl' as compatible front ends... The core would take care of displaying to the user, and loading only the plugin compatible with the currently loaded front end. > 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. > The GUI does nothing for this, the Core will do everything, the GUI will merely provide a set of API so that the core can put any info wherever it wants... > 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! > I hope I explained a bit my idea correctly... I know Tom has more ideas, and Alen said he wrote a good plugin system for elloquence, so maybe he has good advice... the emesene guys also have a good plugin system from what I heard, so again, their advice might help! > PS: I think I rivalled KaKaRoTo's mail length! > nah, nowhere near me :p but yeah, good effort, it was pretty long.. but a pleasure to read :) > -- > Wesley Stessens <[EMAIL PROTECTED]> > Human Knowledge Belongs To The World - Antitrust (2001) > http://wesley.debianbox.be > KaKaRoTo ------------------------------------------------------------------------- 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
