Andre Poenitz wrote:
I think I know now more or less how the LyX GUI works.
However, I still completely fail to see why it needs to be so complicated.
Something about multiple frontends etc :-)
More seriously I think it was just a way to organize the GUI code in the
xform days. I agree with you that this is awfully complicated.
Simple example: The 'About' dialog. We have:
- information somewhere in the kernel (lyx_version etc.)
- a pair of files in frontend/controllers wrapping this
information in a nice string or writing it to a stream
- a class QAbout pushing this information into ...
- ... a class QAboutDialog
All in all roughly 400 LOC for something that could be done in less
than 100.
What's exactly wrong with having kernel functions
void getCredits(std::ostream &) const;
std::string const getCopyright() const;
std::string const getLicense() const;
std::string const getDisclaimer() const;
std::string const getVersion() const;
and a single GUI class QAboutDialog calling the kernel functions
on creation?
There is nothing wrong with that, quite the contrary IMO. Ideally all
helper classes and methods that retrieve information from or give order
to the kernel (i.e. src/) should be encapsulated in frontend/controllers/
Then the Qt4 dialogs should only use the API defined in frontend/ and in
frontend/controllers/
I am also in the opinion that the kernel should be _completely_ ignorant
of the dialogs. So all dialog updates called from the insets etc should
disappear. All opened dialogs will updated themselves by asking proper
questions to the kernel.
Isn't this M-V-C thingy about making maintanance easier? If so, how come
that a simple dialog needs 3(!) extra classes (spilled on 6 files in 2
directories, no less...)?
Something went awfully wrong here as far as I can tell...
I am glad that someone joins me there :-)
I propose that we discuss this when 1.6 time comes.
Abdel.
