This is because you are not working with an image in Indexed mode.
Just leave the file type menu on "By Extenstion", enter a filename
that ends in .gif and the Export dialog will guide you thru the
necessary steps.

That's right for the "Save as..." dialog but in the case of "Save a
copy..." it should always be possible to save to a filename with any
extension by selecting the type in the dropdown. IMO the "Save a
copy..." dialog should enable all available types regardless of
whether the image complies with the format's requirements, assuming
that the export is always possible. I suppose that enabling all
formats in the "Save a Copy..." dialog will be trivial.

We should consider to never set any file formats insensitive and use
the export dialog whenever needed. Doing it differently depending on
how you invoked the dialog seems even more confusing.

I agree, and I would like to see all file formats active when saving a
file to allow specifying a different extension. Reopening and changing
the summary and severity accordingly. See also the somewhat related
bug #115103.

It would be better to implement this enhancement after merging the
Export dialog into the Save dialog, as described in bug #119545.  Then
it would make a lot of sense to enable all file formats in the list.

Although this bug could also be fixed without fixing bug #119545, I
think that it would make more sense to enable all file formats if the
user can see immediately what is going to happen.  If you agree, please
add a dependency on that bug report.

Even if bug #119545 looks like a very reasonable proposal, I think 
that this bug report is independent of it. If #119545 is implemented, 
this bug report would automatically be solved because of the change 
in philosophy it implies, but just as bugs #62988, #75328 and #75459 
mentioned there, this one does not actually depend on it.

Furthermore, the save dialog reorganization means quite a bunch of 
changes which can be postponed if there's a sudden need of a hurry. 
Has happened and may probably happen again. This one, however, is 
almost trivial to fix. For these reasons, I don't think that adding a 
dependency on #119545 is a good idea.

I'm adding the tracking bug #118191 as a blocker, though. I actually 
made this change before, but for some reason Bugzilla has not 
recognized it.

This issue keeps causing confusion or at best annoyance among users.
Every so often people ask how to save their image in this-or-that
format which appears grayed; a workaround exists, but it is not
obvious for many users. This corresponds to the definition of "minor"
severity, so I'm raising it.

I think that this problem should be revisited before 2.0; changing the
milestone accordingly.

As per discussion in other bugs and elsewhere, it's been suggested to
remove the dropdown entirely, since it just causes confusion. Perhaps
have it disabled by default, or even have the option in the prefs
dialog and not the load/save dialog.

Created attachment 23207 [details] [review]
Proposed patch to fix bug #110610

There is no way we can do such changes before 2.0. Bumping to 2.2.

I'm convinced that any misbehaviour caused by the patch would happen
also when using "by extension", so it won't break anything more than
it is now. I was convinced before but I've tried all cases I could
think of and I'm now even more confident.

Reverting milestone to 2.0 again.

I guess we can leave this on the 2.0 milestone to discuss it, but I'm
convinced that this is not appropriate when we are (in principle) only
3 or 4 weeks away from a release. 

Despite its many flaws, some people use the "By type" dropdown. I'm
not implying that we shouldn't do away with it, but we can't do it in
the middle of pre-releases. I suggest holding off a month and a half
or so (until after 2.0.1, and we branch a 2.0 stable branch), and
committing it, or something similar, then. Perhaps as yosh suggested,
in conjunction with a preference.

Dave.

I am not sure that removing the dropdown menu would be a good idea.
It would be better to keep it, but with all file formats enabled as
suggested by the title of this bug report.  This menu is used (and
abused) for selecting the file format, but it has another very useful
feature: it allows the users to see what file formats are supported by
their copy of the GIMP (depending on the installed plug-ins).

Removing the menu now would probably cause more confusion than keeping
it, because many users would have no idea of what they can select as a
file extension.  Having a list in the menu is more convenient than
relying on trial and error or browsing the PDB.  So my suggestion
would be to apply a patch that enables all file formats (for 2.0) and
then investigate (for 2.2 or later) if we can remove the menu and
replace it by a a better way to present the list of available file
formats in a way that can be found and understood easily by all GIMP
users.

I fully agree with Raphaël here. Even if "others do it" tends to not
be a good reason for me, the format selection menu is a
well-stablished standard used by many applications (including, but not
limited to, Sketch, Sodipodi and KPaint, just to mention some graphics
apps). Removing it could cause many users to complain.

I never advocated any big change for 2.0, my comments were made when
the milestone was 2.2.

The right thing to do I think is simply move the export functionality
into the core and always hand the plugins what they expect. Perhaps
something could be done in the UI to discourage the use of the
dropdown, since it's really not a useful thing in 99% of save cases.

Perhaps we should try the change that Pedro suggested for 2.0pre2. If
it turns out to cause problems, we can always revert it before 2.0final.

Fixed in CVS. I suggest that further improvements (removing the
selector or whatever action is desired in future) are reported as new
bugs and tracked by #118191.

2004-01-15  Pedro Gimeno

	* app/gui/file-save-menu.c (file_save_menu_update): Removed the
	code that disables save formats conditionally, making all of
	them available. Fixes bug #110610.