> > Have I said that I really do not like the dialogs at all? > > I'd prefere an application completely without dialogs... > > I was thinking about this myself. Seriously. > > Do you remember my hacking of the lyxserver back in september? I made a > suggestion at that time that I clean up the controllers code, so that they > weren't passed an inset*, from which to extract the info they required and, > on return from the view, to fill it with the desired values. Instead, I > suggested that these controllers were passed the inset::write(...) string > and dispatch()ed a modified version of this string with a single, common, > LFUN identifier. It would then be up to the LyX core to parse this using > inset::read(...) and 'do the right thing'. > > The advantage of this approach is that all dialog functionality could also > be performed by an intelligent app communicating with the LyX core via the > lyxserver. You didn't seem to get the thrust of the idea at the time, but > André did and sort of jumped up and down with excitement ;-) > > If we did this, then lyx could quite conceivably become a daemon process > communicating via the lyxserver with an external process which --- quite > conceivably --- could be our frontend dialogs with a main() routine. > > So, no dialogs in LyX at all ;-)
>From a design standpoint, I think that would be a nice and clean solution. I always thought that most document-oriented apps (editors, etc) should have a "workhorse" backend server with (hopefully) a simple and documented interface, and a front end which handles display and user interaction. Here, "a frontend" would be split between lyx and the frontend, but that's OK, I guess. A little more splitting as proposed would not be that bad, methinks. So, correct me if I'm wrong. There would be 1. lyx -- displays menu and document views, processes keystrokes 2. dialog frontend -- displays the dialogs 3. lyxserver -- works on the model (lyx document) Cheers, Kuba Ober
