--- Mike Hearn mike@navi.cx wrote:
On Sat, 2005-03-12 at 21:00 +0000, Oliver Stieber wrote:
Ah, that's different. That'd actually require
using
Gtk/Qt which we cannot do, the best we can get is to look like them.
What's the problem, licensing, integration or thread-safety (I know QT isn't thread safe)
Well all those *could* be problems, but the real problem is that the Windows widget toolkit and GTK/Qt are too different, you can't map between them.
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.
I may have a look at that too, it would be useful
if
QT/GTK could use some of the existing Windows accessibility software.
No, that's not what I meant. Implementing OLE accessibility would mean that Win32 apps on Wine appear to in native tools like at-poke. It wouldn't mean you could use win32 accessibility software to access native apps.
That doesn't sound too hard, I don't know how well defined Gnome and QT's accessibility interfaces are but I think QT's coming along quite well it would be nice is everything got Dbused though.
Send instant messages to your online friends http://uk.messenger.yahoo.com
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.
It was tried, back in the early days of the project (to Tk). But it failed.
That doesn't sound too hard, I don't know how well defined Gnome and QT's accessibility interfaces are but I think QT's coming along quite well it would be nice is everything got Dbused though.
Well the Qt/KDE a11y stuff is integrating with the GNOME APIs, as Sun developed the a11y infrastructure on Linux basically for GNOME. It's based on CORBA and yes it's quite well defined.
thanks -mike
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.
It was tried, back in the early days of the project (to Tk). But it failed.
That doesn't sound too hard, I don't know how well defined Gnome and QT's accessibility interfaces are but I think QT's coming along quite well it would be nice is everything got Dbused though.
Well the Qt/KDE a11y stuff is integrating with the GNOME APIs, as Sun developed the a11y infrastructure on Linux basically for GNOME. It's based on CORBA and yes it's quite well defined.
thanks -mike
.
Couldn't you just wrap the theme engine, like the GTK-Qt Theme Engine does?
--Mitchell Mebane
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 -
Mike Hearn -
Mitchell Mebane -
Oliver Stieber