On Mon, 14 Aug 2000, Baruch Even wrote:
> On Sun, 13 Aug 2000, Asger K. Alstrup Nielsen wrote:
>
> [Finally a clear explanation of the External Inset] :-)
Did you read the document in the doc-directory as well?
That should give you much of the same information...
Which reminds me: Do we have a volunteer from the doc-team to merge
this external inset documentation into the proper documentation?
It's only a matter of finding the correct file, and then copy/paste
it there...
Another thing: At the FILM, we introduced a new LyXConfig.lyx.in file
which covers a lot of the external programs that LyX can interface
with, along with the existing information about LaTeX packages. This file
was supposed to replace the existing LaTeXConfig.lyx.in file, but this
part was never done.
It should be a relatively easy job. Maybe Juergen could do it?
Now, back to the InsetGraphics/InsetExternal discussion...
> How will the user differentiate between the External Inset and the
> Graphics Inset?
Ideally, the InsetGraphics will be based on the InsetExternal, as
discussed earlier. If this is the case, there will be no difference to the
result of whichever approach you use to include a graphic.
However, as you seem to imply that the InsetGraphics is not quite there
yet, I think we should just wait before we take any further action.
I don't think it's a huge problem that we have two different mechanisms
for including graphics. It's only a temporary situation, and since each
has different advantages (see below), we should just keep both around,
until we are ready to merge them.
> This is especially true with the conversion mechanism
> intended for the Graphics Inset where from any format with a converter to
> a known graphics format you can create a Graphics Inset, effectively the
> chess board can be loaded to the Graphics Inset and it will be shown
> inline and printed and all (assuming there is a conversion between xboard
> and a known graphics format).
Notice that the external inset does more than just the conversion: It
allows format specific parameters both in the conversion and in the
produced LaTeX (and other formats) code. Furthermore, it will invoke a
custom external application. So, if you include a GIF picture, the Gimp
will be invoked on it when you click on it. If you include a chess
diagram, XBoard will be invoked.
Obviously, this functionality can also be built into the InsetGraphics,
but that seems like a strange solution, because what you would end it up
with is exactly the external inset as it is now...
> Regarding the extension of the External Inset with the graphics dialog and
> the inline viewing of images where applicable, this should not be too
> hard.
That sounds good. I hope you will have time to do this when your service
is completed.
> The dialog will need some work since It's pretty much tied
> to InsetGraphics (I actually have an idea of how to do better decoupling
> between dialogs and insets, but I still need to formulate this)
We have toyed with a few ideas on providing a general mechanism for
building GUI dialogs which allow setting/reading a few different parameter
types such as metrics, units, doubles, filenames, bools, colors, and so
on. If we had such a general mechanism, we would be able to reuse it in
the configuration part of LyX, and obviously, it would be a welcome
addition to the external inset such that it would truly be general.
I'd be interested in hearing about your ideas in whatever form you have
them now.
--
I'm glad you seem to agree that the external inset is moving in the right
direction. I'm confident that we will get there -- whether we will have
the InsetGraphics as a separate inset in between or not does not matter a
lot to me, because it will be relatively easy to convert between the
different formats later, and then consolidate the different mechanisms
into one.
Juergen has demonstrated this nicely with his excellent work on the
new tabular inset.
Btw, I hope people appreciate the excellent work Juergen and Lars are
doing with the text insets. Their work is very much related to
infrastructure, and therefore not as immediately visible as much of the
other excellent work being done on the GUII, i18n, and more.
I'm not trying to tone down the importance of this other work, but I'd
just like to publically pad these guys on their back and say: Good work,
have a beer! And while we are at it, you other guys can have one as well.
Greets,
Asger
