Richard Heck wrote: > 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.
The connection lies in the Mailer interface: Every inset that needs to pass data between kernel and frontend has a mailer, and this mailer exchanges the data in the same format that is used in .lyx files and naturally uses the same classes to read and write this data (in this case InsetCommandParams). Since the inset name is part of the mailer interface you would need a new mailer and a new controller if you changed the inset name to individual names. Maybe it would also be possible to change InsetCommandMailer to recognize the other names. I don't think so, but I do remember this only vaguely. > 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. Yes, some insets already have their own controller, but currently that is not required. > 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. That's what always happens with compatibility layers: You can write in big red letters not to use them for new stuff, but if they exist they get used. > 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. The most important ones should probably be handled individually, but for the not so important ones it should be simple, e.g. a listbox and a text edit: The listbox contains all argument names, and if you select one the corresponding value appears in the text edit. The only problem with this approach is that in some cases there is a difference between an empty parameter and a parameter that is not given at all. But this could be solved with two listboxes: Onwe contains all possible parameters , and the other one contains the selected ones (similar to the citation dialog). If you want to be really fancy you could associate a type to each parameter (string, integer, LaTeX length etc), and instead of a text edit the input field would change dynamically to a sepcialized one for that type. Georg
