On Jul 8, 2010, at 9:39 AM, Igor Novikov wrote:
Another valuable reason is planned preferences for translation. We are going provide a lot of translation options (we already have the code but we still not expose it as a command line options) and naturally such preferences could be managed better from GUI than command line. So we will add preferences dialogs for each format into UniConvertor. It's not an easy task so for Inkscape team will be better utilizing ready dialogs from UniConvertor than creating the same but on Inkscape side. And as I have wrote UniConvertor translation progress dialog would be also a good additional feature for Inkscape.
Unfortunately this approach is going in the opposite direction from Inkscape. Mixing different UI elements, especially toolkits, is one of the major issues with Inkscape and one that reviewers who might recommend it to others find to be a major problem. There are many other issues with such mixing, and the Scribus team has confirmed and pointed out many more. These issues have also plagued libraries and interfaces such as TWAIN.
For a library, it is far better to separate user interface from the functionality, and to abstract needed data into the API. We also have been planning on a refactoring pass for both our plugins and our preferences, so unifying those instead of diversifying is where we'd like to go.