FWIW, my opinion is that any deep integration is going to be hard, and that for the moment we should go with something much simpler: simply support mstheme files well, and provide themes that look like the default themes on Ubuntu / OpenSuse / Fedora.
2008/11/2 Dan Kegel dank@kegel.com:
FWIW, my opinion is that any deep integration is going to be hard, and that for the moment we should go with something much simpler: simply support mstheme files well, and provide themes that look like the default themes on Ubuntu / OpenSuse / Fedora.
Yes. That's why I ordered the level of integration the way I did (colours, msstyles, deep integration).
- Reece
On Sun, Nov 2, 2008 at 3:01 PM, Dan Kegel dank@kegel.com wrote:
FWIW, my opinion is that any deep integration is going to be hard, and that for the moment we should go with something much simpler: simply support mstheme files well, and provide themes that look like the default themes on Ubuntu / OpenSuse / Fedora.
I agree. I simply think any outside tools we develop should be used in conjunction with a proposed formal standard. If the MS formats are open there is no reason we cannot propose the usage of them, or a variation on them as part of FreeDesktop making Wine play nicer with everyone (mono and moonlight prove MS standards and formats can be of use for Linux). I'll spend some of the copious amounts of free-time I have at work researching for formats and we can continue the propose standard discussion off list later in the week.
For fun I looked a bit at the format. An msstyles file is just a win32 resource file. It contains various sections each containing strings, colors or bitmaps. Colors are just stored in a text file. Uxtheme parses this text file and loads the colors 1:1 from this section into the registry.
The main issue is creating a resource file it can either be compiled using wrc or it could an empty file could be created from a program and then updated using UpdateResource and friends. The first solution is the nicest way but not everyone might install wrc.
Anyway desktops will never move to this microsoft format. I think both gtk and qt are now moving to xml based formats. We could define our own spec for that but I doubt they will move to this. They attempted before to use the same theme format but it didn't work out well.
Roderick
On Sun, Nov 2, 2008 at 3:01 PM, Dan Kegel dank@kegel.com wrote:
FWIW, my opinion is that any deep integration is going to be hard, and that for the moment we should go with something much simpler: simply support mstheme files well, and provide themes that look like the default themes on Ubuntu / OpenSuse / Fedora.
I agree. I simply think any outside tools we develop should be used in conjunction with a proposed formal standard. If the MS formats are open there is no reason we cannot propose the usage of them, or a variation on them as part of FreeDesktop making Wine play nicer with everyone (mono and moonlight prove MS standards and formats can be of use for Linux). I'll spend some of the copious amounts of free-time I have at work researching for formats and we can continue the propose standard discussion off list later in the week.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On Sun, Nov 2, 2008 at 2:52 PM, Roderick Colenbrander thunderbird2k@gmx.net wrote:
Anyway desktops will never move to this microsoft format. I think both gtk and qt are now moving to xml based formats. We could define our own spec for that but I doubt they will move to this.
Right, I doubt we can have any influence on them. That's why I think we should focus on the most superficial kind of compatibility, i.e. just supporting Windows theming and providing theme files that make us look not so jarring.
I doubt we can ever do automatic theme extraction. - Dan
2008/11/3 Dan Kegel dank@kegel.com:
On Sun, Nov 2, 2008 at 2:52 PM, Roderick Colenbrander thunderbird2k@gmx.net wrote:
Anyway desktops will never move to this microsoft format. I think both gtk and qt are now moving to xml based formats. We could define our own spec for that but I doubt they will move to this.
Right, I doubt we can have any influence on them. That's why I think we should focus on the most superficial kind of compatibility, i.e. just supporting Windows theming and providing theme files that make us look not so jarring.
I was not proposing that Gtk and the other frameworks adopted the msstyles format (which has changed in Vista to an unintelligible binary format).
What I was proposing, after some discussion, was standardising at the *API* level. Something that would be acceptable with (and have the buy-in from) the toolkit writers and key applications. The various toolkits would still use their current formats for those themes. Wine could then use this standardised API,
Alternatively, there could be a Universal Theming Engine that does the same thing. That would be an external project that provides bindings to at least the major theming engines available, but such that applications can use it to simplify their code. Wine could then use this external library.
But Dan is right, the first step for Wine is making the uxtheme/msstyles support work well so that it can be used by distributions to theme Wine.
Another thing that potentially needs resolution is that Vista has added support for theming menus, but this will require us to use the new binary msstyles if Wine intends to properly support this without adding our own custom extensions to the XP format. This is where deeper integration will help: an XP msstyles theme will not support menu theming, but a native theme will.
I doubt we can ever do automatic theme extraction.
Agreed.
- Reece
On Sun, Nov 2, 2008 at 10:58 PM, Reece Dunn msclrhd@googlemail.com wrote:
.. the first step for Wine is making the uxtheme/msstyles support work well so that it can be used by distributions to theme Wine.
BTW, has anybody noticed a speed problem with our theme support? http://finance.addblogger.com/2008/11/15/how-to-install-picasa-3-in-linux-vi... complains "while WINE does accspt themes, those are Windows themes, and they are VERY SLOW. You're better off just keeping the default theme, but using your Linux color scheme..."
2008/11/15 Dan Kegel dank@kegel.com:
On Sun, Nov 2, 2008 at 10:58 PM, Reece Dunn msclrhd@googlemail.com wrote:
.. the first step for Wine is making the uxtheme/msstyles support work well so that it can be used by distributions to theme Wine.
BTW, has anybody noticed a speed problem with our theme support?
Yes.
If you use some themes (e.g. the Zune theme from Microsoft) then the performance is ok. If you try other themes (e.g. the Gem theme from the StyleXP program) then it renders very slowly - the performance killer in the Gem theme is rendering the parent background for property sheets (e.g. winecfg). This can clearly be seen in winecfg when switching themes.
I believe there were discussions about this earlier that tracked it down to theme parts having alpha channels in their bitmaps.
It may also be that as several of the theming APIs are using double buffering. Vista has some APIs that help out with double buffered drawing (http://blogs.msdn.com/e7/ has a nice video (requires Silverlight) from the latest PDC - http://channel9.msdn.com/pdc2008/PC43/ - that covers them in some detail). These may help improve performance.
In addition, the DIB engine is likely to prove invaluable here, as there will be a lot of drawing and blitting, which will certainly be killing performance at the moment with the X server round trip.
Do you know if the DIB engine is advanced enough to test this? Theming would make an interesting test case.
- Reece
On Sat, Nov 15, 2008 at 8:37 AM, Reece Dunn msclrhd@googlemail.com wrote:
2008/11/15 Dan Kegel dank@kegel.com:
On Sun, Nov 2, 2008 at 10:58 PM, Reece Dunn msclrhd@googlemail.com wrote:
.. the first step for Wine is making the uxtheme/msstyles support work well so that it can be used by distributions to theme Wine.
BTW, has anybody noticed a speed problem with our theme support?
Yes.
If you use some themes (e.g. the Zune theme from Microsoft) then the performance is ok. If you try other themes (e.g. the Gem theme from the StyleXP program) then it renders very slowly - the performance killer in the Gem theme is rendering the parent background for property sheets (e.g. winecfg). This can clearly be seen in winecfg when switching themes.
FWIW, http://www.ubuntuproductivity.com/journal/software/01/2009/theme-wine-integr... is a report of a happy user, so I guess the Human theme is ok. Maybe the Ubuntu package should come with that theme applied, or at least included and easy to turn on.
I believe there were discussions about this earlier that tracked it down to theme parts having alpha channels in their bitmaps.
It may also be that as several of the theming APIs are using double buffering. Vista has some APIs that help out with double buffered drawing (http://blogs.msdn.com/e7/ has a nice video (requires Silverlight) from the latest PDC - http://channel9.msdn.com/pdc2008/PC43/ - that covers them in some detail). These may help improve performance.
In addition, the DIB engine is likely to prove invaluable here, as there will be a lot of drawing and blitting, which will certainly be killing performance at the moment with the X server round trip.
Do you know if the DIB engine is advanced enough to test this? Theming would make an interesting test case.
Give it a try - somebody posted patches for his own mashup of the DIB engine recently... - Dan
2009/1/14 Dan Kegel dank@kegel.com:
On Sat, Nov 15, 2008 at 8:37 AM, Reece Dunn msclrhd@googlemail.com wrote:
2008/11/15 Dan Kegel dank@kegel.com:
BTW, has anybody noticed a speed problem with our theme support?
Yes.
If you use some themes (e.g. the Zune theme from Microsoft) then the performance is ok. If you try other themes (e.g. the Gem theme from the StyleXP program) then it renders very slowly - the performance killer in the Gem theme is rendering the parent background for property sheets (e.g. winecfg). This can clearly be seen in winecfg when switching themes.
FWIW, http://www.ubuntuproductivity.com/journal/software/01/2009/theme-wine-integr... is a report of a happy user, so I guess the Human theme is ok. Maybe the Ubuntu package should come with that theme applied, or at least included and easy to turn on.
That's great :).
Not everything works yet (particularly state changes in buttons -- such as pressing a button, or it becoming disabled -- revert it to non-themed behaviour), but it is getting there.
In addition, the DIB engine is likely to prove invaluable here, as there will be a lot of drawing and blitting, which will certainly be killing performance at the moment with the X server round trip.
Do you know if the DIB engine is advanced enough to test this? Theming would make an interesting test case.
Give it a try - somebody posted patches for his own mashup of the DIB engine recently...
Will do. I'll also give some games a spin to see if it makes a difference there as well.
- Reece
On Sat, Nov 15, 2008 at 8:37 AM, Reece Dunn msclrhd@googlemail.com wrote:
2008/11/15 Dan Kegel dank@kegel.com:
On Sun, Nov 2, 2008 at 10:58 PM, Reece Dunn msclrhd@googlemail.com
wrote:
.. the first step for Wine is making the uxtheme/msstyles support work well so that it can be used by distributions to theme Wine.
BTW, has anybody noticed a speed problem with our theme support?
Yes.
If you use some themes (e.g. the Zune theme from Microsoft) then the performance is ok. If you try other themes (e.g. the Gem theme from the StyleXP program) then it renders very slowly - the performance killer in the Gem theme is rendering the parent background for property sheets (e.g. winecfg). This can clearly be seen in winecfg when switching themes.
FWIW, http://www.ubuntuproductivity.com/journal/software/01/2009/theme-wine-integr... is a report of a happy user, so I guess the Human theme is ok. Maybe the Ubuntu package should come with that theme applied, or at least included and easy to turn on.
I believe there were discussions about this earlier that tracked it down to theme parts having alpha channels in their bitmaps.
It may also be that as several of the theming APIs are using double buffering. Vista has some APIs that help out with double buffered drawing (http://blogs.msdn.com/e7/ has a nice video (requires Silverlight) from the latest PDC - http://channel9.msdn.com/pdc2008/PC43/ - that covers them in some detail). These may help improve performance.
In addition, the DIB engine is likely to prove invaluable here, as there will be a lot of drawing and blitting, which will certainly be killing performance at the moment with the X server round trip.
Do you know if the DIB engine is advanced enough to test this? Theming would make an interesting test case.
Give it a try - somebody posted patches for his own mashup of the DIB engine recently...
- Dan
A while ago when I looked at how XP theme files worked I also took a look at this theme. I don't think any package should ship this theme the same for other XP themes. The problem is that all XP theme 'creators' are in fact editors which use original XP themes as templates. The basic clearlooks theme I made a while ago is clean though. We really need to be able to create our own themes but as I showed it is quite a bit of work but it isn't that hard.
Roderick
2009/1/15 Roderick Colenbrander thunderbird2k@gmx.net:
A while ago when I looked at how XP theme files worked I also took a look at this theme. I don't think any package should ship this theme the same for other XP themes. The problem is that all XP theme 'creators' are in fact editors which use original XP themes as templates. The basic clearlooks theme I made a while ago is clean though. We really need to be able to create our own themes but as I showed it is quite a bit of work but it isn't that hard.
Have you written a HOWTO on this, perhaps suitable for the wiki? Would be most useful for the future!
- d.
2009/1/15 Roderick Colenbrander thunderbird2k@gmx.net:
A while ago when I looked at how XP theme files worked I also took a
look at this theme. I don't think any package should ship this theme the same for other XP themes. The problem is that all XP theme 'creators' are in fact editors which use original XP themes as templates. The basic clearlooks theme I made a while ago is clean though. We really need to be able to create our own themes but as I showed it is quite a bit of work but it isn't that hard.
Have you written a HOWTO on this, perhaps suitable for the wiki? Would be most useful for the future!
- d.
I submitted my work to wine-devel a couple of months ago (see http://article.gmane.org/gmane.comp.emulators.wine.devel/64542/). I attached a sample theme file with just coloring (XP style coloring; this is slightly different from the old coloring method in the registry as some names change). The file clearly shows how to create a simple theme from scratch. Adding bitmaps is more involved though but not that hard.
Roderick
2009/1/15 Roderick Colenbrander thunderbird2k@gmx.net:
I submitted my work to wine-devel a couple of months ago (see http://article.gmane.org/gmane.comp.emulators.wine.devel/64542/). I attached a sample theme file with just coloring (XP style coloring; this is slightly different from the old coloring method in the registry as some names change). The file clearly shows how to create a simple theme from scratch. Adding bitmaps is more involved though but not that hard.
I've added your message to the wiki, with some editing:
http://wiki.winehq.org/XPThemes
Please correct as needed :-)
- d.
I made some progress. As I mentioned last time a .msstyles theme is just a resource file wrapped into a dll. Windows tools try to edit real themes or create themes by injecting resource data into a blank dll.
In order to obtain a resource file I used a tool called resource hacker to retrieve one from a GPLed clearlooks theme (most windows theme tools only provide binaries or some usefuless xml files). A msstyles file contains various section which contain the msstyles version (PACKTHEM_VERSION), the different color version of the theme (COLORNAMES). The real info is burried inside 'ini files' which are stored inside the 'TEXTFILES' section of the file (the names of the ini files correspond to FILERESNAMES). Each ini file contains a bunch of sections for buttons, textboxes and all other controls. There's also a generic 'SysMetrics' section which contains some classic properties like ActiveCaption and others. The control specific ones are the most important and they contain the dimensions of lets say a button, where to position text, what DPI to use and more.
Initially my idea was to create a sample .msstyles project but this looks like a huge task as I would need to fill in every attribute of each control. If I would provide an incomplete theme (which might be legal not sure) the current theming code in Wine will fail as it expects theme info to be around.
As everyone is aware of big improvements are needed to the comctl32 theming code and other places which need to draw using themes. For example in case of a button the current drawing code calculates the position for drawing text iself while it should get this info from the theme. The same for other controls.
Roderick
For fun I looked a bit at the format. An msstyles file is just a win32 resource file. It contains various sections each containing strings, colors or bitmaps. Colors are just stored in a text file. Uxtheme parses this text file and loads the colors 1:1 from this section into the registry.
The main issue is creating a resource file it can either be compiled using wrc or it could an empty file could be created from a program and then updated using UpdateResource and friends. The first solution is the nicest way but not everyone might install wrc.
Anyway desktops will never move to this microsoft format. I think both gtk and qt are now moving to xml based formats. We could define our own spec for that but I doubt they will move to this. They attempted before to use the same theme format but it didn't work out well.
Roderick
On Sun, Nov 2, 2008 at 3:01 PM, Dan Kegel dank@kegel.com wrote:
FWIW, my opinion is that any deep integration is going to be hard, and that for the moment we should go with something much simpler: simply support mstheme files well, and provide themes that look like the default themes on Ubuntu / OpenSuse / Fedora.
I agree. I simply think any outside tools we develop should be used in conjunction with a proposed formal standard. If the MS formats are open there is no reason we cannot propose the usage of them, or a variation on them as part of FreeDesktop making Wine play nicer with everyone (mono and moonlight prove MS standards and formats can be of use for Linux). I'll spend some of the copious amounts of free-time I have at work researching for formats and we can continue the propose standard discussion off list later in the week.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
-- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
On 02.11.2008 23:28, Steven Edwards wrote:
I agree. I simply think any outside tools we develop should be used in conjunction with a proposed formal standard.
I've just seen this: http://www.andreasn.se/blog/?p=91
In short, there is work being done on a GTK+ theming engine that uses CSS(!) for describing themes. If that pans out ... arguably you could cover quite a good part of a hypothetical 'formal standard' by just reusing CSS.
-f.r.
-
Dan Kegel -
David Gerard -
Frank Richter -
Reece Dunn -
Roderick Colenbrander -
Steven Edwards