Darktile – GPU rendered terminal emulator designed for tiling window managers
github.com
github.com
Probably good choice since, after all, terminal graphics is simple enough for the engine to be capable to render.
It's a bit disappointing to me who was expecting some kind of (likely to be excess) rocket science, but I know that's not a fair complaint :-)
Perhaps the focus on tiling wms is a justification for not having tabbing/splitting support built in.
Also, given xorg-dev dependency I assume that if one is on wayland, they are better off using alacritty.
I can copy around 500 lines of logs this way. Quick and dirty.
Other than that IDK.
And about the tabbing and splitting. I got tired of all the terminal emulators I like not supporting it, and some contexts not supporting paging, and not having a nice way to review a long running process, and took the dive to learn tmux.
Tmux. A terrible solution to a bunch of stupid problems. Highly recommend.
I'm clearly not smart enough to do it without having to think about the process every time
cat file.txt | pbcopy
This adds the contents of file.txt to your clipboard.What could they do instead? There's so many trivial solutions. A clipboard named pipe for instance, or at least something that operates like one. Read is paste, write is copy. That's a very 1970 style fix that could have been done 35 years ago. Then anything that can read and write from a file can interface the clipboard, opening up a whole new array of applications without setting aside "highlighting text" as having some special magical power.
Also having multiple clipboards is trivial, just have more of these special files. You can even set one aside if say some crazy old Xt application someone is still running only works with copy-on-select for some reason
A clipboard history is super trivial as well, just set up a pipe...
There's so many more unixy ways this could have been done. It's so dumb how it works. Heck dbus would be a less insane fix
reading yoru entirely comment, I am not entirely sure if you mean changing how it's implemented or if you really would like to get rid of the user interface it has.
Because copy-on-select along with middle-click-to-paste is like ... the best thing. Tiny bits of data stuck that follow your cursor is the most information-at-my-fingertip feeling that I can get out of these machines.
I've hated this feature for 25 years. I run up against the design flaws of this limitation alone usually multiple times a day. From websites that try to have some funky JavaScript convenience (including nearly impossible to use things like medium) to applications that want to select the entire thing and destroy the clipboard as I'm trying to put something in. UX limitations and bad design make it utterly useless constantly.
The whole paradigm is broken. From applications that just select the entire document when you're one pixel off the line of selection, as if anyone has ever asked for that, to application interoperability with anything more than text, parity with windows OLE from around 1993, being still a total pipe dream. Drag and drop is still totally dependent on what toolkit the two programs you're using was written in.
That's nonsense! It'd be like a world where I can't pipe say output from python as input to a bash script because they were implemented in different languages and people would be like "welp. That sounds right. I don't see a problem here"
Also the world of programmers have decided they can go around randomly selecting shit to try to make my life dealing with clipboards easier even though it just makes it utterly unusable. I'm not going to go on a crusade to personally win that fight on a program by program basis. It'd be so much better to have flexibility on how clipboards work
Things could be amazing but instead we defend it being terrible.
Here's an example. Imagine where I can not only do basic asks like drag from inkscape to figma but also have something I'll call a "transport station" where I can drag things into a dock to share them with colleagues who can receive them and then put it into their application of choice, in a non-destructive, non-disruptive way that maintains the flow of productivity. Sound like a smooth and fantastic collaboration tool? I agree.
I've tried to make this, there's lots of fundamental problems that ought not exist. That's the power an unbroken clipboard could have.
What do you do with computers where you don't viscerally feel these limitations daily?
I will grant you that the situation concerning copy/paste as a whole is "not great", I have certainly run into issues before. But this interaction where selecting a word either by dragging a mouse along some text, double or triple clicking to select and then being able to paste this text somewhere else just by pressing the middle-mouse button is just really god computing.
Crucially: This is a very local interaction that does not interact with my clipboard at all. Which lets me copy two things at the same time. I use this all the time for copying/pasting username/password combos.
But that reminds me - the correct way to do this is setting up my password manager to do it for me...
I am interested in the "transport station" you described. I am currently trying to find a way to seamlessley working on multiple computers at the same time, and a shared clipboard like that would be really iteresting. Also to synchronize to my phones' clipboard. Do you have some already written notes on the issues that you ran into ?
No problem copying a few MBs of output this way (100,000 lines for instance).
Learn what’s possible in Vi mode from the key_bindings section of the alacritty.yml config, largely the ones with `mode: Vi` and similar. You’ve got the usual things like hjkl navigation, Ctrl+B and Ctrl+F to go Backwards and Forwards a page, / to search, all that sort of stuff. (Though I will note that ? to search backwards doesn’t work, because Alacritty is using winit’s currently utterly insufficient keyboard API for its bindings, see <https://github.com/alacritty/alacritty/issues/5251>.) Also in alacritty.yml, scrolling.history defines how many lines are kept in the buffer (defaults to 10,000).
- Doesn't do any kind of tabs, or split view, or switching between different "buffers", under the assumption that you use your window manager for that stuff
- Always fills the entire window with the contents of the terminal, regardless of what size the window is (e.g. non-integer multiple of size of a character cell), and doesn't draw its own window decorations
- Launches very quickly
- Generally has a flat, minimalist aesthetic. Uses (ideally configurable) keyboard shortcuts instead of a toolbar, menu bar, or right-click menu, and is configurable by editing a file.
Some terminals are like this already, and I don't know how well Darktile lives up to it. But it's a very different design direction from, say, GNOME Terminal.
Not to dissuade people from hardening them as I'm all for that.
(I'm sure you're aware since you pointed out these measures are incomplete. Just spelling it out.)
A terminal needs to be able to spawn an unconstrained shell or other process linked to a pty that it controls the IO with.
That ability can equally be used for malicious purposes.
E.g. if the user can use the terminal to ssh anywhere, then the terminal itself can too.
There certainly can be situations were a constrained terminal could be useful too, though
Keep in mind that the terminal app is what reads keyboard events and passes them on to what it runs, and the terminal app reads the output back from the attached application (or tmux session) to render them to the screen. It has full control to monitor what you do, and to inject additional commands (and hide the responses) to whatever you connect it to.
Anything you can do in the terminal, the terminal can also do without your permission unless you do far more complicated filtering.
EDIT: I think what might not be clear here is how a terminal operates. It'll differ by operating system and winding system, but on Linux what you have is this:
X server ----[keyboard events]----------> terminal ------[pty w/keyboard events]----> [app/shell/tmux session]
<---[rendering instructions]----/ <----[pty w/output]------------------/
The terminal is always a middleman, and can send whatever it wants to the app/shell/tmux session or whatever else you connect to it. It could "just" send your keypresses, or it can do macro expansions, or it could just randomly take over the endpoint on the other side.You could conceivably still lock this down, but it would involve writing something that either replicates the keyboard event pipeline of the terminal to verify that what is sent over the pty matches the inbound keyboard events, or applying heuristics to what is sent to block things that seems odd, so it's potentially possible to do "something" useful here. E.g. something that blocks and pops up a warning if the pty "keyboard events" suddently contains the string "curl" when that string hasn't been seen in the keyboard events from the X server for example could be useful, but bubblewrap certainly can't do anything like that.
It'd be quite interesting to write a tool that wraps an app and allows you to script monitoring and/or munging of what goes over its sockets, though...
If it is malicious, you're screwed. If it has bugs you might be screwed just viewing a malicious text file.
Most don't even read termcap or termdb anymore and just pump out xterm no matter what display is set to :(
Double width and height are tricky - they are line-based and that makes using them tricky in full-screen apps. Tmux and other screen managers filter them out.
But it does allow fun stuff like shaders. E.g. I added some outlines in the shaders for my version of Kitty (not public anywhere - my hacky shaders are a mess) to let me use more transparent windows without making things unreadable.
Image support and sixel support exists on any number of terminals with no GPU support. A majority of the ones I've used w/sixel support in fact are totally oblivious to GPUs.
Keep in mind sixel originated on terminals a few orders of magnitude slower than even modern mobile devices. For most uses you'll not even benefit from more than a basic 1980's era blitter in terms of acceleration, but given the data volumes even that will not make much difference with a well written terminal app (which will minimize copying to start with)
Still not worth it it me, I try to keep my gpu usage as low as possible to save on battery life, and this just sounds overkill.
But even there CPU based rendering can be fast enough for most things. E.g. I hacked xst to add outlines by just crudely rendering things three times, and that was more than fast enough still on CPU only.
The current glow I add with shaders on Kitty would be hard to do fast enough, but a close approximation with cached glyphs would not be hard.
Does this support Wayland? It's not clear, I can see someone has raised the question in an issue.
I've been using kitty for a while which supports GPU rendering and has Wayland support too.
I believe it supports sixels and ligatures (but I haven't tried those, I don't care much about them).
It works on Wayland - I'm running it under Sway and I'm very happy with it. It also supports server/daemon mode where server does all the rendering and shares glyph cache between windows - lower memory usage & faster startup.
Just tried to run alacritty:
https://megous.com/dl/tmp/4af49886c7c9854d.png
Personally, I'd want something that keeps working even if I don't reboot immediately after a system update, especially for something as key as a terminal emulator.
The day that driver mess is cleaned up a shit ton of problems will disappear overnight.
Not an option to buy anything else for a sane price at the moment sadly, due to crypto craze. ;)
https://wiki.archlinux.org/title/Alacritty#Requires_hardware...
go run github.com/liamg/darktile/cmd/darktile@latestHow do they compare? Are there significant differences or are they just marginally different one from the other?
Kitty has fully featured window management built in, also kittens
Darktile seems to be simpler.