flyinghyrax / Elementary

Some Rainmeter skins

Home Page:http://rainmeter.net/cms/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Configuration style consistency

flyinghyrax opened this issue · comments

For several skins, we have the option of three (or even four) configuration styles:

  1. Config variants
  2. Context menu options
  3. Text variable in config file
  4. Text variable in centralized settings file

I know I want to reduce use of (4) to only those variables which appear in more than one config (things like the font and color). But that still leaves us with three styles that can be mixed and matched! Here is a more concrete example of the options using the chrono skin. The user option is to show either the day of the week or the day of the year as the last displayed digit in the skin. We can expose that setting in any of the following ways:

  1. Config variants: have a variant chrono-dayofweek.ini and a variant chrono-dayofyear.ini
  2. Context menu option: A context menu entry that toggles a single skin between displaying the day of the week and the day of the year and back again
  3. Text variable in config file: An integer variable showsDayOfTheWeek=0 that toggles the skin between modes

Sometimes (2) can stand on it's own, but often the easiest way of implementing (2) is in combination of (1) or (3) - I once experimented with having the context menu entry just load the appropriate variant for the option it displayed. For settings where variants could be used instead, (3) can make the config more complicated than just having variants - it depends on whether or not the two variants share other settings.

Some factors that might influence how I think about this:

  • Desire for the skins to be easy to edit
  • Desire for the skins to be easy to use
  • How often is the setting in question changed? A setting that is toggled often is a good candidate for a context menu entry, while a setting that is only changed once seems like a waste of context menu space.
  • Maintaining consistency. There should be a rational for which options are made available using which method, beyond just one or the other being more easy for me to implement or maintain.
    • Some options do not lend themselves well to context menu entries when we're trying to keep things simple. I do not want to implement a configuration meta-skin, or add InputText measures/meters for text entry of a user choice. If the option is a path/URL or something else that isn't basically a toggle, then it needs to be a config variable anyway...