On Mon, 15 Feb 1999, Jean-Marc Lasgouttes wrote:
> >>>>> "Joacim" == Joacim Persson <[EMAIL PROTECTED]> writes:
>
> Joacim> I gave it a second though on be bus home yesterday; forget the
> Joacim> `family' file, it's not necessary. Instead we can have one
> Joacim> more lines for the Style-definitions in the layout files; a
> Joacim> named Category. ...it's allways only a matter of comparing
> Joacim> two layouts at the time, so the whole family doesn't have to
> Joacim> be gathered. Besides, this is easier to implement. ;)
>
> Yes, we need something like that, or rather:
>
> LatexType section
> SectionLevel 1
>
> The idea is that there are many features of LyX that should depend on
> the type (numbered/not/numbered, put in the TOC, equivalence between
> classes, ...).
I was thinking the categorisation (extended to just about any objects a lyx
document can consist of, not just headings), could come in handy when
building menu entries for them. We'll get trouble with adding support for
more or less random LaTeX features if we have to hard code menu entries etc
every time for it (what JPW said about scalability....). Some sort of
automatisation is necessary I think. ...not that I know how it should be
designed and implemented; there are a couple of approaches to the problem,
each with its pros and cons:
------------------------
* Have all the definitions in configuration files; layout-files on steroids.
Pros:
- Easy for a layout/style implementor to handle. (assuming the
configuration file formats will be easy to understand and use)
- No recompilation/relinking is necessary. (assuming the configuration
files have a toolset that is complete for all tasks)
Cons:
- Hard to implement. In the worst case we could end up with having to
design a whole internal API and a set of abstracted widgets, combined
with a scripting language (gtk all over again). As it's hard to
forsee in advance what tools are necessary for future objects, the
kernel may have to change often. Or, the interface will be too weak
to support some more complicated cases of layout/styles.
* Put the document objects in C++ classes (perhaps in the form of
modules, so that the lyx executable doesn't have to be rebuilt whenever
someone adds a new feature), and have the objects set up their own
dialogues, do the painting in the buffer window (via the painter),
generate output for exported files etc, themselves. I call this The
anarchistic approach: (lots of modules -- statically or dynamically
linked -- which each handle their own input and output and the input
(dialogues etc) could in principle be implemented with whatever tools are
available to the implementor. He could write a prototype dialogue using
an xterm + /usr/bin/dialog if he pleases, or use tcl/tk, or gtk or... all
separate from the dialogues internal to the LyX core and the toolkit
it uses. ...or alternatively -- and prefferably -- use whatever tools
the LyX core provides, if they are sufficient for the task.)
Pros:
- The kernel won't have to change often.
- The modules can be debugged easily (it won't even be necessary to
have a lyx executable; one can call functions in the module directly
from the debugger, or have a faked lyx with stubs to communicate
with the module, or put a debug object in between to eavesdrop on
the communication between the kernel and the object in a more
high-level manner than is possible with gdb).
- If the modules can inherit eachother, this can be very powerful.
(separate linking must only be a compile-time option - not all
platforms support dynamic linking, and there are many different ways
it is implemented in. There is also a danger in mixing a kernel
built with one compiler with objects built with another, even on the
same platform.)
Cons:
- Makes the layout/style implementor's task harder (he may have
to do some c++ coding)
- It could become a confusing bazaar; objects implemented in a number of
different ways, using all kinds of strange tools.
- The interface from the kernel to the objects would be narrowed down;
all the kernel would see of an object would be in the form of an
abstract base class that the object inherits (that is, to have the
objects be separately linked modules that would be a requirement).
...maybe that's a pro, come to think of it.
* Another approach...?
------------------------------------
A compromise or rather a combination of the two would be my favourite
choice. I think there should be /both/ an easy-to-use quick&dirty way to
get support for a new simple document class or environment, as well as a
more powerful set of tools for the complicated cases. But I think the
latter is more flexible as it would be the task of the objects to check the
configuration files. (We could have a set of generalised environment/inset
objects that works for most common cases. It's just a matter of whether
the kernel should be the one configuring the objects from instructions in
the configuration files, or if the objects should be configuring
themselves.)
Actually, I'm doing things backwards here. The first thing to do is
obviously to define exactly how much and what an object (be that a heading,
an inset, whatever can be a part of a document) needs to know about the
rest of the programme, and how much the core needs to know about the
objects. Clearly defined interfaces between different parts of the design
could help up the development process, regardless of what method of
implementation we'll use. (Input methods should also be more separated
from LyXFunc::dispath I think, or LyXFunc in general for that matter; a
stateless dispatch() )
So, what would a spec for the interfaces look like? What methods/signals
should they have, and which part should handle which tasks? Anyone?
Btw, I've been doing some experimenting with dload()/dsym() integration
with c++ the last days, and also downloaded the andrew-8.0 source for
inspiration. Ez is a rather crude word processor -- the output is more
like from roff than from TeX -- and the implementation is somewhat unclear
and buggy, but the design is just beatiful: ez is just an object in ATK
(Andrew ToolKit), and it's perfectly legal to put /ez itself/ as an inset
in an ez document. =) (whatever the use of that would be...)
It's object-orientation put to its extreme.
Joacim
-
With both feet on the ground, you won't get very far.
-- Loesje
