FAQ - sizzlemctwizzle/GM_config GitHub Wiki

Why is GM_config so ugly?

By design the style of GM_config is minimalistic. I'm the type of person who worries more about how something works than how it looks. Plus loading up GM_config with some fancy style rules would IMO encourage users to just leave things the way they are rather than trying to match the look of the site their user script runs on. By giving you something bare-bones, I inspire your inner code monkey to tinker with the panel the way you would a website. However, unlike many websites, everything in the settings panel has its own class or even a unique id. See the relevant section of the home page for more information on style customization.

Will you add feature x?

When deciding to add a new feature I ask myself two questions: 1) Is this something that many users will need? 2) Can this be accomplished by a motivated user using currently available means?

I love the idea of someone creating a library that extends GM_config to do complicated things that a few users might want.

How do I get rid of the default style?

Want to style the frame from scratch? Clear out the default style:

let gmc = new GM_config(
{
...
  'events': {
    'init': {
      gmc.css.basic = '';
    }
...

How do I change the style of the frame?

Yes, the frame (or outermost element of the settings panel) has a style attribute you may want to change:

let gmc = new GM_config(
{
  'id': 'MyConfig',
...
  'frameStyle': '', // whatever you want
...

How do I get the value of a field while the settings panel is open?

Getting the value of a field in the settings panel is actually easy (by design):

let gmc = new GM_config(
{
...
  'events': {
    'open': {
      // getting the saved value
      let savedValue = gmc.get('fieldId');

      // getting the value in the settings panel
      var currentValue = gmc.get('fieldId', true);
    }
...

These values could possibly be different if the user has modified the value but not yet saved the settings. If the settings panel isn't open then second call to get() is identical to the first.

Isn't there another (legacy) version of GM_config?

Yes, there is a derivative. I'm one of the co-creators of GM_config and the other is Joe Simmons. In the beginning we passed code snippets back and forth using pastebin and Joe eventually hosted a testers and creators version of the code on userscripts.org (now offline). In an attempt to lighten the load on the site, it was decided to mirror the official code on Google Code. Eventually discovering git and GitHub, the official code was migrated to this repository and removed from Google Code. This wiki applies to the official version of GM_config located here. Some similarities may still exist, but the derivative is now incompatible.

Why do I need to pass GM_config an id?

Historically initialization of GM_config was done by passing settings (title, css, fields, event callbacks) directly to init() as arguments and then GM_config would try to figure out what everything was, like trying to detect the difference between a title and css (which are both strings). Not the best way to do things I'll admit. When I decided to make initialization done using JSON, to maintain backwards compatibility, I needed a way to differentiate the new JSON settings object from the fields JSON object of the old style. I decided to use "id" because it would kill two birds with one stone. It encourages users to set their own unique "id" for their instance, which is important if two scripts use GM_config on the same page (because of style rules) and even more important if localStorage is used to store values (since the two scripts would overwrite each other's stored values).