Support for pkgconfig

[Dimitrie O. Paun]

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.

-- 
Dimi.