On Mon, Sep 24, 2007 at 11:04:39AM +0200, Abdelrazak Younes wrote: > Jean-Marc Lasgouttes wrote: > >Abdelrazak Younes a écrit : > >>Georg Baum wrote: > >>>If you had a serialization that > >>>would not require to implement these wrapper classes for new insets and > >>>that would 'just work' without additional effort (for example by > >>>using the > >>>insets read() and write() methods directly), then I think this would be > >>>ideal. > >+1 > >> > >>That would be a good first step indeed. But I personally don't think > >>the hypothetical benefit of using "inset globs" in the lyxserver is > >>worth it. I mean, I agree this would be nice to have, this kind of > >>thing is even necessary for simulation programs where you definitely > >>want to separate the algorithm from the GUI but, in our case, I really > >>think this serialization is a typical case of over-engineering and we > >>should get rid of it. That's just my opinion of course :-) > >Serialization allows us to have the paragraph-params-apply lfun, for > >example, which allow to bind any aspect > >of paragraph settings to a key or icon. > > No, what you are talking about is the frontend -> core communication, > which I agree should be kept working via LFUN. But we don't need any > serialization to do that, just a well defined protocol. > Right now, we have a copy of the current ParagraphParam in the > controller and this is very wrong.
A sign that there's something wrong is that e.g ControlWrap accessing InsetWrapMailer, which stores a InsetWrap reference. So ControlWrap basically has indirect access to InsetWrap already. Just letting it access it directly without intermediate serialization just looks like a sensible thing to do. Andre'
