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
Hi,
Test.winehq.org is the new home of the cross compiled winetest.exe. Alexandre
put in some magic to create the new winetest.exe on winehq.
The new link:
http://test.winehq.org/builds/winetest-latest.exe
The link can also be found at the bottom of the test.winehq.org index page. I
already changed the wiki to reflect these changes.
This also means that Paul Millars winetest is no longer available. I'd like to
thank Paul for all the hard work he did with keeping up that site and providing
us for years with a cross compiled version of winetest. I also like to thank the
people that provided the necessary MinGW patches in the past to get that
winetest compiled again.
--
Cheers,
Paul.
Different error than usual though:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator,
bugs-admin(a)winehq.org and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
</body></html>
Is there anything we can do to prevent it from going down so much?
--
-Austin
Hi,
I'm in Southern California.
I did a search for the event when my
Office 2000 Professional gave me an error
message. It won't setup.
The event was 1000
and the fault address is the same as a
read out of your computer that you posted online.
http://www.winehq.org/pipermail/wine-devel/2003-July/018313.html
Did you ever figure out how to get it to work?
Thanks!
Ciao!
Connie
Maarten, could you look at http://bugs.winehq.org/show_bug.cgi?id=16297
as you're the author of 717df5b2972b3cb998ca5a43279ae2283b117eaa? I
tried adding you as CC but bugzilla complained.
Hi all,
I had managed to fix my selinux/wine/mono problem in fedora 10... it is actually two issues, in fact:
1) fedora 10 ships some much stricter selinux policies (but make some exception for wine).
2) I have kernel support for miscellaneous binary formats
enabled and have win32 PE registration in the kernel, and run
win32 mono.exe (or other PE executables) direct from time to time.
so "wine [path]/mono.exe [.NET.exe]" works within the restriction of f10 selinux policies, but "[path]/mono.exe [.NET.exe]" does not. I could either relax the "execmod" policy in selinux, if I want to run any PE .exe's wholesale; or I just need to remember always putting "wine" in front of PE .exe's I want to run...
Sorry for the noise.
