GNOME Bugzilla – Bug 145554
"Save as" dialog boxes always suggest same directory
Last modified: 2004-12-22 21:47:04 UTC
When saving a page or image (from context menu or File > Save As), Galeon remembers the last directory that was used and suggests it for the new download. However, the suggested directory is always the last one used in the previous session of Galeon, and if I choose a different directory for a download, subsequent dialogs still suggest that directory from the previous session. Strangely, the directory that Galeon keeps suggesting was found in GConf at apps/galeon/State/last_upload_dir -- I expected that Galeon would use last_download_dir. That value (apps/galeon/State/last_download_dir) seems to be correctly updated after each save.
This bit of code was found in mozilla/FilePicker.cpp in GFilePicker::Init (galeon 1.3.16) -- should it be using CONF_STATE_LAST_DOWNLOAD_DIR instead of _UPLOAD_DIR? mDialog = gul_file_chooser_new (NS_ConvertUCS2toUTF8 (title).get(), gparent, action, CONF_STATE_LAST_UPLOAD_DIR);
No, that bit of code is only related to uploading files from web pages. This is odd, as it works perfectly for me, the last save directory gets set as the default for the new save. The relevant code is in mozilla/HeaderSniffer.cpp.
If I change the value in apps/galeon/State/last_upload_dir, it still uses the old value in new dialogs, so I think it's either getting the wrong value back from gconf (despite the right value being stored) or it's ignoring the value coming back from gconf. Any way I can check where the dialog is initialised?
Created attachment 29318 [details] [review] Patch to add some debugging If you apply this patch to the gul-file-chooser.c file, it will print out the values it gets from gconf, and the values it writes back, hopefully this might shed some light on what is happening.
OK -- I save an image with right-click, "Save Image as...", and galeon suggests "/home/bwhite". I accept this. Then I save another image the same way, changing the directory to "/home/bwhite/tmp". Finally, I save another image, but galeon is still suggesting "/home/bwhite". eel_gconf_get_string ("/apps/galeon/State/last_download_dir") = "/home/bwhite" eel_gconf_get_string ("/apps/galeon/State/last_download_dir") = "/home/bwhite" eel_gconf_set_string( "/apps/galeon/State/last_download_dir", "/home/bwhite/tmp" ) eel_gconf_get_string ("/apps/galeon/State/last_download_dir") = "/home/bwhite"
How very strange, this does appear to be a gconf problem, we are correctly setting the download_dir to "/home/bwhite/tmp" but when getting it back we get "/home/bwhite". I assume that your ~/.gconf directory (and everything inside it) is writable by you. Also can you check to see if there is anything useful in the xsession error log, usually in ~/.xsession-errors
Err, state is not supposed to be stored in GConf... at least not until gconf_client_get_default_state() is implemented.
Yes, ~/.gconf is writable, and the correct value is indeed being stored (as reported by gconf-editor or gconftool-2, but it looks like gconf is caching the old value. I've seen galeon work properly for other users too though, so I don't know what affects gconf's caching behaviour. So are we saying GConf shouldn't be used to store this sort of state?
IIRC crispin said he was able to reproduce this. wrt GConf and state, http://www.gnome.org/projects/gconf/ has the following to say: "Do not store anything but preferences in GConf. Documents, session state, random data blobs do not belong in GConf."
Well, not on-demand, but I did have the situation where trying to update my home page stored it in gconf, but galeon still got the old value. I suspect a bug in gconf somewhere.
I've been looking at the gconf-client code, and it's hard to tell how this could work reliably anyway -- it always returns a value from the client cache if possible, and there doesn't seem to be any guarantee that the cache will be up to date. (I happily admit that I could be misunderstanding the way it maintains that data.) It seems to be updated when apps are notified of changes to directories that they are watching, but I don't know whether that's guaranteed to happen. Maybe GConf assumes that apps will not read back preferences unless notified of a change by another app, or on startup? If that's the case then I can see why state is banned from GConf, but otherwise it should be doing the right thing, at least.
This looks very much like bug 147472
I can confirm that bug 147472 is identical in behaviour to what I'm seeing -- Galeon preferences are also ignored until the application is restarted (so preferences dialogs show old values and Galeon behaves according to the old preference). But... I can't reproduce the bug in other apps, such as the sticky notes applet that the reporter of 147472 describes.
Following an upgrade from ORBit2 2.10.0 to ORBit2 2.10.2, this problem seems to have gone away! Might have been some sort of IPC problem. Oh well, thanks for the great browser, guys. :)
Interesting, I didn't think orbit had anything to do with gconf, but perhaps it does.
http://developer.gnome.org/feature/archive/gconf/impl.html I'll leave it to someone else to decide whether there needs to be a "State variables are stored in GConf" bug. :)
Actually, this isn't anything to do with Orbit, after much looking I worked out what the problem is, and it is fixed in the debian 2.6.4-2 package and in the gconf 2.7 CVS. Basically every time a GNOME package was upgraded gconf broke :-( *** This bug has been marked as a duplicate of 147472 ***
Grrr, I'll get it right, I mean bug 148028 (bug 147472 is already a dup of that one) *** This bug has been marked as a duplicate of 148028 ***