On 14 Apr 2003, Alexandre Julliard wrote:
Even if you need some GUI support, or some registry calls, you most likely don't want to use the Wine variant of them. You want to add stubs to make the calls integrate with your apps; you want controls drawn by the dll to look like your other controls, you want settings to be stored in your app config file not in some mysterious system.reg file, you don't want paths to contain drive letters, etc.
Yes, you are describing an ideal world, but it looks very unlikely to happen. In fact, it's similar to the QT vs. GTK debate. Fact of the matter is, there's no unifying the two, there are here to stay as separate thing, even if people try to build one on top of the other. And the scenario you present is also very unlikely to happen -- a thing that should take days will take weeks or month to implement for little gain. Yeah, you'll get a dialog box that looks a bit different, so what? Availability always beats perfection. People would love for example to have Photoshop plugins work in Gimp now with slightly differnt dialogs, than to wait month/years for someone to create a perfectly looking GTK dialog on top on some Windows code.
In a way, Wine is just another toolkit (from a user point of view). The integration work will be through things like freestandards.org, RedHat BlueCurve, etc: http://mail.gnome.org/archives/desktop-devel-list/2003-March/msg00001.html
In fact, once we do Wine 1.0, people may decide to build a desktop environment around it. I think this is very exciting possibility, and I think we can even beat KDE and GNOME despite their big lead. I don't even think it's that much work (we need a panel, a file browser, and a control panel), we will have a lot more apps than they do, and we'll have far better binary compatibility.
At that point you'll have GNOME, KDE, WIND (WINe Desktop :)). Do you think app writers will abstract their stuff so they have perfect integration with each and every one of them? They don't do it now for GNOME and KDE (when there is an incentive to do so, in the future thinks like BlueCurve will remove big part of that incentive).
I don't think that's feasible, at least not without a major change in our development philosophy, which IMO would impact binary compatibility. If you want a lightweight environment, and good Unix integration, what you want is to write a wrapper as thin as possible, that calls to Unix immediately. For instance an open file dialog should resolve to a Qt or Gtk dialog. In Wine we want just the opposite: we want high level features to use the low level features, and call to Unix as late as possible. So the open file dialog calls comctl32, which calls user32, which calls x11drv, which calls the registry, which calls the server; and you end up pulling in most of Wine for what seems to be a trivial function.
Well, but his can happen within the Wine framework. If anyone wants to put in the effort to do such a thing (which I doubt, but hey!), they can create another implementation of the comctl32 (which will work even better when we move the standard controls in there, like XP). Then you can use one or the other.
But I'm afraid this approach is hard, and it will never work reliably due to very complicated Windows controls (custom draw, owner draw, etc).
The more workable solution would be to make our controls theamable (like XP), and have styles that try to render them in the currently selected style (say BlueCurve). The users shouldn't care what toolkit the app uses, just as it should not care or see what language the app has been written into.