Angus Leeming a écrit :
Go read controllers/Dialog.C which *is* pretty transparent even if
things become less so in the frontends. My feeling about this is that people try
and make sense of the logic by starting in a frontend implementation of a
Dialog::View and, of course, end up confused because they can't see the
controlling logic.
OK, I have read Dialog.[Ch], Control*, QDialogView, etc...
And I still think that this is too complicated. The infrastructure
assumes that all GUIs will be separate dialogs with OK, Apply, Cancel,
and Restore buttons. IMHO the model should not know about the view. Qt4
provide a clean separation between those too but I am having a hard time
trying to fit that into current architecture.
I only need a base class that will transfer all lyx func request to/from
the kernel. My QLAction class does that already for the toolbars and the
menubars and I think this is the way to go for all kind of GUI. This
would mean extracting the logic from the current controllers and put
that into what Qt4 would call "delegates". A delegate job is to know
about the data inside and to provide a nice and easy interface for the
frontend. Basically, in the case of the Citation dialog, this is just a
version of ControlCitation freed from the controller work. Some more
code could be transfered from the current frontend code.
This new architecture would imply that those new dialogs use nothing
from the frontends/controllers. No need to do that in one go, this can
be done dialog per dialog. Of course, no need to rewrite the current
frontends to this new architecture, this can be a Qt4 only thing.
Please don't take this all personally, the GUII surely was a good thing
for xforms and I guess it provided an easy porting to Qt; but I think
that we should use what Qt4 provides.
Of course I am not going this way if there is no consensus among
potential Qt4 developers. I guess Andre is already on my side ;-), what
about others?
Abdel.
