Support for pkgconfig
m.hearn at signal.qinetiq.com
Tue Apr 15 04:47:46 CDT 2003
> 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:
Already happening with EWMH, menu specs and at some point notification
> 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 :)
Mike Hearn <m.hearn at signal.qinetiq.com>
QinetiQ - Malvern Technology Center
More information about the wine-devel