The future of Widgets

[tomek-szczesny]

So me and @chromafunk been talking, and although he did not commit to any of that just yet, I'm curious whether we have any "rules" about which widgets are welcomed in notcurses and which are not.

The braille-based graph plotter that @chromafunk has found implemented in Python, could be a perfect widget for notcurses - even better, utilizing nc's internal possibilities it could be much faster and not limited to Braille symbols.

Personally I am interested in some clever ways of representing scientific data for my other project. Widgets with graphs, heat maps, multi-layer vertical progress bar arrays, pie charts or whatever.

I trust you've got nothing against features like that. Perhaps it's a high time to organize widgets somehow. Right now they sit mixed up with "core" features of notcurses, and when notcurses gets its well deserved recognition, I suspect the widget collection will explode.
I suspect there will be a demand for organizing widgets both within the code, and from the user's perspective. A basic set of rules how to contribute a widget, and perhaps a naming convention surely won't hurt.

Or maybe the higher level widgets are not to be a part of notcurses directly, that is something that should be decided at some point as well.

[journeytosilius]

I'm up for this, the sooner the better. Since I either need to:
A- make a module for my software with what we got
B- do it the right way and create a widget that can be used straight from notcurses, it's fast and reusable

[tomek-szczesny]

Well, I think you can start coding it anytime. In the best case scenario @dankamongmen will fully support your work and help you out, and in the worst case you'll create a separate library dependent on notcurses :p

I think you should start by studying the existing widget, can't remember its name... The one that shows fps graph on the bottom of notcurses-demo.

[journeytosilius]

cool, I'll start taking a look in to it asap then, keep you updated

[dankamongmen]

So me and @chromafunk been talking, and although he did not commit to any of that just yet, I'm curious whether we have any "rules" about which widgets are welcomed in notcurses and which are not.

The braille-based graph plotter that @chromafunk has found implemented in Python, could be a perfect widget for notcurses - even better, utilizing nc's internal possibilities it could be much faster and not limited to Braille symbols.

i'm all for more widgets, and they're one area that i really hope will bring more developers to Notcurses. @MasFlam put together a lovely tabbed interface widget.

i'd prefer to keep them in-library if possible. even if they have some kind of new dependency, i'm happy to write the necessary CMake code to allow that dep to be optional, leaving out said widget if it's not there. of course, if someone wants to release them as their own library, that's absolutely fine (and might be better, since that way you can depend on the widget library and know you'll have it, as opposed to deping on libnotcurses-core by itself and not being certain).

my only requirement would be that they ought work like the other widgets, unless it's absolutely impossible:

• they ought usually accept ownership of an ncplane on which to do their thing rather than creating their own
  • this plane ought be destroyed on all error paths in the constructor, and in the destructor
• any subplanes they need create ought be properly bound so that the widget moves as a single entity
• each widget requires a man page and unit tests
  • and ideally also USAGE.md updates and even example code
• reuse as much code as possible

[tomek-szczesny]

now, i might have been a bit too permissive here -- i'm not bringing in python deps that we then wrap in c, etc. that's a bit much. however, for this example, expanding the ncplot concept is something i've had plans to do for some time. i'd love to see linegraphs at a minimum. but we'd almost certainly be writing our own code (likely using lots of stuff factored out of plot.c), and definitely not calling into some Python module.

I agree, and we all understand notcurses are developed in C, thus any new widget shall be coded in C as well.
I had to learn C to start working on the VT thing, I'm getting used to it already. ;)

I take it as a warning you may be busy with more important stuff in the following weeks, and I don't think it's a major setback.
My model is to write the VT support in a completely separate program, and when it works well, book some of your time on a goals list and move the parts of the prototype into the library, one after another. We shall see how it works in the end, but at least I'm not nagging you with PRs that may or may not be necessary in the final thing, and I'm not working on a notcurses clone that will be thousand commits behind when I'm done.

[dankamongmen]

I take it as a warning you may be busy with more important stuff in the following weeks, and I don't think it's a major setback.

hehehe, look over the history of the project; i've been busy since 2019-11 =]. 6k commits in about 600 days, you do the math.

like i said somewhere a few days ago, i'll usually either reply to something within an hour, or it will be a few days. i need to go get on the macmini that @michaelsbradleyjr set up like a boss and make good on that investment. but if you put something up, i'm not going to let it rot.

[tomek-szczesny]

like i said somewhere a few days ago, i'll usually either reply to something within an hour, or it will be a few days. i need to go get on the macmini that @michaelsbradleyjr set up like a boss and make good on that investment. but if you put something up, i'm not going to let it rot.

Sure enough you're a busy guy. And it pays!

I don't know much about cooperative code development, but I can at least predict that with more contributors, your work may gradually shift into overseeing the work of the others, at least partially. ;)

My shitty PR is a fine example - thanks for your patience and useful remarks. I promise to contribute at least tested stuff in the future. ;)
The VT thing is getting near full usability. Colors work, UTF-8 works, next stop are cursor movements (when you merge the PR :P).

[journeytosilius]

yep, and one of the goals on this is to get rid of python. once you enter micro-service territory you can't afford 190mb docker images. it's like ... adding a 190mb container to fire a script that paints braille plots ... takes all the logic out of it :)

[journeytosilius]

by the way, I'm normally using this on my k8s clusters : https://github.com/derailed/k9s

[tomek-szczesny]

Speaking of Widgets,
Concerning the VT thing, over time I'm growing more convinced the VT should indeed be a widget, rather than just a putvt() function and a context struct.

Here are a few examples why I think this is the case, and I'd be happy to hear what you think.

• Terminals generally send data to applications, and may receive commands altering their default behavior in this regard (Mouse support, arrow keys coding)
• Terminals have scrollback buffers and alternate buffers, and quite complex states, such as scrolling regions. Sending anything else than putvt() to ncplane makes no sense and will surely break the consistency of the session,
• VT thus must provide callback pointers for terminal output, or maybe even stuff like BEL
• VT must have extra function to let a user scroll through scrollback
• Why do I keep using vim shortcuts on a github page

Surely enough, most of that could be handled with a few functions taking a VT context struct as an argument, but on the other hand, isn't that what makes widgets stand out from a regular ncplane?
And what's the point of tainting an ncplane API with a bunch of functions that are usable only in a very narrow, specific circumstances.

For now, I have no clue about widgets in general, and I can only imagine that widgets are the solution to the points I've risen here. I keep refactoring putvt() so it is clean-ish and maintainable, and supporting input-only operation.

[dankamongmen]

@dankamongmen,

I may understand your request wrong, but I don't think we're able to cover all terminals from terminfo. If we pass terminfo entry name to VT parser, what exactly should it do with that information?

it needn't do anything right now -- i just would like a hole for it left in the API.

ideally in the future it would cause a lookup of the named terminfo database, and translate according to that dictionary.

@tomek-szczesny

[dankamongmen]

but it's not incumbent on you to write that by any means. just leave the space in the API for it. if you want, check that it's always NULL for now even.

[tomek-szczesny]

Got it - I'll just ignore the input for now.

Mind you, I'm chilling in the mountains far from home, near Slovakian border, so I'll get back to all that next week. :)

[dankamongmen]

have an awesome time, mang! if you want to put up what you have before you go, i can review what's there. if you'd rather not, no worries!

[tomek-szczesny]

Thanks, I am visiting an old friend of mine. No mobile coverage, we steal some wifi from the neighbors, we carry water from a well, chop wood with axes, that kind of living. I promised help fixing some minor issues around the house - finally a bit of manual labor for my geeky ass.

The state of work is always available at the proto repo. You may want to share your thoughts in the issues, or bash my code. ;) Keep in mind this code is evolving and probably it will get replaced in its entirety at some point, and that I am aware of many terrible practices present in there. If you still feel like reviewing it, be my guest!