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 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
Re: Guidelines for stable branch changes in GLib/Gtk
hi Morton, On 12-11-16 03:09 PM, Morten Welinder wrote: The breaking of mouse wheel support in gtk+ 3.4 also comes to mind. (Bug 675089 and others, I'm sure.) If I'm not mistaken, this was a different kind of breakage that we engage in a lot of lately: API-incompatible changes on the unstable branch. As much as those breaks are annoying a lot of people I do believe that we gain quite a bit of benefit from playing a little bit 'fast and loose' with regards to compatibility. Our old behaviour of nothing can change ever led to a substantially stagnated gtk2. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Guidelines for stable branch changes in GLib/Gtk
If I'm not mistaken, this was a different kind of breakage that we engage in a lot of lately: API-incompatible changes on the unstable branch. Close, but not quite. This was a case of user updates gtk+ to new stable 3.x and applications cease to work. No API involved, it's all a matter of ABI. The normal mechanism to signal ABI changes is to admit it and change soname. However, that is so painful[*] that people get the urge to sneak little changes in here and there. Morten [*] So painful that the g++ people backed out a change to std::list required for standards compliance in order to avoid changing soname. ___ 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 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
+ *
Re: Guidelines for stable branch changes in GLib/Gtk
On Sun, 2012-11-11 at 12:55 -0800, Matthew Brush wrote: Any chance of reverting/fixing those changes? Here's some related bug reports I could find: [snip] Thanks for compiling this list of bugs; it's very helpful! Please see the thread I started as a reply to Ryan - the File chooser recent-files one. It has a patch to revert to the old behavior, but I want to run this as an experiment. I've also put the patch in bug #658280. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Guidelines for stable branch changes in GLib/Gtk
The breaking of mouse wheel support in gtk+ 3.4 also comes to mind. (Bug 675089 and others, I'm sure.) Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Guidelines for stable branch changes in GLib/Gtk
hi, It seems to me that we've been playing a little bit fast and loose with what goes into stable branches of GLib (and particularly) Gtk+ of late. From my point of view I think the only thing suitable for a stable branch is a bug fix. New features are completely out of the question and new API as well. Deep bug fixes (eg: requiring substantial changes to the iconview in order to workaround difficult issues) are probably also best avoided but it's more difficult to draw a firm line here. Those are my views. I'm not presupposing to enforce my views about what is appropriate in a stable series, but I think we should have a discussion about it and come up with an answer. Then we should stick to it. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Guidelines for stable branch changes in GLib/Gtk
Hard to disagree in the abstract. But also not much of a discussion unless you cite the specific examples that made you write this mail. Which changes were problematic ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Guidelines for stable branch changes in GLib/Gtk
hi, On 12-11-11 03:03 PM, Matthias Clasen wrote: Hard to disagree in the abstract. But also not much of a discussion unless you cite the specific examples that made you write this mail. Which changes were problematic ? There are three specific cases that come to mind: 1) Recently Martin asked me for permission to backport his boxing of GPollFD to the stable branch of GLib and I said no new API on stable branches. I mention this only because of how small of a change it would have been compared to the following two: 2) The icon view changes that landed in the 3.4 cycle. 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... My main reason for raising these concerns is that I want to see GLib and Gtk stable releases picked up by the distributions for the valuable bugfixes that they contain but distributions (Ubuntu, specifically) are getting annoyed with the non-bugfix changes that are often appearing in our stable series... Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Guidelines for stable branch changes in GLib/Gtk
On 12-11-11 12:24 PM, Ryan Lortie wrote: hi, On 12-11-11 03:03 PM, Matthias Clasen wrote: Hard to disagree in the abstract. But also not much of a discussion unless you cite the specific examples that made you write this mail. Which changes were problematic ? There are three specific cases that come to mind: 1) Recently Martin asked me for permission to backport his boxing of GPollFD to the stable branch of GLib and I said no new API on stable branches. I mention this only because of how small of a change it would have been compared to the following two: 2) The icon view changes that landed in the 3.4 cycle. 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... I know it's somewhat off-topic from the thread, but since you mentioned it... I also think that #3 is a huge problem. It broke so many apps that were doing the right thing by not setting a default/current folder, there's a large bug ticket (multiple ones actually) with lots of unhappy users and GTK+ application developers offering some reasonable solutions, it was not (that I can tell) ever discussed anywhere except on a GNOME guy's personal blog, it never got documented anywhere in the 2.x GtkFileChooser docs, and selfishly, it's a huge pain in the butt for me many times every day :) Any chance of reverting/fixing those changes? Here's some related bug reports I could find: https://bugzilla.gnome.org/show_bug.cgi?id=658280 https://bugzilla.gnome.org/show_bug.cgi?id=667252 https://bugzilla.gnome.org/show_bug.cgi?id=687247 https://bugzilla.gnome.org/show_bug.cgi?id=676636 https://bugzilla.gnome.org/show_bug.cgi?id=675792 https://bugzilla.gnome.org/show_bug.cgi?id=682931 https://bugzilla.gnome.org/show_bug.cgi?id=675961 https://bugzilla.gnome.org/show_bug.cgi?id=665919 https://bugzilla.gnome.org/show_bug.cgi?id=665297 https://bugzilla.gnome.org/show_bug.cgi?id=674600 https://bugzilla.gnome.org/show_bug.cgi?id=680248 https://bugzilla.gnome.org/show_bug.cgi?id=684964 Note: there's a bunch of dupes in the list because it shows the extent to which this also disrupted applications (which the bugs then (rightly) got re-assigned/marked as duplicates). Cheers, Matthew Brush ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Guidelines for stable branch changes in GLib/Gtk
There are three specific cases that come to mind: 1) Recently Martin asked me for permission to backport his boxing of GPollFD to the stable branch of GLib and I said no new API on stable branches. I mention this only because of how small of a change it would have been compared to the following two: 2) The icon view changes that landed in the 3.4 cycle. 3) The file chooser recent folder changes that landed in 3.0 and also on 2.x. Ah, ok. So, this is not about anything recent, but a 'multi-year accumulated frustration' mail. And it is really just about GTK+, not GLib, as your initial mail seemed to indicate. I don't think anybody disagrees that these examples would have been better off in devel branches. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Guidelines for stable branch changes in GLib/Gtk
hi, On 12-11-11 04:46 PM, Matthias Clasen wrote: Ah, ok. So, this is not about anything recent, but a 'multi-year accumulated frustration' mail. The thing that brought this up recently was a discussion at UDS. Ubuntu is nervous to take our stable releases because of what has happened in the past... And it is really just about GTK+, not GLib, as your initial mail seemed to indicate. I if we decide on a policy, it should apply equally to both. I don't think anybody disagrees that these examples would have been better off in devel branches. At the time, I (and others) got the impression that many people felt that what happened was OK and may well happen again in the future -- particularly on the file chooser changes. If this really is in the past and we agree that nothing like this should ever happen again then I do consider the issue to be entirely closed. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
