Georg Baum wrote:
The bad news is that this change will require one controller class for each
inset. Currently there is only one command controller, used by all command
insets. That is the only reason I did not do this change already during the
InsetCommandParams rewrite.
Sorry, could you explain this? I'm not sure I understand which part of
what I'm proposing affects the frontend. It's not that I'm skeptical. I
just don't immediately see why, e.g., GuiBibitem can't still use
ControlCommand. And GuiCitation already has its own controller.
InsetCommandParams/InsetCommand is in a state of flux: The goal was to
decouple the children of InsetCommand from LaTeX, use the name/value
interface exlusively in LyX, and concentrate all LaTeX stuff in
InsetCommandParams. This was not finished because of the freeze.
IMHO the legacy code using the old interface (marked withg FIXME remove)
should be converted to the new one. That alone gets rid of quite a bit of
ugly code.
Yes, in fact, I kind of got started on this when I was looking at
removing the legacy code---something you and I discussed a while ago.
Most of that is concentrated in InsetInclude now, which is the only
inset that still uses the old format. (There are a handful of remnants
elsewhere, they're easily replaced.) Unfortunately, when Bo did the
listings include, he of course used the old interface, since that's what
InsetInclude uses, and so things are slightly worse than they were
before. But not terribly.
Another planned, but not implemented bit is support for keyval options
(currently not used): An inset does not need to know that they need to be
exported to TeX as [a=A,b=B]. It could use the same existing interface for
setting/getting these options in InsetCommandParams. Only in the definition
of the inset (currently in InsetCommandParams.cpp, but it should be
straightforward to read this info from a text file) the type of these
parameters would be specified. Then you would never need to parse a
"a=A,b=B" string (which is quite complicated if you want to do it correctly
with escaping), because in .lyx files these values would be written as
separate parameters.
Yes, this would be very useful indeed. There's been some discussion of
this in connection with listings, the new hyperref support, etc, namely:
If you have a whole ton of optional arguments, what's a decent UI? The
backend support is simple enough.
Richard
