A new kind of terminal

Related tags

notty
Overview

notty - not a typewriter

Join the chat at https://gitter.im/withoutboats/notty

notty is a virtual terminal like xterm, gnome-vte, sh, or rxvt. Unlike these programs, notty is not intended to emulate a DEC VT-series physical video terminal, or any other physical device. Instead, notty is an experimental project to bring new features to the command-line which would not have been possible for the physical terminals other terminals emulate.

Current command-line tools have stagnated (if you prefer, 'stabilized') around the ECMA-48/ISO 6429/ANSI X3.64 escape code protocol, which is defined on the basis of the capabilities of 1980s video terminal devices. Essentially all terminals in use today are virtual terminals being run on devices which are significantly more capable than these ancient machines, and yet the terminal environment has not kept pace with these developments. The last revision of the ANSI escape code protocol was released in 1991.

notty will attempt to remain true to the text-oriented, command-line user interface of the terminal while extending it to include new and more powerful interface features, such as:

  • Full support for rich text formatting, including 24-bits of color.
  • Full and correct support for all of Unicode.
  • Lossless keyboard input.
  • Inline media content, including raster graphics and structured data.
  • Dropdown menus, tooltips, and other features which do not strictly reside in the character grid.
  • Local echo and retained off-screen character grid state to reduce the need for the tty to transmit data back to the terminal.
  • Subdividing the character grid to enable more complex interface layouts without repeatedly reimplementing that logic in the controlling process.
  • And more! If you know any features you wish the terminal had, please open an issue and let's talk about this.

Many of these features are not yet implemented.

To achieve these ends, notty will implement a new and more consistent escape protocol than ANSI escape codes. This protocol will be comparatively easy to extend with new features as the project grows. Once a feature set has been stabilized, I will write a framework for creating terminal applications that use notty's features, written against this protocol (allowing other terminals to implement the protocol and support these features as well). This framework will include a polyfill for approximating these features as well as possible in terminals that don't implement notty codes.

This repository is a library which defines an engine for translating both ANSI and notty escape codes into state changes in the terminal's abstract state. This library does not directly implement any means of drawing the state to the screen and is agnostic about the interface it uses to communicate with the controlling process, so hopefully it will be reusable for writing terminals in different graphical environments, for writing screen/tmux-like server-side multi-terminal managers, and for writing SSH clients in non-UNIX environments. Because it implements (most) ANSI escape codes, this terminal is backwards compatible with existing command line tools.

A subdirectory, named scaffolding, contains a minimal graphical terminal using GTK/pango/cairo, intended for testing notty's features interactively. This terminal is buggy and feature poor and not intended for general use.

A major difference between notty and other projects in the same space is that this is just a virtual terminal, and is fully backwards compatible with the existing shell/terminal setup. It does not implement any features of a shell, and it is not attempting to totally supplant any existing paradigms. Graphical terminals based on this library should be useable as drop-in replacements for other terminals, but with new features that can be used to implement better interfaces for command line programs such as shells, text editors, and other utilities.

That said, terminals as they exist today are a pile of ugly kludges. From the kernel's tty/pty subsystem, to the termios ioctl calls which control it, to the terminfo and termcap databases, to the ANSI escape codes they describe, to the ancient codebases of the terminal emulators themselves, this is a universe of arcane and poorly documented old growth code, much of which is no longer actively useful to people in the 21st century - your system ships with a terminfo db page for more than 2500 different terminal devices, nearly all of them extinct, and every new console you open has a baud rate set in the kernel, even though it exchanges data in memory. More advanced features of notty will certainly requiring sidestepping this system to a certain extent: the current plan is to implement a command to "switch" notty to an extended mode; in such a mode, only notty escape codes would be used and the tty's flags would all be unset except for CREAD and ISIG (and maybe not even ISIG).

This implementation is written in Rust, an exciting new systems language from Mozilla.

Much thanks to Thomas E. Dickey, the maintainer of xterm, whose website hosts excellent documentation regarding xterm's behavior, and to Paul Flo Williams, who maintains vt100.net, which hosts manuals for the actual DEC VT-series terminals. Credit also to Gary Bernhardt, whose talk A Whole New World influenced me to pursue this project seriously.

License

notty is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/.

Conduct

The notty project is committed to upholding the Rust Code of Conduct. Please see CONDUCT.md for more information.

Issues
  • Subdividable screens.

    Subdividable screens.

    Introduce a layer of indirection between Terminal and CharGrid, using the Screen type, which allows a Terminal to contain multiple CharGrids in different sections of the visible screen.

    Prior to this commit, a single Terminal contained a stack of CharGrids, which each filled the entire size of the Terminal window.

    Now, a single Terminal contains a single Screen, which is divided into ScreenSections. Each ScreenSection is a rectangular section of the screen. They are formed by splitting an existing section into two along a horizontal or vertical axis. This means that the relationship between sections that exist is always a binary tree. Each ScreenSection has an unsigned 64-bit tag. One section is identified as the 'active section' - commands that apply to the CharGrid are applied to the grid contained in this section.

    Each section contains a non-empty stack of Panels. A Panel can take one of two forms: either it contains a CharGrid, or it is split into two parts, each of which contains a ScreenSection. As a result, there is a mutually recursive relationship between the definition of ScreenSection and Panel, which allows for considerable flexibility in adjusting the layout screen, while still maintaining a certain level of restraint.

    This commit and its associated commit to notty-encoding add or modify several commands to the notty protocol:

    • PUSH BUFFER is now PUSH PANEL, and takes as an argument the tag of the screen section being pushed to. If no argument is passed, a panel is pushed to the active section. The panel that is pushed always contains a single character grid. It also takes a boolean argument, which determines whether or not the grid retains offscreen data as it scrolls.
    • POP BUFFER is now POP PANEL, and also takes as an argument the tag of screen section to pop from. If no argument is passed, the top panel of the active section is popped. A stack with 1 member cannot be popped from.
    • SPLIT PANEL describes splitting a panel into two. It takes arguments defining the axis and position of the split, which panel the contents should be saved to, how resizing of child sections should be handled, and whether or not the grid in the new panel should retain offscreen data as it scrolls. Panels which are already split can be split again; the existing split sections are resized into the identified saved sections.
    • UNSPLIT PANEL describes removing the split from a panel. It takes an argument identifying which of the two sections in this panel should be saved. The stack of the saved section will be pushed to the top of the section this panel is on top of; the stack of the unsaved section will be destroyed.
    • ADJUST PANEL SPLIT allows an existing split panel's split to be moved or adjusted. It takes arguments defining the axis and position of the split, and how resizing of the child sections should be handled. It performs no action it the section's top is a unsplit panel.
    • ROTATE SECTION DOWN rotates down the stack, putting the top of the stack on the bottom.
    • ROTATE SECTION UP rotates up the stack, putting the bottom of the stack on the top.
    • SWITCH ACTIVE SECTION switches which section is active. It will only perform a switch if the top panel of the target section is a single character grid.
    opened by withoutboats 21
  • (ISSUE-21) Work on distribution of notty configuration data throughout library.

    (ISSUE-21) Work on distribution of notty configuration data throughout library.

    @withoutboats here's what I've got so far.

    Currently I am working to remove all usage of Config::default() as the source of configuration other than in scaffolding and the tests in various modules since I'm not sure how else we would make use of configuration with the approach I've taken so far of replacing default() methods with new(config: Config) for all structs that need to be passed configuration data.

    The problem I am running into currently is what appears to be overgeneralization of the Grid class: https://github.com/withoutboats/notty/blob/master/src/terminal/char_grid/grid.rs#L24

    Looking through the rest of the source code I only see two specific types of Grid: Grid<CharCell> and Grid<i32>. The reason I think of this as problematic is because there are a number of T::default() calls used to construct Grid elements--which sort of enforces the need for CharCell structs to call Config::default() in CharCell::default() to obtain configuration data, which makes it difficult for me to imagine a way to pass the Terminal-owned Config down to the CharCell. Here are a couple possiblities I am considering:

    • Create a Configurable trait that requires a configure(&self, config: Config) method, add that to the Grid type constraints; then use this to configure the CharCell created by T::default().
    • Remove generics from Grid entirely since the only specific type used in this library is Grid. I think this is my preferred approach, unless you anticipate new specific types of Grid in the near future.
    opened by waynr 16
  • #30 Fix Ctrl-D termination behavior.

    #30 Fix Ctrl-D termination behavior.

    Specifically set up a GTK main timeout function to periodically check an Arc value that indicates whether a read on the pty in the listening thread fails--this failure is taken to mean that the process on the other side of the pseudoterminal has exited.

    Also improve error handling in CommandApplicator. Also decrease timeout for CommandApplicatior::apply() calls to improve responsiveness to keystrokes (notice difference between 125 and 25 milliseconds when holding down a character in scaffolding)

    opened by waynr 9
  • Installation?

    Installation?

    Looks like a really interesting project, it would be great to see some installation instructions.

    opened by bmcorser 7
  • How do I build and run notty?

    How do I build and run notty?

    I cloned the repo and ran cargo build, but I see:

    ➜  notty git:(master) cargo build
        Updating registry `https://github.com/rust-lang/crates.io-index`
        Updating git repository `https://github.com/withoutboats/notty-encoding`
     Downloading unicode-width v0.1.3
     Downloading mime v0.1.3
     Downloading base64 v0.1.1
     Downloading serde v0.6.15
     Downloading libc v0.2.7
     Downloading log v0.3.5
     Downloading num v0.1.31
       Compiling unicode-width v0.1.3
       Compiling libc v0.2.7
       Compiling base64 v0.1.1
       Compiling num v0.1.31
       Compiling notty-encoding v0.1.0 (https://github.com/withoutboats/notty-encoding#671ce83f)
       Compiling log v0.3.5
    /home/patrick/.cargo/git/checkouts/notty-encoding-f90d2d7580660013/master/src/args/movement.rs:16:9: 16:44 error: expected type, found `/// Direction of the tab character.`
    /home/patrick/.cargo/git/checkouts/notty-encoding-f90d2d7580660013/master/src/args/movement.rs:16         /// Direction of the tab character.
                                                                                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Build failed, waiting for other jobs to finish...
    Could not compile `notty-encoding`.
    
    To learn more, run the command again with --verbose.
    

    Is this a regression introduced by https://github.com/withoutboats/notty-encoding/commit/91d7e8c0b31ce3b23d96c3d96ddc0b791263e742, or is there something wrong with my environment? I've never used Rust before so I may be missing something obvious.

    opened by pscollins 7
  • Update README.md

    Update README.md

    Current year :)

    opened by sullyj3 6
  • Fix tab right case.

    Fix tab right case.

    Naive fix for #13

    opened by waynr 6
  • Store Config info on the Terminal struct

    Store Config info on the Terminal struct

    As of writing this issue, config information is stored on a global constant called CONFIG, which is imported into several scopes, both in notty and in notty-cairo. Because configuration info is stored on a constant, the only way to reconfigure notty is to recompile it. This is not a great user experience.

    There are several steps that need to be taken to make notty configs convenient to change, this issue is only the first step. Here is a broad roadmap of the whole process to making notty configured dynamically:

    1. The Terminal holds a Config struct, from which all the configurable values for that terminal are accessed. At first, all terminals can be instantiated with the CONFIG constant for this. This is what this issue is about.
    2. This Config struct is made into an argument, and the config info in src/cfg.rs is moved into the scaffolding terminal (though the Config type definition will stay inside of notty).
    3. Add a way for scaffolding to create a Config struct at runtime from some source (probably a TOML file). This way, users can configure the scaffolding terminal without recompiling notty.

    This is a great task for someone to pick up to learn the notty code base better (and probably also Rust). It doesn't interact much with the core logic of notty, but it does require you to explore how it is structured. I am glad to provide guidance and answer any questions about this task.

    To sort of restate the issue, once this is done, cfg::CONFIG should be invoked in only one location, stored somewhere on the Terminal struct, and everywhere it is invoked now should instead invoke the value stored on the Terminal.

    Please drop a note here if you start to work on this and I will assign the issue to you.

    enhancement 
    opened by withoutboats 5
  • Add to Gentoo repository

    Add to Gentoo repository

    opened by vitaly-zdanevich 1
  • Wondering if line-based data like Markdown and RTF which allow for higher lines and Headings will be first-class in this project

    Wondering if line-based data like Markdown and RTF which allow for higher lines and Headings will be first-class in this project

    I love using markdown, but it just never looks right in the terminal I think something like this could really fix that.

    opened by kanliot 0
  • Is this a dead project?

    Is this a dead project?

    I realize this project had very lofty goals from the start, and that it would take a tremendous amount of time and effort. That being said, the latest commit was nine months ago. I'm not trying to complain about this as I realize people have busy lives, but I am wondering if you plan on picking this back up or if it is abandoned.

    opened by Qyriad 6
  • Can't build master branch

    Can't build master branch

    Joyful compiler errors

    error[E0038]: the trait `cmds::EscCode` cannot be made into an object
     --> /home/seunlanlege/.cargo/git/checkouts/notty-encoding-26bc718f9ba2caca/ba5daba/src/client.rs:6:5
      |
    6 |     fn write(&mut self, &EscCode) -> io::Result<()>;
      |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `cmds::EscCode` cannot be made into an object
      |
      = note: the trait cannot contain associated consts like `OPCODE`
    
    error[E0038]: the trait `cmds::EscCode` cannot be made into an object
      --> /home/seunlanlege/.cargo/git/checkouts/notty-encoding-26bc718f9ba2caca/ba5daba/src/client.rs:12:5
       |
    12 |     fn write(&mut self, code: &EscCode) -> io::Result<()> {
       |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `cmds::EscCode` cannot be made into an object
       |
       = note: the trait cannot contain associated consts like `OPCODE`
    
    error: aborting due to 2 previous errors
    
    error: Could not compile `notty-encoding`.
    warning: build failed, waiting for other jobs to finish...
    error: build failed
    

    rustc version rustc 1.22.0-nightly (f1b5225e8 2017-10-01)

    opened by seunlanlege 1
  • Wishlist : Magic Wormhole

    Wishlist : Magic Wormhole

    I have a little idea but don't know how it could be done or if it's even doable or not :

    The magic wormhole is a fifo between multiple terminal. Let's take an example.

    • You open a terminal. You connect to ssh. You then enter a container with "lxc-attach -n foobar".
    • You open another terminal. You start another ssh session on another machine which can't reach the lxc container.
    • You start/enter/trigger the magic wormhole to bind the two terminal to get data from one term to the other. That way you can transfer files or even pipe commands between the two terminals.

    For now you can mimic this with tmux by using buffer copy and all but it's quite complex and not very reliable.

    I discussed a bit of this on alacritty's irc channel and was redirected here. What do you think of this ? Is it out of scope ? technically not feasible ?

    opened by lord-re 1
  • Wishlist: `dialog` support

    Wishlist: `dialog` support

    Some apps like debconf support dialog for drawing various widgets in (traditional) terminals.

    If notty can operate as a drop-in replacement for dialog (or whiptale), then it may in that way find some customers!

    opened by daveloyall 0
  • notty-encoding fails to build on OSX 10.11.6

    notty-encoding fails to build on OSX 10.11.6

    Hi,

    I'm trying to compile notty and have run into an error building the encoding package. Here is the output from my build:

    ➜  notty git:(master) cargo build --verbose
           Fresh uuid v0.3.1
           Fresh base64 v0.1.1
           Fresh num-traits v0.1.37
           Fresh unicode-width v0.1.4
           Fresh log v0.3.7
       Compiling notty-encoding v0.1.0 (https://github.com/withoutboats/notty-encoding#ba5daba3)
           Fresh num-integer v0.1.34
         Running `rustc --crate-name notty_encoding /Users/mgrunder/.cargo/git/checkouts/notty-encoding-26bc718f9ba2caca/ba5daba/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=46ffb3a5a218e748 -C extra-filename=-46ffb3a5a218e748 --out-dir /Users/mgrunder/dev/rust-foss-projects/notty/scaffolding/target/debug/deps -L dependency=/Users/mgrunder/dev/rust-foss-projects/notty/scaffolding/target/debug/deps --extern base64=/Users/mgrunder/dev/rust-foss-projects/notty/scaffolding/target/debug/deps/libbase64-21fea01bef6f0feb.rlib --cap-lints allow`
           Fresh num-iter v0.1.33
           Fresh num v0.1.37
           Fresh serde v0.6.15
           Fresh mime v0.1.3
    error[E0038]: the trait `cmds::EscCode` cannot be made into an object
     --> /Users/mgrunder/.cargo/git/checkouts/notty-encoding-26bc718f9ba2caca/ba5daba/src/client.rs:6:5
      |
    6 |     fn write(&mut self, &EscCode) -> io::Result<()>;
      |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `cmds::EscCode` cannot be made into an object
      |
      = note: the trait cannot contain associated consts like `OPCODE`
    
    error[E0038]: the trait `cmds::EscCode` cannot be made into an object
      --> /Users/mgrunder/.cargo/git/checkouts/notty-encoding-26bc718f9ba2caca/ba5daba/src/client.rs:12:5
       |
    12 |     fn write(&mut self, code: &EscCode) -> io::Result<()> {
       |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `cmds::EscCode` cannot be made into an object
       |
       = note: the trait cannot contain associated consts like `OPCODE`
    
    error: aborting due to 2 previous errors
    
    error: Could not compile `notty-encoding`.
    
    Caused by:
      process didn't exit successfully: `rustc --crate-name notty_encoding /Users/mgrunder/.cargo/git/checkouts/notty-encoding-26bc718f9ba2caca/ba5daba/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=46ffb3a5a218e748 -C extra-filename=-46ffb3a5a218e748 --out-dir /Users/mgrunder/dev/rust-foss-projects/notty/scaffolding/target/debug/deps -L dependency=/Users/mgrunder/dev/rust-foss-projects/notty/scaffolding/target/debug/deps --extern base64=/Users/mgrunder/dev/rust-foss-projects/notty/scaffolding/target/debug/deps/libbase64-21fea01bef6f0feb.rlib --cap-lints allow` (exit code: 101)
    

    rustc:

    ➜  notty git:(master) rustc --version
    rustc 1.19.0-nightly (06fb4d256 2017-04-30)
    

    OS Information:

    ➜  notty git:(master) system_profiler SPSoftwareDataType
    Software:
    
        System Software Overview:
    
          System Version: OS X 10.11.6 (15G1217)
          Kernel Version: Darwin 15.6.0
          Boot Volume: Macintosh HD
          Boot Mode: Normal
          Computer Name: MG-MBP
          User Name: Michael Grunder (mgrunder)
          Secure Virtual Memory: Enabled
          System Integrity Protection: Disabled
          Time since boot: 2 days 13 minutes
    

    I was able to find a few places on the net mentioning this error but unfortunately I don't know nearly enough about rust to figure out a solution. Hopefully I'm not missing something totally obvious here :smiley:

    Edit: I get the same error in Ubuntu.

    opened by michael-grunder 8
  • Build error on OSX 10.12: error: Could not compile `glib`

    Build error on OSX 10.12: error: Could not compile `glib`

    Hey i'm really hyped to try out notty, but i haven't been able to compile it.

    The compilation always crashes because of glib v0.0.8 - i've pasted the relevant errors below.

    I'm already using the nightly build of rust, so it should compile fine – since there are other OSX users here that have managed to compile it without errors.

    I've tried using a newer package of glib, but unfortunately that didn't help. Also searched on Google and stackoverflow and found some similar problems with glib. But the solutions provided there also didn't help. Like reinstalling the glib located at /usr/local/opt with brew. Didn't help either... Then cargo updateand re-build – still failing at the same point.

    What could be wrong with my installation / settings? Do i need a specific glib version or some extra flags to get past the errors?

    Here are the generated errors:

    sudo sh build_test.sh
       Compiling notty v0.1.0 (file:///Users/david/github/build/notty)
    (...)
    test terminal::screen::split::tests::into_6_6::max_right ... ok
    test terminal::screen::split::tests::into_6_6::percent ... ok
    test terminal::styles::tests::styles_update ... ok
    
    test result: ok. 74 passed; 0 failed; 0 ignored; 0 measured
    
       Doc-tests notty
    
    running 0 tests
    
    test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured
    
       Compiling either v1.1.0
       Compiling cairo-rs v0.1.2
       Compiling gdk-pixbuf v0.1.2
       Compiling libc v0.2.21
       Compiling gdk v0.5.2
       Compiling c_vec v1.2.0
       Compiling gdk-sys v0.3.3
       Compiling gio-sys v0.3.3
       Compiling itertools v0.5.10
       Compiling gdk-pixbuf-sys v0.3.3
       Compiling bitflags v0.5.0
       Compiling bitflags v0.4.0
       Compiling pango-sys v0.3.3
       Compiling cairo-sys-rs v0.3.3
       Compiling gio v0.1.2
       Compiling glib-sys v0.3.3
       Compiling gobject-sys v0.3.3
       Compiling glib v0.1.2
       Compiling pango v0.1.2
       Compiling glib v0.0.8
    error[E0591]: `extern "C" fn(&std::cell::RefCell<std::boxed::Box<std::ops::FnMut() -> source::Continue + 'static>>) -> i32 {source::trampoline}` is zero-sized and can't be transmuted to `std::option::Option<unsafe extern "C" fn(*mut libc::c_void) -> i32>`
      --> /Users/david/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.0.8/src/source.rs:73:70
       |
    73 |         glib_ffi::g_idle_add_full(glib_ffi::G_PRIORITY_DEFAULT_IDLE, transmute(trampoline),
       |                                                                      ^^^^^^^^^
       |
    note: cast with `as` to a pointer instead
      --> /Users/david/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.0.8/src/source.rs:73:70
       |
    73 |         glib_ffi::g_idle_add_full(glib_ffi::G_PRIORITY_DEFAULT_IDLE, transmute(trampoline),
       |                                                                      ^^^^^^^^^
    
    error[E0591]: `extern "C" fn(&std::cell::RefCell<std::boxed::Box<std::ops::FnMut() -> source::Continue + 'static>>) -> i32 {source::trampoline}` is zero-sized and can't be transmuted to `std::option::Option<unsafe extern "C" fn(*mut libc::c_void) -> i32>`
      --> /Users/david/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.0.8/src/source.rs:91:78
       |
    91 |         glib_ffi::g_timeout_add_full(glib_ffi::G_PRIORITY_DEFAULT, interval, transmute(trampoline),
       |                                                                              ^^^^^^^^^
       |
    note: cast with `as` to a pointer instead
      --> /Users/david/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.0.8/src/source.rs:91:78
       |
    91 |         glib_ffi::g_timeout_add_full(glib_ffi::G_PRIORITY_DEFAULT, interval, transmute(trampoline),
       |                                                                              ^^^^^^^^^
    
    error[E0591]: `extern "C" fn(&std::cell::RefCell<std::boxed::Box<std::ops::FnMut() -> source::Continue + 'static>>) -> i32 {source::trampoline}` is zero-sized and can't be transmuted to `std::option::Option<unsafe extern "C" fn(*mut libc::c_void) -> i32>`
       --> /Users/david/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.0.8/src/source.rs:109:13
        |
    109 |             transmute(trampoline), into_raw(func), Some(destroy_closure))
        |             ^^^^^^^^^
        |
    note: cast with `as` to a pointer instead
       --> /Users/david/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.0.8/src/source.rs:109:13
        |
    109 |             transmute(trampoline), into_raw(func), Some(destroy_closure))
        |             ^^^^^^^^^
    
    error: aborting due to 3 previous errors
    
    error: Could not compile `glib`.
    Build failed, waiting for other jobs to finish...
    error: build failed
    
    opened by subzerofun 0
  • Graphical rendering

    Graphical rendering

    Hi,

    I am the developer of a new terminal emulator, https://github.com/kovidgoyal/kitty and I am considering adding graphics rendering capabilities to it. To that end, I have posted some thoughts here https://github.com/kovidgoyal/kitty/issues/33

    Since you also seem to be trying to develop standards in this space, I thought I would invite you to join the discussion.

    opened by kovidgoyal 0
  • Typo in readme

    Typo in readme

    There's a typo in Readme.md "not have been possible for the physical terminals other terminals emulate." You probably wanted to remove "other terminals" and replace it with "to"

    opened by rinchen 1
Owner
Saoirse Shipwreckt
In civilizations without boats, dreams dry up, espionage takes the place of adventure, and police take the place of pirates.
Saoirse Shipwreckt
A cross-platform, OpenGL terminal emulator.

Alacritty - A fast, cross-platform, OpenGL terminal emulator About Alacritty is a modern terminal emulator that comes with sensible defaults, but allo

Alacritty 33.1k Jun 13, 2021
A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust

Wez's Terminal A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust User facing docs and guide a

Wez Furlong 1.9k Jun 14, 2021
Reusable Reproducible Composable Software

Reusable Reproducible Composable Software Welcome What is this? Fractalide is a free and open source service programming platform using dataflow graph

Fractalide 684 May 10, 2021
A terminal IRC client

tiny - Yet another terminal IRC client tiny is an IRC client written in Rust. Features Clean UI: consecutive join/part/quit messages are shown in a si

Ömer Sinan Ağacan 618 Jun 14, 2021
Limit screen time to children's various mobile devices by blocking internet access on the family Wifi router.

Device Blocker Limit screen time to children's various mobile devices by blocking internet access on the family Wifi router. This is the server which

null 32 May 19, 2021
A purpose-built proxy for the Linkerd service mesh. Written in Rust.

This repo contains the transparent proxy component of Linkerd2. While the Linkerd2 proxy is heavily influenced by the Linkerd 1.X proxy, it comprises

Linkerd 1.2k Jun 14, 2021
A system to programmatically run data pipelines

Factotum A dag running tool designed for efficiently running complex jobs with non-trivial dependency trees. The zen of Factotum A Turing-complete job

Snowplow Analytics 162 Jun 8, 2021
Full fake REST API generator written with Rust

Weld Full fake REST API generator. This project is heavily inspired by json-server, written with rust. Synopsis Our first aim is to generate a fake ap

Seray Uzgur 149 Jun 4, 2021
Bindings for Binomial LLC's basis-universal Supercompressed GPU Texture Codec

basis-universal-rs Bindings for Binomial LLC's basis-universal Supercompressed GPU Texture Codec basis-universal functionality can be grouped into two

Philip Degarmo 21 Apr 9, 2021
A (self hosted) pastebin for easily sharing text right from the terminal

termpad termpad allows you to easily host a pastebin server for saving and viewing text right from the terminal, or the browser. Client Usage Assuming

Spyros Roum 18 May 23, 2021
Command-line utility for managing DigitalOcean infrastructure

docli-rs (pronounced "dockly") A command-line utility for managing DigitalOcean infrastructure via the DigitalOcean API v2 Disclaimer This utility is

Kevin K. 34 Sep 9, 2020
An API for managing your servers

Intecture APIs Intecture is an API for managing your servers. Visit intecture.io. API docs can be found here: intecture.io/api/intecture_api/. Intectu

Intecture 28 May 12, 2021
Cross-platform tool to update DNS such as Gandi.net with your dynamic IP address

GDU | Generic DNS Update A cross-platform tool to update DNS zonefiles (such as Gandi.net) when you have a dynamic public IP address. It's a DynDNS or

Damien Lecan 10 Apr 9, 2021
A user-friendly database interface

Diwata Diwata is a database interface for PostgreSQL,Mysql, Sqlite with the goal of being usable, user-friendly with its basic and advanced functional

Jovansonlee Cesar 386 Apr 9, 2021