>> Asger K Alstrup Nielsen writes:
AKAN> We add an KDE OpenParts inset. Or the corresponding GNOME
AKAN> thing. This does not require much support from the kernel.
Matthias has bugged me a bit about this. So yes we should support
OpenParts, and other similar protocols/insets.
Lgb
> 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...)
Here's how we ge
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 la
> 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 object
On Mon, 1 Mar 1999, Asger Alstrup Nielsen wrote:
> [How to handle the extendibility problem.]
> [Layout files on steroids or linked objects a la Gimp.]
>
> > 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&dir
[How to handle the extendibility problem.]
[Layout files on steroids or linked objects a la Gimp.]
> 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 e
