I have worked on some of these, and I am looking at the others:

bulia byak wrote:

1 The dialog is modal but not transient. It's a very dangerous combination: it sinks under your document and you can't understand why the document is unresponsive. Please make it transient as it was before.

2 The dialog opens in some unpredictable place on the screen. Before, it opened centered over the document window. Can we restore that? (Maybe it's a consequence of its not being transient.)

Done. Adding a call to sp_transientize() took care of these two.

3 BUG: when I press Ctrl+O for the first time, there are no files listed at all in the directory where it opens, only subdirectories. If I go e.g. to the parent dir and then back, the files appear.

I have noticed this, too. This might be a Gtk bug. I will see if I can force that initial scan manually.

4 After some thinking I'm convinced that (as suggested here) we must replace the "Autodetect" with two new options, "All images" and "All files". That makes much more sense and is more consistent with typical Windows/Mac programs. Both these options would do autodetect and differ in filtering the list: no filtering for "All files" and showing only Inkscape-supported images for "All images". The bad thing about "Autodetect" is that it speaks about what the program does, not about what the user needs. Autodetect is not something I ever want to be off; it must always work behind the scenes. What I want to control is what files are shown and what not, and this is what this menu must affect.

Sounds good. What would help would be something in the Extension::DB information to indicate this. Maybe the mime-type would be enough, ("image/blah" or "x-image/blah") , but an enumerated int would be easier.

Also, by "All files" do you mean all, or all Inkscape-supported? Originally I had the filter set to "*" for all, but changed it to a concatenation of all of the files supported by Inkscape. So should there be 3 items?

All Images All Files All Inkscape Files

5 The menu should be reordered more logically so that the most frequently used options are at the top:

All images <-- default All files SVG Compressed SVG ---------- (separator) AI EPS PS Dia Sketch WMF text rest of bitmap formats...

The filters are somewhat laid out like that now. If anyone has an idea how to do a separator within the API, please let me know.

6 Also it would be nice to group the same formats with different extensions as proposed here:

https://sourceforge.net/tracker/index.php?func=detail&aid=990674&gro...

I suppose we can sort the remaining types by mime-type. I already added accessors for file_extension and mimetype to IOExtension.

7 If I want to go e.g. to /home/me/inkscape and browse files here, I go to the filename field, type "/home/me/inkscape" and press Enter. Nothing happens. In other programs (and I believe in Inkscape with the old dialog) this caused the dialog to switch to that dir.

I will work on this one. Currently it tests for TEST_IS_REGULAR.

8 I get these warnings whenever I open it for the first time:

(inkscape:7505): Gtk-WARNING **: Could not find the icon 'gnome-fs-home'. The 'hicolor' theme was not found either, perhaps you need to install it. You can get a copy from: http://freedesktop.org/Software/icon-theme/releases

(inkscape:7505): Gtk-CRITICAL **: file gtksettings.c: line 447 (gtk_settings_get_for_screen): assertion `GDK_IS_SCREEN (screen)' failed

(inkscape:7505): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(inkscape:7505): GLib-GObject-CRITICAL **: file gsignal.c: line 1726 (g_signal_handler_disconnect): assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

I installed http://freedesktop.org/Software/icon-theme/releases/hicolor-icon-theme-0.5.t... but this did not help. Any ideas?

No idea.

Preview:

9 There's no way to turn the previews off.

This could be either easy or difficult. What people are likely to expect is the same tree-widget type of switch provided on the Save dialog. That might not be so easy. A simple toggle would be easier. Remember, we must work within the API. The actual widgets of the FileChooser are private.

10 The open/close dance of the preview pane as you go through image/non-image files is a bit disconcerting. Can't we always have the preview widget on (that is, unless you turn it off, see 8), even if inactive for the current file, with the same unchanging size?

Sure. I just need to think of a "No preview available" svg drawing, something like the Gimp has. Maybe a good artist could volunteer to make one?

11 Bob, you mentioned that you did preview for the bitmap files as well, but this does not work for me, only SVGs.

.bmp? or .xbm? What I did for the preview was choose the more common formats. Maybe I should use the Extension::DB list for these, too.

Looks like we fired messages simultaneously :)

Sounds good. What would help would be something in the Extension::DB information to indicate this. Maybe the mime-type would be enough, ("image/blah" or "x-image/blah") , but an enumerated int would be easier.

Ted?

Also, by "All files" do you mean all, or all Inkscape-supported?

All files.

All Images

All openable files

All Files

All files at all :)

All Inkscape Files

All native files (svg & svgz)

...

Preview:

9 There's no way to turn the previews off.

This could be either easy or difficult. What people are likely to expect is the same tree-widget type of switch provided on the Save dialog. That might not be so easy. A simple toggle would be easier. Remember, we must work within the API. The actual widgets of the FileChooser are private.

OK, but this is not really critical, because the previews are surprisingly fast even for complex files.

Sure. I just need to think of a "No preview available" svg drawing, something like the Gimp has. Maybe a good artist could volunteer to make one?

Well, just make it show anything, and maybe it will be good enough :) If not I'll see to it.

...

11 Bob, you mentioned that you did preview for the bitmap files as well, but this does not work for me, only SVGs.

..bmp? or .xbm? What I did for the preview was choose the more common formats. Maybe I should use the Extension::DB list for these, too.

Preview does not work for PNG (most important), JPG, BMP or XBM. I think it should ideally work for anything we can open/import.

Speaking about type-ahead in the filechooser, it seems that someone just wrote the patch: http://webwynk.net/jrb/#1091224434

Which is good, but I still don't understand how they could release it with such bad problems and regressions. And of course type-ahead is no replacement for the lack of a filename field.

By the way here's another regression:

13 Before it was possible to press a button to create a new subdirectory. I see no such button now. What's up?

On Mon, 2004-08-02 at 10:33, Bob Jamison wrote:

bulia byak wrote:

...

By the way here's another regression:

13 Before it was possible to press a button to create a new subdirectory. I see no such button now. What's up?

On the save dialog, it is under "Browse"

That seems like a very strange place to put it.

-mental

bulia byak wrote:

...

...

On the save dialog, it is under "Browse"

That seems like a very strange place to put it.

Well, not really, actually it's where it should be - at the top of a file browser list. It's only that the entire file browser including preview is now folded by default (but that's OK with me).

With regard to save dialog, I see two problems now:

1 Pressing Enter in the filename field does not activate save (very annoying)

This item is private. This might not be possible to change.

2 By reusing the same file type list as in Open, we have effectively removed the possibility of saving in any format other than SVG (even SVGZ). If you want to save in some other format, first you must guess to open the "browse folders" pane (why?) and then you must guess that the list starting with "All images" actually controls your save format. Both of these guesses are highly counterintuitive.

When the dialogs are created, the desired type is passed to the constructors: OPEN, SAVE, IMPORT, EXPORT. This could be used as a switch during filter generation to get what is desired. The menus are not accessible directly. We create and add FileFilters.

Also, note that when the RESPONSE_OK is received after showing the dialog, we query which filter was selected, and lookup the Extension from that. So, if the user picked a file type that is not one of the aggregates (All 'blah') , then we do know what type was desired, and we might be able to use it. It would be good if the API returned the info "which pattern listed this file type?" but that would be dreaming.

Here's what I think must be done:

• move the "Append extension" checkbox right under the "Name:"

This is an API thing. I do not think that it can be moved. However, we can -maybe- (maybe not) have the "extra widget" allowed by the api to be a panel that stretches the width of the dialog, and align the checkbox on the right. This might take some investigation/playing.

• to the right of it, add a new drop-down menu "Format:

[SVG|SVGZ|...]" - this will control the format

Same thing.

• before the "All images" list in the filebrowser, add "Show:" label

(both in save and in open dialogs) - this will only affect what is shown in the list, not save format

Maybe the same thing, too, as the right of the panel would be near the filter list.

Changing the topic a bit.... maybe someone can look at the export dialog (export.cpp, not filedialog.cpp), and see how it could be updated.

And thanks for fixing the "No preview" thing. Looks nice.

I have a software delivery this week for the "day job", so I will not be able to work on this for a few days.

Bob

On Sun, 2004-08-01 at 05:51, bulia byak wrote:

...

Sounds good. What would help would be something in the Extension::DB information to indicate this. Maybe the mime-type would be enough, ("image/blah" or "x-image/blah") , but an enumerated int would be easier.

Ted?

I'm sorry, I'm not clear what your asking here. I think that what is being discussed is whether the input extension should be used for a preview? I guess my question would be, why not all? Speed? I think that right now the only extension that is 'easy' to detect is SVG because there are #defines for the IDs. Everything else will move to be external from the codebase.

I guess we could just add a field, but I would like to leave all the input extensions as 'equals' as much as possible. I guess we already makre save extensions as 'lossless' or not, but I see that as a property of the save more than a special marker.

--Ted

On Tue, 2004-08-03 at 22:17, bulia byak wrote:

What will it look like?

I think adding "Save in folder:" list and the "Browse for other folders" expander instead of the old "Browse" button is all that is needed. Otherwise the dialog is fine as is. For one thing, I don't want to make it modal like Save, nor add a Cancel button.

That's basically what I was thinking. I was thinking about moving the name to the top with the other options below so that it looks a touch more like other applications - but I'm not decided on that at all.

I'm not sure how flexible the Gtkmm dialogs are, it would be kinda nice to be able to start with the save as dialog as a base.

I really haven't thought much about this.

--Ted