Richard Heck wrote: >>> In the end, I don't think this will be needed. But yes, the >>> serialization here is a hassle, and it's sheer luck that it isn't a >>> problem. >>> >> How would an optimal/a better solution look like in your opinion? >> [Serious question] >> > Well, there are advantages to the serialization. I can't remember what > they are ;-), but I have seen them.
It is a type question. Passing InsetFooParams directly would mean that the dispatch mechanism needs to know about all these types, or rather you need a way to encapsulate them since it is probably not a good idea if some generic code has to care for the types. > That said, this is the normal flow > from controller to core: The controller has a copy of > InsetCommandParams; it wants to pass that information upstream to the > inset. So what it does is serialize them, call an LFUN, and then the > kernel reads the stream back into an InsetCommandParams. So you have to > do it this way if you want to use dispatch, etc, rather than some sort > of direct interaction with the kernel. I'd have to look a lot more > closely to see what that would be like exactly. But surely there's some > way to just hand the inset its new parameters. Of course, but I guess implementing that would not be trivial. All in all I think that serialization is not bad at all, since it allows to handle some aspects of kernel<->frontend interaction centrally, and more importantly, offers a possibility for automation through the lyxserver. Only the current implementation with the mailers is clumsy. 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. Georg
