On 16 Sep 1999 18:50:58 +0200, Lars Gullik Bj°nnes wrote:
>If you have comments or questions too this, please step onto the
>soapbox.
>
> Lgb
[...]
> - use of std::string
[...]
>An other change that
>will impace users is the move to more modern C++, we aim to begin use
>the Standard Libarary extensively, and to use several of the new
>construct found in ANSI C++ (e.g. C++ style cast, containers). This
>will make it impossible to compile LyX on older compilers.
>
Am I wrong, that the ANSI C++ library is on very few systems (namely
sgi) available as a manually optimized and thoroughly debugged option?
Using this means asking for complaints for bugs/slow performance. So it
might be a good idea to provide (precompiled and tested/debugged)
versions of the library for the different compilers, as well as
performance reports for all those ...
You should also report, which compilers are 'LyX proof' and test for
the compiler/version in the configure process, warn users about
untested:
["Sorry, you're trying to compile our shinin' baby on ye ol'
rusty waste box. We (the parents) don't like this idea at all..."].
[...]
>Some of the work that needs to be done on GUI indep:
>
> - make all popups GUI indep
[...]
- My idea here is to restrict messages so as to simply print to a log
file/named pipe with a tag that identifies and classifies the message
using only standardized functions. The respective gui wizard would then
decide how and if the message be presented to the user.
Popups are still an obstacle for splitting the code into independent
libraries (using only posix functions) and linking as shared objects.
Then you would have a separate dynamic library providing the necessary
non-standard OS and toolkit interface.
- Work an LyX could then be split in a way that only one core developer
is responsible for exactly one library.
- Defining strict and simple inter-library interfaces providing
abstract data types and simple functions as well as starting to
implement a 'programming on contract' scheme, - e.g. using assert() or
custom debug functions -, for those interfaces could prevent further
frustrations, soon stabilize an industrial quality code base and enable
rapid changes/progress.
> [...] Note however that:
>
> - bug fixes are always welcome
> - changes to implementations (not API) to
> independant modules might be accepted even if
> this is not part of the goal/taks of the current
> phase.
Maybe this is very near to the idea above.
> [...] One of the user visable
>changes that will be made soon be the inability to compile LyX with
>old versions of the XForms lib (older than 0.89).
If I understood forms home page correctly, 0.89 is not a production
release, yet a 'for evaluation only' version, released for a fraction
of the supported systems. For non-experimental use they still only
support 0.88.
Greets,
Arnd
