feat(ux/#2496): Configurable statusbar

[andr3h3nriqu3s11]

Adds a fully configurable status bar from the configuration file

<breaking>Fully configurable status bar</breaking>

Based on the ideas from @z0al #3402 there is some work that needs to be done on this branch:
☑️ Change from start/end right/left
☑️ Make ... move all to one side
☑️ Make ... move all the extensions to their side based if ... is on both sides or not
☑️ Make Hidden
☑️ Add a notificationMode or make showInNotificaion work as notificationMode if it's a string
☑️ Make notificaionPopup with fixed size for compact

There are some changes differences from @z0al proposed, I left the rightItems and leftItems If you want to move the all the left or right extensions items to a different position, but all the other "rules" still apply.

I also made, so you could use the command and the id for selection extensions items.

The compact mode for notifications is now 2 possible options compact and compact+ where compact lets notifications "stack up" on the bar and compact+ does not (we could probably find better names for this).

What do you think? @z0al @bryphe

Sorry for the long GIF

[z0al]

I left the rightItems and leftItems If you want to move the all the left or right extensions items to a different position

I'm confused. I don't understand why leftItems and rightItems would be relevant anymore given the introduction of the ... notation. Maybe you can share an example for the use case you have in mind?

Previously (or currently, in the main branch), leftItems and rightItems are based on the extension alignment config. We will still respect that if the user provided an expansion slot (a.k.a ... notation) in both items.left/right configuration.

However, with the ... syntax, the user can overwrite the default alignment (set by the extension) to something else. e.g.

{
  "workbench.statusBar.items": {
    "left": ["modeIndicator"],
    "right": ["...", "notificationCount"],
  }
}

In the above configuration, I'm basically overwriting all items that there previously known as leftItems to be right-aligned.

Now if we keep the leftItem/rightItems what would that mean for the logic of ...? Taking this configuration as an example.

{
  "workbench.statusBar.items": {
    "left": ["modeIndicator", "rightItems"],
    "right": ["...", "leftItems", "notificationCount"],
  }
}

That doesn't seem to be predictable or deterministic anymore to me. The ... and leftItems/rightItems will be conflicting with each other and making the configuration a bit vague.

The compact mode for notifications is now 2 possible options compact and compact+ where compact lets notifications "stack up" on the bar and compact+ does not (we could probably find better names for this).

It's not about the naming for me. I don't see the benefit of the compact+ mode. There is a very limited space on the status bar and showing multiple messages next to each other horizontally doesn't seem like a good idea to me.

The purpose of the notification popup is to give visual feedback that there is something that may need my attention. Having the last message on the status bar is more than enough to achieve that. That being said you might have noticed that the notification pop contains duplicated information by design. If I want to see any message in details there is a notification panel for that. In fact, the messages are most likely to be duplicated in the editor too as errors/warnings or hints in a specific line if possible.

But in any case, we can always add it in future if see a need. The current configurations set is flexible enough to support different modes in future.

I also made, so you could use the command and the id for selection extensions items.

I've no clue if this is a good idea or not tbh 🤷🏻‍♂️

---

On a different note, I think it's a good idea to start explicitly assigning priority and alignment attributes to the built-in/hardcoded items e.g.

let modeIndicator = {
  id: "mode",
  alignment: RIGHT,
  priority: 1 // I don't know
}

let notificationCount = {
  id: "notificationCount",
  alignment: LEFT,
  priority: 1 // I don't know
}

This should avoid accidentally changing the priority or alignment of these items between releases.

[z0al]

I might have confused the difference between compact and compact+ . What I wrote above is about the one that adds multiple notification messages to the status bar. The compact mode I have mind doesn't.

[bryphe]

Nice job with the decoder here 👍

[bryphe]

It looks like there is a difference between here and the docs - can we use startItems and endItems instead of leftItems and rightItems? I like start/end vs right/left because when we implement a configuration setting for right-to-left languages, startItems and endItems will be less ambiguous than right/left.

[bryphe]

It looks like we'll need to replace leftItems with ... and rightItems with ... below

[bryphe]

(Oops, this was just echoing what @z0al mentioned in his reply - beat me to it!)

[bryphe]

Instead of left/right, we'll need to change these to start/end to be in sync with documentation

[bryphe]

It might be nice to have a type for notification mode, like:

type notificationMode = 
| Default
| Compact
| CompactPlus

Then, we could add a decoder, like:

module Decode = {
   let notificationMode: Json.decoder(notificationMode) = Json.Decode.(string
   |> map(String.lowercase_ascii)
   |> and_then(fun
   | "default" => succeed(Default)
   | "compact" => succeed(Compact)
   | "compact+" => succeed(CompactPlus)
   | invalid => fail("Invalid notification mode: " ++ invalid)
   )
};

[bryphe]

This gets us out of the business of having to check strings elsewhere in the code for this (and will give us a compiler warning if we add a new mode and don't handle it)

[bryphe]

This change might not be needed, since the function isn't taking any arguments

[bryphe]

Would be great to document the 'notificationMode' and 'hidden' properties here, too!

[andr3h3nriqu3s11]

Done! 👍

Although I would ask for anyone to check the docs that I made, because I am not good with words...

[bryphe]

Thanks for the impressive work on this, @andr3h3nriqu3s11 !

I had a lot of fun playing with it - like, putting mode indicators on both sides of my status bar 😎

I noticed a bug with the notifications - it seems like the background color isn't being transitioned for the status bar items that are 'pinned' to the notification - like:

More noticeable with more items pinned:

The sort of 'gap' in the pinned items where the color isn't transitioning seems a bit jarring / confusing - it does make more sense in the 'compact' mode where it just the smaller notification is animating. In 'default' mode - I wonder if we could preserve the existing color transition behavior?

[z0al]

I noticed in the demo from @bryphe below that we need to adjust the default configuration shipped in Oni to eliminate the spacing gap between notification items by default. It's caused by items hidden due to showOnNotificaiton still occupying their position.

To remove the spacing we can adjust the default configuration to something like this.

{
  "workbench.statusBar.items": {
    "left": ["notificationCount", "diagnosticCount", "notification", "..."],
    "right": ["...", "modeIndicator"],
    "showOnNotification": ["notificationCount", "modeIndiactor", "diagnosticCount"]
  }
}

[andr3h3nriqu3s11]

Actually that's not necessary, but it might be a good idea, to make diagnosticCount be next to the notificationCount and always the shown.

By default, diagnosticCount is not on showOnNotification so it will be hidden.

Also, I changed the code now so that the default behavior is for the showOnNotification to be forced grouped together on their side, ex:

  "start": ["aa", "bb", "cc"]
  "showOnNotification": ["aa", "cc"]

Then it's shown as

["aa", "cc", "bb"]

And then I added a new noficationMode keepPosition where it forces the items to be in the position that user specified, but it will cause those gaps

[z0al]

Not sure I follow. I thought diagnosticCount is part of the default notification pop. If it's not then nevermind

But the point I was trying to make is to explicitly define the notificationMessage position next to the items that will be shown in items.start. That means something like below. That ensures by default there is no gap. If the user changed the ordering then they need to make it a way that doesn't introduce gap as well:

{
  "workbench.statusBar.items": {
    "left": ["notificationCount", "notificationMessage", "..."],
    "right": ["...", "modeIndicator"],
    "showOnNotification": ["notificationCount", "modeIndiactor"]
  }
}

Also, I changed the code now so that the default behavior is for the showOnNotification to be forced grouped together on their side

That can also be a fix for the issue. But the reason I didn't suggest that because it rearranges some of the elements on the status bar only to revert back to the original positioning a second later, I think that can result in a bad UX. But I didn't see it in practice, maybe it's not that bad.

[andr3h3nriqu3s11]

That can also be a fix for the issue. But the reason I didn't suggest that because it rearranges some of the elements on the status bar only to revert back to the original positioning a second later, I think that can result in a bad UX. But I didn't see it in practice, maybe it's not that bad.

Sorry I have seamed to not explain my self correctly...

It will be shown as this all the time not only for the notification

["aa", "cc", "bb"]

[z0al]

Oh, I see, I misunderstood. If I get it correctly now, it means we will automatically group notification items even though the user might have chosen a different positioning. To force the items to be kept in the same position as the configs the keepPosition mode must be set, right?

I feel like that defeats the purpose of explicitly positioning the items via configs... in general, I'd try to make things Simple and Stupid. In this case, It seems like we are adding complexity for a little gain especially since the fix for gapping can be done by the user him/herself with little effort. We just need to make our defaults gapless.

But I also feel like I'm being too picky here, sorry. so I'd leave it for @bryphe to decide what makes sense. Thanks for the great work on this 🙇🏻‍♂️

[andr3h3nriqu3s11]

| Oh, I see, I misunderstood. If I get it correctly now, it means we will automatically group notification items even though the user might have chosen a different positioning. To force the items to be kept in the same position as the configs the keepPosition mode must be set, right?

Yes

I feel like that defeats the purpose of explicitly positioning the teams via configs... in general, I'd try to make things Simple and Stupid. In this case, It seems like we are adding complexity for a little gain especially since the fix for gapping can be done by the user him/herself with little effort. We just need to make our defaults gapless.

True, true then maybe what we have to do it's have default to match what the user put and then maybe have a prettify option tries to move everything together? What do you think?

[z0al]

The sort of 'gap' in the pinned items where the color isn't transitioning seems a bit jarring / confusing - it does make more sense in the 'compact' mode where it just the smaller notification is animating. In 'default' mode - I wonder if we could preserve the existing color transition behavior?

💯