On 12 Mar 2001, Jean-Marc Lasgouttes wrote:
> I do understand why a native GUI windows binary would be a good thing,
> but we have to be more ambitious than that: iwe want to infect
> windows users/developpers with the GPL virus :) More seriously, we
> will _never_ have a good windows product without a windows developpers
> community. It is as simple as that.
Here's my take on the native Windows issue:
We have only three realistic options at this point in time:
1) Use Qt
2) Use MFC
3) Use native Win32 windows
Each issue has mayor drawbacks:
1) requires licenses for Qt on Windows for all developers that work on
the windows port. It's not enough that Kalle has one, because otherwise
we will never achieve momentum enough to support the port: One man is
not enough.
2) requires MFC. This implies having Visual C++, or some similar
development platform with MFC. I know the free (as in beer) Borland C++
compiler can compile MFC, but I'm not sure it is included with the
compiler. Since Visual C++ is the de-facto standard compiler on Windows,
this might stand a better chance of gaining enough momemtum to support
the port.
(Cygwin can not compile MFC, and probably never will since it's not API
compatible).
3) is comparable in effort to a Motif port: There is basically no help
from the toolkit: You have to code everything by hand, and implement
all message handlers for each dialog by hand. In other words: A lot of
work. The good side is that you can use either the true free Cygwin C++ or
the free as in beer Borland compiler.
So 3) is the only one that is free as in free speech, but it's also the
least modern solution in the sense that it will take a lot of effort
to do the port. The code will be more C than C++.
Personally, I think 2) would be the best strategic solution, because
if you want to grab some interested and skilled Windows developers, it's
safe to assume that they have Visual C++, since it's the de-facto standard
C++ compiler in the same way as gcc is the de-facto standard compiler on
Linux.
Even if Troll tech or some other party donated 10 Qt licenses for LyX
developers, it would be hard to get going, since basically no Windows
developers know Qt. The people would have to be "unix-converts" that
know Qt from Unix, but for some reason have a genuine interest in a
Windows port.
But, there is no point in introducing a policy on this from the LyX
developers side: Any solution might work out, given a skilled and
motivated individual that has the time necessary to keep the port alive.
Jean-Marc is right that this is basically the only crucial factor.
Personally, I would like to help out on a MFC solution, but so far I'm
waiting for the GUII effort to get further along: The requirement for
X headers has to be easy to remove before I can begin for earnest. This
in turn implies getting XForms out of the main source.
It is simply too hard to get the source to compile on Windows with
Visual C++ at this point.
Greets,
Asger
