Arrangement of status bar tiles by relevance


#1

Simurai brought up an interesting idea in a PR earlier:

Here another thought: Separate the status-bar items based on if something is permanent (global) or just temporary (per file):



Then the permanent items, like updates etc. could be on the left and under the “global” tree-view. On the right are all the items that change “per file”. So the file name would be under the editor and look less disconnected…

Some users obviously wouldn’t like the new arrangement (being the temperamental lot that we are)… but a good solution would be to also make each tile sortable via a drag-and-drop interface. This way, users could arrange elements to their liking, and would ameliorate any friction imposed on change-resilient users like myself.

Thoughts?


#2

Yes, please. Both of those ideas would be very nice usability improvements individually. However, it might be easier to sell the idea as a status bar configurable through a plain-text file (which would contain alignment and spacing rules) and then add graphical interaction.

I’m imagining a CSON like

left:
  <is>: [       # Unique identifier div[is].
    text: ""    # A text label.
    altText: "" # A floating bubble that appears on hover.
    class: ""   # For styling.
    command: "" # What happens if you click it.
  ]
center:
right:

#3

You mean like menus and keymaps?

Because that wouldn’t be a bad idea: giving packages the ability to define tiles using the same schema as, well, everything else.


#4

Ease of use for package creators would be an additional benefit of doing things that way (and with reasonable inheritance rules, the end user could override some or all or none of the package’s presets according to how much they define in their local file).


#5

Eh, I think drag-and-drop would be the most intuitive approach. I’m not sure why users would need to be able to alter the text of individual components (particularly when packages will obviously need control over what’s shown).


#6

Drag-and-drop is an intuitive front-end, but some users may (I say this because I’m one of them) prefer the feeling of precise editing via text.

The way I’m envisioning the CSON would give flexibility to users in defining their own status bar components and also allow for custom labels and hovertext. The status bar on my Linux machine has unicode characters as labels, which I find helps me quickly read the information without adding much space. If I were to add much more to my Atom status bar, I would want similar labels so that I’m not staring at a lot of numbers, punctuation, and acronyms. It’s an accessibility issue for some people. And yes, I’m aware that I can simply use ::before selectors in my stylesheet to add labels to the things that already exist, but I think this way would be more straightforward and powerful.

For someone whose only need was to rearrange the components, their file might just look like

left:
  launch-mode
  update
right:
  cursor
  file
  grammar-selector
  encoding-selector
  line-ending

#7

I get eye-strain trying to read 2-space indented code, so I’m always the first to complain about accessibility issues. :stuck_out_tongue:

“… prefer the feeling of precise editing via text.”

No, you and me both. I hear what you’re saying. But I think the issue is more human in nature. Package authors should take additions to the status bar seriously, and offer users an option to remove them if they want them gone. To actually alter what the package’s status-bar addition looks like is more in the domain of a forked status-bar package more than anything.


#8

For the permanent/temporary separation, it could be just a convention that packages are encouraged to follow. Or if it should be enforced, the API needs to be changed.

Anyways, that was just a quick idea and I guess a bit late for this major version.


#9

I personally am perfectly willing to fork packages and tweak as necessary for my needs (you might have noticed :smiley: ). I feel like what I’m suggesting would be a very minor change of route to get to what you want, but the minor change would open up major flexibility for certain users. It can (and should) be something that just works if the user completely ignores it.

I feel like @Alhadis’ modification is an attractive solution. If the status bar is configurable, packages don’t need to know anything about where their icon is.