Leuven, E. wrote:
Helge Hafting wrote:
The problem is, you either support things through the
preamble or some dialog, but not both.
let me guess, the law of hafting?
No. Feel free to implement stuff that way, I described how
LyX works now.
If you use the listing support, where in the preamble would
you put an additional option?
in the case of the listings package i had the impression they could be passed
using \lstset{}
Right, you can do that with listings. Do every other package have
a similiar mechanism? This wasn't about listings only.
But the listings dialog can provide a textfield where experts may
enter the rare extra options.
And it is even possible to have some
syntax checking that avoids common problems like mis-spelled
keywords or mismatched braces.
sure, and for these rare extra options a simple lineedit with (possibly) a validator should be enough.
Yes, and I think that is a much better approach than "use the preamble".
now there is a big textedit with an ugly "documentation" field next to it and
that i don't like so much: imagine if we start doing that for all packages and options
that are unsupported through the ui atm!
That'd be one page per package then. Not too bad, but I think many packages
are simpler than the listings package. Such a setup won't be so useful
for them.
That would certainly cut down on the GUI work, but won't solve the
problem of bad design if 163 parameters are crammed into
a dialog (or set of dialogs).
but it would make it more easy to support new packages (and the 163 parameters
case is a pathological example) and it should also be possible to generate a ui
for unimplemented parameters and put it in an advanced options tab...
Yes, it'd sure be nice for simpler packages.
Helge Hafting
