gtk look progress and pthreads.

[Mike Hearn]

> 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:
> 
> 1. 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.

> 2. 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:
> 
> 3. 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)

> 4. 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.

> 5. 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.

> 6. 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