GNOME Bugzilla – Bug 153828
Filechooser does not remember state
Last modified: 2009-02-27 19:57:20 UTC
When saving a file, the filechooser does not remember the last state it was in. By state I mean - if the little trianlge next to "Browse for other folders" has been clicked or not. I prefer using the filebrowser component that is available in the expanded view and currently I have to open it manually every time. I would expect the filechooser to remember its state from one invocation to the other. Other information:
*** Bug 161162 has been marked as a duplicate of this bug. ***
As in the duplicate, "saving state" should probably also save the dialog size, the position of the paned's handle, etc.
i'll ask the question here too: is there a quick way to change the default-size of the filechooser? gconf? change some DEFINEs in the source-code? or is it using some kind of use-the-default-size-of-the-parent-"class" thing?
*** Bug 170294 has been marked as a duplicate of this bug. ***
*** Bug 302053 has been marked as a duplicate of this bug. ***
*** Bug 170138 has been marked as a duplicate of this bug. ***
*** Bug 144036 has been marked as a duplicate of this bug. ***
*** Bug 323997 has been marked as a duplicate of this bug. ***
*** Bug 144033 has been marked as a duplicate of this bug. ***
Since my bug #323997 was filed as a dupe, let me restate my proposal here: Revert to a non-stateful Save as-dialog. Atleast until the problem with the current design is solved (which I argued that it was unlikely that they could be).
Shouldn't the application that pops up the file chooser remember its size and resize it when creating one - just like they set the initial folder for filechoosers they open? I would prefer this way since if we remember the size for any filechooser, problems/annoyances may occur with resizing different filechoosers with previews, etc. For that reason, simply adding some API for setting the initial filechooser state and reading it after it's dismissed should be pretty much enough. Same goes to show/hide other folders expander.
I think it's crappy to force a developer to handle that stuff. We have ONE file chooser (from a user-perspective - even if it has some visual differences - the purpose is the same). And I - from a user-perspective - expect that it keeps the size, visuals (and location) I used the last time. Moreover, there's too much effort to update a thousand file-chooser calls instead of updating the file-chhoser itself.
It would not be consistent for Application X to invoke System Function A in A(X) way and Application Y to invoke System Function A in A(Y) way. What I mean is, if the file chooser is stated to "Browse" mode by default, it should be stated that way across all applications. Personally I think this should be a configuration option, because memorizing the last state seems semi-random when the actions you take in Application X affect the behavior of Application Y. A change to the configuration of System Function A is expected to change Applications X and Y.
GNOME overall lacks config options. I doubt this one will turn into being configurable. :/
Having filechooser that keeps it state globally is wrong - think of user opening some files in her Music folder, and then opening some document in a word processor. Presenting the file chooser in Music folder would be wrong then, since she always opens stuff inside Documents folder in word processor, and Music in her media player. Same to saving - she might just drop files to the Work folder with their names as-is from the word processor, so a "minimized" filechooser that only asks for a folder and is not expanded by default is ok, but when she is saving stuff from the web browser, she always wants to save them under different names (web is a mess, you know) so she would like to have an expanded filechooser by default in web browser. Thus, the right way(tm) would be remembering the last state of the filechooser on a per-application basis, just like the positions of Nautilus windows are remembered and restored - we're after spatial desktop after all.
By 'state' I just meant ... - size - position Optionally - 'Remember working directory' could be a checkbox within the dialog.
*** Bug 332270 has been marked as a duplicate of this bug. ***
FWIW, I agree with comment #15... no user-visible config ought to be necessary here, it should just work. Another consideration is whether to also save "working folder state" separately for Open, Save etc. dialogs in the same application... sometimes I get annoyed when apps use the same "most recently used" folder for both opening and saving, and sometimes I get annoyed when they don't :) (But I always get annoyed when they ignore it altogether and default to "Documents" or something). I guess the main thing is to pick something sensible and apply it consistently.
Seems like GtkFileChooserSettings [1] can be used to address this issue. Here is my proposal: 1. A new property is added to the GtkFileChooser interface that identifies the filechooser. Thus, to create a filechooser that restores its state you simply provide an identification to the filechooser when creating it: GtkFileChooser *chooser = g_object_new (GTK_TYPE_FILE_CHOOSER_DIALOG, "action", action, "identification", "org.gnome.Application.SaveDocumentAs", NULL); 2. When such filechooser that has non-NULL "identification" property is destroyed, its GtkFileChooserSettings are saved to the appropriate location (~/.config/gtk-2.0/gtkfilechooser/org.gnome.Application.SaveDocumentAs). 3. When the filechooser with this identification is constructed next time, its saved state is read from that file and the filechooser gets updated accordingly. [1] http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00016.html
It seems bug #310574 is duplicate of this bug
http://gentoo-wiki.com/HOWTO_Beautify_GNOME has a patch to change the default to expanded.
Created attachment 79453 [details] [review] save the folder open/closed state with the file chooser settings
The above patch resolves part of this bug - it saves the expander state along with the other file chooser settings. It doesn't add any other saved state. It should apply cleanly against current 2.10 CVS.
Very nice! Thanks, Peter. Can you please commit it to HEAD and gtk-2-10? As an exercise, I leave it to you to translate that into svn's terminology ;)
Can't it be done without filechooser flashing and resizing randomly? Now it at least flashes (yuo can see expander expanding quickly); and sometimes it resizes back to small size after expanding.
Or how about finally making some gtk_file_chooser_set_expanded() public, so application developer may actually fix this thing, since it's already admitted that "always collapsed" is not what a user may want? Then one could also save size of Save dialog (it's not as critical as size of Open dialog, which thank to don't know whom can be saved, but would be still nice).
with the new release of gtk, gtk_file_chooser can save it folder open/closed state now, but can we add another feature to allow save the dialog size for open and save, by default the size of save dialog is a bit smaller than I need. in the content pane, I can only get three items. See the attached image for detail.
Created attachment 80561 [details] Save dialog The save dialog which only 3 items can be seen in the content pane. So I hope the size can be saved after I resize this dialog
Created attachment 80575 [details] [review] patch This patch fixes mentioned flashing and other dances caused by loading state in map(). Federico, could you comment on how you think all this stuff with state and everything should be? Somehow it was believed "filechooser does the right thing", now things seem to be better, it's great. Still, without you it's not going to fly anywhere. Random patches like one that was applied (to 2-10!) do no good; and they will silently break stuff of people who actually try to fix FileChooser behavior in applications (yes, there are silly people doing that).
(In reply to comment #29) > > This patch fixes mentioned flashing and other dances caused by loading state in > map(). We need to do it in map() because some apps recycle the same instance of a file chooser, instead of creating one every time the user does File/{Open,Save}. It's probably enough to do this: in gtk_file_chooser_default_map(), move the call to settings_load() before the call to ::map() in the parent class. Could you please test it that way? > Federico, could you comment on how you think all this stuff with state and > everything should be? Somehow it was believed "filechooser does the right > thing", now things seem to be better, it's great. Still, without you it's not > going to fly anywhere. Random patches like one that was applied (to 2-10!) do > no good; and they will silently break stuff of people who actually try to fix > FileChooser behavior in applications (yes, there are silly people doing that). Applications should not have to do anything special to get a decent file chooser; that's why I don't want to expose APIs like gtk_file_chooser_set_expanded(). We may remove the expander in the future, or change the GUI in ways that are unrelated to the API. As for remembering the size, I'm all for it. Someone has to test disabling the hairy code that computes the sizes, add code to save the user-defined size, and test it with various apps that add different "extra" widgets.
*** Bug 331313 has been marked as a duplicate of this bug. ***
Bug 331313 went a little further with this logic and cleaned up the interface by hiding the redundant combo when the save dialogue is in it's expanded form. This goes a long way to simplifying the interface and making it easier to assimilate what is presented since this is pure duplication and clutter when the expander is open. patch was provided in that bug , have not tried applying it now but it should be a trivial mod if it does not apply. Nice to see some movement on this.
*** Bug 339440 has been marked as a duplicate of this bug. ***
*** Bug 341132 has been marked as a duplicate of this bug. ***
This patch has apparently been committed; setting patch status accordingly.
Comment on attachment 80575 [details] [review] patch Marking patch as obsolete, it was hanging in patch list.
Why is this bug still open?
Closing due to inactivity.
*** Bug 310574 has been marked as a duplicate of this bug. ***