James Gregory wrote:
Ok, fair enough. Let me start by prefacing this: it won't be perfect, it can't be perfect. I am doing this as a starting point for getting Wine a bit more integrated with Linux. In particular I would like it to integrate more with the GNOME desktop I use (no technical reason to choose GNOME over KDE other than I use GNOME so I'd be able to test the code I write :)). I have only thought through the first few steps; after that I'll be in a better position to see what direction to take next.
Integration is a good goal! It's great that you're thinking about it.
re: bloat - I'm currently intending for this to be a compile time option. I don't think it will exacerbate the situation that most linux desktop users are in right now. The existing infrastructure works and should be kept for applications where memory and cycles are at a premium.
Even if you make it a compile-time option, it's important to avoid increasing the RAM consumption or startup time of wine applications.
Come to think of it, we probably should be doing regular measurements of RAM consumption and startup time of a few typical apps (e.g. Notepad, AbiWord 1.0) and make sure the trend is *downwards*, not *upwards*.
Rough plan:
- Get Wine to use the same colours as current GTK theme. I had thought
that this would be a relatively harmless, straight-forward patch that would save me from the shock I get when switching to the desktop I often have running IE. I use Bluecurve, and the dark greys of Windows apps are extremely distracting.
- Get Wine to use the same fonts and font sizes as the current GTK
theme. I have much the same ends in mind as (1) here. Again, this shouldn't really affect usability. It's just for reducing screen-shock.
As Mike pointed out, we need to implement XP's native theming APIs anyway, so that's where you should start. You can hook in to the gnome and kde theme config files at that level, and the changes will naturally affect all apps, just like you want. Or so I gather; I haven't ever used them. Here what I just dug up: MSDN's page on this is http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/programmersgu... Windows Themes are controlled by ascii files (in .ini format) with suffix .theme. See http://www.tgtsoft.com/ for a collection of tools that make it easy for the average user to create .theme files.
-- evaluate position here, maybe proceed as follows:
- use GDK's gdk_window_new_foreign() to get GdkWindows out of the X
Windows that Wine is using, pass these to the appropriate GTK functions to render some widgets using GTK. Stuff like buttons etc. Text boxes in particular are a problem. I have not yet figured out precisely what to do with them. It is conceivable that they could be similarly hacked in, but it would be much more complicated. Existing event handlers would need to be patched to make similar calls to GTK in order to use the 5 states of GTK widgets.
- Maybe add a GDK driver to WINE. Porting the X stuff to GDK should be
reasonably straightforward, though I'm not sure that it's necessary. It would simplify code written in (3) though.
- Possibly replace some (maybe all) of the common dialogs with their
GTK counterparts - this starts introducing inconsistencies in button placement etc, which is why this is only a "possibly" and leads on to...
- The fun bit: depending on how things are at this point I am
considering adding some simple heuristics to get things to start feeling more GTK/GNOME like. Tricks like using the tab index and the text on buttons to identify "OK" buttons etc and using the stock GTK-OK button in its place. Likewise using tab-index to dictate button placement (GGAD says button placement should be in the direction you read with most likely selection "first", so for english, the least tab-indexed button should be placed on the left, probably with some other constraints). I would remind you of my disclaimer at the top at this point. :) - I'm not entirely convinced of this myself, so there's no need to try to dissuade me on this point just yet.
- STUFF NOT DIRECTLY RELATED TO GTK, BUT RELATED TO INTEGRATION :
An entirely separate idea I had was to patch Wine to (optionally) use gconf to store registry data in. WINE & gconf seem to me like they were meant for each other, the one obvious hurdle being that gconf doesn't do binary entries - this would need to be implemented with some sort of string to signify that an entry was in fact binary data, followed by a hex-encoding of it or something (or convincing the gconf guys that they really do want binary data in gconf).
All of the above sounds like you might be heading off in the wrong direction a bit. A GDK driver would be useful, but not for the reasons you give. Basically, you seem to be a true believer in the gnome API's. That's great when you're developing apps, but when you're developing platform software like Wine, you should probably take a much more conservative tack. Let's look for ways to integrate with Gnome and KDE that are based not on linking in huge gobs of code, but instead are based on common file formats and protocols! I encourage you to bring up your ideas not just on the wine mailing list, but also on xdg-list@freedesktop.org (see http://www.freedesktop.org/ ) At least one fellow there has thought about this a bit; see https://listman.redhat.com/pipermail/xdg-list/2001-March/000072.html
What sort of things are likely to be broken in linking to gtk? Where do I want to look if I want to try to fix this?
I suppose a good place to start is the source of that FIXME message.
It's probably the same issue Mono had: Wine doesn't use pthreads. We need to fix this, but it's a pretty big job.
by "fix this" - you mean get WINE to be pthreads linkable / use pthreads or something else entirely? Is this something that I can help with?
Sure, but it's a really big job, probably bigger than you want to tackle. I'd suggest going the "windows theme" route instead, and figuring out how to hook that into gnome or kde themes. (I think Windows implements its themes in comctl32.dll, and you could stick in magic code there that would read the gnome or kde theme info.) Not only would it be easier, but it'd also make us more compatible with XP, thus killing two birds with one stone.
- Dan