Contributing to notty

[withoutboats]

It doesn't seem reasonable to write a CONTRIBUTING.md for a repo to which I am the only major contributor, but since there are 45 people watching this repo I am optimistically positing that at least one person is interested, at least in the abstract, in contributing to notty, and may read this.

If you've thought about contributing to this project, but were put off - yeah I expect you would be. The core notty crate is changing in deep ways with each commit I make following a design that is only inside my head. It isn't realistic to imagine anyone else could make a large to this section of the code at this point.

But what would be very helpful to me would be if someone were interested in taking over management of either the notty-cairo crate, which draws the screen state of notty to a Cairo context, or the scaffolding crate, which uses GTK+ to create a window with a cairo context and coordinates the interaction between the notty state machine and that context. Hopefully between these crates an actually useful terminal emulator will grow out of this.

If anyone is interested in getting involved with this by taking over one or both those wings of the project, let me know. The interface notty presents to these libraries is fairly stable, and most changes come from improvement to those libraries rather than changes to notty, and I'm happy to answer any questions about how the system works right now.

[tomhoule]

I have been meaning to dive into the notty code for a while now, but couldn’t find the time unfortunately. I wanted to implement a terminal emulator with proper bidi support in rust when notty was announced, and I really like the idea of it. I am not a very experienced programmer at all but would be interested in contributing to notty-cairo and scaffolding if it can help.

[withoutboats]

Hey @tohou, glad to hear you're interested. Here's some info about notty-cairo and scaffolding to help you (or anyone) hack on these parts of the project.

notty-cairo

This crate draws the state of a notty Terminal to a cairo context. The entrance to it is this method. Each line of text is rendered with the TextRenderer, which wraps pango, and each image is rendered with ImageRenderer, which wraps gdk-pixbuf. A lot of the code in this crate (and the crates in subdirectories here) is wrapping pango/cairo/gdk C APIs.

There are almost certainly a huge number of bugs, and definitely some low hanging fruit:

• There is no attempt to fit images within the area of the screen they're supposed to have, so they overflow their bounds. If you can get scaffolding running, the imagetest.rb program should draw an image to the terminal to confirm this.
• Lines of text are not being spaced properly - the information returned by font_extents() is not, apparently, pixel dimensions for this text. How do we get the width/height of the font from cairo? I don't know.

scaffolding

This crate depends on notty and notty-cairo and is an actual terminal built using GTK+. It 'works' but only barely, it needs a lot of love to get it to the point of being a basically usable application - like it doesn't even have an 'exit' button right now, you have to kill it with ctrl+C. Its also rather messy, since it hooks up the terminal and the cairo context in the context of GTK+'s event loop.

The main thing it needs is just feature extension to make it basically on a par with xterm. Fancier features can come later.

[tomhoule]

Thanks for the context! I’ll definitely try to help very soon.

[ysangkok]

What kind of features are most important, and how is the UI for the scaffolding supposed to look like? Xterm allows changing the font using control-right-click, is that preferable to a settings dialog like LXTerminal? It is supposed to be scriptable?

[withoutboats]

What kind of features are most important, and how is the UI for the scaffolding supposed to look like?

The goal of the scaffolding app is (for now) to be able to confirm that notty actually works. I haven't formed a strong opinion about the UI. That said, I'm aware that a lot of people would like to run a notty terminal, and that this is a preliminary step to getting apps that use notty's features written, and scaffolding could grow into being a worthwhile terminal emulator in its own right (at which point a rename would be in order).

I guess this would be a breakdown of priorities here from my perspective:

1. Get notty-cairo to behave correctly. #12 made the line spacing issue more bearable, but its still not correct, so both of the issues in my previous comment are still there.
2. Have a better config set up. Currently configs are statics in src/cfg.rs and you have to recompile notty to adjust them. So the main task here is replacing that with some way of dynamically loading cfgs (I think its possible that a config struct could be passed when instantiating a Terminal). In the long term, my personal preference for configs is storing the canonical configs in a TOML file and providing a GUI menu that edits that TOML file.
3. Confirm that scaffolding is sending all key events to notty.
4. Opening multiple terminals in one window with tabs.

After all of these, I think scaffolding would be a reasonable terminal for daily use, notwithstanding showstopping bugs like #13.

[Deleted user]

if you're using gtk, then using gsettings might be a good way to go. You can choose the backend storage later, with the default being your internal format, but then it could also be stored in dconf too, which gives you a sorta automatic gui (via dconf-editor)

[masukomi]

wouldn't it be easier for others to help out if the notty-cairo and scaffolding code were broken out into their own repos? Maybe the difference is purely in one's head, but if you've got a stable/incrementally improving module it feels much safer / easier to contribute to that than to contribute to a larger codebase that's got a lot of instability.

[withoutboats]

Yes, notty is intended to be reimplemented in other terminals, and this library will be the reference implementation. I think OS consoles are probably the most unfriendly environments for notty, because some commands would require them to depend on image rendering libraries and other more things that are graphics heavy by their standard. It'll be much easier, though still not easy, to get notty's capabilities implemented in other hosted terminals.

Its unlikely any existing terminal would directly depend on notty to implement this protocol though, because it wouldn't integrate with their existing means of managing terminal state.

I just wonder maybe the Rust language might hinder the popularity of the Notty project too.

If I had had to write notty in C or C++, I wouldn't have written a single line of code, which makes Rust a much better language for notty than C or C++ 😄.