On Tue, 9 Feb 1999, John Weiss wrote:
[...]
> > How often do we add new insets?
> > (I'd say more often than new writers)
>
> Therein lies a major problem:
>
> Every time someone wants to support some new whiz-bang LaTeX package,
> or an SGMLDocBook feature, and so on, they go and add:
> 1) A new Inset for it, for the LyX document editing pane.
> 2) A new menu entry for it.
> 3) A [possibly] new submenu for it.
> 4) A new popup, or subpopup, or new widgets in an existing popup.
>
> Clearly, this approach is not scaleable.
[other good scalability points snipped...]
> Why not instead make the kernel --- including output formats, Insets,
> display, and popups --- generic? I said this many moons ago: after
> cleanup, LyX should be extensible through *.layout files for 90% of
> new features. This is what Tex/LaTeX did; they seldom need to alter
> the core code, which is highly stable.
>
> Yes, it will require more work to do this, especially with popups and,
> to a degree, Insets. Figuring out a generic scheme by which something
> like a *.layout file can specify a new popup will be *very* tricky.
> Doing the same for insets won't be quite as hard, but will still be
> tricky. I think, however, that we can lay the foundation for this by
> 1.1.
> I realize I'm all talk at the moment. Truth be know, I haven't looked
> at the source for 1.1 I would like to, however. I'd like to
> stimulate a discussion on this.
>
> Some Points:
> Support for optional arguments, or secondary/tertiary arguments,
> to environments are accreting onto the Paragraph Layout popup.
> For most environments, however, that support need only be a popup
> with a line edit and a descriptive label for each arg, plus some
> overall description for these.
>
> Certain optional args lend themselves to "fixed" collapsable
> insets. These are insets like a footnote, but with a full-line,
> normal font label. [E.g.: Think short-form section headings and
> captions.]
My latest email on the "writer" thread proposed generic handling of the
optional arguments (admittedly I didn't spell out how this would all
work). The generic begin(...), end(...), and command(...) member
functions of the Writer hierarchy are driven by definitions in the .layout
files. The LaTeXName parameters format would be changed to include the
list of options such as "section[]{}" then if we have generic insets based
on our current breakup of paragraph types ITEM_ENVIRONMENT, ENVIRONMENT,
COMMAND etc. these insets can handle the various data as required.
Probably in a vector<LString> since each new command/environment has a
different number of options and only compulsory options must be
present in the call to begin(...) or command(...).
That leaves the generic popup. I think it was probably you John who
suggested ages ago that we have a generic popup with six or seven text
input fields for such a purpose. The problem of accessing the popup is a
little trickier since we have two scopes: document and paragraph.
Paragraph level is easy enough -- right mouse click on the paragraph
brings up a menu appropriate to that paragraph with a few other useful
entries perhaps (this is already planned anyway). We might offer
a "Paragraph format -- Document Scope" option on that menu otherwise
document scope is a bit trickier. Hmmm... how would a given paragraph
find out what its corresponding document scope settings are?
The labels for said input fields would be kept in the .layouts (and hence
they'd need to be included in POTFILES).
> Some Questions:
> How expensive would it be to make the Insets a base class with
> many protected members, member to perform the most frequently
> used operations for any Inset?
> [The idea: special Insets, e.g. Math Mode, would subclass from
> this and use this "inset toolkit" internally. There would also
> be one child class, "GenericInset", that implements any of these
> operations/features depending on the use of constructor flags.]
I'm not sure what you're getting at here. What effect will the
constructor flags have: reconfiguring which inherited methods are
supported?
> What are common features of LaTeX, SGML, XML, HTML, etc., that
> we'll need to support?
The ones we currently support now:
fonts
item environments
environments
commands
specialised versions of above:
ref
toc
figures
tables
math
footnotes/marginnotes
> What existing features fit a similar schema?
What exciting new packages might also fit this schema?
And better yet which ones don't?
> What features could use a similar popup? Similar insets?
Most environments should be able to be supported by the environment inset
as described above (and likewise the command inset handling of generic
commands) its only a handful of specialised things that need specialised
handling (see the incomplete list above).
Allan. (ARRae)
