On Tue, 11 Jul 2000, Lars Gullik Bjønnes wrote:
> | 2. Make LyX compatible with the string class included in libstdc++ by
> | fixing files src/support/lstrings.C (lines 184 and 201,
> | string::compare) and src/lyx_cb.C (line 1109, algorithm copy and string
> | interaction).
>
> You mean unfixing I hope.
> The lyxstring tries to be close to API compatible with std::string.
Well, it should be possible to find API and libstdc++ compatible
implementation. For example, instead of comparing string and char*
directly (src/support/lstrings.C, lines 184 and 201), one can make
temporary string object from char* and compare it with other string. It is
not as effective implementation as the current one, but it will work just
fine with libstdc++. It is hard for me to say how to re-implement the code
in src/lyx_cb.C (line 1109) to make it compatible with libstdc++ since STL
is very new to me.
> | 3. Include GTK-- and Gnome-- into LyX (as sig++) and compile this
> | libraries with lyxstring.
>
> Isn't Gtk-- and Gnome--- a bit large for that?
Yes, it is. However, we can include scripts that build Gtk--/Gnome--
automatically with lyxstring instead of std::string. At least, the
resulting frontend code should work fine and we can drop it later (after
release of libstdc++-v3).
> Can we have an interim solution where we use char* to communicate
> between lyx-core and the gtk frontend? When Gcc 2.96 is released it
> will hopefully be with the new libstdc++-v3 library, and then there
> will be no problems.
This will require isolation of Gtk/Gnome frontend code from the rest of
the LyX code. For example, it will be not possible to include even
src/frontend/Dialogs.h directly from the frontend implementation since it
contains "#include "LString.h"". I think such solution will lead to
unnecessary code in LyX.
Marko
