On Tuesday, 13. March 2001 10:21, Andre Poenitz wrote:
> > 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:
> > [...]
>
> Even given this restriction of choice, I do not think that 2 is best. This
> is a _complete_ new port, moreover, every line of code written for that
> port is lost for Unix land.
>
> If _I_ had to choose between these three, I'd probably go for the Qt
> solution. At least a temporary solution has been outlined in this case
> (using Kalle's licence) and I don't see a really dark future.
>
> And to get a bit religious: Even if there were later no way to get hold
> of other licences, I'd rather shove money to Trolltech than to Microsoft.
> They've got money from me for the keyboard, that should suffice for the
> next century...
>
> > 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.
>
> I have to admit I have no clue: Suppose we had a working Qt-port for Unix
> (which is being worked on, isn't it?) how much effort would be needed
> to "port" that to Windows? How much work would that be compared to a
> native Windows port?

If there are no Unix-specific calls in the backend (only POSIX calls), then 
at least in a theoretical perfect world, all that would be needed is a 
recompile.

The world is not perfect, however, there all kinds of compiler 
incompatibilities, system library bugs, etc., but still porting a Qt/Unix 
version to Qt/Windows should be considerably less work than porting to pure 
Win32 or to MFC. Remember that the compiler incompatibilities, system 
library bugs, etc. hit you no matter which toolkit you use.

One of the problems is that the STL version shipped with MS Visual C++ is 
severely broken. I haven't looked at the backend code much, but if you do 
more than simple list operations, chances are that these bugs will hit you as 
well. There is a workaround for this as well, you can buy drop-in 
replacements for the MS STL implementation; I am using the Dinkumware 
replacement with some success.

Kalle

-- 
Matthias Kalle Dalheimer
President & CEO/VD
Klarälvdalens Datakonsult AB
Fax +46-563-540028
Email [EMAIL PROTECTED]

Reply via email to