On Wed, 3 Mar 1999, Asger Alstrup Nielsen wrote:
> > Yes, that'll do nicely for simple insets. I wouldn't want to write a
> > complex inset like a music, tree or Feynman diagram inset with that though.
> > Do you plan to have an internal API (i.e. functions and variables in this
> > scripting language that interfaces to the public members in the objects in
> > the compiled part) covering every public member in all the classes?
>
> If you want to do something as complex as music, you could use the inlined
> scripting code as a hook-point. Write the complex music code in a DLL, and
> then use the inlined scripting code to dispatch into the DLL. Probably, you'll
> find that it is not possible with the existing design.
Of course you realise that has nothing to do with by which method the inset
is hooked to the core. It's just a matter of if the core has a design that
is or isn't open enough to allow such an inset without modification.
> So, no, we should not have access to everything inside the LyX kernel. We will
> only have access to what we immediately can see is useful, and then later
> whatever else turns out to be useful... Then over time, we'll hopefully have a
> powerful interface. If somebody needed a hook into the canvas for doing a
> music inset, we would add this hook in the best way we could.
I mentioned these because I suspect they are best left to do their event
handling and drawing themselves. Imagine a feynman inset (diagrams
consisting of a few types of oddly shaped lines and dots, used by quantum
physicists), the most intuitive editing of such an inset I can think of
would to have it act as a primitive drawing tool. Feynman diagrams have a
small set of graphic objects, but one way or the other they must be drawn.
If it is to be implemented in a scripting language, the language has to be
able to express the zig-zag shaped lines etc. If these objects shall
remain as part of the inset/object itself (that's OO design), it means the
inset self must render the strange lines, involving low-level functions
like pixel level drawing functions.
What the core needs to know about such an inset is the size of its box, and
a way to send key and pointer events to the object. (and whatever other
things the core allways must know about insets in general; how to hook it
to the menu, how to make it generate LaTeX etc...)
> Seriously, I have tried again and again to get a design phase going on this
> list. I have written proposal documents about how I think the kernel should be
> designed, and had hardly no feedback.
Keep it up!
Joacim
-
With both feet on the ground, you won't get very far.
-- Loesje
