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

andr3h3nriqu3s11 · 2021-04-12T12:40:57Z

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

… for object

z0al · 2021-04-13T16:45:50Z

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 · 2021-04-13T18:30:06Z

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 · 2021-04-13T20:38:39Z

src/Feature/StatusBar/Feature_StatusBar.re

+
+  let decode =
+    Json.Decode.(
+      obj(({field, _}) =>


Nice job with the decoder here 👍

bryphe · 2021-04-13T20:39:50Z

src/Feature/StatusBar/Feature_StatusBar.re

+    leftItems: list(string),
+    rightItems: list(string),


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 · 2021-04-13T20:41:35Z

src/Core/ConfigurationDefaults.re

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


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

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

bryphe · 2021-04-13T20:42:17Z

src/Core/ConfigurationDefaults.re

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


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

bryphe · 2021-04-13T20:53:53Z

src/Feature/StatusBar/Feature_StatusBar.re

+    rightItems: list(string),
+    hidden: list(string),
+    showOnNotification: list(string),
+    notificationMode: string,


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

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 · 2021-04-13T20:55:16Z

src/Feature/StatusBar/Feature_StatusBar.re

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

-  let sectionGroup = [
+  let sectionGroup = () => [


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

bryphe · 2021-04-13T20:55:50Z

docs/docs/configuration/settings.md

+- `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.
+


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

Done! 👍

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

bryphe · 2021-04-13T21:03:22Z

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 · 2021-04-14T08:18:59Z

src/Core/ConfigurationDefaults.re

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


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

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

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.

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

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

| 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 · 2021-04-14T08:21:22Z

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 added 10 commits April 9, 2021 20:29

feat(ux): Configurable mode indicator (onivim#2496)

cd08482

Started work

21a2c5d

Update settings.md, ConfigurationDefaults.re, and 3 more files...

775b3e8

Formated

91793e1

Added possible extencion control(need testing), changed configuration…

42dd87d

… for object

Notification now works on It self without moving items around

cb9822c

Refactoring

745c3f8

Changed extencion items detection from id to id || command

b3e5bac

Started working on the 1st to items of the list

203c4ec

Added "compact" mode for notifications

600c48a

bryphe reviewed Apr 13, 2021

View reviewed changes

src/Feature/StatusBar/Feature_StatusBar.re

let decode =

Json.Decode.(

obj(({field, _}) =>

Copy link

Member

bryphe Apr 13, 2021

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 👍

bryphe reviewed Apr 13, 2021

View reviewed changes

bryphe mentioned this pull request Apr 13, 2021

feat(ux/#2496): Configurable mode indicator #3391

Closed

z0al reviewed Apr 14, 2021

View reviewed changes

andr3h3nriqu3s11 added 5 commits April 14, 2021 11:06

Fixes and update to the docs

402e3cf

Format and removed logs

6792f0b

Merge branch 'master' into feat/ux/configurable-statusbar

c552736

Fixed "left/rigth" to "start/end"

34bd310

Fixed if configuration was alone the text din't appear

9744bff

andr3h3nriqu3s11 marked this pull request as ready for review April 15, 2021 08:58

Merge branch 'master' into feat/ux/configurable-statusbar

c3475c1

andr3h3nriqu3s11 added 9 commits April 17, 2021 09:56

Merge branch 'master' into feat/ux/configurable-statusbar

2bde61c

Merge with master

de6585b

Merge branch 'master' into feat/ux/configurable-statusbar

5b75ef2

Merge branch 'master' into feat/ux/configurable-statusbar

b43dcce

Merge branch 'master' into feat/ux/configurable-statusbar

df930d9

Formated

aa2b3ee

Merge branch 'master' into feat/ux/configurable-statusbar

efcd50b

Merge branch 'master' into feat/ux/configurable-statusbar

c69fb1e

Merge branch 'master' into feat/ux/configurable-statusbar

f10f07b

LifeCANvs mentioned this pull request Jun 6, 2024

upstream Pull Requests LifeCANvs/LCvs-softdev_tool-Onivim2#3

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

andr3h3nriqu3s11 commented Apr 12, 2021 •

edited

Loading

z0al commented Apr 13, 2021 •

edited

Loading

z0al commented Apr 13, 2021 •

edited

Loading

bryphe Apr 13, 2021

bryphe Apr 13, 2021

bryphe Apr 13, 2021

bryphe Apr 13, 2021

bryphe Apr 13, 2021

bryphe Apr 13, 2021 •

edited

Loading

bryphe Apr 13, 2021

bryphe Apr 13, 2021

bryphe Apr 13, 2021

andr3h3nriqu3s11 Apr 14, 2021

bryphe commented Apr 13, 2021 •

edited

Loading

z0al Apr 14, 2021 •

edited

Loading

andr3h3nriqu3s11 Apr 14, 2021 •

edited

Loading

z0al Apr 14, 2021

andr3h3nriqu3s11 Apr 14, 2021

z0al Apr 14, 2021 •

edited

Loading

andr3h3nriqu3s11 Apr 14, 2021

z0al commented Apr 14, 2021

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

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

Are you sure you want to change the base?

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

Conversation

andr3h3nriqu3s11 commented Apr 12, 2021 • edited Loading

z0al commented Apr 13, 2021 • edited Loading

z0al commented Apr 13, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bryphe Apr 13, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bryphe commented Apr 13, 2021 • edited Loading

z0al Apr 14, 2021 • edited Loading

Choose a reason for hiding this comment

andr3h3nriqu3s11 Apr 14, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

z0al Apr 14, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

z0al commented Apr 14, 2021

andr3h3nriqu3s11 commented Apr 12, 2021 •

edited

Loading

z0al commented Apr 13, 2021 •

edited

Loading

z0al commented Apr 13, 2021 •

edited

Loading

bryphe Apr 13, 2021 •

edited

Loading

bryphe commented Apr 13, 2021 •

edited

Loading

z0al Apr 14, 2021 •

edited

Loading

andr3h3nriqu3s11 Apr 14, 2021 •

edited

Loading

z0al Apr 14, 2021 •

edited

Loading