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.
Indeed - at the moment the only way to do such a thing would be to use IPC. For apps that wanted to redirect API calls, could they not use the windows hooks mechanism?
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
Already happening with EWMH, menu specs and at some point notification area icons.
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.
Eurgh. My god. Please tell me you're kidding or have been drinking. We put so much work into Wine to run the applications, not because we think Windows is perfect and should be copied to the last detail. Anyway, there is already XPde which is copying XP to the last pixel.
At that point you'll have GNOME, KDE, WIND (WINe Desktop :)).
Well we already have GNOME, KDE, ROX, Enlightenment, as well as a seemingly infinite number of "lite" window managers.
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.
Well, good Unix integration is somewhat relative - having a Photoshop plugin work in the GIMP, using my WM and being able to read my Linux drives *at all* would be great integration from my perspective, using drive letters and win32 style open dialog boxes is an extremely trivial annoyance really. And as we're much further along with the complete-environment windows integration, it makes sense to use that, even if the results would be sub-optimal.
And of course we're ignoring that despite its lack of elegance at times, people already are integrating with Wine, but they're using IPC hacks, or ripping parts of the loader, or writing stub winelib apps, which is even less clean.
Well anyway, this is an interesting discussion to have, but I'm not able to write any code for even allowing GetProcAddress-level integration at this time, so take my views with a large pinch of salt :)