After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 667252 - have a way of disabling recently-used files (e.g. via gconf/system-settings)
have a way of disabling recently-used files (e.g. via gconf/system-settings)
Status: RESOLVED DUPLICATE of bug 658280
Product: gtk+
Classification: Platform
Component: Class: GtkRecent
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Emmanuele Bassi (:ebassi)
: RocketZX 682931 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-01-04 12:39 UTC by T.J.Pinkert
Modified: 2012-11-16 19:31 UTC
See Also:
GNOME target: ---
GNOME version: 3.1/3.2



Description T.J.Pinkert 2012-01-04 12:39:54 UTC
Since I don't like the recently-used files stuff, I disabled it by making the .recently-used.xbel a directory (partially in the hope that the "open file" dialogs would now revert to start in the home directory).

I did not find a normal way of disabeling this "feature". I would suggest that there should be an entry in e.g. the gconf system to disable/enable this functionality in a proper way.

Two reasons one could have for disabeling the recently used are:
- user does not want a trace of files opened left
- user does not use the same files often and is therefore nagged by recently-used

In a disabled state applications should not show or go to the recently used "folder" but to the users home directory, or the last directory a file was opened from (the latter choise should probably be made by the application?).

Another suggestion could be to add a configuration option for the default directory (including virtual directories as recently used) for the "open file" dialogs?
Comment 1 Redsandro 2012-03-26 18:39:28 UTC
I agree.

This 'feature' structurally introduces extra steps to my user experience that aren't otherwise necessary, and could therefor be described as contrary to nature, reason, or common sense.

95% of times when I load something, I want to save it in the same directory or another place which is rarely in 'recent files'. Also, like to see the neighboring files and possibly choose to overwrite one.

I understand this feature was invented to make things easier, but it does just the opposite.
Comment 2 HennR 2012-05-05 09:14:15 UTC
+1

This feature is extremely annoying.

Please give the user a chance to chose his own workflow.
Comment 3 Jan Spurny 2012-05-05 15:31:50 UTC
I wonder why this is still "UNCONFIRMED" - it makes people's lives worse, it's annoying and it has no place in low-level library like gtk+.


PLEASE, PLEASE, PLEASE do something about it..
Comment 4 Matthias Clasen 2012-05-07 15:33:30 UTC
unconfirmed vs new doesn't make any difference in this bugzilla.
as for what has or doesn't have a place in gtk is up to the gtk maintainers to decide.
Comment 5 John K. Herreshoff 2012-06-16 13:44:44 UTC
How about giving the user a change to switch this 'feature' off.  It's a pain in GIMP.
Comment 6 Yeti 2012-07-23 06:48:13 UTC
Actually, it's pain in the a***.

At this moment I am patching all Gtk+ utility programs I have written with something like

    gchar *cwd = get_current_dir_name();
    gtk_file_chooser_set_current_folder(chooser, cwd);
    g_free(cwd);

to make them usable again without wishing to kill someone.
Comment 7 Redsandro 2012-07-23 12:04:15 UTC
Clever, although it shouldn't have to be necessary. I am very surprised that this bug isn't more 'popular'. A toolkit that is used by at least half our software shouldn't have an annoyance the likes of which is usually associated with blood and doctors.

We should raise aware by tweeting about it or something:
#667252. The biggest #fail of #GTK in modern history. PLS RT
Comment 8 confluence 2012-08-03 08:28:25 UTC
Agreed.  Please add a preference to configure the default.
Comment 9 Jan Spurny 2012-08-13 19:08:06 UTC
No wonder nobody cares about this bug: http://blogs.gnome.org/otte/2012/07/27/staring-into-the-abyss/

So what if I offer $100 (paypal only) for fixing this bug in official gtk+ sources?
I mean OFFICIAL sources, i.e. gtk+ developers acknowledging that this is in fact a bug and FIXING it in next gtk+ release.
Comment 10 confluence 2012-08-13 21:54:08 UTC
It looks like this is yet another duplicate of bug 658280.
Comment 11 André Klapper 2012-08-29 12:15:51 UTC
*** Bug 682931 has been marked as a duplicate of this bug. ***
Comment 12 André Klapper 2012-08-29 12:37:21 UTC
(In reply to comment #9)
> So what if I offer $100 (paypal only) for fixing this bug in official gtk+
> sources?

Jan: Just do it (there are some pages out there for software bounties), or see
http://www.gtk.org/support.php for contacting GTK+ support companies.
Comment 13 Jan Spurny 2012-08-29 13:23:46 UTC
(In reply to comment #12)
> (In reply to comment #9)
> > So what if I offer $100 (paypal only) for fixing this bug in official gtk+
> > sources?
> 
> Jan: Just do it (there are some pages out there for software bounties), or see
> http://www.gtk.org/support.php for contacting GTK+ support companies.

I don't want anyone to fix it just for me, I can do that myself (in fact I did, but only for my own computer and it's an ugly hack). I want the fix to be available for anyone who suffers from this abomination and more importantly (as I am a pretty selfish person) I want it fixed on every computer I use or will use in future.

I am offering money, because I value my time over money now. I don't want to search for website where I can offer money and waste even more time. So I'm offering a bounty now, here. If anyone trustworthy (like listed as official gtk+ developer - you certainly qualify) tells me here he did it, the fix will be in officialy released sources, and posts a paypal addres, I'll pay $100.

Or you can ask for more money!

Just please, anyone from you official gtk+ gods (developers..), do SOMETHING, please!

Don't just ignore us only because we do things a little differently than you.
Comment 14 Marek 2012-10-09 15:26:40 UTC
This is really annoying, whenever I want to open or save my files, it distracts me -- I get that for minority of users having a recent document list may be useful, but if I work on thousands images a day, which I have organised by dates/events in a folder structure, it's really annoying. Why the save dialog cannot just remember my last save location per application? and why it has to revert to Recently Used while in most cases it makes little to none use for me?

An option to decide whether behaviour user wants would be really helpful. I don't mind this to be set by default to use "Recently Used" list, as long as there is a simple way to change it.

Thanks.
Comment 15 Michael Natterer 2012-10-29 20:56:41 UTC
*** Bug 675961 has been marked as a duplicate of this bug. ***
Comment 16 Federico Mena Quintero 2012-11-16 19:31:00 UTC

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