Created attachment 59421 [details] [review]
patch to set expander default state to true ; widget hidden

I would argue that there is something fundamentally wrong with the 
set of bugs you've filed:

The current GtkFileChooser was designed starting from a coherent
set of ideas about who was going to using the filechooser and how;
these assumptions include things like:

 - People will be saving files to a small set of directories
 - People will create bookmarks for those directories if they
   aren't the standard set of directorise
 - People will mostly be working with files within their home
   directory

and so forth and so on. Some of the original design work can be
seen at:

 http://www.gnome.org/~seth/designs/filechooser-spec/

(That doesn't really go a lot into the reasoning behind the design,
partly because Seth considers design as much an intuitive
process than a logical one. But the design there was done pretty
much entirely *before* any coding started on it, and you can
see how the behavior was thought through in detail and has lots
of interlocking components.)

You clearly have a fairly different idea about what people will
want to do with the file chooser. Your idea isn't necessarily wrong.

But the idea that you can take the current file chooser, and piecemeal
make changes towards your internal idea of what a file chooser should
look like is. As you note yourself, saying that the file chooser
should start off expanded is silly ... if people *aren't* saving in
a small set of directories -  if they normally need to navigate to a
directory - then the expander shouldn't be there at all.

I'm not going to claim that pushing a different design direction for
the GTK+ file chooser is easy ... there is a lot of momentum behind
the current design. But if that's your interest, then the correct
way to approach it is to first create detailed descriptions and mockups 
of how *you* think the file chooser should operate. You might even want
to create a patch for GTK+ that implemented that design and get
people using it ... I'm sure Gentoo users would love to 
emerge gtk2 +better-file-chooser or whatever.

I should also say that, of course, there are UI improvements improve 
the way that the file chooser works while staying consistent with
the current design, and likely some of your patches and suggestions
fall into that category. But the general impression I get is that
you'd like to see the file chooser significantly changed and if that's
the case, you need to present the full change, not just a bunch
of changes in that direction. Something halfway between your design
and Seth's design is almost certainly a worse filechooser than
either one.

Thanks for your comments , that's very useful. I will reply more fully once I've read the link.

I created several bugs for clarity to focus on each point where I think the interface is weak , and so as not to be accused of "griping" added a little patch to remedy the critisism.

Recognising that it will be an long hawl to get changes accepted, I thought the patches may prove useful to those who find the interface lacking.

I think there are two general areas where I would like to see change. 

1. The present interface could be made more stable visually (eg column widths changing unnecessarily and path bar buttons moving around).

2. A more global change in approach because I find the interface requires too much interaction to achieve a simple result.

Hopefully in presenting it piecemeal, at least some of the mods may gain some acceptance or insprire changes. In particular giving the path bar full width seems at least to have raised some interest.

Thanks again for your help.

I have opened #331404 to address some of points of general sytle and where I 
think the basic design concept is a bit flawed.

Thanks for pointing me to that document. It is certainly valuable to see
this from a top-down perspective rather than nibbling away at the symtoms.

I just hope it is positively received.

regards.

Created attachment 59500 [details]
screenshot of modified save-mode  filechooser

The principal thing to note is the full width path_bar. As 
many user have the habit on long file names the need for
the width is clear.

Many themes also markedly increase the space reqd by the buttons of 
the bar from the plain Jane look shown here.


This shot combines a number of small mods that I think make
it clearer and easier to use that have been detailed elsewhere.

Notably adding "bookmarks" label and hiding the expander 
and (disabled) combo.

impressions please.

oops attached to wrong bug . Pardon.

The plan for this is threefold:

1. Remove the "Browse for other folders" expander altogether.  Put an "Other..." item at the bottom of the "Save in folder:" drop-down.  If you select this "Other..." item, the dialog will expand to show the file browser.

2. Fix bug #314889.  The dialog should expand to show the file browser if you type a folder name in the "Name:" entry and press Enter.  Currently, doing that only changes the current folder, but doesn't expand the dialog.

3. Actually do a better job of picking a startup folder if the app didn't specify one, *and* make it easier to navigate to the folders which you may be interested in.  This is the work described in http://live.gnome.org/RecentFilesAndBookmarks

>>
1. Remove the "Browse for other folders" expander altogether.  Put an
"Other..." item at the bottom of the "Save in folder:" drop-down.  If 
you
select this "Other..." item, the dialog will expand to show the file 
browser.
>>

Oh , no. This is going backwards. 

Just take a step back and look at this. 

Imagine I am a real anarchist user and I dont want to store everything 
on my desktop ;) In fact I want free and easy access to store a file 
somewhere - anywhere that permissions allow - in my filesystem.

So what do I need to do?

File | Save  from the program calls up the dlg
click "save in folder"
click "other"
choose the bookmark closest to where I want to go 
navigate a bit clicking on the pathbar and double-clicking on file list.

Now that is a lot of work for a trivial task. In fact I dont think I 
know another interface that makes it such a job to save a file.


Now if you consider the choice of suppressing the combo and exposing the
full dlg by default you instantly eliminate two of these steps. Nice.

More over the current conception of the user having a limited number of "favourite" directories is _also enhanced_: one click on the now 
visible-by-default bookmarks list will get him all the way. This is quicker
than - click on combo - roll to reqd bookmark...

Everyone gets there quicker.

If you take a look at the shot I posted in #5 , this is how it comes up,
straight away. Without the need for either the expander or the combo the 
interface is clear and fully functional for all types of user.

The added bonus is a much greater degree of consistancy with the other 
file dialogues. 

This also resolves the bug in point 2. The expander should not be flipping
itself if.. and when .. and but .. This again is distruptive. 

If the expander is always open bug #314889 is no longer an issue.


I'm sure I've made the point elsewhere but I feel a lot of reason this
interface can be hard work for the user and there are niggling bugs like
this above is that there is too much conditional behaviour.

gtk is trying too hard to please, the result is often a hinderance.

Do you see what I mean?

> Imagine I am a real anarchist user and I dont want to store everything 
> on my desktop ;) In fact I want free and easy access to store a file 
> somewhere - anywhere that permissions allow - in my filesystem.
>
> So what do I need to do?

Use a file chooser thats designed for anarchists. Bending the design
of the current file chooser to suit anarchists will make it less usable
for regular users ...

> Use a file chooser thats designed for anarchists. Bending the design
> of the current file chooser to suit anarchists will make it less usable
> for regular users ...
> 

Please take the time to read the post before replying, this is a suggestion
that improves the experience for all users. To quote the bit you missed:


More over the current conception of the user having a limited number 
of "favourite" directories is _also enhanced_: one click on the now 
visible-by-default bookmarks list will get him all the way. This is 
quicker than - click on combo - roll to reqd bookmark...

Everyone gets there quicker.



Apart from dismissing your comments as being a defensive reaction 
(apologies if suggesting there could be improvements is treading 
someone's toes here) I fail to see how a dev can make a faceacious 
comment like "choose another filechooser". 

There is not a choice . I dont use gnome desktop (that's a choice) but there
is a whole fleet of excellent software that is build on gtk libraries.

I dont intend to stop using all software based on gtk because there are
some things that could be done better in the filechooser.

This is open source and I have enough programming and UI mileage behind 
me to make a positive input. That is what I am attempting to do.

There has been some solid programming gone into gtk and gnome in general. 
That's not to say certain things could not be improved. 

A good programmer is not necessarily a good interface designer.

I could just hack the bits that annoy me and be done with.

I dont know what your motives as a dev are but having put the effort
to make this a bit run a bit smoother it makes sense to feed that back
into a project from which I benefit every day.

I thought that was one of the pricipals of open source.

sorry if I have ruffled some feathers, that was not the aim.

Sorry for being dismissive. But you are late to the game. The
file chooser has been discussed to death for two years now,
in tons of bugs and mailing list threads. 

Sorry for being late ;)

If this is still drawing bug reports two years on maybe the basic
design model is flawed.

That's why , having followed Owens information I created bug #331404 
as a critique of the basic assumptions.

If you're tired of hearing about it I understand.

I'm tired of battling with this interface every time I need to open
or close a file and have decided to do something about it.

best regards.

Created attachment 60088 [details] [review]
combined patch to create dlg shown in screenshot attachment

For completeness patch to produce the screenshot dlg.

patch includes modification to hide combo and it's label 
rather than leaving it visible but redundant

contains three mods all fully fuctional independantly.

expander open by default
hide combo when disactivated (ie browser visible)
hide expander: full dlg as shown in jpeg. less clutter.

(In reply to comment #11)
> Sorry for being dismissive. But you are late to the game. The
> file chooser has been discussed to death for two years now,
> in tons of bugs and mailing list threads. 

It's not being late. It's gtk developers decision not to support people who use GTK programs for more than saving a picture on the desktop. E.g. people using gtk text editors for more than "Open with Text Editor".
This argument "has been discussed" is always used in these arguments instead of honest "Works as designed, GTK file choosing interface is oriented towards certain kind of people, you're out of luck".
As federico once said "Of course unix hackers use GTK filechooser, for example in firefox" ;)

>>It's not being late. It's gtk developers decision not to support people 
>>who use GTK programs for more than saving a picture on the desktop. 

I started bug #331404 as an re-evalution of the suitability of this
rather limited view of what is required here.

Sooner or later I think the basic design objectives will have to be 
reviewed. 

I'd like that discussion to be as objective as possible with an eye to 
making some positive changes, so if you have any specific ideas please
post.

Bugzilla makes a poor discussion forum. If you feel like discussing
the filechooser design, please take it to usability@gnome.org. 

I will also post this suggestion to usability@gnome.org , but this is specifically a feature request.
Why can't we make this a gconf or other setting, so that users or organizations can decide which way they'd like it to operate?  I am in the process of patching the code for a library system whose patrons are confused by the current behavior. I think even novice users expect to see more information about where they can save files.  Although open source code is great since anyone can patch it, it's much nicer if everyone doesn't have to create their own version!

It seems this bug is related to the bug #153828

This got fixed as part of a patch for bug #153828; marking as duplicate.

(The file chooser now remembers whether it is expanded or collapsed)

*** This bug has been marked as a duplicate of 153828 ***