Fixes #3073: Adds Bar as a replacement for StatusBar

[tig]

Fixes

• Fixes Create a new Bar view to replace StatusBar (and eventually MenuBar) #3073
• Fixes StatusBar should support right alignment on last StatusItem #2106
• Fixes Menu hints in StatusBar #191

Todos

Still very much a Proof of Concept/Prototype

• Implement Shortcut view that holds a Key, KeyBindingScope, Title, and help Text.
  • Renders just like a MenuItem.
    • Proper spacing/alignment of help text.
  • Supports arbitrary Views in the CommandView (first) position. E.g. CheckBox
  • Works with KeyBindingScope.Application and KeyBindingScope.HotKey.
  • Supports mouse clicks to activate the shortcut
• Implement Bar view that
  • Looks just like the old StatusBar (StatusBarStyle = true, Orientation.Horizontal)
  • Looks just like the old MenuBar (StatusBarStyle = false, Orientation.Horizontal)
  • Looks just like the old Menu (StatusBarStyle = false, Orientation.Vertcal)
• Update UI Catalog to use the new Bar
• Update to leverage `Dim.Auto``
• Update to leverage Pos.Align
• Replace Toplevel.StatusBar

Pull Request checklist:

• I've named my PR in the form of "Fixes #issue. Terse description."
• My code follows the style guidelines of Terminal.Gui - if you use Visual Studio, hit CTRL-K-D to automatically reformat your files before committing.
• My code follows the Terminal.Gui library design guidelines
• I ran dotnet test before commit
• I have made corresponding changes to the API documentation (using /// style comments)
• My changes generate no new warnings
• I have checked my code and corrected any poor grammar or misspellings
• I conducted basic QA to assure all features are working

[tig]

Now that Dim.Auto and Pos.Align are merged, I am going to get back to working on this...

[BDisp]

Now that Dim.Auto and Pos.Align are merged, I am going to get back to working on this...

I think you are heading in the right direction. Go with it :-)

[dodexahedron]

I'm confused about KeyBindingScope, though.

That should be implicit, by the object graph.

Otherwise, it breaks some pretty basic assumptions most people make in OOP and especially in C#, and especially when events are involved.

If there is to be such a property, it seems to me it should be defined recursively, so that a node in the graph farther from root never has a higher value than anything closer to root. That turns the object model on its head otherwise.

A simpler option would be for hotkeys to live at the root level, and just have a reference to the object that declared them.

[tig]

I'm confused about KeyBindingScope, though.

That should be implicit, by the object graph.

Otherwise, it breaks some pretty basic assumptions most people make in OOP and especially in C#, and especially when events are involved.

If there is to be such a property, it seems to me it should be defined recursively, so that a node in the graph farther from root never has a higher value than anything closer to root. That turns the object model on its head otherwise.

A simpler option would be for hotkeys to live at the root level, and just have a reference to the object that declared them.

I find this suggestion hard to parse. First, KeyBindingScope was not added or changed in this PR.

Second, your wording is very general, and I struggle to see what you really mean. It would be great if you could explain yourself with some code examples (even pseudo-code).

Note, I know the design isn't perfect and there's parts of it that worry me, but I have very intentionally exercised it with a bunch of real-world use cases in various new Views and Scenarios and it works great.

This particular PR definitely stresses it, which is part of my motivation to do this.

[dodexahedron]

Oh certainly, I get that it's a targeted attempt at improving things (and it does).

I intentionally spoke generically, because the concept I intended to convey is a general concept, but it was also a question, though not really properly posed as one, to be fair.

In general, any object should be responsible for its own behaviors, or else a repository pattern is the appropriate alternative (where those objects are managed by a "repository" object that is responsible for telling everything what to do). That's a fundamentally different pattern from how most of TG is designed, though, so that's a non-starter anyway.

The easiest and most appropriate comparisons I can make are to other UI frameworks, since they all kinda set the de facto standards and expectations for developers.¹

So, I'll use WPF, WinForms, and JavaScript as usual.

In all of those, the best place to handle user interaction is as close to the element they are interacting with or that the action is relevant to as possible. The loosest is JS, where you can certainly attach handlers to the window or document if you want, but are strongly advised not to do so.

The question

What is the aim/purpose of KeyBindingScope?
I'll leave that question bare, so as not to influence the response, and expand to better answer your request once I have that context.

Footnotes

1. While it's perfectly cool to be somewhat different/disruptive to conventions and such when we have a good case for doing so, being different for no solid reason is perhaps not so advisable. ↩

[tig]

Did you read the keybindingscope docs and keyboard conceptual docs?

[dodexahedron]

Did you read the keybindingscope docs and keyboard conceptual docs?

Yes, and I'll re-read it again later, to see if I parse it any differently than before, but that's not what I'm looking for.

What I was looking for was something more direct and distilled, and intentionally on-the-spot, for a pointed reason. Because, if it can't be related like that without referencing a conceptual doc, it may be an indication that it could stand to benefit from more design work.

It was basically just a clumsy use of the Socratic method to lead to what my thought is on it, with the potential for my thoughts to be supplemented by your input, as well.

The short version of my opinion on it is it's unnecessary, at least as implemented. The concept and the goal are great, but it seems a little bit heavy-handed and kinda unintuitive. Almost like a solution in search of a problem, but not really to that degree.

Of course, that's from my perspective as someone who didn't write it or have the benefit of sharing a mind with who did implement it. 😅

[dodexahedron]

Put another way, it seems like an over-definition, if that makes sense.

But maybe I'm not grokking something staring me in the face.

Which is the value of the back-and-forth, since I'm always a fan of RTFM regardless. :)

And if that's the case, then it would just come down to doc tweaks.