Andre Pönitz wrote:
Quoting Peter Kümmel <[EMAIL PROTECTED]>:
The fact that there's now only one frontend left to care about
should not lead to the conclusion that's now suddenly fine to
mix core and GUI.
As a matter of fact I will strongly oppose any change that will
lead to
(a) using any QWhateverStuff in src/*, src/inset/* src/mathed/*
src/support/*
(b) using any src/* stuff in src/frontends/qt4/*
i.e. the interface between the core and the frontend is
src/frontend/* and only that.
Andre'
This could be easily checked by not linking to Qt and
enabling the option no-undefined-symbols.
-- Oh, I forgot, this isn't possible (at least LyX isn't coded in C)
no-undefined symbols work well with C++. However I don't
see what you'd link to make this usable.
We have (1) core + frontend (without Qt)
(2) frontend + frontend/qt (without core)
But linking-wise both depend on the 'without' stuff
With some effort (1) should not depend on Qt and that's the way to go IMHO:
- static lib libLyX.[a/lib]:
contains core (src/inset/support/etc) + frontend + controller
- executable LyX[.exe]:
* contains main.C
* statically link to libLyX.
* not linked at all to qt.
* will dllopen a dll that conforms to the virtual interface defined
in frontend
- dynamic lib libLyXqt4.[so/dll]:
* constaind qt4/*
* statically linked to libLyX
Of course this would mean that the resulting binary files would be a bit
larger because libLyXqt4 and LyX.exe would contain non shared symbols
but with further cleanup of the frontend and controller interface, this
should be diminishing with time.
Abdel.
