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

feat(ux/#2496): Configurable statusbar #3402

Open
wants to merge 25 commits into
base: master
Choose a base branch
from

Conversation

andr3h3nriqu3s11
Copy link
Contributor

@andr3h3nriqu3s11 andr3h3nriqu3s11 commented Apr 12, 2021

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

Peek 2021-04-13 11-18

What do you think? @z0al @bryphe

Sorry for the long GIF

@z0al
Copy link

z0al commented Apr 13, 2021

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
Copy link

z0al commented Apr 13, 2021

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.


let decode =
Json.Decode.(
obj(({field, _}) =>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice job with the decoder here 👍

Comment on lines 46 to 47
leftItems: list(string),
rightItems: list(string),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@@ -36,6 +36,12 @@ let getDefaultConfigString = configName =>
"workbench.sideBar.location": "left",
"workbench.sideBar.visible": true,
"workbench.statusBar.visible": true,
"workbench.statusBar.items": {
"left": ["notificationCount", "macro", "leftItems", "diagnosticCount", "git"],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@@ -36,6 +36,12 @@ let getDefaultConfigString = configName =>
"workbench.sideBar.location": "left",
"workbench.sideBar.visible": true,
"workbench.statusBar.visible": true,
"workbench.statusBar.items": {
"left": ["notificationCount", "macro", "leftItems", "diagnosticCount", "git"],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

rightItems: list(string),
hidden: list(string),
showOnNotification: list(string),
notificationMode: string,
Copy link
Member

@bryphe bryphe Apr 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)
   )
};

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

@@ -194,7 +360,7 @@ module Styles = {
transform(Transform.[TranslateY(yOffset)]),
];

let sectionGroup = [
let sectionGroup = () => [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- `workbench.statusBar.items.start` __(_[items]_ default: `["notificationCount"]`)__ - Defines the first group of items that appear.

- `workbench.statusBar.items.showOnNotification` __(_[items]_ default: `["notificationCount", "modeIndicator"]`)__ - Defines the group of items that are hiden by the notification popup text.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done! 👍

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

@bryphe
Copy link
Member

bryphe commented Apr 13, 2021

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:

2021-04-13 14 01 07

More noticeable with more items pinned:

2021-04-13 14 01 14

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?

@@ -36,6 +36,12 @@ let getDefaultConfigString = configName =>
"workbench.sideBar.location": "left",
"workbench.sideBar.visible": true,
"workbench.statusBar.visible": true,
"workbench.statusBar.items": {
"left": ["notificationCount", "macro", "leftItems", "diagnosticCount", "git"],
Copy link

@z0al z0al Apr 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"]
  }
}

Copy link
Contributor Author

@andr3h3nriqu3s11 andr3h3nriqu3s11 Apr 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"]

Copy link

@z0al z0al Apr 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 🙇🏻‍♂️

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

| 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
Copy link

z0al commented Apr 14, 2021

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?

💯

@andr3h3nriqu3s11 andr3h3nriqu3s11 marked this pull request as ready for review April 15, 2021 08:58
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

Successfully merging this pull request may close these issues.

3 participants