Hi, everyone!

I suppose that this list has a very short memory, since we were talking about this about a month ago. :-) Some work has already been done toward this..

Here is a first cut: http://inkscape.org/win32/export/export-dump.png

Explaining the look, first please note that this is a first attempt. The dialog is basically a SaveAs dialog, with an extra panel added. The position of the panel is a Gtk thing, not something I devised. That's just where it goes.

The Gtk::Frame on the left is for the scope of the source document to export. It is output format-agnostic, and would apply to all types. Notice the blank area on the right. That is where the Preview box goes, the same as on the Open dialog. We would probably use this to display a preview of the scope of the source document.

The right side currently has information common to most types of exports we would provide. It is conceivable that some of the controls on the right side could change as the result of a callback from the type-selecting Gtk::Combobox. However, of course we would want to avoid bloat.

Now, I'm not really concerned with the appearance of this thing, and I'm not a GUI guru. What we need is this set of parameters to give us at least the amount of information that we have now. But the basic look of a FileChooser remains the same, and is not something we would want to waste our time coding from scratch. We are not in the toolkit business, but SVG editing.

In addition, PNG exporting has been decoupled from file.cpp, so that it can be called from elsewhere than the existing dialog.

There are 3 other things that we have been discussing, to support this functionality:

1) A clone-with-crop function, which will duplicate all or part of a Document according to the user's needs (left side of dialog)

2) Getting the output-specific parameters to the Output classes in Ted's extension architecture (right side)

3) (wish list) Decoupling the interpretation of the Document tree and the generation of the various output formats. This way the Document traversal only needs to be written and debugged once, and the various drawing contexts can be plugged into it. If you look in /internal, you will see a lot of redundant tree-walking code. With this decoupling, the gurus of what is in an SPDocument can determine how the tree is interpreted, and the people writing the outputs can concentrate on simpler drawing primitives. Also, the drawing commands of the contexts need only concern themselves with absolute coordinates, alleviating the need for output-writers to constantly convert coordinate spaces.

Remember, form must follow function.

bob