Feature request: use dotfile to override browers.js

[Jackymancs4]

This is a thing I started implemeting yersterday (for personal use).

It works like this: the app look for something like ~/.browserosaurus.json or ~/.browserosaurus/conf.json at startup time and, if it finds it merges it with the default behavior.

If this is the default:

[
  { name: 'Brave', key: 'b' },
  { name: 'Chromium', key: 'c' },
  { name: 'Firefox', key: 'f' },
  {
    name: 'FirefoxDeveloperEdition',
    alias: 'Firefox Developer Edition',
    key: 'd'
  },
  { name: 'FirefoxNightly', alias: 'Nightly', key: 'n' },
  { name: 'Google Chrome', key: 'g' },
  { name: 'Google Chrome Canary', key: 'y' },
  { name: 'Iridium', key: 'i' },
  { name: 'Maxthon', key: 'm' },
  { name: 'Min', key: '-' },
  { name: 'Opera', key: 'o' },
  { name: 'Safari', key: 's' },
  { name: 'TorBrowser', key: 't' },
  { name: 'Vivaldi', key: 'v' }
]

and my handcrafted dotfile is:

[
  { name: 'Firefox', key: 'v' },
  { name: 'Google Chrome', key: 'g' }
]

than the final object that will be rendered is:

[
  { name: 'Firefox', key: 'v' },
  { name: 'Google Chrome', key: 'g' },
  { name: 'Brave', key: 'b' },
  { name: 'Chromium', key: 'c' },
  {
    name: 'FirefoxDeveloperEdition',
    alias: 'Firefox Developer Edition',
    key: 'd'
  },
  { name: 'FirefoxNightly', alias: 'Nightly', key: 'n' },
  { name: 'Google Chrome Canary', key: 'y' },
  { name: 'Iridium', key: 'i' },
  { name: 'Maxthon', key: 'm' },
  { name: 'Min', key: '-' },
  { name: 'Opera', key: 'o' },
  { name: 'Safari', key: 's' },
  { name: 'TorBrowser', key: 't' },
  { name: 'Vivaldi', key: null }
]

It basically override order and keys.

[Jackymancs4]

It's definitely something that I would use. Also it will do the job #5, (and maybe #2). Obviously it's just a placeholder feature for some kind of eventual future UI preferences, but for not-so-advanced user it'll do the trick.

And most importantly is slighlty less than half done, if you are willing to accept a PR, i'll finish it and than discuss it with you.

[will-stone]

Definitely interested as it seems like people are interested in customisation. Some thoughts:

• we’d have to make it clear which browsers are supported, due to the logos people just can’t add any old browser. I can imagine this can be simply covered off in the ReadMe and website.
• error handling for a corrupt json file.
• error handling for a misspelled browser.
• error handling for a duplicate key.
• error handling for a missing key.
• handle code injection in alias (haven’t checked if this is already covered off)
• maybe we don’t merge but just allow people to make their own list, I think this would be more obvious as to the results.

[Jackymancs4]

Going for points:

1. Covering supported browsers sure seems important, and also putting some link reference to json standard. Althought if I use firefox 56 or earlier, it's not a big deal if it appear with the 57 icon.
2. I thought of some silent try-catch on JSON.parse() after reading the file, with some minor kind of notification, maybe.
3. This one is interesting. My idea was that if there is an arbitrary name in name and it correctly appears in the system-profiler call, well congrats 'cause you just added your custom browser, otherwise it will be just discarded:

So:

[
  { name: 'Google Chrome Error', key: 'g' }
]

will have no effect but:

[
  { name: 'Beaker Browser', key: 'g' } // a browser nobody knows but I use
]

will add it to the list, with an empty or maybe general icon, and some notification, message or suggestion to create an issue for official support. If the user managed to create a correct dotfile, for sure it will be able to do that.

4. just keep the first assignment and the others will be putted to null.

5. missing keys seems a feature to me.

6. The idea behind the merging logic is that the user will get good defaults easy. If I only have

   [
   { name: 'Google Chrome', key: 'g' }
   ]

   the effect I'm looking for is to get Chrome on top of the list, and the remaining supported browsers to act just like always..

Your turn ;)

PS. I wrote this in a hurry, so the grammar can be the worst ever seen.. sorry

[will-stone]

Join us on 57, you will wonder how you put up with such a slow browser before.

Anyway...

*Just going to star this as I'm going to keep referring to it. I'm thinking notifications will be appended or prepended to the list, probably using a white background so they stand out from the browser list. As all errors/notifications won't stop the user from actually using the tool, I quite like this as it doesn't require building any more windows. Think Alfred, you used that? When there's an update available, the notification is simply added to the search box, it's effective and unobtrusive.

1. Documenting supported browsers will be easy enough. Leave this to me.
2. Try/catch should work. Error message shown in notification*.
3. Not on defaults list, not in profiler results: Notification says: "Google Chrome Error" not currently supported or found on this Mac. Not on defaults list, in profiler results (therefore shown with no icon): Notification says: "Beaker Browser" not officially supported, please ask Browserosaurus to add this browser. ...Interestingly, this will be a link and clicking it will open another Browserosaurus instance: Browserosaurus-inception!
4. Duplicate keys. Hmmm... it means some parsing logic on the file before it's sent to the renderer but not difficult I suppose.
5. Agreed. Happy to have browsers with no keyboard shortcuts.
6. Not agreed. I think by having the .browserosaurus file win over the defaults, the user will be able to remove browsers completely from the list if they want. They can always copy the list from the docs to get back to status-quo. If I made a config and browsers appeared that weren't on my list, I'd be a little put out. Essentially the defaults should just be for the lazy and me (because they're my choices 🙂)

[Jackymancs4]

Actually, I'm a proud Firefox Quatum user since day-one! And also a less proud user of Alfred, since the Powerpack has failed to convince me of his value.. still a dope product, tho.

Also I have not foreseen the Browserosaurus-inception! Mindblowing! Need to try this..

I love your idea for notifications. Right now I'm not confortable touching the UI, so in the short term my code will just emit events like emit('notification', {type: "error", msg: "Nothing works"}).. If you can do the spawning/disposing part, that would be great. This system would scale well for the future updater feature.

ok, back to the points:

1. Ok
2. Ok
3. Ok (to test the inception effect)
4. More parsing logic was the juice of my original idea 👍
5. Ok
6. This my last try on the matter (given you had a good point that i agree with):

This can be the json dotfile:

{
'version': 'x.x.x',
'settings': {'configmode': 'merge'}, // or 'override'
'browsers': [
              { name: 'b1', key: 'g' },
              { name: 'b2', key: 'g' }
            ]
}

This way you can let the user choose the way to handle the issue. I know that it raise the complexity of the app configuration, but it also create the foundations for a more complete and featureful settings system.

I can think of various use case where this approach would benefit config-lover user while not bothering normal just-do-the-thing user.

From a programming point of view is not more difficult than bunch of extra checks..

Also, I'm thinking of making this config file thing more 'mandatory', letting the app creating this dotfile with the default setting, if not already present. The end user will just need to modify it according to the documentation, if willing to do so.

7. ~/.browserosaurus.json or ~/.browserosaurus/conf.json? :)

[will-stone]

6. I agree on the structure: definitely more future proof. Can we go with "overwrite" mode first? Then look into a more advanced "merge" mode later if really required? Only because I'm thinking we'll eventually end up with a settings GUI which will be a list of browsers with tick boxes and keyboard shortcut boxes, making the merge mode moot.

7. I currently (unless you can) can't think of anything more we'd need than a simple json config file to store settings in, so my vote is ~/.browserosaurus.json but I think we should parse ~/.browserosaurus as well.

[Jackymancs4]

6. Definetely a good idea, agreed on that.
7. I was thinking of caching or stuff like that but yeah, just the json is easier on multiple level so I'll stick with that

[will-stone]

Cool. Let me know when you have something in Main that you'd like me to look at. I'll then look at creating the Renderer notification part.

[Jackymancs4]

Ok, since our last considerations added a bit of complexity, and the side-project nature of my contributions it will take me up to a week (maybe more/maybe less) to ship something mergeble..

[will-stone]

No problem, I'm working on something else anyway. Thanks for all the help.

[will-stone]

As we're going to go with electron-store to store the config (for future preferences GUI), using a dotfile is no longer the goal, closing this issue.