Extract into library/widget

[p-e-w]

Alacritty's stated intention to not support tabs and split panes for simplicity reasons is understandable, but also makes the terminal useless for many people who rely on these features (no, I'm not switching to tmux to get a poor text-mode approximation of what my window manager does so much better graphically). It would be a pity if such a promising terminal were limited to the i3/tmux niche.

A solution could be to extract the actual terminal (which is the hard part to get right for any emulator) to a library or widget in the spirit of GNOME's VTE. VTE has been very successful and is used by more than a dozen emulators, some of them minimal, others specialized (e.g. dropdown terminals), and yet others full-featured with all bells and whistles.

The current Alacritty application would be a thin wrapper around the terminal widget and construct a configuration object by just deserializing a YML file, which is about as minimal as it gets and should satisfy the soul of any purist. But another emulator based on the same widget could offer tabs and splits, and a graphical configuration dialog. It could also use platform-specific UI, e.g. header bars in GNOME, and feel more like a native application that way.

[casey]

This would enable a lot of really cool use cases, like a quake-style drop-down terminal.

[beefsack]

I created #635 without seeing this ticket, but this one very relevant to the issue I created so I'll close mine.

I'm interested in creating a terminal multiplexer in Rust, particularly if it'd be possible to make one which was in the realm of the performance of alacritty as tmux has trouble keeping up with it on my machine. I think that thinking about how abstracting a library out in the context of creating virtual terminals might be an interesting thought experiment.

[Zerophase]

It would be nice to just have a toggle for a Quake style drop down. Though, I guess a simple bash script would work for most desktops / wms.

[sodiumjoe]

I spent some time researching how to implement #168 and #686 and I came to the conclusion that this issue would be a better way to approach it. For each of these platform-specific issues, winit would have to expose some platform specific api, especially considering issues like #161, where the interface to configure these settings can't really be abstracted across platforms.

https://github.com/google/xi-editor is a good example of the approach of implementing a core, platform-agnostic "backend", with separate platform-specific "frontend" applications that consume the backend as a dependency.

Native UI. Cross-platform UI toolkits never look and feel quite right. The best technology for building a UI is the native framework of the platform. On Mac, that’s Cocoa.

I think winit is valuable for applications that want to be consistent across platforms, but I think alacritty is more compelling as a more native experience. I think this would also make it easier for more people to contribute to these platform-specific UI issues.

I believe this would also address #585.

[binary132]

This is a great idea. You could conceivably even embed it in views in framebuffers for games and things like that.

[zacps]

I'm all for this but I'd appreciate if we could wait until #28 is done as it's likely to touch a lot of the same code.

[nixpulvis]

I have no idea how much work has gone into the windows support yet, but it might make more sense to do this before adding windows support.

[zacps]

@nixpulvis I've already done a large part of the work in event_loop.rs and tty.rs which are the main files that this would extract. I think I'll probably be done in a couple of weeks.

[ghost]

My use case would be a shell for an interpreter embedded in my application. It would be nice to have say, IPython work properly, for example.

[tbodt]

I've done a bit of work on this and pushed it at #1023

[LegNeato]

I want to use alacritty to create animated gifs of terminal playback rather than embed an interactive terminal. I've used the WIP and have been able to render a static image using a glutin HeadlessRenderer:

There are some issues when doing this though, which I will post in the PR. I believe this can be useful for rendering reftests in the project as well.

[jwilm]

@LegNeato This is really neat!

I believe this can be useful for rendering reftests in the project as well.

I've wanted this feature for such a long time!

[LegNeato]

I was able to solve most of my problems without needing any changes to the WIP PR. This is an animated gif created by replaying a saved terminal session in an asciicast file:

(click through to see animation if it looks static)

This is slightly different from the previous image in that I am pumping saved output to alacritty to display rather than pumping commands for the terminal to run and then display. For example, in this one the date is constant and in the other one it changes every time the binary is run (as it is really running date).

I'll do a write up on some stuff tomorrow.

[LegNeato]

What needs to be done to push this through?

[tbodt]

Get #1023 merged :)

[zx1986]

Just need the quake-style drop-down terminal in macOS, that's the only reason I still stick with iTerm2 ...

[mkpankov]

What's the current status? I see the #2312 is merged.

[chrisduerr]

#2312 has made significant advancements and #2438 has brought up even more separation.

I think we've already come very far and all winit dependencies have been completely removed from alacritty_terminal. It's probably just a bit of finishing off that is required to make this a first class library.

The biggest question is always about usecases, so if someone is interested to build something awesome with the library, that will likely drive things forward. If there's no interest, Alacritty just mantains the separation as an abstraction and separation of concerns.

[mkpankov]

I think that warrants closing this issue, and in case a binary author discovers something missing, they'd open a separate issue for that specific thing.

[chrisduerr]

That is a good point and I do think that using Alacritty without winit should be significantly easier now. The renderer is still in alacritty_terminal, but completely optional iirc so it shouldn't significantly impact people trying to use things.

So I think you're right that this can be closed, at least until someone finds specific problems that still require work in this area.

So if someone has any problems with this, I'd recommend opening a separate issue unless it's about very broad work that still needs to be done to support this, in that case please let me know and I'll re-open.

[refaelsh]

Hi all,

Could you guys please help me and point me in the direction of documentation of alacritty_terminal. How to embed it in 3rd party apps as a widget?

Thanks.

[chrisduerr]

The alacritty crate should show you an example of how to interact with the library. There's still some work left to be done to separate these two crates but generally you should just have to replace alacritty bit by bit.

[refaelsh]

The alacritty crate should show you an example of how to interact with the library.

Do you mean that I should just look at the source code of Alacritty and figure it out myself? If yes, its completly acceptable answer. I just wanted to make sure its the currently official way.

generally you should just have to replace alacritty bit by bit

I did not understood it. Can you please explain again using different words?

[chrisduerr]

Do you mean that I should just look at the source code of Alacritty and figure it out myself?

Yes, it should be fairly simple. There's fundamentally not much to the alacritty crate itself.

[brlcad]

The alacritty crate should show you an example of how to interact with the library. There's still some work left to be done to separate these two crates but generally you should just have to replace alacritty bit by bit.

This is amazing, thank you for taking the time to separate them. Very helpful.