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.
Sure. There are quite a few other things that you could do that'd improve integration for everybody though first - for instance, the system tray code was broken by the recent switch to an XEmbed protocol. The system tray is a fairly commonly used feature by Win32 apps, and it doesn't work :(
Other things would be, as you say, using the freedesktop MIME spec (when it gets written, i don't think it's done yet, but you could always help with that too :)
Fonts are a good idea too.
Stuff like colours, themes etc would be very hard to do unless the app was aware of the XP theming APIs. Many Win32 apps draw their own custom controls, but in such a way that it fits in seamlessly with the win9x look. XP exposes some APIs so that people using custom controls can make things fit in nicely still. Even then, it'd still use XP style artwork etc, which is why I think these features are nice to have but wouldn't work very well "out of the box", you'd need to put in the legwork to make it HIG compliant etc.
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.
I don't personally think bloat is a problem, 95% of users will have GTK mapped into memory already. Complicating the code is a bigger deal.
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.
Agreed, it'd be nice to get this customisable. I'd do it by directly reading the gtkrc however.... assuming you can do this still. Like I said, if you need to use a theming engine it's best to actually work with the Win32 port of GTK.
- 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.
Yeah, that's cool.
-- 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.
Ah, you'll run into issues with that. Actually using native toolkit widgets has been tried twice, and failed both times. The first was in the early days of Wine, when instead of actually implementing the controls they were mapped to Tk. Didn't work well. The second time was with Mono and System.Windows.Forms, when they tried to map it to GTK. Didn't work. The devil is in the details.
Adapting the button code to perhaps use the GTK theming engine is certainly possible, if you use the gtk windows port (because then it'd all be piped through the gdi)
- 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.
Hrm, why? GDK simply maps to X anyway, and that'd be probably impossible, Wine needs direct control of X to do some things.
- 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...
This is doable for sure, but would be hard to do well all the time, as apps often customise dialog boxes by adding custom controls etc. Also, for instance for the file dialog, you need to restrict the user to what Wine allows the app to see. That'd be pretty hard to do well.
- 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.
As I said earlier, probably very hard to do in a way that doesn't feel "half way" which imo is even worse than not at all - non HIG gnome2 apps really feel bad to me these days :)
- 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).
Nooooooo, part of the appeal of GConf is that it *isn't* the Windows registry. It's design isn't designed for registry style mass dumping of info, and its own creator says "don't try and store binary, don't even assume you can write to it - it is for personal preferences only".
This last point opens up possibilties like registries stored in ldap, and access control over particular keys. It makes the notion of a centrally administrated WINE multi-user system a little more attractive (to me anyway).
I think those features would be better to be put onto the Wine registry itself.
I also think it would be cool to have some mappings between common windows settings and GNOME settings - stuff like setting IE's home page to be the same as X GNOME browser. Ditto proxy settings etc. This might go into WINE or into another layer entirely. I'm not sure yet.
Well this stuff should be standardised at freedesktop.org, then picked up by Wine in the core. All these integration things need to be specced out really, rather than being gnome specific.
I'd also like to start looking into ways to get Windows apps into .rpms / .debs. ie code to trace what files and registry entries get touched in a given invocation of wine, and dump this to an .rpm / .deb (either from a log file or on program exit) - this isn't directly related but it's part of the integration thing that got me started on all this.
I've been doing a lot of work with app packaging on Linux lately, see autopackage.org to find out what i've been getting up to. It's a nice idea, and would have some advantages. Again, it'd be hard to do well.
Having said that, I think this would be rather difficult, RPM and InstallShield style installers are too different. For instance, InstallShield allows lots of user interaction, customization of components etc. As of yet, no Linux system allows for this. I hope soon we will be building one that does :)
Licensing is the responsibility of the user of course (as it always has been), but it does give enterprises a great way to push out the software that they need on all their desktops, and offers capabilities like using the existing apt-get/urpmi/up2date code to keep WINE software installations up to date in a clean manner. This also implies that I'd like to see a standardised place for installation of WINE software -- I'm not aware if one exists, but I think it would be a good move to start recommending one.
Well normally it'd be in your fake windows directory, but there is no standard place for this, I guess you'd have to read the wine config file. It might be worth putting something in the FHS about that.
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?
Indirectly, this is kind of a good example of the challenges faced. Basically, Wine is two things:
1) An implementation of parts of the Win32 APIs. For instance, it contains a replacement for the common controls library, and in theory it can be dropped into a Windows with no problems.
2) A mapping layer between some of the APIs that simply cannot be reimplemented and their native Linux equivalents.
For instance, Wine can't really drive the hardware directly like Windows does, so the window management APIs are mapped to X. Direct3D is mapped to OpenGL.
The main problem with these kind of mappings is that it's very hard to get them exactly right. Window management bugs have plagued Wine for years, and for instance Dungeon Seige directly blits the mouse cursor into the rendering backbuffer, something that Direct3D allows for but OpenGL simply does not.
And then we have threads. The friction between Wine threading and glibc pthreads has been the cause of a lot of concern here on wine-devel lately. Basically Wine has had its own threading implementation for quite some time now instead of using pthreads, and recent changes in glibc have b0rked it. So, Wine has to be ported to pthreads for it to work properly in future. That'll solve a big problem for people who use pthreads and want to link in with Wine, but it introduces others.
The higher level you perform the mapping, in other words, the harder it becomes. Files are files, on UNIX and Windows, and so Wine uses the unix filing system rather than using its own FAT partition in a file for instance, but subtle differences can cause issues (locking, case sensitivity etc). It's for that reason that Wine prefers to implement things as "sealed" implementations where possible, ie implementing its own widget library rather than using GTK.
Hopefully I'm making myself clear... basically I think some of your ideas are great and should definately be done, but not always in the way you're suggesting. Trying to make Windows apps use GTK won't work, the contention between GTK and Windows common controls is too high, but maybe letting the Wine common controls lib read colour and font prefs from the system will work.
thanks -mike