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:
- 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.
- 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.
- 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.
- 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.
- A LGPL, neat implementation
That isn't finished ;)
Let's see how the other compare:
- 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.
- 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.
- 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.
- 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.
- 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.