Am Samstag, 19. Mai 2007 18:45 schrieb Richard Heck: > Georg Baum wrote: > > A flag for the name of that directory does already exist: resultdir. Please > > use that instead of /path/file.html.conversion/. > > > I could be wrong, but this seems to do something else. > /path/file.html.conversion/ is where the files end up if you're > exporting, and the copying happens in Exporter.cpp. The resultdir flag > operates in Converter.cpp and seems (though it's hard to tell, since > it's not actually used in any of our converters) to inform us where the > external converter will have put its output, and then things get moved > in Converter.cpp, and then they get moved again in Exporter.cpp, if > we're exporting. I also don't think we want to require resultdir to be > set whenever usetempdir is. It may well be though (I haven't tried) that > setting resultdir with usetempdir is possible and works as one would hope.
Yes, I mixed that up. So resultdir should be set if and only if the converter creates a directory by itself. Please make sure that this does work in combination with usetempdir, or make these two flags mutually exclusive (since usetempdir is not really needed if the converter creates a directory itself one could ignore usetempdir if resultdir is set). > >>> As a result, the originaldir flag does not need to be used by any of our > >>> converters, and it may be redundant, though there's no harm leaving it, > >>> so far as I can see. > >>> > > IMHO it should be removed. > Have done. When I looked more closely, it caused massive problems: The > existing code copies all HTML files found in the original directory to > the temporary directory, whether they were created by the converter or > not! It's amazing there's no bug report for that. There have been several bug reports about the originaldir flag, not only in bugzilla but also on the users list. It is sort of known that it does not really work, but until now nobody was interested to fix it. > Here's an idea: Instead of Converter::convert() returning a boolean, > have it return a the location of the converted file as a FileName. It > can return an empty one (checkable with FileName::empty()) on error. > I'll still need the used_temp_dir boolean as a flag, though, ... > > Then there is some error checking missing: If the caller can't deal with a > > converted directory (e.g. for preview) then it should check that the > > result is indeed a file and act appropriately if that is not the case. > > > as I do NOT want to return a directory. I missed that, I thought you were returning a directory. Since you return a file I believe that no check is needed indeed. > The HTML converter, for example, > dumps about a billion files but there is going to be one that the viewer > wants, and it's that FileName I want to return, since there's no general > way in which to recover it. The temporary directory, on the other hand, > can be recovered as the path portion of the file name. Then again, I > suppose I could return a std::pair<FileName, bool> or a > std::pair<FileName, FileName>, with the latter being the temporary > directory if one was created, rather than have a bool & as an argument. > Advice welcome. My intuitions aren't always great here. (I tend to think > Perl. Just make it work.) If you do that I think the <FileName, bool> would be better. But I also think that the simple bool as return value is expressive. What confused me was the fact that there were two signatures. If there is only one, and the name of the converted file is always set by the converter, then I think it is clear. > > BTW there is another problem in this area that I solved in my playground > > branch: Some converters don't accept a commandline argument to set the > > resulting file name, but determine it using their own rules. They only > > work if these rules match the naming given by LyX, but will fail if a user > > changes e.g. the extension of a format. I solved this by a new resultfile > > flag. > > > I think you might have committed this. No, I only changed the semantics. Search for result_file in http://www.lyx.org/trac/browser/lyx-devel/branches/personal/baum/playground/src/converter.h and http://www.lyx.org/trac/browser/lyx-devel/branches/personal/baum/playground/src/converter.C to see the details. > I see the resultfile flag in the > exiting code and was wondering exactly what it did. It is documented in Converter.h. > Again, there's no > converter that ships with LyX (i.e., that is configured by configure.py) > that sets this. Candidates for the flag with the new semantics are all converters without the $$o placeholder. The old semantics is maybe needed for some HTML converters. One would have to check whether the guess of LyX for the main file name is correct. Georg
