Re: Common widget for choosing file formats

["Freddie Unpenstein" <fredderic excite com>]

>>>> format = egg_file_format_new (_("Scalable Vector Graphics
>>>> (SVG)"), "svg", NULL);
>>> That may be a bit short for container formats, which must handle
>>> subformats (e.g. AVI with different audio/video codecs).
>> Definitly didn't have this case in mind, and maybe its out of
>> scope for a _common_ widget
> Agreed. After all applications needing to choose a codec will want
> to specify a bitrate and some other settings, way out of scope for
> your generic widget. A simple format name with an optional icon
> should be ok.

There's no reason the standard save dialog can't still have a widget for format.  Sure, extra format-specific settings still need to be provided for, but that's only an issue where the application supports those extra settings.  And container sub-formats don't matter much when the application only has one or two formats that it's capable of saving in.

A tabless notebook beneath the format selector can probably handle the most common basic extra options in many cases, with an "Advanced" button for more.  Or, do as GIMP does, and just bring up a secondary dialog with the full range of options for that format.

One issue, is handling of formats supported already within GTK.  Using only GTK (GDK actually, I think?) alone, there are several formats I can save a raw image in, for example.  So GTK needs to have a list of formats provided by its built in image handling, ready for inclusion in such a list.  Selecting a format would emit a signal that includes a pointer (or other information) to a structure with information about that format.  An application could, for example, run through the standard list, setting or clearing a flag on each format indicating whether it should be included or not (since the list isn't likely to change during an applications run).  It could also add extra formats it supports to the standard list.

Based on that structure, the files shown in the save dialog could be filtered by type, first off.  This would be standard behaviour provided automatically by the save dialog.  Then, if basic options are provided for also within the dialog, that same signal would cause the relevant page of an embedded tabless GtkNotebook to be shown (after loading/constructing the page as needs be).  Especially viable once the GtkBuilder stuff is worked out, allowing the equivelant of a glade file to be distributed, that gets loaded and parsed automatically the first time it's needed.

But whether specific options are provided for savable formats or not, the file filtering is a "good thing!", as is the signal that allows the application to do whatever they'd like to do instead (including nothing, if they want to jump straight to the advanced options).  And if you don't like it, allow it to be optional, especially during the early releases (a little option in a right-click menu to turn it off if it's hiding files it shouldn't be, is all that's needed).

I for one would welcome development in this direction.  I can't remember how many times it's frustrated me digging through a long directory listing for the file I want, more-so in load dialogs, but also when I've wanted to over-write a file with new fresh content I'd just pasted into the application.


Fredderic

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!