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.
>
>
>
> >
> > 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
