Carl Hetherington wrote:

On Thu, 15 Apr 2004, Ted Gould wrote:

...

On Thu, 2004-04-15 at 07:47, Carl Hetherington wrote:

...

I just committed a patch to allow save as PS/EPS on Win32. I'd be grateful if any Windows-ers could test it.

It looks like the fileTypes parameter to the FileOpenDialog and FileSaveDialog constructors is now not required. Perhaps it should be removed?

Cool! Thanks for the work. I think that parameter can go away also. I kept breaking the win32 build when changing that dialog - so I was trying to be conservative because I couldn't test the win32 compile. I believe that parameter can go away also.

Sounds good. Please make certain, though, that filedialog.cpp and filedialog-w32.cpp both follow the filedialog.h API, so as not to break it on Unix.

OK. I'm a bit confused about the Import dialogue, though. Is it right that on Linux the menu only offers "SVG", and no other types? ATM, the Windows version offers "SVG files" and "Image files" as selection options.

Notice that for Import, even on Windows, the GTK file open dialog is used. Really, since on Win32 we are using the windows native file open dialog for SVG, we should be using the same for Import. I didn't make this change, because I thought that if we could wait until GTK 2.4, the new file dialogs would be good enough that we would not need two different implementations.

One thing to keep in mind, is that we need to migrate from "filename" to Mental's URI model. This is important for (1) portability and (2) SVG spec compliance. Currently on Windows, if you import an image, the SVG file will quote the path in Windows format. Something like:

<image .......blah .... filePath="c:\path\to\the\file"/>

....which is obviously unacceptable, and useless on non-Windows boxen. Eventually we will need several things:

1. The file dialogs return URIs 2. The sp_module_open() calls handle URIs too 3. All of the resource-handling modules use URIs too, like for markers, icons, clipart, etc.

Bob

On Fri, 16 Apr 2004, Ted Gould wrote:

On Thu, 2004-04-15 at 09:16, Carl Hetherington wrote:

...

OK. I'm a bit confused about the Import dialogue, though. Is it right that on Linux the menu only offers "SVG", and no other types? ATM, the Windows version offers "SVG files" and "Image files" as selection options.

[snip]

I think that we need to decide what functionality we want accomplished by 'Save', 'Open', 'Import' and 'Export', and then strive to make it happen. Here is what I'm thinking:

Open - Take a file and make a new window with it

Save - Take the entire document and stuff it into a file

Import - Take a file off the hard drive and put it into the current document

Export:

1. Take the current document and save it, without changing the name of

the current file or anything else about the current document (ie modified or anything like that)

2. Take a selection, and put that selection, by itself, into a file.

Sounds sensible to me. I suppose we should check the Gnome HIG, if we're following it. I'd probably say "Save - Take the entire document and stuff it into a file from which the document can be losslessly recovered by Inkscape." e.g. save doesn't contain PS because saving as PS loses information.

When I say "lossless" I mean "save from Inkscape and re-load into Inkscape gives you the same thing". So suppose we had a completely functional PS export but that Inkscape could not fully load PS files that it had saved. Then PS export would be lossy.

So Open and Import are the same, except that Import pastes its data into the current document and Open creates a new window?

Then Save and Export are the same, except Save is always lossless and export is always lossy.

Issues

• Should the two different exports be different menu items? Perhaps:

"Export Document" and "Export Selection"?

I'm not fussy. Either that or a tick box in the Export dialogue.

[snip]

Okay, what do people think about all that. It is was kinda a brain dump.

Likewise.

Cheers Carl

On Fri, 2004-04-16 at 09:37, Carl Hetherington wrote:

Sounds sensible to me. I suppose we should check the Gnome HIG, if we're following it. I'd probably say "Save - Take the entire document and stuff it into a file from which the document can be losslessly recovered by Inkscape." e.g. save doesn't contain PS because saving as PS loses information.

I don't know how I like this - I kinda like being able to do a save with 'lossy' formats. Remember that the only formats that aren't currently lossy are 'Inkscape SVG' and 'Compressed Inkscape SVG'. Currently, if you save with a format different than those, you'll get a dialog on close reminding you that data may have been lost and allowing you to save again. I like this for save.

One of the reasons for that is that now we can open and save Adobe Illustrator files. I don't think that either of the filters are currently very good - but they could be useful, and will hopefully get better. But, I think it would be reasonable to open up an Illustrator file, edit it in Inkscape, and then want to save it. I don't think the user should have to 'Export' at this time -- they should just be able to save.

The distinction that I was trying to make with Export and Save is what happens to the document. If you had a document that you were working with that was Inkscape SVG, and you wanted a EPS version to send to a buddy, what do you do? Well, currently you'd save it as EPS, then you'd have to reopen it as SVG (or save it twice) to get back to your editable state. Instead, I was thinking that you could just export it. The export wouldn't change the name of the file, the save format, set the 'lossy' bit, or even adjust the modified state. It would almost be an orthogonal action to save - that doesn't get in the way of the variables that we use to track saving internally.

So Open and Import are the same, except that Import pastes its data into the current document and Open creates a new window?

That's what I'm proposing, yes.

--Ted