On Sat, Feb 06, 1999 at 09:14:43PM +0000, Allan Rae wrote:
> WARNING: this is even longer than Lars' original post!
[ergo: I've snipped much of it]
Much of this conversation is about a "Writer" class that handles
output to a particular format [e.g. LaTeX, HTML, ASCII, etc.] and how
that might interact/work with Insets.
> How often do we add new writers?
> (If we start with ASCII, LaTeX, SGMLDocBook and HTML4_0
> would we need any others? (XML?) man pages and a number of
> other things can be generated by SGMLTools (either now or
> in the future)
Not that often, so be sure. However, there are other considerations
besides how often we add new writers.
> 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.
Yes yes yes, I know that we feel some features to be important
additions. So, we go through the rigamarole to add "support" for it
to the LyX kernel, requiring all of the bloody recompiles, duplicating
code, duplicating popups, et cetera, et cetera, et cetera.
Again, this approach is not scaleable.
Right now, we support LaTeX, basic ASCII, and SGMLDocBook [sort of] as
output formats. As we add HTML, XML, support for more LaTeX
classes/features, and so on, we'll find our nice, clean kernel
"accreting" code for this support.
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.]
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.]
What are common features of LaTeX, SGML, XML, HTML, etc., that
we'll need to support?
What existing features fit a similar schema?
What features could use a similar popup? Similar insets?
I'll add more, but the train's getting near my stop. Gotta shut down.
--
John Weiss
On a train, someplace between Pawling and White Plains...
