feat: add tab stop to enable right-aligned content

[andyearnshaw]

Another (hopefully) quick win. This adds a single right-aligned tabstop to the menu item title text, which allows for images and text to be anchored on the right by separating them with the \t character.

Example screenshot:

I've picked a default tab stop of 150 points, as I think this is reasonable enough as a first pass. However, I could add more tab stops for potentially wider menus. My original thought was to allow configurable tabstops through params, but I'm not sure what the format should look like as you'd need both a number for the location and an alignment string. I'm happy to follow up on this with improvements if there's a concrete approach. Either way, I think some level of default is useful.

Caveat: it doesn't look quite so good when there are submenus or badges, but it's great for submenus that don't have those things.

[andyearnshaw]

Hmm... I've just spotted #455, which makes me think a full approach might be more appropriate. Maybe I can get your thoughts on this @melonamin?

[melonamin]

Just merged #464 that addressed #455. Take a look to see if it achieves what you were trying to do.

[andyearnshaw]

I think that might be good enough as a default tab stop behaviour. However, it has some drawbacks and doesn't cover my use case because of these:

• It doesn't allow for right-aligned content as per my screen shot
• Dynamically generated menu items require extra logic to guess how many tab characters are needed, but string length doesn't convert neatly into points. This is important when you have something like this:

  Short\t\t\tValue 1
  Really really long\t Value 2
  

How do we know we are using the right amount of \t characters on the short line? If it's a static thing then we can just test it, but if it's dynamic we don't know if it will be using a lot of wide characters, e.g. W or a lot of narrow characters, e.g. I. If it is a narrow 7-letter word like illicit, it might need three tab stops, but if it's a wide 7-letter word like woodmen, it might only need 2.

Allowing the plugin author to define tab stops makes the estimation easier, because you can make it so you only need a single \t character whether your column's field is 5 characters long or 20. You'd calculate a character as being no wider than the number of points of an em-dash character and set your tab stop at 25x or something and truncate anything that might exceed it.

I was originally thinking along the lines of one or two params that would allow the tab stops to be defined as well as the alignment, e.g.

1 param

# Centre align the 2nd and 3rd columns, right align the last
Team\tWins\tLosses\tScore | tabstops="100c 200c 300r"
Mongooses\t3\t0\3000 | tabstops="100c 200c 300r"
Jackals\t2\t1 | tabstops="100c 200c 300r"
...

Or 2 params

# Centre align the 2nd and 3rd columns, right align the last
Team\tWins\tLosses\tScore | tabstops="100 200 300" tabalignments="center center right"
Mongooses\t3\t0\3000 | tabstops="100 200 300" tabalignments="center center right"
Jackals\t2\t1 | tabstops="100 200 300" tabalignments="center center right"

Naturally, the 1st is shorter and less noisy for the output, but the second would use simple splits rather than complex parsing.

[andyearnshaw]

I also thought it might be cool if an author could define their tab stops in a single place to reduce line noise, e.g.

# <swiftbar.tabStops>100c 200c 300r</swiftbar.tabStops>