Open hatsumatsu opened 6 years ago
Hey Martin, thanks! Sounds like this PR might be the answer—or do you wish to have a preference to get rid of the statuses altogether?
The PR looks promising, but separate settings for the different features might be handy. Maybe with a nested setting like:
show_status: {
network: true, // loading etc.
link_preview: true,
...
}
I could try to to do a PR but tbh I didn't touch Electron until now...
That sort of granular approach to status settings is interesting. Unsure if a nested object within the preferences is the best way of doing that, though; keeping it flat makes it more understandable. In that sense, and with my pull request, we’re progressively adding these feature flags.
Good idea—I think this is what I was trying to do by specifying different ways to output a status (somewhat like console.log
vs console.error
, etc.). See status.js.
To that point, if we're adding more feature flags to those logs, I think I'd like to move them into status.js
directly rather than let it clutter the logic of the components that are requesting statuses.
In that scenario:
• anything in the app can request a status be displayed
• a "category" is sent along the status' message
• status.js
checks the preferences and makes the final cut
• if no category is specified, the message is considered a log and displayed accordingly
Could be a small (but worthy) refactor, lmk!
As for the format of oryoki-preferences.json
, I too would prefer keeping a flat/easy to read structure of key:value. That way we also rely on less functions to parse the file and find the values.
Lovely app! Is there a setting to disable the status bar / URL preview on links?