On April 27, 2003 12:47 am, Francois Gouget wrote:
Only as far as commercial companies are concerned. Under the GPL license, anyone can fork QT.
And you think this is any way acceptable? I am sorry, but an OS that puts commercial development at such a tremendous disadvantage (that is, subject to the monopolistic whims of one company) is not a platform. So all the portability issues you listed don't even start to apply.
So you're saying Linux developpers should abandon Gnome/Gtk and KDE/QT and instead develop using Win32+OLE+COM?
No! Unfortunately, KDE/QT is in a difficult situation due to the licensing problem. It is the desktop of choice for most people, I use it, but I can't see what we can do about it.
I'm not criticizing, I'm trying to clarify because in one of your previous email I had the impression that you advocated development against a Win32-based Gtk API.
Gtk is already ported to Win32. App wouldn't even know what Gdk backend is used, they would be just the same.
What about graphical applications? In the Windows world most applications don't use Win32 directly for the GUI. Should we provide an LGPL implementation of MFC? Implement a replacement for Visual Basic? A binary compatible one?
I am mainly referring to graphical apps. And no, commercial apps provide their own framework just like they do now. It'd be nice to have efforts toward a free MFC implementation, but it's besides the point. It's an orthogonal issue.
What API would open-source developpers use for WIDE applications?
They have a choice: Gtk/Gnome, wxWindows, Win32. There are a lot of free apps (see the top SF downloads for examples) that use the Win32 API, so it's not something new I'm suggesting? Do you think it's more moral/ethical to treat these apps as second class citizens in Linux?
Yes it would be very cool. I am far from being an expert on OLE/DCOM but I have been told that it may be feasible. Probably a heck of a lot of work though.
I'm not saying it would be easy. But given that Bonobo was so deeply inspired by OLE, I'm hoping it can map easily onto an OLE backend, and maybe that leads to an easier path to integration.
But AFAICS what's needed is much smaller in scope from what you propose with WIDE.
Hm, it seems I have problems communicating. In fact, it seems to me we have most of the pieces for Wide already.
Other questions so I better understand:
- are you proposing source-level compatibility or binary level
compatibility?
Both. We get both with Wine, we should be able to keep that.
- if it is source level, does it mean modifying gcc to support the
Visual C++ COM extensions?
It would be nice to have gcc support for those, but this is independent of the Wide effort. Just like we have support for other stuff that was added through the MinGW project.
- how do you propose to handle the issue of drive letters?
What we do in Wine is just fine. I'm only concerned with GUI apps, and there I see drive letters as just shorthands to a bunch of dirs. If you like that, go nuts. I see it as mainly a UI thing, other than that we'd try to pass Unix paths around as much as possible.