On Thu, 17 Aug 2000, Asger K. Alstrup Nielsen wrote:
> 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...
I read it once, I will go read it again soon enough.
> > 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.
Hmm, yes, this is a good solution :-)
And as you said later, this should be postponed until the Graphics Inset
is working and well, I'd rather work with something I know about already
then with something I need to learn.
I pretty much have grandiose plans for InsetGraphics, they can also do
wonders to the Graphical inserts of the External Inset. Mainly stuff like
supporting the picins package to allow wrapping of text around the image
and the like. Pretty cool stuff I think.
After I'll get the Graphics inset up and running with complete inline
viewing, I will investigate integrating the External Inset and the
Graphics Inset. Don't hold your breath though, soon after my army reserve
service the university studies start again (for the last year hopefully).
> 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.
I didn't said it is a huge problem, but this should be differentiated
somehow, possibly by not including pure graphics includes in the external
inset (or including them only as comments).
> > 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.
The invocation of the original program is not something too big, The
ability to define the inclusion latex commands is important for something
like that and possibly XFig elements should be added only this way and not
through the graphics insert, specifically those XFig drawings that use
latex fonts. It still eludes me on how to do inline viewing of such a
thing, it might require latexing this to get a PS file and creating an EPS
out of this and display the EPS, pretty long process I think.
> > 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.
Only time will tell :-)
This will require some extension to the External Inset so I have no real
idea how much work it will be, but the part of inline viewing will not be
too hard. But the merging of InsetGraphics and InsetExternal is the best
solution.
> > 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.
The basis of my idea is only related to insets and dialogs, specifically
the problem of re-writing a dialog behaviour for different toolkits, the
idea was to factor out the basic behaviour of dialogs to a base class so
that the behaviour will be independent of the dialog view which is
toolkit/platform dependent. The idea I had to communicate between the
dialog and the inset is similar to what I use right now, a parameters
class that is passed back and forth. This should be simpler than a special
function for each type. As I said I haven't thought about it too much,
this is mostly a sketch of my idea.
I will try to see how it goes when I'll factor the behaviour out of
FormGraphics. (Hint to toolkit porters, avoid doing FormGraphics for a
while, I might be able to make your job easier).
--
Baruch Even
http://techst02.technion.ac.il/~sbaruch/ (My Site)
http://rpghost.com/jindor/ (My brothers AD&D site)
" Learn to laugh ... it's the path to true love! "
- The Angel in the movie Michael
