Andre Poenitz wrote:
On Wed, Apr 25, 2007 at 12:07:25PM +0200, Abdelrazak Younes wrote:
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 :-)
Surely not in this case as
I was referring to your statement "why it needs to be so complicated"
not to your proposal with which I agree.
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;
is GUI-agnostic.
Agreed. See clarification above.
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/
I don't think such a helper class is needed at least for the about
stuff.
This was generally speaking, not specific to the About stuff. There are
cases where a class is needed to store some intermediate states.
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.
Sure. But there's nothing wrong with std::string const getLicense()
fundtion in ther kernel IMNSHO.
Agreed IMSHO :-)
So all dialog updates called from the insets etc should
disappear. All opened dialogs will updated themselves by asking proper
questions to the kernel.
The kernel should emit signals...
Yes, the kernel should emit signals when something changes in the
internal structure like Buffer::changed(). But it should not emit a
signal to tell a given dialog to update itself. updateDialog() signal
type is wrong.
Abdel.
