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 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. > >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. > 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. > 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... > >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. Sure. Andre'
