As you know at the moment we have two packages: uniconvertor and uniconvw. First is a command line interface to translation engine, second is a GUI interface. We plan adding preferences dialogs to uniconvw and command line options to uniconvertor. If you prefer command line translation this interface will be accessible anyway. If you need we can adding verbose mode for command line and you could parsing this info.

uniconvw is pyGtk based so it's the same toolkit as Inkscape used. Actually there is no problem in using GUI way because it has the same L&F and this dialog can be screen centered. Even transitional and modal features is possible if you will pass Inkscape window xid/winID.  Under Windows to look more natively Inkscape calls WinAPI dialogs. So it's already toolkit mixing. But under win platform it's considered like rather advanced feature than a bad coding. At opposite cmd window for translation process is a worst case. Common win pattern is: avoid using command line, prefer library function calls.


On Fri, Jul 9, 2010 at 8:08 AM, Jon Cruz <jon@...18...> wrote:

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.