Angus Leeming <[EMAIL PROTECTED]> writes:
| We used to have code that would have resulted in each separate LyXView having
| its own set of dialogs.
>
| Lars created guiapi.C and moved all the dialogs into singleton classes that
| could be accessed through the various functions. Eg
>
| extern "C" {
| void gui_ShowAboutlyx(LyXView & lv, Dialogs & d)
| {
| static GUI<ControlAboutlyx, FormAboutlyx,
| OkCancelPolicy, xformsBC> cal(lv, d);
| cal.controller().show();
| }
| }
>
| and, indeed, that's just what Dialogs now does. Eg:
>
| void Dialogs::showAboutlyx()
| {
| gui_ShowAboutlyx(*dialogs_lyxview, *this);
| }
>
>
| I'd like to turn this round. Ie, let Dialogs.h store a bunch of
| boost::functions. Eg:
| boost::function0<void> showAboutlyx;
>
| Connect these boost::functions to the appropriate methods hidden deep within
| frontends. Eg
| showAboutLyX=boost::bind(&ControlAboutLyX::show, this);
| (I'd like to do this in the Dialogs c-tor, but we'll see...)
and where do you setup the Dialog constructor?
The dialogs are currently lazy-constructed.
| and allow guiapi to access these boost::functions. Eg
>
| extern "C" {
| void gui_ShowAboutlyx(LyXView & lv, Dialogs & d)
| {
| d.showAboutLyX();
| }
| }
>
| Ths gives us back the ability to have per-LyXView dialogs and is cleaner code
| too I believe.
>
| Lars?
Perhaps.
--
Lgb
