Basic menu system UI for IoT devices

[maloo]

If one where to create a graphical/textbased menu system UI in C# using .NET IoT device bindings for input (gpio, buttons, rotary encoders) and displays (1/2/4 line textmode or small graphical displays). Much like you can find on a 3D printer. Would that be something to include in this repo? I don't have the time to create my own nuget repo and maintain it. But I still think it is something that could be useful for a lot of IoT developers since most of these sensor systems with displays would need some kind of UI. Structure and rendering should probably be separated like Xamarin Forms. I have looked a bit at @migueldeicaza's gui.cs but I think it is a bit too coupled to consoles/terminals to be usable here. But it is the most promising one I've found so far.

[krwq]

I think it depends. I.e. short-term for LED matrices which are frequently small sizes I think it makes sense to create some kind of small UI library because even if we somehow make Xamarin work with that it will not likely look good (i.e. fonts will very likely look bad and graphics has to be adjusted specifically for that).

For larger displays I think it might be worth investigating how to make that display natively visible on Linux (i.e. some kind of instruction on how to install/configure driver) and re-use Xamarin.

Long-term it would be nice if we could re-use Xamarin everywhere but I'm not sure how much work would that be and if it that stuff would be useful outside of this repo.

Definitely adding any kind of UI here should start with design discussion where we figure out the plan and it would be useful to involve some Xamarin folks in this conversation to see if there is perhaps some solutions we could re-use.

[maloo]

Ok, I'll let you get hold of some Xamarin guys. As for API I was thinking something like this:

Much like how .NET XDocument, Xamarin, gui.cs are setup

Logical structure setup

var ui = new Window(new Menu(
    new Command("Do stuff", DoStuff),
    new Menu("Sub menu >>",
        new ReturnCommand("<< Go back up"),
        new Slider("My value", 0, 100) is var s ? s : s,
        new Selector("Option 1", "Option 2") is var o ? o : o,
        new Command("Confirm", () => SetConfig(s.Value, o.SelectedItem))
    )
));
ui.Input
    .WithBack(Keys.Backspace)
    .WithEnter(gpio:4)
    .WithUpDown(new RotaryEncoderDevice(gpio0:7, gpio1:13));

Renderers

var displayDevice = ... ;
var renderer = new TextRenderer(ui, w:16, h:4);
renderer.Update(displayDevice);

[krwq]

cc: @KirillOsenkov

[KirillOsenkov]

@migueldeicaza .NET IOT folks are looking around for a small UI framework for small screens (think LED 64x64, maybe limited colors, various screen sizes and color capabilities). The devices run .NET Core and C# but I imagine hardware can be severely limited.

They probably need basic text display, simple rectangular buttons, maybe basic panels (splitting screen in half, simple menus, pages), maybe a scrollable panel.

Any recommendations, ideas or guidance? Thanks!

[KirillOsenkov]

So far the consensus is https://github.com/migueldeicaza/gui.cs

[Ellerbach]

What about point people who need some UI to this: https://github.com/migueldeicaza/gui.cs Seems like it's what is needed. The code is MIT, makes it easy for anyone to build console apps. It's in .NET Standard 2.0 so will be compatible with any .NET Core implementation so with .NET Core IoT.

[joperezr]

Sounds good to me, switched the issue to a documentation issue so that we can track adding this to our docs.

[Ellerbach]

[edit] Yes, this is related to #1013 :-D :-D [original] So I checked manually all the devices and here are those which needs to be fixed:

• CharacterLed: needs shouldDispose
• DCMotor: needs shouldDispose
• Dhtxx: needs both both GpioController and shouldDispose
• ExplorerHat:
  • Led: needs shouldDispose
  • Light: needs shoudDispose
  • Motors: needs shouldDispose
• Hcsr04: needs shouldDispose
• Hcsr501: needs both both GpioController and shouldDispose
• Mcp23xxx: needs shouldDispose
• Mcp25xxx: needs shouldDispose
• Nrf24l01: needs both both GpioController and shouldDispose
• Pca95x4: needs both both GpioController and shouldDispose
• Pcx857x: needs shouldDispose
• RGBLedMatrix: needs both both GpioController and shouldDispose
• SoftwareSpi: needs shouldDispose
• Ssd1351: needs shouldDispose
• Tm1637: needs shouldDispose
• Uln2003: needs shouldDispose

[pgrawehr]

@Ellerbach : I think your previous post is in the wrong ticket, shouldn't this be on #1013?

[joperezr]

Right I think this is the wrong issue 😆, I'll let him move it so that it still shows that he wrote it.

[migueldeicaza]

Also gui.cs can support multiple backends, so as long as you have a grid of characters that you can address, you can provide a backend.

[pgrawehr]

Maybe I get to test whether any of the existing interfaces fits. I've just added a console helper class, so this shouldn't be so big of a deal.

[pgrawehr]

@migueldeicaza Can you point me to the interface or callback method that would need to be implemented?

[migueldeicaza]

https://github.com/migueldeicaza/gui.cs/blob/master/Terminal.Gui/Drivers/ConsoleDriver.cs#L255

[pgrawehr]

For the character displays I'm familiar with, I'm not sure this is going to work. They are only 16x2 or 20x4 characters big and also don't normally support drawing border characters. So something that mimics a graphical menu system will not really fit on that room. It may be different for the small graphic screens, though.

[migueldeicaza]

Right for 16x2 you probably can use something a lot simpler, like WriteLine :-)

[pgrawehr]

Yea, but I think the OPs idea was less about the graphical or textual representation but more about the semantics. I.e you should be able to define a menu structure (a hierarchal set of options) and navigate trough them using a few buttons. And I agree that there could be support for something like that in a library.

[KirillOsenkov]

I think the best bet is to write the logic manually for the particular usage scenarios at hand, and then see if it can be extracted into a reusable library. Usually libraries that aren't designed from concrete usage scenarios don't turn out well.

[krwq]

[Triage] This seems out of scope for this repo. Any library like that should be a separate package.