GNOME Bugzilla – Bug 730622
Encodings: merge auto-detected and shown-in-menu
Last modified: 2015-04-12 10:07:04 UTC
See the org.gnome.gedit.preferences.encodings settings. The UI in gedit can only modify the shown-in-menu setting, not the auto-detected. To simplify things, I propose to merge the two settings. If the user adds an encoding to the menu, it is better in my opinion to try this encoding automatically for the next files to open. The default value of the auto-detected setting is currently translated. With the work on the file loading and saving in GtkSourceView (see bug #721016), it is better to move this translation to GtkSourceView, so all text editors benefit from the translation. If the user didn't change the setting in gedit (empty by default), the menu contains the translated list of encodings from GtkSourceView. If the user modifies this list, it is saved to the gedit setting and the new list is used instead. The UI can have a Reset button to reset the setting.
The translation of the default candidate encodings has been moved to GtkSourceView: https://git.gnome.org/browse/gtksourceview/commit/?id=fc67d8c2c815674e9fa67cf278e8aed2b7fc6d46 The translated list is available with gtk_source_encoding_get_default_candidates(). By default, the FileLoader uses this list and prepend the GtkSourceFile's encoding if set. So far so good. In gedit, the idea is to replace the auto-detected and shown-in-menu gsettings by the candidate-encodings gsetting. By default the new setting is an empty list. The candidate encodings are: 1. GtkSourceFile's encoding if set. 2. Metadata's encoding if set. 3. candidate-encodings gsetting if not empty, OR gtk_source_encoding_get_default_candidates(), which should always include UTF-8 and CURRENT. Then duplicated encodings are removed with gtk_source_encoding_remove_duplicates(), which keeps only the first occurrences. For example if we have the list [UTF-8, ISO-8859-15, UTF-8, ISO-8859-1], the final list is [UTF-8, ISO-8859-15, ISO-8859-1]. The encodings shown in the menu in the file chooser is just point 3. When configuring the encodings, the UTF-8 and CURRENT should be mandatory, i.e. it should not be possible to remove them. There should also be up and down buttons to configure the order. And a reset button. When saving the gsetting, we should compare the list with gtk_source_encoding_get_default_candidates(): if it is the same, we set the gsetting to the empty list. By doing that, if gedit is relaunched with another locale, it'll work as expected with the translation. In the file chooser encoding menu, choosing "Automatically Detected" means that gedit will try the encodings listed below in the menu (plus points 1 and 2). It's more logical in my opinion. Currently in gedit if I add a strange encoding to the shown-in-menu gsetting (i.e. I use the UI to configure the encodings), this encoding won't be added to the candidate encodings used for auto-detection (the auto-detected gsetting).
(In reply to comment #1) > 3. candidate-encodings gsetting if not empty, OR > gtk_source_encoding_get_default_candidates(), which should always include UTF-8 > and CURRENT. It should probably be enforced both in gtk_source_encoding_get_default_candidates() and in gedit when retrieving the gsetting, by prepending UTF-8 and CURRENT if not present.
*** Bug 407659 has been marked as a duplicate of this bug. ***
From bug #407659: > The "auto_detected" is mostly there so that the translator can customize the > default encodings tried in their locale... The translation is now in GtkSourceEncoding. > A potential problem is that the list specified in shown_in_menu could grow big > and that would make opening a file slow. Yes, but with up/down buttons, the user can put the most frequently used encodings at the beginning. And I don't think many users need a long list of encodings. Nowadays UTF-8 is quite widespread I think.
To implement what is described here, new APIs need to be added to GtkSourceView: - gtk_source_encoding_remove_duplicates() would be useful to ensure that UTF-8 and CURRENT are present in the list when retrieving the candidate-encoddings gsetting (exactly what is done in gtk_source_encoding_get_default_candidates()). - If the gsetting is empty, we get the default candidates with gtk_source_encoding_get_default_candidates(). But the function returns a GSList where duplicates are already removed. But for GeditEncodingsDialog we need to display CURRENT explicitly. For example if CURRENT and UTF-8 are the same, the returned GSList will contain only UTF-8, and we don't know where to place CURRENT in the GtkTreeView. So we need two variants of the function: get_default_candidates_list() and get_default_candidates_strv(). At that point, why not adding also the strv_to_list() function? It is needed both in gsv and gedit. And list_to_strv() can be useful too. The API would become a little too cumbersome. The initial idea is to make the gedit code more reusable. So probably a better solution is to move GeditEncodingsComboBox (and the contained class GeditEncodingsDialog) in GtkSourceView, with a GSetting. (with a GtkSourceEncodingsComboBox, I think gtk_source_encoding_get_default_candidates() can be private.)
Branch merged! Between commit be3c6ca77645b30928d8c7109dae181e6b654d3d and commit a9bc77594b2c12ded51741cb3802378cbed793b2