Andreas Vox wrote: >> It looks like I opened a can of worms with this XFig stuff >> > I caught up with my reading (previous DVI file thread on lyx-devel, > insetexternal, etc.) and I don't envy you :-)
InsetExternal is actually one of the most powerful concepts in the whole of LyX. Amazing how such a simple concept can go so far. Asger is a clever, clever bloke. >> Usually, Mover will just invoke '::rename', or 'mv' when a shell script >> representation is requested for the graphics converter. However, this >> will be configurable, based on file format. Users can register an >> external command to do something more complex. > > So it's something like a converter with source format == target format? If you like. But converters are strung together automatically to link beginning format to end format. Our concept of converter will not allow the beginning and end formats to be the same. > Or do converters have a restriction of working only in one directory? All conversions for a given buffer (document) take place in a single temp directory. All files that need to be converted to a different format are first copied to this temp directory and there names are mangled to ensure that files that are originally in different directories can happily coexist when placed in a single directory. So, to answer your question, conversions do take place in a single directory. That's not a restriction of the converters concept per se but does make the implemetation easier. > For my taste this whole external file business is already very > complicated. A Mover would be a clean solution but also another concept > to learn. (my head is already spinning from converters, templates, > previewloaders, graphicloaders, etc.) Oh, it isn't that bad really. All the above are clean concepts. Each has one or more classes to implement that concept. The encapsulation is quite good. Moreover, LyX can handle literally any file format in the known universe automaically, so long as you can define a conversion path to a target format. That too is a very powerful concept, so it's worth persevering with. > About your code: how do you decide when to copy and when to move? > Shouldn't there be some parameter in the interfaces? Probably. I was just starting the discussion. Here's where I'm coming from: * All of our conversion efforts in 1.4.x take place in a temp directory. * The first thing we do in initiating a conversion is to place a copy of the original file in the temp directory. * Thereafter, we build a list of conversion steps that will take us to the desired output format and execute them. That's not so terrible is it? Quite understandable really. However, the problem is that this moving of the original to the temp directory invalidates any relative file paths inside the original file. Trying to subsequently fix the *conversion* step is fixing the symptoms of the problem, not the cause. As is often the case, it is actually really very messy to do so, because information about the original file location is no longer available to us. However, if these relative paths are fixed at the time the file is moved, then everything just falls into place. -- Angus
