Re: File chooser recent-files
On 21/11/12 20:36, Federico Mena Quintero wrote: > On Mon, 2012-11-19 at 10:52 +, Simon McVittie wrote: > >> If this sort of change is important, it sounds to me as though Gtk 2 >> should continue to have (short!) branches corresponding to a GNOME >> release when necessary? > > GTK+ 2.24.x still has releases! > > Do you mean that they should appear in sync with Gnome releases? That > would certainly be nice, to keep things rolling. What I mean is: if GNOME 3.6 shipped with GTK+ 2.24.x and GTK+ 3.6, and GNOME 3.8 needs changes to GTK+ 2 that are bigger than you would normally allow in the GTK+ 3.6 branch, I would tend to expect those changes to be a GTK+ 2.25 branch that is released as 2.26.0 alongside GNOME 3.8. Distributions that support an older version of GNOME for longer than 6 months (RHEL, Debian, Ubuntu LTS etc.) would presumably want to get the non-intrusive bugfixes for that older version's corresponding GTK+ 2 (if any), but not, for instance, a file chooser that changes behaviour to match a version of GTK+ 3 newer than theirs. S ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File chooser recent-files
On Mon, 2012-11-19 at 10:52 +, Simon McVittie wrote: > If this sort of change is important, it sounds to me as though Gtk 2 > should continue to have (short!) branches corresponding to a GNOME > release when necessary? GTK+ 2.24.x still has releases! Do you mean that they should appear in sync with Gnome releases? That would certainly be nice, to keep things rolling. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File chooser recent-files (was: Re: Guidelines for stable branch changes in GLib/Gtk)
On Mon, 2012-11-19 at 17:07 +, Sam Thursfield wrote: > The biggest issue I've had with the feature is that the list of > recently used folders in the 'Save As' dialog only displays the name > of the folder, not its full path. Which of the 6 folders named 'src' > did I want to use again? There is a tooltip with the full path; it appears if you hover an item in the file list. I don't really have a good way of showing full paths in the list without it becoming illegible. Maybe it would be good to do it only for ambiguous/duplicated names (i.e. non-ambiguous items get displayed with just the basename as usual). If you can cook a patch to do that, I'd be very happy to review it. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File chooser recent-files (was: Re: Guidelines for stable branch changes in GLib/Gtk)
On Fri, Nov 16, 2012 at 7:27 PM, Federico Mena Quintero wrote: > On Sun, 2012-11-11 at 15:24 -0500, Ryan Lortie wrote: > > > 3) The file chooser "recent folder" changes that landed in 3.0 and also > > on 2.x. > > > > I consider the last case to be particularly egregious because nothing > > was broken to start with and the changes were highly visible from a UI > > standpoint. As I understand it, GNOME enters UI freeze at a particular > > point in time and never leaves it (on a given stable release). We can > > argue that Gtk is not GNOME, of course... ... (The file chooser is a bit peculiar; I've wanted to keep it as much in > sync as possible between GTK+ 2.24 and GTK+ 3.x, because Big Important > Apps(tm) still use 2.24. I didn't want a situation where the main apps > use a shitty file chooser and "only" small/new Gnome utilities use the > improved file chooser.) > Interesting point. A colleague of mine once proposed that we move the file chooser out of the toolkit completely and into a separate process, so that all applications would use the same file chooser, and it would also be easier for users to customise. I realise it would probably be a non-starter, since Gtk+ currently allows embedding and modifying the file chooser dialog, so to be at all compatible we would end up needing GtkPlug/GtkSocket and it would be crazy mess. But I like it in theory > In [1] I wrote a detailed reasoning for starting up in recently-used > mode. I still think that reasoning is correct. However, you and other > people clearly don't like the resulting behavior. > > Still, I've had even other people tell me that they like the new > behavior. > The biggest issue I've had with the feature is that the list of recently used folders in the 'Save As' dialog only displays the name of the folder, not its full path. Which of the 6 folders named 'src' did I want to use again? Sam ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File chooser recent-files
On 16/11/12 19:27, Federico Mena Quintero wrote: > In retrospect, I completely agree with you: the changes to make the > file chooser start up in recently-used mode when no starting folder is > specified, should have gone into master only, not in the stable > branches. ... > (The file chooser is a bit peculiar; I've wanted to keep it as much in > sync as possible between GTK+ 2.24 and GTK+ 3.x, because Big Important > Apps(tm) still use 2.24. I didn't want a situation where the main apps > use a shitty file chooser and "only" small/new Gnome utilities use the > improved file chooser.) If this sort of change is important, it sounds to me as though Gtk 2 should continue to have (short!) branches corresponding to a GNOME release when necessary? Happily, version numbers starting with "2" are not a finite resource. :-) S ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
File chooser recent-files (was: Re: Guidelines for stable branch changes in GLib/Gtk)
On Sun, 2012-11-11 at 15:24 -0500, Ryan Lortie wrote: > 3) The file chooser "recent folder" changes that landed in 3.0 and also > on 2.x. > > I consider the last case to be particularly egregious because nothing > was broken to start with and the changes were highly visible from a UI > standpoint. As I understand it, GNOME enters UI freeze at a particular > point in time and never leaves it (on a given stable release). We can > argue that Gtk is not GNOME, of course... Mea culpa. In retrospect, I completely agree with you: the changes to make the file chooser start up in recently-used mode when no starting folder is specified, should have gone into master only, not in the stable branches. I think I got the wrong impression of just how bad the previous situation was: apps didn't suggest a default folder and they came up in $HOME (because $CWD tends to be just $HOME if users launch apps from the desktop shell); apps sometimes suggested a default folder, sometimes saved from their last instance, sometimes not... I thought it was pretty inconsistent, and wanted to make that situation better. But yes, it was a big change, and it should not have gone into the stable branches. (The file chooser is a bit peculiar; I've wanted to keep it as much in sync as possible between GTK+ 2.24 and GTK+ 3.x, because Big Important Apps(tm) still use 2.24. I didn't want a situation where the main apps use a shitty file chooser and "only" small/new Gnome utilities use the improved file chooser.) In [1] I wrote a detailed reasoning for starting up in recently-used mode. I still think that reasoning is correct. However, you and other people clearly don't like the resulting behavior. Still, I've had even other people tell me that they like the new behavior. At the risk of introducing another preference in the file chooser, I want to make an experiment. The attached patch, for gtk+ master, lets you select whether to use the current behavior (recently-used at startup unless a folder is pre-set), the original behavior ($CWD unless a folder is pre-set), or something that didn't really ever reach a stable version (save the last directory you used and use it in the next invocation of a file chooser). The way this is set is by reusing the old ~/.config/gtk-2.0/gtkfilechooser.ini file - you create a DefaultFolder key and it can have the values "cwd", "last", or "recent". The reason I'm using *that* configuration file is that: 1. If we want to play with this patch on big apps that still use GTK+ 2.24, they'll need to store the configuration there anyway. 2. I don't want 2.x apps and 3.x apps behaving differently. 3. Although the code to save the last-used-dir uses GSettings in GTK+ 3.x, it used to use gtkfilechooser.ini in 2.24 - and if we actually keep that code in the end, I intend to move the last-used-dir to the .ini file so it is kept in sync. I really hope you and other people who don't like recently-used by default get to try this patch. I honestly don't know what the best behavior is; maybe the best is to let people who know about filesystems to use $cwd or whatever, and for people who are not as comfortable to be presented with a recently-used list. [1] https://live.gnome.org/DocumentCentricGnome/Help%20the%20user%20choose%20a%20place%20to%20put%20a%20new%20file Federico >From dc52c6d45d05841b916c61c454666fd99cc52372 Mon Sep 17 00:00:00 2001 From: Federico Mena Quintero Date: Fri, 16 Nov 2012 11:56:46 -0600 Subject: [PATCH] Allow choosing whether to open in recently-used mode, last-used-folder mode, or This works by having a GKeyFile, in ~/.config/gtk-2.0/gtkfilechooser.ini and reading this: [Filechooser Settings] DefaultFolder=cwd|last|recent That is, the DefaultFolder key can have values of 'cwd', 'last', and 'recent'. The default, if the key is not set, is 'recent' - this will bring up the recently-used mode as usual. The 'cwd' mode will use instead, and 'last' will restore the folder that was used in the last instance of the file chooser in any application. We use that config file in ~/.config/gtk-2.0, not in gtk-3.0, so that it *is* the same config file as used in GTK2 applications. Signed-off-by: Federico Mena Quintero --- gtk/gtkfilechooserdefault.c | 86 ++- 1 file changed, 85 insertions(+), 1 deletion(-) diff --git a/gtk/gtkfilechooserdefault.c b/gtk/gtkfilechooserdefault.c index 09d6303..26a014a 100644 --- a/gtk/gtkfilechooserdefault.c +++ b/gtk/gtkfilechooserdefault.c @@ -6152,6 +6152,90 @@ get_file_for_last_folder_opened (GtkFileChooserDefault *impl) return file; } +typedef enum { + DEFAULT_FOLDER_CWD, + DEFAULT_FOLDER_LAST, + DEFAULT_FOLDER_RECENT +} DefaultFolder; + +static DefaultFolder +get_default_folder (void) +{ + GKeyFile *keyfile; + char *filename; + DefaultFolder folder; + + folder = DEFAULT_FOLDER_RECENT; + + /* Note that this is really "gtk-2.0" so that we can share the configuration + * with GTK2, for o