November 2008 - Wine-Devel - list.winehq.org

Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes

by Frank Richter

On 01.11.2008 14:04, Reece Dunn wrote: > Note that as Vista has a different msstyles theming engine (it is a > DLL), It's also a DLL on XP. Note that in both cases no code is exported, the DLLs serve only as a container for the theme data, stored as resources. > we could have the msstyles DLL expose the uxtheme API and have > uxtheme call msstyles to do the rendering. That way, we could have a > gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles That sounds like misappropriating the msstyles 'format'. The idea of "theming engine plugins" is a good one, but then some other mechanism than abusing the msstyles extension should be used to detect these plugins. Some ideas: an extension (but a different, unique one), putting them into a special directory, listing engines in the registry. Anyhow, this is somewhat bikeshedding ;P First step would probably be to define a theming plugin API - you say that the theming plugins would just export the whole uxtheme API. However, it could be possible that the theming plugin interface can be simplified compared to that, with uxtheme.dll filling the gaps. (After all, a simpler interface can mean a simpler plugin implementation...) -f.r.

Nov. 1, 2008

Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes

by Roderick Colenbrander

Hi, There are a bunch of uxtheme / control theming bugs which need to be fixed but lets ignore those issues for now. In the end we need to support a bunch of different theme engines GTK, QT, Cocoa and perhaps later on more. In theory it would be possible to create a different uxtheme backend for each different toolkit. One major issue is the language which each of these toolktis is written in. GTK would be fine as it is C but QT and Cocoa require respectively C++ and Objective C. Alexandre doesn't want such languages in (although he might make an exception for the winecocoa driver if it is really, really needed). While using a language different than C is a definitive no, I think Alexandre might allow the use of other languages in helper programs. The best way would be to write a separate program (which would have backends for all the needed toolkits) which generates a .msstyles theme (or if Vista uses a newer and better format, lets directly move to that format). The main issue would then be on how to sync themes. I guess that would need to be done at wine startup. Roderick > Hi, > > There is a discussion going on over at > https://bugs.launchpad.net/ubuntu/+source/wine/+bug/111061 about > improving Wine's look and feel to better match the system that it is > running on. > > The situation is as follows: > > == Colour Schemes > > Wine supports these by reading the settings from the registry. Winecfg > can load a .theme file containing a colour profile and adapt > accordingly (saving those settings to the registry). > > At the moment, if you need to script this (e.g. when installing Wine) > you need to manipulate the registry. It would be helpful if winecfg > (or some other helper utility) supported setting the theme file on the > command line. > > In addition to this, if the user changes the theme used on their > system it would not be reflected by Wine. > > == Windows Theme Support > > Windows theming support is in place to some extent, w.r.t. the XP > theming APIs. There are some user32 controls and the window/dialog > handlers that don't support theming yet and there are some performance > issues that need resolving. > > This would be set via the command line used to set the colour scheme > since they can be set via the same .theme file. This is limited in > that you need an XP theme for each native theme available. > > == Native Theme Support > > The main thing here is that Wine would monitor the native system for > theme changes. > > The colours of the native theme would be mapped to the Windows system > colours, saved to the registry and then a WM_SYSCOLORCHANGED message > would be sent to all open top-level windows so they could update to > the new look. > > Any metric data would be mapped in a similar way. > > As for the theme, an implementation of uxtheme would map the API calls > to the native calls. Here, it may be possible to just send a request > to redraw everything on each active window. If not, a WM_THEMECHANGED > message would need to be sent to all active windows. > > > The challenge with native theme support is two-fold: (1) it should > work on any system - some have Gtk, some Qt and some Cocoa/Carbon, > while others (like the *BSDs and OpenSolaris) are likely not to have > those engines available; (2) it should not break any Windows > application. > > Note that as Vista has a different msstyles theming engine (it is a > DLL), we could have the msstyles DLL expose the uxtheme API and have > uxtheme call msstyles to do the rendering. That way, we could have a > gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles that > would bind to the corresponding theming engine. If the msstyles DLL > does not expose those methods, the uxtheme engine could then fallback > to the current XP theme processing. > > For Mac theme support that would possibly require Objective-C code to > be done properly, that theme could be an external package (possibly in > darwine) that would be installed in addition to Wine. The same thing > for the Qt engines, allowing them to directly interface with the C++ > Qt APIs. > > Thoughts? Ideas? > > - Reece > -- GMX Download-Spiele: Preizsturz! Alle Puzzle-Spiele Deluxe über 60% billiger. http://games.entertainment.gmx.net/de/entertainment/games/download/puzzle/i…

Nov. 1, 2008

Re: [try 2] [2/2] mlang: Add implementation offnIMLangFontLink_GetCharCodePages

by Dmitry Timoshkov

"Vitaly Perov" <vitperov(a)etersoft.ru> wrote: > This function must set only supported codepages bits > The supported codepages are: > ttp://www.microsoft.com/globaldev/reference/WinCP.mspx Again, it absolutely doesn't really matter what code pages Windows supports, or MSDN declares as supported, the only thing that matters is what code pages are valid for mlang APIs. > For example, we use a symbol from Latin1 codepage. > All codepages are include this symbol. > So if we use EnumSystemCodePage() it enumerates codepages from the cptables > array. This array include all codepages. So when we use a symbol from Latin1, > all bits are set (I've tested it long time ago, so maybe I'm mistaken, maybe > 1 bit or 2 are not set). > But only the following bits must be set: > FS_LATIN1 | FS_LATIN2 | FS_CYRILLIC | FS_GREEK | FS_TURKISH | FS_HEBREW | > FS_ARABIC | FS_BALTIC | FS_VIETNAMESE | FS_THAI | FS_JISJAPAN | > FS_CHINESESIMP | FS_WANSUNG | FS_CHINESETRAD > > So, it's impossible to use EnumSystemCodePage() It *is* possible to use EnumSystemCodePages. > If we use codepages from mlang_data[], everything works perfect. Although yes, using code pages from mlang_data is preferrable. So, you can remove EnumSystemCodePages from the list of APIs to use. > The functions GetCPInfo/MultiByteToWideChar aren't also provide the list of > needed codepages. They do provide other information your implementation uses, like character size and lead bytes (although you don't need that information, therefore that APIs are not needed either). > There is one extra problem: > I can't find the size of the dbcs_table->cp2uni array, so It needs to > calculate it. This calculation works perfect, but maybe there is more easy > way to obtain it? Forget about Wine internal code page structures. Try for instance implement GetCharCodePages using only public Win32 APIs as an exercise. To find whether a mapping for a unicode character exists in some code page you could use WideCharToMultiByte(WC_NO_BEST_FIT_CHARS) for instance. -- Dmitry.

Nov. 1, 2008

Re: [try 2] [2/2] mlang: Add implementation offnIMLangFontLink_GetCharCodePages

by Vitaly Perov

> I can't read your mind or guess what those "some extra bits" are. Why can't > you mark the failing tests with todo_wine and think later how to make the > tests pass? > This function must set only supported codepages bits The supported codepages are: ttp://www.microsoft.com/globaldev/reference/WinCP.mspx For example, we use a symbol from Latin1 codepage. All codepages are include this symbol. So if we use EnumSystemCodePage() it enumerates codepages from the cptables array. This array include all codepages. So when we use a symbol from Latin1, all bits are set (I've tested it long time ago, so maybe I'm mistaken, maybe 1 bit or 2 are not set). But only the following bits must be set: FS_LATIN1 | FS_LATIN2 | FS_CYRILLIC | FS_GREEK | FS_TURKISH | FS_HEBREW | FS_ARABIC | FS_BALTIC | FS_VIETNAMESE | FS_THAI | FS_JISJAPAN | FS_CHINESESIMP | FS_WANSUNG | FS_CHINESETRAD So, it's impossible to use EnumSystemCodePage() If we use codepages from mlang_data[], everything works perfect. The functions GetCPInfo/MultiByteToWideChar aren't also provide the list of needed codepages. There is one extra problem: I can't find the size of the dbcs_table->cp2uni array, so It needs to calculate it. This calculation works perfect, but maybe there is more easy way to obtain it? -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru

Nov. 1, 2008

Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes

by Reece Dunn

Hi, There is a discussion going on over at https://bugs.launchpad.net/ubuntu/+source/wine/+bug/111061 about improving Wine's look and feel to better match the system that it is running on. The situation is as follows: == Colour Schemes Wine supports these by reading the settings from the registry. Winecfg can load a .theme file containing a colour profile and adapt accordingly (saving those settings to the registry). At the moment, if you need to script this (e.g. when installing Wine) you need to manipulate the registry. It would be helpful if winecfg (or some other helper utility) supported setting the theme file on the command line. In addition to this, if the user changes the theme used on their system it would not be reflected by Wine. == Windows Theme Support Windows theming support is in place to some extent, w.r.t. the XP theming APIs. There are some user32 controls and the window/dialog handlers that don't support theming yet and there are some performance issues that need resolving. This would be set via the command line used to set the colour scheme since they can be set via the same .theme file. This is limited in that you need an XP theme for each native theme available. == Native Theme Support The main thing here is that Wine would monitor the native system for theme changes. The colours of the native theme would be mapped to the Windows system colours, saved to the registry and then a WM_SYSCOLORCHANGED message would be sent to all open top-level windows so they could update to the new look. Any metric data would be mapped in a similar way. As for the theme, an implementation of uxtheme would map the API calls to the native calls. Here, it may be possible to just send a request to redraw everything on each active window. If not, a WM_THEMECHANGED message would need to be sent to all active windows. The challenge with native theme support is two-fold: (1) it should work on any system - some have Gtk, some Qt and some Cocoa/Carbon, while others (like the *BSDs and OpenSolaris) are likely not to have those engines available; (2) it should not break any Windows application. Note that as Vista has a different msstyles theming engine (it is a DLL), we could have the msstyles DLL expose the uxtheme API and have uxtheme call msstyles to do the rendering. That way, we could have a gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles that would bind to the corresponding theming engine. If the msstyles DLL does not expose those methods, the uxtheme engine could then fallback to the current XP theme processing. For Mac theme support that would possibly require Objective-C code to be done properly, that theme could be an external package (possibly in darwine) that would be installed in addition to Wine. The same thing for the Qt engines, allowing them to directly interface with the C++ Qt APIs. Thoughts? Ideas? - Reece

Nov. 1, 2008

Users posting to wine-bugs

by Luke Bratch

Hi You may remember me as the person that does the mailing list moderation. Every day there are always several users posting directly to wine-bugs, as they are hitting reply to emails generated by Bugzilla instead of posting in Bugzilla itself. I added a message in the text that Bugzilla generates to make it clearer to not reply to the email a few months ago, which at the time seemed to improve things but as of late the number of emails has been going up again. Is anybody opposed to me setting up an auto-responder so that any mail going to wine-bugs(a)winehq.org gets auto responded to with a message to post in Bugzilla instead? I ask this in wine-devel as I'm not sure who is the actual administrator of the lists are. Thanks Luke Bratch

Nov. 1, 2008

General script for installing Wine build dependencies

by Dan Kegel

I have in the past written one script per version of Ubuntu to install Wine's build dependencies. Many versions on, that's getting old, and I figure it'd be better to have a single script that handles all common versions on Linux. I've taken a first stab at that, combining my scripts for gutsy and hardy, and adding ibex. The result is at http://winezeug.googlecode.com/svn/trunk/install-wine-deps.sh If anyone wants to add support to that script for another OS, please do, and send me the patch. I'd like to see this in the wine tree sometime. It's kind of silly we have to direct people to a big, confusing wiki page (or set of them) to explain how to install the needed packages; let's just have a unified script and be done with it.

Nov. 1, 2008