Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#546 closed Enhancement (invalid)

Should only write changed prefs to .transmission/gtk/prefs.ini

Reported by: pbenner Owned by: charles
Priority: Lowest Milestone: None Set
Component: GTK+ Client Version: 0.96
Severity: Minor Keywords:
Cc:

Description

On Thu, Dec 13, 2007 at 12:46:47AM -0800, Josh Triplett wrote:

I keep my home directory in version control, as a means of sharing it across systems, keeping it backed up, and tracking changes to it. One of the biggest problems I run into relates to applications that always write out their entire preferences, rather than only changed preferences. This makes it much harder to track changes and share files across machines. Could transmission please write out only its changed preferences, rather than all preferences?

On Sat, Dec 15, 2007 at 02:39:27PM -0800, Josh Triplett wrote:

To elaborate on the problems I've encountered with other applications that write out all preferences:

  • If I have two different versions of the application on two different machines, each will want to write out its entire set of preferences, which may differ. Thus, the file will become changed on all machines not running the same version as the one which generated the file I checked in. Furthermore, if the new version writes out new preferences and the old version does not ignore preferences it does not understand, this could lead to breakage.
  • Similarly, sometimes GUI applications write out their preferences in inconsistent orders, and these orders may change between versions. (This may or may not apply to transmission, depending on what future versions do.)
  • A new version may change the default for a preference. If you write out only changed preferences, then you allow a distinction between preferences the user specifically wanted a certain way and preferences the user left at the default, and can decide to update only the latter to new defaults; this avoids overriding a user's desired configuration.
  • Preferences like default-download-directory contain my home directory path. On all my personal machines I have the username "josh", but on some other machines I have different usernames, or occasionally non-standard home directory paths. If transmission avoided writing this preference out unless I change it, I could leave it at the default of my home directory. (As another solution, transmission could abbreviate my home directory to ~, and expand that when reading in the file.)
  • Some applications automatically change preferences based on system configuration and available features. For example, what if transmission decided to turn off the system tray icon when I run it in an environment that has no system tray (such as a minimalistic window manager)? It should not write out this preference, because I did not explicitly change it.
  • Some applications record their window position and size, even if explicitly told not to *use* the last window position and size. Fortunately transmission does not do this (yet).
  • Josh Triplett

Change History (3)

comment:1 Changed 14 years ago by livings124

  • Component changed from Transmission to GTK+ Interface
  • Owner set to charles

comment:2 Changed 14 years ago by charles

  • Resolution set to invalid
  • Status changed from new to closed

I kind of like the idea, since it means that future changes to the default values will be picked up automatically.

On the other hand, I kind of don't like the idea since (1) the whole point of saving to a human-readable .ini file was so that users could poke around in the file and edit things by hand, and that's not really possible without having all the key/value pairs in there for users to read, and (2) the work-to-benefit ratio seems high.

If someone wants to submit a patch for this that somehow still lets users discover options by reading through this file, I'd be very inclined to accept it.

comment:3 Changed 13 years ago by add

by end users who would like to contribute and start to use docs to learn cool stuff about their apps in the first place. Both annotations and contributions will only clutter the interface by default as a design pattern rather than trying to put it all together. That way you can never create offline or print docs of high quality without again having the devs or current admins maintain the comments and annotations. Hopefully a small Wiki quality team will evolve (i am against ops or admins) to review and summarize the contributions. I hope this gives us more users as contributors than having the docs focused on the devs. Cheers, duns china tour Apparel shoes bags Kitchen Food and Wine Furniture) Flowers and Gifts Wall Art Computer Components I still prefer a wiki like approach since the php (or mysql) docs are very cluttered when you have to take their comments in account. On the other hand they are professionally maintained imho, since they are *much* better than KDE documentation. KDE is by far larger and has so many different apps, which need screenshots and end user not dev/api docs

Note: See TracTickets for help on using tickets.