Subject: commit -- first pass at command-line conversion
From: Paul Rohr (paul@abisource.com)
Date: Wed Mar 08 2000 - 16:42:17 CST
First pass at command-line conversion, courtesy of Joaquín Cuenca Abela
<cuenca@ie2.u-psud.fr>
M src/wp/ap/Makefile
M src/wp/ap/beos/ap_BeOSApp.cpp
M src/wp/ap/unix/ap_UnixApp.cpp
M src/wp/ap/unix/gnome/ap_UnixGnomeApp.cpp
M src/wp/ap/win/ap_Win32App.cpp
M src/wp/ap/xp/Makefile
A src/wp/ap/xp/ap_Convert.cpp
A src/wp/ap/xp/ap_Convert.h
Since discussion of Joaquin's series of patches for this seems to have died
down, I've gone ahead and checked it in more or less as is. The status for
each platform should be as follows:
GNOME, GTK -- Joaquin tested these, so I didn't.
WIN32 -- The build breakage for Win32 was very easy to fix so I did.
BEOS -- I went ahead and turned this on as well, changing the #if 0s
to #if CONVERT to make it easier to turn off if it breaks the
build too horribly.
QNX -- Thomas, he didn't provide an implementation for me to check in.
I doubt that the oversight was intentional.
I suspect that this feature could use a bit more work, now that more people
have an opportunity to play with it. Five comments:
1. abiword foo.abw -to abw
---------------------------
Do people think this command should be valid? I presume that this should
only work if:
a. we have importers and exporters for the same format
b. that round-trip process is *not* lossy
c. it's OK to overwrite the original file
If so, it makes a great way to allow folks to "upgrade" old documents to the
latest file format. However, I'm a bit nervous about overwriting existing
files like that (especially given #4 below). Is there a better way to do
this?
2. argument order now significant
----------------------------------
0n all platforms except GNOME, the order of arguments has now become
significant. For example, if you launch abiword as follows:
abiword foo.abw bar.rtf -to html -show blip.txt -verbose 2 zot.rtf
it will open foo.abw and bar.rtf in document windows, then convert blip.txt
and zot.rtf to html. Also, only the zot conversion would be at verbose
level 2. Worse, if you omit the -show argument, those windows may appear
quickly, then disappear. YMMV.
I'm not sure whether this order-sensitivity is a feature worth keeping. For
example, given the current argument-parsing logic, I suspect that a command
like the following would actually *work*:
abiword -to html foo.abw bar.rtf -to rtf foo.html bar.html
This seems to be the kind of QA fun we don't necessarily need. For example,
that command, if successful, would perform the following conversions, in
order:
foo.abw --> foo.html
bar.rtf --> bar.html
foo.html --> foo.rtf
bar.html --> bar.rtf
Note that the original bar.rtf file gets clobbered. By contrast, if we only
allowed one conversion, you could still achieve the same effect in two steps
as follows:
abiword -to html foo.abw bar.rtf
abiword -to rtf foo.html bar.html
Moreover, if we change the non-GNOME parsing to not be order-sensitive,
then those commands would be equivalent to the following:
abiword foo.abw bar.rtf -to html
abiword foo.html bar.html -to rtf
Am I the only one who finds this more readable?
3. convertTo(szFilename, szSourceSuffix, szTargetSuffix)
---------------------------------------------------------
I'm pretty sure that the implementation of this method should use IE_Imp to
do suffix-detection on the incoming file. However, I couldn't find any
place where it got called to test the change.
4. *printf messages lost on Win32
----------------------------------
We're not building the Win32 version as a console application, so all of
the verbose output sent to stderr or stdin by this command gets lost.
Anyone have a more appropriate solution?
5. code factoring
------------------
Finally, seeing all this redundant logic down in platform code makes me
itch. As always, suggestions for better refactoring of the code are
welcome. However, this shouldn't be done until #2 gets resolved.
Enjoy!
Paul
This archive was generated by hypermail 2b25 : Wed Mar 08 2000 - 16:36:48 CST