Show Settings Icon in Status Bar

[confused-Techie]

Simple PR, adds the a settings icon into the status bar.

Within settings-view further utilizes the statusBar service, which it already consumes.

When clicking it will open up the settings via the atom.workspace() API.

Resolves #313

---

Additionally this is totally configurable. By default displaying the icon, but can always be turned off via showSettingsIconInStatusBar

[DeeDeeG]

Approving because: I tested it and it's working.

Code overall looks reasonable.

I note that toggling the setting requires a new window or restarting the app/current window to take effect, but I see that as totally reasonable and okay.

It might be possible to do statusViewIcon = new SettingsIconStatusView(statusBar) outside of consumeStatusBar(), and then it could be destroy()ed when the setting is toggled, or perhaps only when deactivating the package? But honestly, I think that might be overkill, and the extra code complexity might not being worth how slick/cool this would seem, toggling the setting and the icon just goes away, would be "neat".

At the moment I assume(?) the destroy() function in packages/settings-view/lib/settings-icon-status-view.js is never used, but having the ability to easily use this functionality in the future makes it worthwhile to have.

Just looking for things to say here honestly, but in all honestly the main bit of what I have to say is: "tested working, looks good to me."

P.S. (EDIT): I like that it is toggleable with a setting, some folks might consider it clutter, others might consider it super convenient to have a GUI-oriented, "point-and-click with the mouse" way to get into settings. So, having it be a preference is great, IMO.

[Daeraxa]

thers might consider it super convenient to have a GUI-oriented, "point-and-click with the mouse" way to get into settings.

I'm definitely one of those, I've been using Package > Open Package Manager as a faster way to get to the settings as that at least is the same key combo and menu location no matter what OS.

[DeeDeeG]

I am intending to merge this before we do a 1.103 Regular release, if someone else hasn't done it before then. Leaving it for a moment in case anyone's going to leave a review, since those don't really work after a merge, but yeah, I'm ready to merge this one for the next release.

[confused-Techie]

I do like the idea of included some changes to make it toggle right away. But if alright by you might be work for another day. And as for now with approval I'd be more than happy to merge this one

[Daeraxa]

I've noticed a couple of things about this implementation - one of which I've already submitted a PR for at #456

The other is more... up for debate... as I have no idea what the correct answer is.
So it seems that this adds a -99 priority so that it appears on the far right of the status bar.

However this seemingly goes much higher and can be bested by other packages, for example atom-clock which has a priority of -500 and ends up looking a bit odd on the status bar.

So if we wanted to ensure this always shows on the very far right then we need to set an even higher (lower???? cuz -ve) priority for the icon to make sure it trumps most others.

However I imagine that can still lead to competing until it hits some kind of integer overflow.

The other solution is that we somehow hard code this to always be on the right regardless of other packages, like giving it its own section of the panel to which the rules do not apply.

Related to this I think that there should be a very easy to access user override for the panel icons, either via a simple config file heirachy or drag-and-drop. i.e. not just making people do it in the init script, it should be for all levels.

[confused-Techie]

@Daeraxa That's good to know it can go higher.
The original docs mentioned -99 to force something all the way to the side, so had assumed people wouldn't go beyond that.

Personally I'm not a huge fan of priority system, and totally agree it'd be nice to let it be easily configurable, but doing so would likely need a pretty big refactor of how the icons are handled, and I'm not sure that's worth doing just for this one icon.

Like if we could make a system that uses the priority, but then allows a user to change it, and stay with that change that'd be awesome, but what we could do for now is one of two things either set the priority here to -999 or if we really really want to make sure nobody overrides it we could set -Number.MAX_SAFE_INTEGER instead

[Daeraxa]

and I'm not sure that's worth doing just for this one icon.

No, I definitely agree, I'll open the idea as an enhancement issue.

but what we could do for now is one of two things either set the priority here to -999 or if we really really want to make sure nobody overrides it we could set -Number.MAX_SAFE_INTEGER instead

Did a quick check and -999 and -Number.MAX_SAFE_INTEGER both seem to work:

[confused-Techie]

So maybe if we want to always ensure it's right aligned we can set it to the negative max safe integer, because then it'd be impossible for another package to override it. Even if I'm not a huge fan of condoning that sorta behavior

[Daeraxa]

I agree, it seems wrong somehow which is why I was bringing it up as a discussion rather than just submitting a -999 PR or something. Maybe we just do this in the short term. Ultimately we do grant some control over it as it can be toggled on and off.

[savetheclocktower]

I think ultimately the right answer is making it easily user-configurable. I don't think it looks too odd in that screenshot, but I also think any system where various packages have to argue about the order in which they appear on the status bar is doomed to failure.