Theming for Wine via the registry

James Gregory james at linuxaus.com
Sat Mar 19 19:22:56 CST 2005


On Sat, 2005-03-12 at 22:36 +0000, Mike Hearn wrote:
> On Sat, 2005-03-12 at 22:15 +0000, Oliver Stieber wrote:
> > The only problem I can see would be drawing the
> > widgets, I haven't looked deeply enough into QT or GTK
> > to know if it's more on the 'impossible' side of
> > difficult or not.
> > 
> > Wrapping the event loop and passing events should be
> > relatively easy.
> 
> You have feature mismatches, eg GtkTextBuffer cannot do some things the
> richedit control can, Win32 menus can't do some things that GTK can etc
> etc. Also getting the message/paint sync especially for subclassed
> windows would be impossible. Basically we have to do our own widgets, we
> can't actually map win32 widgets to some other toolkit. 

I've actually tried getting Wine to use GTK widgets. I made some
progress but hit some issues that I wasn't sure I had a solution to.

It is true that the controls in Wine and GTK have different semantics,
however matching semantics probably shouldn't be the first goal you try
to achieve. To begin with, you just want to get GTK to draw the widgets
and let Wine feed GTK's rendering engine with enough information to do
what it needs to. That is, Wine would still intercept all the mouse
clicks, keypress events etc and use that to update the state of the GTK
analogue of each of your widgets.

If it turns out you can get that going, then it's probably worth
thinking about other modifications to Wine's behaviour, probably based
on some configuration file. Reversing the order of buttons for example.

It's also worth remembering that there are a bunch of controls that will
work just the same. Checkboxes for example.

Now, when I did this, I asked the gtk widgets to draw themselves
directly onto the X windows that Wine used. That won't work. There was
something going on in the way GTK handled X events that left my widgets
half rendered.

What would probably work is to use the windows port of GDK to do the
actual drawing. That way, X messages would still be dealt with by wine
and this drawing code would just be another thread managed by wine like
any other. There are some other hurdles to overcome in doing this, but I
think that approach would get you somewhere.

I started prototyping what I'm suggesting to you and found that there
was a missing wine feature that stopped glib from working. I'll try to
have a look some time this week and see if that's still the case.

On the question of mapping colours though (which is where this thread
started): I had some code in my local tree which would query GTK for the
colours it was using for various widgets and set the equivalent registry
entry for Wine. It was relatively straightforward and I can probably dig
it up if anyone's interested. It really did look quite weird for some
themes though. GTK gives you a lot of control over the colours used on
widgets. The basic colour mechanism in Windows doesn't give you the same
level of control. To get it to look "right", you'd really need to use
GTK widgets.

Keep us informed on this. I'll offer any feedback I can from my
experience in doing this. If there's anyone here really familiar with
the windows GTK port, maybe we could combine resources to get this
working.

James.

-- 
James Gregory <james at linuxaus.com>




More information about the wine-devel mailing list