On Mon, 4 Feb 2002, John Levon wrote: > no you can't. the external material inset is very basic and provides no > interface inside lyx, which is what he was asking for.
Suppose we wanted to implement the spread-sheet functionality that Martin recently hacked up. In overall terms, which approaches could we go about to solve this task? 1) Hack it into the LyX code, like Martin did. Probably the easiest. 2) In a distant future, the entire LyX document data-structure is inspectable and manipulatable via an API. I.e. LyX becomes a component in the sense of COM technology on Windows, or KParts in KDE. An external application can then use this API to inspect and modify the data inside LyX. Realistically, we will not reach this scenario in at least two years, since the internal API is not stable itself. In addition, notice that the GUI of this application would be external as well, because we will not provide another API for an abstract GUI toolkit from LyX. In other words, the LyX team has a huge task to formalize a stable and powerful document API before this is possible. 3) Extend the LyX server on a need basis: In this case, there would be a need for some new commands to read/write the contents of cells in a table. 4) Use the external material inset as it is today. And now you ask: "How can the simply external material inset be used for this?" Well, the beauty of the external material inset is that it is simple, but still extremely powerful. The crucial feature is that it provides an option to produce arbitrary LaTeX output and stitch that inside the final output. This effectively gives us write access to the output. Now, what about read access? We need that in order to ensure a tight integration with LyX. Well, read access is easy: Just provide the LyX document itself as a command line parameter to the plug-in. Then the program will use this to parse the document. In this way, it effectively gets read-access to the entire LyX document data structure. In other words: Rather than building a new API for accessing the LyX document, we exploit that we already have such an API: The LyX format! Now, it is true that we could use a few extra small features to make this really beautiful. The most important of these would be the ability to let the external program produce LyX format output, rather than LaTeX/Text and so on. This snippet of LyX format would be parsed by LyX, and inserted at the appropriate place in the data structure. Such an ability would provide us with a complete read/write API for reading and manipulating the LyX format, and obviate the need for external programs to be able to produce both LaTeX, DocBook, ASCII, and so on. We discussed this feature at the last LyX developers meeting in Norway, but we did not have the time to implement it. I don't think it would be too hard to do it, but the real question is this: If people do not understand what the external inset in its present form is able to do, will we ever get anybody to use an even more advanced one? Based on past experience, I don't think so. Furthermore, I think we should draw another bold conclusion: Nobody would really make full use of a complete document API either. People might say that they would, but in reality, it would still be simpler just to hack the LyX code itself. So, realistically, we will get the best cost/benefit ratio by just doing as now: Let people hack the code directly, or in the rare occasions people need it, simply extend the LyX server with whatever commands people require from time to time. Greets, Asger
