>>>>> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> Do we still care about xforms? Why don't we remove it? We should try to have a good idea of who uses xforms and why. Maybe ask on lyx-users or setup some kind of poll. Michael> Are we still working on a text processor? Or has LyX turned Michael> into a WeCanDoEverythingButTextProcessing project? Having several frontends is good IMO. Michael> IMHO, we should remove xforms because nobody needs/uses it Michael> nowadays. Since qt4 will satisfy the needs of the Mac and Michael> Windows users, qt3 may turn into the kde-enriched frontend. This is not how it works. Eventually (I do not know when), the qt4 frontend will replace the qt3 one. So there is no need to specialize them. Michael> If there are users without KDE, they can use the gtk frontend Michael> (at least in principle). This does not make much sense, if I may object. Michael> Regarding the build system, I have to thank Abdel and Bo for Michael> their scons work. If you never tested it by yourself, you Michael> cannot imagine how greatly it simplifies compilation on Michael> Windows. THANKS! THANKS! THANKS! But why do we need yet Michael> another build systems??? I see no need for cmake. Agreed (meaning: I am glad some people step up and help in LyX, but I'd rather see the effort go in the things that ar already on the plate). Michael> I think we should also decide on the objectives of LyX 1.5. Michael> IMHO, LyX 1.5 should feature qt4 and scons support (what an Michael> improvement for the Windows platform!) scons support means nothing to users. This is not a new feature to brag about, just a convenience for us. Michael> and improved change tracking. (Not to forget Bo's session Michael> management and Martin's outlining :-)) These feature alone, Michael> plus overall improved performance and stability, will Michael> certainly justify a new major release. Where is the improved performance and stability? Michael> It will also tell the users that we managed to overcome the Michael> problem and shortcomings of the 1.4.X releases. We did not. I'd welcome help to fix 1.4 bugs. Michael> Personally, I would like to postpone unicode support until Michael> 1.6 because this will delay 1.5 for at least a few months. I think we should not. JMarc
