Support for pkgconfig

[Mike Hearn]

> Maybe. We do have a few big advantage. Unfortunately Qt is GPL and for
> taht reason I don't think it's viable to become the standard for Linux
> desktop. I'm not the only one thinking this way, that's why RedHat it's
> pushing GTK. But regardless, this is another discussion.

Well, at this point I seriously doubt any widget toolkit or platform
will end up the standard, not that it matters much these days anyway,
once we have unified theming as far as the end user is concerned Qt and
GTK apps will look practically the same anyway (minus HIG differences).

> Let's look at what we bring to the table:
>   1. Stable API *and* ABI

Only while Microsoft are around. Wine is effectively slaved to what
Redmond do - where they go, we must follow. Losing control of our own
APIs is a bad idea. Also Microsoft are moving away from Win32 to .NET
anyway.

>   2. Well known programming environment

I don't know that many people with a lot of experience with Win32, they
are all VB/Delphi/MFC coders. I'd guess most of them have used it a bit,
but as I've been discovering, knowing how to call the API occasionally
is very different from writing entire apps with it.

>   3. A working, tested and accepted object embedding standard

Yes, that is true. Linux needs a component model badly. COM/OLE would
never be accepted by the community though, not even a derivative - it's
not even certain for Mono/.NET which gets binary compatability at the
bytecode level as well in a much cleaner and better documented fashion.

>   4. A lot of standardized interfaces lacking currently in Linux

Hmmm. Like? Ignoring OLE we have equivalents for most that are widely
accepted:

comctl: Qt or GTK
WinSock: UNIX sockets
DirectX: SDL (ignoring directmusic which nobody uses)
Direct3D: OpenGL
Windowing/Graphics: X11 (abstracted by the toolkits anyway)
VFS layers: well, there is no standard yet but I don't think making one
would be too hard, and I'd note that the VFS situation in Windows is
poor also, writing shell plugins is a vision of hell.

Yes, there are still some parts missing, and for some things there are
several possible implementations (HTML renderer), but really I doubt
there are that many critical interfaces lacking.

Also you have to remember the issue of control.

>   5. A LGPL, neat implementation

That isn't finished ;)

> Let's see how the other compare:
>   1. KDE: broke API compatibility on every major release, as
> 	  well as ABI compatibility. They claim they'll keep
> 	  API compatibility, but ABI compatibility is likely
> 	  to be broken in the (no so distant) future. This
> 	  is a big no-no for ISV, it certainly doesn't sit well
> 	  with me (mind you, I am a KDE user)

ABI compatability is less of an issue on Linux thanks to proper soname
versioning/symvers etc. Windows has broken it too of course, winsock1,
winsock2, D3D versions and so on. MSXML1,2,3

>      GNOME: broke API compatibility from 1.x -> 2.x. It is
> 	  true, it looks like they're gonna stick to the new
> 	  one, and they are a lot more likely to maintain
> 	  binary compatibitity in the future. But porting
> 	  stuff to the 2.x API is going slowly, and the project
> 	  seems to have lost steam.

AFAIK it's almost all done, the big one we're waiting for now is
Evolution for which the port is nearly finished (but they want to make
it HIGified I think). There are still a lot of GTK1.2 apps out there,
but much development/cvs software has moved to GTK2. Again, it doesn't
matter that much, you've got similar issues on windows with comctl32
versions.

I'd expect more ABI churn while the linux desktop is developing, if you
look at other areas it's far more stable.

> 
>    2. KDE: it's C++, and a lot of people don't like that.
> 	  Yes, they do have bindings to other langauges,
> 	  but they often lag behind, it's simply not a viable
> 	  alternative.
>       GNOME: they justs switched to the new 2.x API, it's
> 	  new, people by and large don't know it. It takes
> 	  a lot of time traning 100 of thousand of programmers.
> 	  However, it seems to be a decent API, so it is
> 	  a promissing alternative.

It's alright. Documentation is rather poor. MSDN beats, well, pretty
much anything, regardless of how much we like to bitch about
undocumented stuff. Open source is much worse :(

The GNOME/GTK bindings for popular languages are pretty good though.
Again, zero documentation, but they work well and are tested/mature.

>    3. KDE: KParts. Very non-standard, many people don't like it,
> 	  it is only KDE that can use it. I really doubt it
> 	  that it will ever become a commonly accepted standard,
> 	  no matter how nice it may be.
>       GNOME: Bonobo. Copied fairly closely from the Windows world
> 	  why is it any better? In fact, the entire CORBA thing
> 	  sucks badly, we'd be a lot better of with binary compati-
> 	  bility with OLE. How cool would it be to have Word
> 	  embedded in gnumeric? :)

Yeah, I've long believed COM/OLE beats the pants off any open source
solution. KParts and Bonobo both have their strong points of course. On
the other hand, Microsoft are leaving COM behind for .NET anyway, and
who can blame them? COM is old and crufty.

>    4. We just have more APIs for stuff. Yeah, some of them are
>       ugly, some not needed, but most are accepted and used by
>       people, which is what matters in the end.

Accepted and used *by Windows coders* because they have no choice. It's
been possible to use Wine to write apps that work on both Windows and
Linux for a long time, I'd guess it wouldn't be hard to avoid or fix the
occasional bug or missing piece of Wine. Yet, no Linux coders do it.
They use wxWindows instead if they really want portability, or
GTK/Win32.

>    5. KDE does not qualify unfortunately. GNOME is OK on this
>       point.
> 
> I think we should change a bit our point of view. We are comparing
> Win32 with GTK and QT. Not fair. We should compare it with Xlib,
> and then it becomes clear that it gives us a lot more.
> 
> The scenario that like to happen (and is preferable from almost
> any conceivable point of view) is to have Wine _below_ GTK, not
> the other way around:

You mean so that GTK/Qt both map to the Windows APIs? I guess you could
introduce another layer, but I don't see what this buys us that using
freedesktop style standards does not.

------------------------------------------------------------
| GTK | Qt | GNOME | KDE | Wine | OpenOffice | Mozilla/XUL |
------------------------------------------------------------
|        Xlib       DBUS       .desktop files (etc)        |
------------------------------------------------------------

Really the parts of Win32 that Linux lacks are rapidly being filled in
with the exception of a component model, and usually end up being nicer
than the old Windows equivalents as well because we can learn from what
worked and what didn't in Win32.

In terms of platforms, our current problem is that we have too many due
to politics, because our major web browser/office suite was written to
be cross platform originally and the need for compatability with
Windows.

The answer would seem to be to suck the platform out of all these
products and into a standardised, specified layer. Which is what is
happening. It might be more work than just adopting Win32 wholesale but
it's politically acceptable and will give nicer results.

-- 
Mike Hearn <m.hearn at signal.qinetiq.com>
QinetiQ - Malvern Technology Center