GNOME Bugzilla – Bug 763541
GTK+ should support a stateless configuration
Last modified: 2018-04-15 00:32:27 UTC
Created attachment 323765 [details] [review] modules: Use stateless configuration for im-multipress Using a stateless configuration, we ship sensible defaults in our vendor-config file to live in the /usr/share/ filesystem, which is considered to be provided by the vendor, and to all intents and purposes, read-only. With this change we can fall-back to the vendor system configuration to always do the right thing, in the absence of a local system administrator configuration file in the /etc/ tree. Notably, this saves users from the potential risks and pitfalls of so called "three way merges" on upgrades, and offers the immediate benefit that one can perform a factory reset of the software, simply by removing the relevant file in /etc/.
Review of attachment 323765 [details] [review]: Is this input method relevant at all for your users ? The fact that MULTIPRESS_CONFIGDIR was still set to /etc/gtk-2.0 after all these years seems to indicate that nobody ever uses it. I might suggest simply not shipping it as the easiest way to avoid a 3-way-merge. ::: modules/input/gtkimcontextmultipress.c @@ +392,3 @@ + conf_filename = CONFIGURATION_FILENAME; + else + conf_filename = STATELESS_CONFIGURATION_FILENAME; Instead of introducing a second hardcoded location with a funny name, this should just use XDG_DATA_DIRS. Use the same sequence of locations we use for settings: XDG_CONFIG_HOME/gtk-3.0 /etc/gtk-3.0 XDG_CONFIG_DIRS/gtk-3.0
Agreed, which again goes back to your point of stateless support in the XDG specification.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new