Re: [Inkscape-devel] Fixes to save as on win32
- Should the two different exports be different menu items? Perhaps:
"Export Document" and "Export Selection"?
Bitmap export has a switch for this on the export dialog. It's pretty convenient. If we implement exporting a selection into a vector format, it should be similar IMHO.
_________________________________________________________________ STOP MORE SPAM with the MSN Premium and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI...
On Fri, 2004-04-16 at 12:26, bulia byak wrote:
- Should the two different exports be different menu items? Perhaps:
"Export Document" and "Export Selection"?
Bitmap export has a switch for this on the export dialog. It's pretty convenient. If we implement exporting a selection into a vector format, it should be similar IMHO.
I like that way too, but I just don't know how to make it work with how I'm thinking about things. I'd like to keep the preferences for the save and the type of save that you're doing separate. The reason for this is to allow more flexibility for the extension that would be implementing the export.
Now, how to do it... or, I guess, is that a worthwhile goal? I don't really want to have two dialogs - that would suck. I could see two menu items, but that seems a touch confusing (and perhaps harder to translate?).
--Ted
On Sat, 2004-04-17 at 02:14, Ted Gould wrote:
Bitmap export has a switch for this on the export dialog. It's pretty convenient. If we implement exporting a selection into a vector format, it should be similar IMHO.
I like that way too, but I just don't know how to make it work with how I'm thinking about things. I'd like to keep the preferences for the save and the type of save that you're doing separate. The reason for this is to allow more flexibility for the extension that would be implementing the export.
Now, how to do it... or, I guess, is that a worthwhile goal? I don't really want to have two dialogs - that would suck. I could see two menu items, but that seems a touch confusing (and perhaps harder to translate?).
IMO, the format-specific options belong in the save dialog alongside the generic save options.
One of the reasons for this is so users can select an output format from the dropdown and immediately know what their options are upfront (and depending on what those are, they might want to pick a different one). We want to facilitate user exploration.
Since we don't want to constrain an extension's UI (or choice of toolkits) unnecessarily, perhaps the best way to achieve this would be to provide a GtkSocket (http://developer.gnome.org/doc/API/2.0/gtk/GtkSocket.html) in the save dialog in which the currently selected extension can embed its preferences window.
However, in the specific case of exporting/saving a selection, it might make sense to have separate menuitems on the Edit menu to select that behavior. "Copy to file..." ?
Similarly for importing a file to be embedded the current document -- applications often call that feature "place", which translates the same as "paste" in many languages. "Paste from file..." ?
-mental
On Sat, 2004-04-17 at 10:33, MenTaLguY wrote:
IMO, the format-specific options belong in the save dialog alongside the generic save options.
One of the reasons for this is so users can select an output format from the dropdown and immediately know what their options are upfront (and depending on what those are, they might want to pick a different one). We want to facilitate user exploration.
Since we don't want to constrain an extension's UI (or choice of toolkits) unnecessarily, perhaps the best way to achieve this would be to provide a GtkSocket (http://developer.gnome.org/doc/API/2.0/gtk/GtkSocket.html) in the save dialog in which the currently selected extension can embed its preferences window.
Hmmm, I like the idea. The one thing that I was trying to preserve was the idea that a external script could have it's own preferences. But, I don't think that is worth saving, and it adds other complications like setting extension parameters externally. I think that if we just make it so that scrips have to use a generated interface, then we can do this, and not have the parameters problem.
That's the way that I'm going to go - any other thoughts?
--Ted
On Mon, Apr 19, 2004 at 09:00:21AM -0700, Ted Gould wrote:
Since we don't want to constrain an extension's UI (or choice of toolkits) unnecessarily, perhaps the best way to achieve this would be to provide a GtkSocket (http://developer.gnome.org/doc/API/2.0/gtk/GtkSocket.html) in the save dialog in which the currently selected extension can embed its preferences window.
Hmmm, I like the idea. The one thing that I was trying to preserve was the idea that a external script could have it's own preferences. But, I don't think that is worth saving, and it adds other complications like setting extension parameters externally. I think that if we just make it so that scrips have to use a generated interface, then we can do this, and not have the parameters problem.
That's the way that I'm going to go - any other thoughts?
This may be related to the work I'm doing on the print dialog. There is an interface to put "other" config options into the gnomeprintui dialog, but I wasn't sure how to handle it with the extensions.
Should I just let the extension work directly on the dialog using this GtkSocket? (Or am I misunderstanding how this should work?)
On Mon, 2004-04-19 at 12:22, Kees Cook wrote:
Hmmm, I like the idea. The one thing that I was trying to preserve was the idea that a external script could have it's own preferences. But, I don't think that is worth saving, and it adds other complications like setting extension parameters externally. I think that if we just make it so that scrips have to use a generated interface, then we can do this, and not have the parameters problem.
That's the way that I'm going to go - any other thoughts?
This may be related to the work I'm doing on the print dialog. There is an interface to put "other" config options into the gnomeprintui dialog, but I wasn't sure how to handle it with the extensions.
Should I just let the extension work directly on the dialog using this GtkSocket? (Or am I misunderstanding how this should work?)
Well, I am still personally leery of extensions providing their own UI -- the problems with extension/driver models that do so (directly, as part of the same module) have been demonstrated repeatedly (in the arena of scanner drivers, for example, compare TWAIN versus SANE).
Of course, in our case, nontrivial extensions often really do demand their own UI. So we can provide them a UI generation facility that is sufficiently flexible (XUL, maybe?), or have a separate category of UI extensions, among which can be specialized frontends for other extensions.
But that is long-term, and just my own thoughts on the subject. For now I think we will have to live with GtkSocket and the understanding that the extension model is still subject to change.
-mental
participants (4)
-
bulia byak -
Kees Cook -
MenTaLguY -
Ted Gould