Re: File chooser recent-files

2012-11-22 Thread Simon McVittie
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

2012-11-21 Thread Federico Mena Quintero
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

2012-11-19 Thread Simon McVittie
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


Re: File chooser recent-files (was: Re: Guidelines for stable branch changes in GLib/Gtk)

2012-11-19 Thread Sam Thursfield
On Fri, Nov 16, 2012 at 7:27 PM, Federico Mena Quintero
feder...@gnome.orgwrote:

 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


File chooser recent-files (was: Re: Guidelines for stable branch changes in GLib/Gtk)

2012-11-16 Thread Federico Mena Quintero
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 feder...@gnome.org
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 feder...@gnome.org
---
 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
+   *