Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Kitty – A modern, hackable, featureful, OpenGL based terminal emulator (github.com/kovidgoyal)
192 points by aumerle on Jan 7, 2017 | hide | past | favorite | 88 comments



I like it!

I've seen just about every terminal implement its own version of tiling, and I just have to ask: Why? Doesn't this just increase the line count and surface area without offering anything that doesn't already work just fine as a tool maintained by someone else?


For me (I am the author of kitty) it is for two reasons:

1) Multiplexers are a hack -- there are various problems with them, such as passing control codes through safely, keyboard shortcuts, performance, etc

2) Tiling WMs -- these can work (in fact I use a tiling WM myself) however, the nice thing about having tiling (and tab management) built into the terminal is that you can manage terminal windows and other windows differently on the same screen. For example, on small screens I like to have most GUI windows such s browser, etc. maximized, but I like to have terminal windows side-by-side, this is hard to manage if you want to have them on the same screen. With tiling built into the terminal, managing terminal windows is in a separate "namespace" from all other types of windows


Multiplexers may have some control key quirks but they seem to be essential for any workflow that involves a remote machine or VM. I can have the same workflow everywhere with tmux, local and remote. Though nesting tmux sessions is annoying and can be more convenient to have a remote session in its own terminal window.


Why? The only advantage I can see to running a multiplexer under ssh is that you can resume after disconnection. There are plenty of non-multiplexer based solutions for that. And you can have the same session locally or remotely if you terminal emulator locally, as long as the terminal emulator support sessions, which kitty does.


You opinion tiling WMs makes me thing you haven't tried something dead-simple like i3wm. What you describe is a non-issue for us i3 users.


Really? Tell me how you would do the following with i3 or whatever tiling WM floats your boat. Have four terminal windows arranged in a grid, run a random gui program by typing the name of the program in one of those terminals and have the program open maximized. Close the program by using a quit command inside the program and have the terminals laid out in the grid again. And all this without having to use any window management/layout commands, keyboard shortcuts, mouse gestures.


> And all this without having to use any window management/layout commands, keyboard shortcuts, mouse gestures.

I need to interact with my computer for it to do stuff, I think you somehow exagerated here.

Exluding that incoherent requirement, I'd have two choices:

1. Run the command in a terminal and hit super+f 2. Run the command in a terminal, super+right, super+w (I can switch back and for to <-> from the terminal).

Bonus point of using i3 is that I can optionally have any external program become part of my grid or add/remove exiting terminals to/from different mixed layouts (or workspaces). With multiplexers you're screwed and can't do that.

Note: I do use tmux on all my sessions, but it's mostly for "tab" support, or attaching/detaching (even from different workstations).


I use awesome, and there's a way you can assign particular programs to specific tags, so that they always open on that tag. I'd be surprised if i3 didn't have a way to do the same, given that even dwm can do it ;)

Then, there's a third option in addition to the two you mentioned: spend two minutes (if that) doing the one-time configuration of having the wm reserve a tag for your browser (and perhaps other GUI apps that you anticipate frequently needing/wanting to run full-screen). In awesome, you'd do that by adding an entry to your global rules table like this one (in rc.lua):

    { rule = {
        instance = "firefox"
      },
      properties = {
        screen = "HDMI1",
        tag = "3"
      }
    }
Which will configure awesome so that any time a new client becomes managed by the wm, it will ensure that its window opens on the XRandR screen "HDMI1", and specifically on that screen's tag "3". ("3" is a string here because, while tags are by default "integers", "1" - "9", they can be named by any string afaik, and many people will rename them things like "www", "irc", "term", etc.).

You can also use awesome-client(1) to send Lua code to a running awesome instance for execution within the wm's context. This could be tossed into a shell script (and parameterized as you see fit) for convenience, if desired:

    $ awesome-client <<EOF
      require("awful").spawn("firefox", {
        screen = mouse.screen,
        tag = "3",
        switchtotag = true
      })
    EOF
The same awful.spawn() call you'd send to awesome-client can also be bound to a keystroke or a menu entry for quick access.

As for me, I tend to only use tmux under X11 if I'm worried about losing an ssh connection and therefore (without tmux, of course) the ssh session. However, I have DEC vt520 glass TTY that connects via RS-232 serial cable to a couple of servers (one OpenBSD, the other FreeBSD) and, while the terminal is pretty damn featureful, it has limited scrollback and awkward copy/paste functionality. So, on that terminal I use tmux quite a bit (although it seems to be rather chatty and during periods of heavy pty traffic can sometimes wind up spitting a garbage glyph on the screen here and there, but I think I may just need to increase the baud rate (despite already being set to ~56 Kbaud! cha-tty!)). The vt520 also only supports 2 sessions at once directly (and I can't even figure out how to get the OS to recognize the second one -_-), so tmux's multiplexing capability is also greatly appreciated when I'm basking in the amber glow.


that is kinda funny. The main complaint of the other OpenGL terminal on the frontpage right now is that it doesn't have support for things like tiling or tabs, arguing that it is because terminals don't have nice interface support that we have to use hacks such as multiplexers.


This issue actually divides the terminal userbase. There are the ones with tabs like Gnome Terminal, and the ones that don't manage screens like Termite, st, xterm, and urxvt.


..and all of them run Tmux/Screen.


urxvt supports tabs as well.


...what? I guess I've not dug into the config options enough then. I use the i3 tiling window manager with some tweaks to add uniform gaps between windows and remove their borders/title bars - at first thought, I can't think where/how urxvt would put tabs and make them look good.


See for example: https://awhan.wordpress.com/2010/04/28/urxvt-tabbed/

Configuration is done through ~/.Xdefaults.


I'm not sure if Kitty does this but with Konsole in KDE it enables a number of features that I've found useful in the past. With Konsole's split view I can have a different terminal setup in each view, i.e. different fonts, font sizes, color scheme, scrollback settings, etc. I've found that to be very useful at times where I've got a bunch of different things being tailed and some are either longer than others or more important and i want them to be up in my face when something goes badly.


Ah interesting, different fonts is something I didn't consider and something that could likely only be done by the terminal itself!


Yea it's not something I do commonly but sometimes my coding/terminal font of choice (FiraCode) just doesn't work if I'm say looking at a database dump or some other output and I've got to switch it.


Tiling is very useful for many workloads on one monitor (in a laptop enviroment). Need to run some long running process that needs intervention + do some editing + connect to IRC all in a 12" laptop formfactor? Well tiling is what you need.


He's saying there are other better tools for the purpose. You can use a tiling window manager like i3 or dwm, or a manager within the shell like screen or tmux.


I think of my computer as two half's of the same coin. One I don't need to think about and use my mouse to click though. The other is the one that needs to be respectful interacted with using my dark incantations of Alt/Cntrl + keys to summon features. I don't want these realms mixing.

That's just my opinion but it's probably mirrored.


Oh wow, it's the guy behind calibre! Cool!

Plz plz plz make a windows build. I use cygwin for so much, and a more performant terminal option would be amazing.


Have you tried Cmder[1]? It's a wrapper for ConEmu[2] with Clink[3] integration, and if you get the git-for-windows bundle it comes with a ton of functionality. It also works well with Windows Subsystem for Linux, and is extensible. I've been pretty happy with it while stuck in Windows.

[1]: http://cmder.net/ [2]: https://conemu.github.io/ [3]: https://mridgers.github.io/clink/


Re WSL in Cmder/ConEmu: it's not so simple as that. In fact, it's a terrible mess. If you try to use the straightforward bash.exe, you will quickly run into things that are unsupported, e.g. arrow keys (fixed in Insider builds), home/end keys (fixed in Insider builds) Ctrl+Space (not fixed). If you try to use MinGW/Cygwin and ssh from there, you may run into random crashes when launching programs after using it for some time, such as less or emacs (old bug in MinGW and Cygwin). There is also something called "wslbridge", which also failed for me, but I can't remember why.

In the end, the only thing that does everything I want reliably is embedding a special build of mintty into ConEmu/Cmder. https://github.com/mintty/wsltty

Here is the ConEmu task that I use: %LOCALAPPDATA%\wsltty\bin\mintty.exe --wsl -o Locale=C -o Charset=UTF-8 /bin/wslbridge -t /bin/bash -l

It does have the caveat that you can't use many ConEmu's keyboard shortcuts, but there is a workaround that allows you to pass WinKey+Key shortcuts through, and I'm learning to live with that.


Love cmder! Only problem I have with it is if you drag and drop something in the window when it's running the Linux subsystem, it doesn't automatically convert the path.


You still have to be in the preview to use the Linux subsystem, right?


You mean the Windows Preview program? No, it's in the anniversary update. But it's still a "beta" product.

https://msdn.microsoft.com/en-us/commandline/wsl/install_gui...


As soon as I start configuring things, I break them :)

(Check scrollbar on the right side..) So I go back to whatever...

http://imgur.com/a/2ptLl


As someone else stated, no it was in the anniversary update for stable.

There is a caveat, though. While you can update the Linux packages through apt, bug fixes to actual translation system are only pushed through insider builds currently. That means in order to get the most functional and stable WSL, you have to run insider builds.


>Oh wow, it's the guy behind calibre! Cool!

That just means it's going to change your files without asking and then move them to random places.


And run with superuser privileges all the time.


Care to explain?


Currently there are no builds, even for linux, kitty runs directly from source code (modulo some C code used for performance) :)

As for windows support it should be relatively easy to get it running unser WSL (windows subsytem for linux) Even for a more general approach -- replacing mitty -- it should be possible, with more work.


Wsl in this case is chicken and egg: you'd want to run wsl in this terminal. Not that big of a deal, but bad UX.


Any plans to get it into official repos?

(I'm not super excited about compiling my own stuff. It's so very, very nice to get automatic updates.)


That's upto distro maintainers. kitty is dead simple to build so creating distro packages should be easy.


Understood. I'll post a "Request For Package" to Debian, per their standard request process. We'll see what happens.


There is / used to be a putty drop in replacement called kitty.


Yeah, that was my thought too. KiTTY is leaps and bounds better than putty -which it was forked from - and for a while I made a point to recommend it to any windows user who needed to do any sshing.

Buuuut, I just found mobaxterm, which has a ridiculous amount of features. And I'm pretty sure git bash for windows has ssh, and cmder, and now the Linux subsystem - so there are a lot more options on the table these days. Kitty's days might be numbered.


I actually regressed to putty.

I don't recall why exactly, I think there was some config option that was missing. More importantly though, tmux basically made the advantages of kitty obsolete.


I really need to start intentionally using tmux.

It's just so hard when my i3 bindings are right there, already learned, and they give me all of the screen management I need already - so tmux is only offering me the long-running, detachable session benefits. But even that would be good to learn...

tbh I'm going to be downloading and checking out both kitty and alacritty when I have time; if alacritty turns out to be worth it, it will be the kick in the tail I need to start in on tmux.

(Maybe this mobile graphics card that bluescreens if used at vanilla clock speeds will finally be useful for something!)


I need tmux because I work from a single putty session. Sadly, I think a lot of tmux value is gone when you start a separate session in each separate terminal window.


MobaXterm is nice, and it does a lot of other really useful stuff too, but $70/year for support is a lot of money for a terminal.


Home edition is free, which you are able to use as long as you want and you don't even get a reminder pop-up from my experience so far. $70/year is for the professional version.

Checking out their download page[0] does reveal some limits on the home edition - 12 sessions, 2 ssh tunnels (I wish I knew if those were "simultaneous" or "saved"), a couple of other things - but I haven't run up against these limits yet. I do think that if I was doing something that required more than twelve simultaneous ssh sessions, I would have already switched over to my Linux installation. SSHing from Windows is something I generally do for small things.

[0]: http://mobaxterm.mobatek.net/download.html


Yup. At my work we are doing embedded development and we use the Sparkfun FTDI breakout boards for UART communication. People have come to call the FTDI breakouts "putty boards" but in engineering, some of us use Kitty and call them "kitty boards". :D


Very nice. Close to what I want but not quite there yet. My goal is to have a terminal environment that is seamless between windows, mac, and linux while supporting the kinds of features a "modern" terminal should (colors, utf8, various fonts, etc)


Windows, AFAIK has a completely different terminal implementation, so I doubt you will ever get the same terminal working on unix-like and windows (modulo the WSL) But as for OS X kitty should be easy to port since it uses only cross platform libraries.


How about with the new Linux-in-Windows stuff? Could you make a terminal emulator that works with just that and ignores cmd/powershell?


Yes, the hard part is replacing cmd.exe (i.e. making a terminal that works with windows programs). Making a terminal that works only with linux programs should be fairly simple, especially with WSL (windows linux subsystem)


Actually cmd.exe isn't the problem. conhost.exe is. Whatever you run on windows CLI, be it CMD, Powershell or BASH, it runs on conhost.exe. Even ConEmu and Console2 are just wrappers around it. The console host is getting better though. The latest W10 release supports arbitrary resizing of the screen atleast :) In the next update we even get 24-bit color.

https://blogs.msdn.microsoft.com/commandline/2016/09/22/24-b...


Does this work with MacOS? I didn't see that mentioned in the README.

I have a Linux desktop and MacBook laptop. I would like to run the same Terminal on both.


Not currently, but it should be easy to port, since it only uses cross platform library such as freetype, glfw, python, etc.


Here's what I did on mac:

    brew install glew                             # install glew
    git clone https://github.com/glfw/glfw.git    # install glfw
    cd glfw
    cmake -DBUILD_SHARED_LIBS=ON .
    make install
    cd ..
    git clone https://github.com/kovidgoyal/kitty # install kitty
    cd kitty
    # Then delete ", '-l' + lib" on line 78 of setup.py... and run:
    python setup.py install
But I get this error:

    ld: symbol(s) not found for architecture x86_64
    clang: error: linker command failed with exit code 1 (use -v to see invocation)


It's not going to work out of the box on OS X, but hopefully porting it will not be more than a weekend project. I just need to find a weekend :)

In the meantime, if you, or anyone else wants to help with porting to OS X, please open an issue on github and I will follow up there.


Likely the reason for the error is your removal of that part of line 78 of setup.py. If it's unable to find the libraries it's trying to add, making it not link with them at all isn't the answer; you need to figure out why it can't find them, and fix that.


I think that's something else. If we keep that line, it errors with:

    ld: library not found for -lPython.framework/Versions/3.5/Python
The "lib" variable is set to "Python.framework/Versions/3.5/Python".


Is there a compare / contrast between this project and Gnome Terminator?

https://gnometerminator.blogspot.com/p/introduction.html


How do these work forwarded over X11? Passibly or does the opengl kill permforance?


No idea, never tried it -- not sure why you would want to run a terminal emulator remotely. Isn't it easier to run the terminal emulator locally and ssh into the remote server inside the terminal emulator?


in case you don't have your favorite terminal emulator installed on the machine you are sshing from which would be common with one like this


Presumably, if you are going to do network forwarding, your machine will be network conencted, so just install it. kitty is designed to run from a single directory if needed, so you dont even need admin permissions to do that.


I connect to a bunch of Linux servers from three OS X machines and one FreeBSD machine. I also use a solaris server, none of the servers have monitors. I'd install it on one of the Linux servers cause that's the only thing supported currently.


OSX/freebsd support should not be too far away -- see issue 5 in the kitty github for the status of the OS X port.


Name clash with KiTTY: http://www.9bis.net/kitty/ , terminal emulator, fork of PuTTY. It will be impossible to create package for both in official repos until name conflict will be resolved.


> It will be impossible to create package for both in official repos until name conflict will be resolved.

Not really, if your package manager allows hierarchies then something like `network.kitty` and `x11.kitty` could be used. If they have to use the same namespace then names like `kitty-ssh` and `kitty-term` could be used.

If you're installing binaries into a single location (e.g. /usr/bin) then they can either be left to conflict, or renamed by the packager (e.g. Debian renames task-spooler's `ts` to `tsp`, to avoid conflicting with moreutils' `ts` timestamp command). If packages are installed to independent locations (e.g. as in Nix and Guix) then there's no need to rename anything, although it might be nice to provide symlinks with unique names so that both can be used from the same $PATH.


so what happens now, some sort of rap battle or fight to the death over who gets to keep the name?


One idea is to s/K/T/ but it'll quickly get flamed into oblivion.


Yeah, seems like a poor choice for a name given the similarity too. If it were a cat tracking app, it'd be forgivable, but this is ridiculous.


kitty isn't packaged for me, so a package in the official repos is still possible. It just depends on whether your distro packages the other kitty or not.

---

Actually, scrub that:

> KiTTY is only designed for the Microsoft® Windows® platform

There's no name clash on any distro. Both kitties support different OS families.


Well, the kitty you mention only works on Windows, so what packages on official repos are we talking about?


It's opensource. PuTTY is ported to Linux and is already in Fedora official repo[1], so KiTTY can be ported to Linux too.

[1]: https://admin.fedoraproject.org/pkgdb/package/rpms/putty/


Out of luck with Nvidia proprietary driver and latest Fedora:

    RuntimeError: OpenGL is missing the required ARB_copy_image extension
ARB_copy_image is OpenGL 4.3 extension. Is it supported by NVIDA driver at Linux? Or it's hardware problem? (I have GF106M [GeForce GTX 460M] (rev a1) installed ).


No idea, sorry, I have not used nvidia in many years. I cant tell you that it works with the radeon and intel open source GPU drivers.


Seems pretty silly to need openGL 4+ to run a terminal lol.


ARB_copy_image is supported on Fermi when using Mesa [0].

[0] https://mesamatrix.net/


Have you tried the nVidia OpenGL 2016 driver?

https://developer.nvidia.com/opengl-driver

As far as I can tell, the GTX 460 supports up to OpenGL 4.4.


Pretty sure your driver supports that (glxinfo |grep ARB_copy_image). Maybe you don't have GLEW >= 2.0?


With GLEW 2.0.0:

   ValueError: GLSL 35633 compilation failed: 
   0(29) : error C1020: invalid operands to "/"
   0(29) : error C1020: invalid operands to "/"
   0(29) : error C1020: invalid operands to "/"
   0(33) : error C1020: invalid operands to "+"
   0(34) : error C1020: invalid operands to "+"


https://github.com/kovidgoyal/kitty/issues/4


It works, now.

Wow. It looks good. It fast. Very neat. Mouse works properly.

The only problems so far:

* ctrl-arrow and ctrl-shift-arrow combinations are not working in bash and mc;

* ctrl-ins/shift-ins, middleclick/shift-middleclick for copy/paste not working too (but ctrl-shift-c/ctrl-shift-v works).


Please report bugs your find on github, or I will lose track of them. There is no ctrl-ins, shift-ins, if you want those shortcuts you can add them in the config. What does ctrl-arrow do in bash? IIRC you have to map it to something it does not do anything by default. For kitty the codes to map are ^[OC and ^[OD


Ctrl-arrow jumps over words, like Alt-f/w.

Ctrl-pgup/pgdown jumps to top/bottom of the current screen in mcedit without moving it.

Shift-arrow selects text as cursor moves, ctrl-shift-arrow jumps over word and selects it in mceditor in mc.

Shift-del (cut), ctrl-ins (copy), and shift-ins (paste) are parts of IBM CUA guidelines since 1988. Only shift-ins is necessary to implement, because mouse selection is automatic (no need for ctrl-ins) and shift-del (cut) has no sense. Unlike ctrl-shift-v, shift-ins is pasting mouse (selection) buffer. I.e. I can select a text with mouse in Firefox and then immediately insert it with shift-ins (or middle mouse button or shift-middle if mouse is overriden by an application) in terminal.

Middle mouse button pastes mouse buffer. Shift-mouse click works when terminal program overrides mouse behavior. mc and mcedit are examples.

All these combinations are working properly in gnome-terminal and mate-terminal. Some of them are working in rxvt too.

Ctrl-arrow and ctrl-shift-arrow are huge performance boosts.


Yes, you are right. Thank you.

    > glxinfo |grep ARB_copy_image
      GL_ARB_copy_buffer, GL_ARB_copy_image, GL_ARB_cull_distance, 
      GL_ARB_conservative_depth, GL_ARB_copy_buffer, GL_ARB_copy_image, 

    > rpm -qa | grep -i glew
    libGLEW-1.13.0-2.fc24.x86_64
    glew-devel-1.13.0-2.fc24.x86_64


glew-2.0.0 is in Fedora Rawhide. Oded, thank you!


The GTX 460 came out six years ago. It goes up to OpenGL 4.1.

Sorry, pal.

http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-460...

Edit: I was wrong! My bad.


> The GTX 460 came out six years ago.

In your opinion, what's a reasonable timeline for hardware incompatibility with a terminal emulator? (That's an odd sentence to need to type...)


I think the real question is what benefits do OpenGL give to the terminal emulator that other solutions doesn't. And do they even need to target the latest versions? Maybe using OpenGL actually gives a huge advantage, but the bits that do work just as fine against an older version?


My notebook (Medion Erazer) was produced 3 or 4 years ago. Currently it has i7 CPU, 20GB of DDR3, but it's not capable to handle basic TERMINAL EMULATOR. It's time to upgrade.

I suspect a covert agreement between hardware vendors and vendors of terminal emulators.


This isn't your fault, but nVidia often doesn't update their product pages for older products even if they release new drivers that support newer versions of OpenGL on older products. The GTX 460 supports up to OpenGL 4.4 according to wikipedia, and I've found driver release notes that officially mention OpenGL 4.3 for the GTX 460.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: