GNOME Bugzilla – Bug 109615
Consider including Windows native theme
Last modified: 2011-02-04 16:17:01 UTC
I haven't looked at the code, but it seems like http://gtk-wimp.sourceforge.net/ or a functional equivalent should really be the default theme on Windows.
Oh, Overlord, please don't! Not yet! :) I am just coming from a long discussion from the GTK+ Windows porter and the Windows maintainer of Gaim. The WIMP theme brings Windows *down to a crawl* as of the latest GTK+ releases. I had to re-install Gaim+gtk on windows and specifically telling it to not install any theme, in order to get normal performance. Others have also seen this problem, as Herman told me. If someone is willing to check out what creates the problem and fixes it (note: I use a dual machine), then I am all for making WIMP the default on Windows. However, I must point out that the theme needs a bit more work to look a bit better. Currently it looks so white that my eyes hurt after a while...
Please give the latest GTK-Wimp release (0.5.0) a try. We have fixed several major issues. This new release feels a lot snappier now. As for inclusion into GTK+, this should (of course) only happen if proven stable. Regardless of stability issues, perhaps we can at least make some initial steps and move over the current CVS archive over from sourceforge to cvs.gnome.org, and introduce a bugzilla component for GTK-Wimp. The sourceforge bug tracker is really tiresome... If you guys decide that GTK-Wimp is not to be placed into the GTK+ tree itself, than GTK-Wimp could perhaps get its own home on cvs.gnome.org somewhere...
Plan is to include this theme with GTK+ proper rather than in the gtk-engines package
Owen/Tor, there has been very little progress on solving this issue. On my part, this is caused because I do not feel very confident to just go ahead, plunge GTK-Wimp somewhere in the GTK+ tree and be done with it, without having solid backing from one of you two guys. I also have some reservations about whether or not this integration thing is the proper thing to do. GTK-Wimp is simply a theme, and is not directly dependent on any of the GTK+ source files. The current loosely coupled approach has several advantages, such as GTK-Wimp not being tied to the GTK+ release cycle, the ability to do separate releases, and so on. All in all, we currently have a clear separation of concerns. Furthermore, integrating GTK-Wimp into GTK+ does not really provide any benefit for our end-users, because most applications/installers I have seen so far already include GTK-Wimp by default. Yet, I must admit that I am getting warm feelings from having some form of official GTK+ blessing by becoming integrated which is why I am keeping an open mind. So, my question is, do you still want to go ahead with this?
Raymond - There are several reasons that make me think that integrating this code into the GTK+ source base really is the right thing to do. - I really want to encourage thinking of the win32 native theme the win32 backed, and in fact, the GTK+ widgets themselves (via style properties or GtkSettings) as cooperating pieces where all are modifiable to get optimum integration. I don't think that integration can be isolated just at the theme layer. - The win32 installer situation is, in my opinion, a bit of a disaster. Anything we can do to increase standardization of how GTK+ is installed on Windows is a win. Or to look at another way, if there is code that depends only on GTK+ that all users of GTK+ on windows should be running, there simply isn't a good reason *not* to have it part of the GTK+ distribution. You'll have a full go ahead to make whatever changes you want to the win32 native theme, even for stable releases. The schedule we are trying to work for now is: - Stable branch releases every month or so (more frequently if an urgent bug is found) - Major releases every 9-12 months. Assuming I can convince you of the above, what technical details need to be dealt with? Did we finalize the directory structure? How we were going to do the import? If you want to provide a tarball of a CVS repository, I can unpack in the appropriate place to preserve history, or we could do a reimport without history.
ok, mclasen contacted raymond this weekend and wanted to see this move forward. to that end, raymond and i are committing our last patches to gtk-wimp and releasing version 0.6.2 on Monday. after that (and with your permission, of course), we'll give you a tarball of either the CVSROOT or just the source. after that, you cvs add the files, and life is good i suppose. i'll be lurking in #gtk+ if someone wants to discuss this in real-time.
Status update: 0.6.2 has been released. It will take about 1 day before I can give you a tarball of the CVSROOT, because on sourceforge CVSROOT tarballs are built nightly. Concerning the directory structure, the plan is to place things into: "gtk+/modules/engines/ms-windows/"
Did this get stuck again ?
The CVSROOT tarball is already in place, meaning the transfer to gtk+ cvs is complete. What still remains to be done is the following: a) integrate gtk-wimp into the main gtk+ build process, both for autoconf and Makefile.msc-style. b) Add a bugzilla component dedicated to gtk-wimp (err, ms-windows-engine) After that, I think we can close this bug. I am a little bit pressed for time currently, so I will not be able to attend to a) the upcoming few days. If somebody else wants to do this, great.
Ah, I should use `cvs up -d` from time to time... thanks a lot.
I've added the necessary auto* bits. msc build integration will have to be handled by Hans. I'll also add the bugzilla component.
My local disk has the necessary changes, but if I commit do I also have to fix bugs like bug #112401 myself ?
I think this is done. Reopen if not, Hans...