Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hide status bar #40

Open
hatsumatsu opened this issue Dec 5, 2017 · 4 comments
Open

Hide status bar #40

hatsumatsu opened this issue Dec 5, 2017 · 4 comments

Comments

@hatsumatsu
Copy link

Lovely app! Is there a setting to disable the status bar / URL preview on links?

@thmsbfft
Copy link
Owner

thmsbfft commented Dec 5, 2017

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?

@hatsumatsu
Copy link
Author

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...

@jondashkyle
Copy link
Contributor

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.

@thmsbfft
Copy link
Owner

thmsbfft commented Dec 7, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants