On Fri, 29 Aug 2014 04:40:34 -0600
Ken Springer <snowshed1@...3003...> wrote:
On 8/28/14 8:24 PM, Steve Litt wrote:
> Let's say the Inkscape programmers added a conversion to
jpg. That's
> one more lump of code that could have bugs or security violations.
> The more complex and entangled a program gets, the more bug-prone it
> becomes.
Since this is open-source, can't you just use code that's
already
written and bug free? Obviously, the UI part would have to be
written for Inkscape.
No. Here's why:
Bugs increase as a result of complexity. Even if there's not one single
bug in any of the pieces, interactions between the pieces, if put
together with "fat interfaces" including GUI, can cause bugs. Plus, the
difficulty of debugging goes up geometically with the complexity of the
program.
One relatively painless way to accomplish what you're talking about
would be for Inkscape to add an export menu that's nothing but space
for user-defined (perhaps with Inkscape default) conversion commands.
So if you chose jpg on the menu, Inkscape might run the convert
executable. This is very modular, and has little likelihood of
introducing bugs. But throwing source code from the convert
executable into Inkscape would be the kiss of death.
http://en.wikipedia.org/wiki/Modular_programming
http://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29
Take it from a guy who wrote code professionally for 14 years: if you
don't write code modularly, with very thin interfaces between modules,
you'll shed lots of tears. I found that out the hard way, early.
By far the thinnest interface is that of one executable program using
the output of another. Each program returns all its RAM. What program A
gives program B is clearly defined, and can be tested. Debugging can be
cleanly isolated to a specific executable, and if that executable is
small, it will be a quick fix indeed.
The user needn't be responsible for stringing together the executables:
The original programmer can provide a "shellscript" to do that. The
following program, which can be run from a menu or whatever, does just
that:
===================================================
#!/bin/bash
svgname=$1
jpgname=`echo $svgname | sed -e "s/\.svg$/.jpg/"`
convert $svgname $jpgname
===================================================
If the preceding script were called svg2jpg.bat, you could convert any
SVG by right clicking on it in a file browser, choosing "open with",
and choose svg2jpg.sh.
The preceding could be used for any .svg file, not just one in Inkscape.
In summary, the Inkscape developers could either add and debug hundreds
of lines of code to include jpg export, or write the previously
mentioned four line shellscript.
SteveT
Steve Litt *
http://www.troubleshooters.com/
Troubleshooting Training * Human Performance