-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[very WIP] Make Alacritty into a library #1023
Conversation
Thanks for the PR! It's great to see some action on this front. Would you mind adding a bit of discussion here about the overall approach? It would help me and others when reviewing the code. |
The first step, which I've done, is make Display not depend on Window. The API for Display would be like:
You could then write a GUI app using the standard platform-specific tools which includes an OpenGL context, and invoke the Display to do the rendering in the context. There will need to be a C API for embedders, since writing native apps in pure Rust is suboptimal (as yet, there are no UI frameworks that use Rust as their native language). Code from event::Processor that's still applicable to embedders should be moved to input::Processor if possible. There's not a whole lot of it, but there are things like handling of Focus events. Ultimately, alacritty should no longer depend on glutin or winit. The existing alacritty app and all of the code such as Window and event::Processor that's tightly bound to glutin/winit would be moved into a separate crate, and be renamed to something like alacritty-minimalist (any better ideas?). |
Thanks for the summary! I generally with the overall approach.
This sounds right. The hardest part of this will be pushing input events into alacritty in a relatively clean way.
👍
To me, this sounds like the |
It might be sane to put both the existing app and the library in the same crate, since cargo lets you build a crate both as a library and a binary. The code specific to the alacritty app would go in src/app, and Cargo.toml would say [[bin]]
name = "alacritty"
path = "src/app/main.rs" |
@tbodt but then crates that depend on |
Actually that's a bad idea, you can't have a different set of dependencies for a binary than the library. And things only depending on the core would have to download and build the whole thing as @nixpulvis pointed out. |
This is when we'd need rust-lang/cargo#1982 :| |
What's the status of this, is it still being worked on? |
@RedHatter I was planning on doing more work on this but school got in the way. I'll probably get back to it eventually. Of course, you're welcome to work on it too if you have time. |
Hi! I'm interested in making a GTK frontend to alacritty, so I picked up this work: https://github.com/myfreeweb/alacritty/commits/alacritty-split-new (rebased "Refactor Display to not use Window" onto master, did not take the unfinished Here's a proof of concept rendering Alacritty to a GTK GLArea: |
6dbfe54
to
3649c64
Compare
Nice work @myfreeweb! After a bit of git wizardry I think I've managed to get your work into this PR. I'll try and get it to compile before pushing. |
Do you have your GTK frontend on github somewhere? |
I'm still working on this! I think I'd rather start a new PR. Frontend is https://github.com/myfreeweb/galacritty |
Hm, okay, I realized something. I was going in the direction of faking glutin events from my app to use with the I currently have working key input, window resize and font size change. Modifiers like Ctrl type garbage for now :D but adding their handling would give me a 100% working minimum viable terminal! So actually @tbodt you can keep pulling into this PR, I don't think I'll need any huge changes :) The most important thing for me is making the Window notifier a trait, that's where I tell my GLArea to redraw. |
Awesome! Now that a working prototype exists, I plan on doing some more work on this in the next week. I'll do another rebase magic trick to get the window::Notifier thing. |
It's looking like half the things in the config object shouldn't be the responsibility of alacritty-core:
@jwilm thoughts? |
Most of the rest of the config options could put into a
|
It's exciting to see your work on this @myfreeweb, and thanks to both you and @tbodt for continuing to push this forward. Regarding event processing, I was hoping that Alacritty could still handle most of this, and the embedder would just need to provide some translation layer to turn things into the types Alacritty expects. The idea is that it would be less work for the embedder. I feel that the key/mouse bindings functionality should be exposed for the embedder even if its their responsibility to populate it. The rest of the organization sounds right, though. |
I mostly agree about event processing, but the one area where it would be annoying is with key bindings, since they're based on virtual key codes. In order to pass virtual key codes to alacritty, the embedder would almost certainly need a 151-line match to translate them. |
The key/mouse bindings system is coupled to glutin pretty tightly. Indeed, the encoding of the incoming events depends on the toolkit, but also the This is how I handle keyboard input: https://github.com/myfreeweb/galacritty/blob/9180f3097489bca7925721802a2a57d6f521d5f0/src/widget.rs#L207-L311 I don't handle non-terminal-input actions (copy-paste, font size changes) through this system, that's what GTK accelerators are for, so I don't need an What I do want is the separation of mouse handling algorithms from that system (from the |
It was vendored from https://github.com/myfreeweb/alacritty/tree/alacritty-split-new with hash: valpackett/alacritty@3443033 This goes away when the following PR is merged: alacritty/alacritty#1023
I am in the process of making an example repo, but I want to drop this feedback/usecase here in case I don't get to it in a timely manner. First, thanks! This is exactly what I need and I am so excited you are working on this. My usecase (as mentioned in the related issue) is to use There are two ways to go about it:
I have implemented both and encountered 2 problems:
|
Totally oddball question, but how hard do you think it'd be to wire this up as a login manager for linux? |
will this work enable rendering with metal on osx? I ask because as you've all probably heard, apple is deprecating opengl for macos. 😞 |
@nixpulvis well, my galacritty project wires this up to GTK, and there are GTK based login managers (gdm), so connect the dots :) and you don't have to use GTK specifically, you can wire it up to a smaller toolkit or whatever (but why use a terminal emulator for a login manager? if you want text based login, the system terminal should be fine, or kmscon.) @sodiumjoe no, this is making Alacritty into a library, not adding new render backends to Alacritty. |
Rebased alacritty-split-new. |
Coming back to this now, there are too many merge conflicts for there to be any way to rebase anymore.. Feels like it would have been best to do the refactoring in small steps that could have already been merged...too late now. My plan now is to abandon this PR and basically do the whole thing again in a new PR, but this time try to get it merged before it bitrots. |
@tbodt Thanks for actually staying on top of this and not just abandoning this completely. I'm totally in favor of doing this incrementally and I'd be happy to cooperate. |
My work on #450. As far as I can tell very little progress has been made on that issue, so I'm posting this just to get a bit of code out there, that maybe others can build on. Feedback would be appreciated.