-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
windows 10 support? #640
Comments
IIRC you can run kitty via WSL. As for making it a native windows executable, not somthing I am interested in, but contributions are welcome. |
I will be personally interested in kitty on Windows 10 without WSL in the future. I have to use Windows at work. I don't have admin rights so I can't install WSL. Unfortunately most computers there still run Windows 7 and it will probably take many more months for more machines, especially mine, to be upgraded. I don't particularly like any of the current terminal emulators available on Windows (that I know of) and I think kitty would be great addition. kitty would also truly be "cross-platform" IMHO as my definition of "cross-platform" includes Linux, macOS and Windows. What would have to be done to work towards supporting Windows? |
see #947 |
Are there instructions somewhere for running kitty in WSL? I'm trying this on Ubuntu 18.04 in WSL:
I'm getting this error:
|
Is there any word on Windows support yet? |
@creallfluharty Certainly, with further tinkering, that can be fixed. Fontconfig is in use on Windows it seems, so start there. |
Got this working on WSL and figured people would be interested in how. YMMV but what worked for me is: VcXSrv (I'm on 1.20.1.4)
Launch Kitty with Results of
|
Hello friends! I want to report my progress/research on this issue before I forget it. I want to say two things right away:
Recipe
Final hurdle
Why it happens? Well because we copied regular GLFW in, and we built GLFW win32 stuff ( If we try quick hack: diff --git a/kitty/main.py b/kitty/main.py
index bc7bf8ce..0f482fe3 100644
--- a/kitty/main.py
+++ b/kitty/main.py
@@ -96,7 +96,7 @@ def init_glfw_module(glfw_module: str, debug_keyboard: bool = False) -> None:
def init_glfw(opts: OptionsStub, debug_keyboard: bool = False) -> str:
- glfw_module = 'cocoa' if is_macos else ('wayland' if is_wayland(opts) else 'x11')
+ glfw_module = 'cocoa' if is_macos else 'win32'
init_glfw_module(glfw_module, debug_keyboard)
return glfw_module We get:
Further investigation is needed. But before I try, I wonder what @kovidgoyal thinks about this method, so I wrote this post. |
There will be a whole bunch of stuff that wont work this way. kitty's fork of glfw has totally different keyboard handling API for instance, and the run loop API, which is what your final hurdle error is about. You cant just drop in glfw upstream into kitty's fork and expect things to work. Somebody has to do the work of porting the various changes kitty has made to glfw to the windows glfw backends. In addition there are unixisms all over kitty's code base, such as using fork to launch child processes, and os.wait() which you discovered for yourself. |
Thanks for quick reply. Unixisms are not a problem if using MSYS which implements POSIX. So, those can be overcome as shown.
I will look into this :-) How hard do you think it would be? |
should take about a week of work for someone reasonably familiar with win32 APIs |
@ctrlcctrlv If you want to work on this, I am willing to help you but I am not familiar with the win32 APIs. |
@Luflosi Thanks for your offer. I see that you know a lot about the GLFW stuff, and you've worked on it a lot. It's hard for me to make a promise that I'll finish this, due to personal financial issues, and other obligations...but I am very interested in the possibility. I guess my question for you would be: why were changes made? Why is glfwRunMainLoop necessary, and what does it really do? Keyboard handling should be simpler to fix than that, I feel (could be wrong!!) |
And BTW thanks @kovidgoyal for quick estimate. I always appreciate your willingness to engage contributors working on things you yourself won't use |
On Wed, Mar 25, 2020 at 12:52:15PM -0700, Fredrick Brennan wrote:
I guess my question for you would be: why were changes made? Why is glfwRunMainLoop necessary, and what does it really do? Keyboard handling should be simpler to fix than that, I feel (could be wrong!!)
glfw's keyboard handling was insufficient no support for input methods,
dead keys, etc. (and is still insufficient see open keyboard issues).
And a run loop was added because glfw's design is fundamentally
incompatible with cocoas design, which asumes cocoa is running the
applications main loop and calling callbacks. This leads to various
impossible to fix issues, just search for issues I have opened in
upstream glfw to see details.
|
On Wed, Mar 25, 2020 at 12:52:56PM -0700, Fredrick Brennan wrote:
And BTW thanks @kovidgoyal for quick estimate. I always appreciate your willingness to engage contributors working on things you yourself won't use
You're welcome I always like to encourage people that wish to hack on
kitty.
|
Hello friends, I have another update. While reading Phoronix today I came across this article: https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-Writing-Wayland-Comp For WSL2, Microsoft will be including a Wayland compositor. As Kitty already supports Wayland, it's my opinion that this will be the best way to fix this issue. Instead of me spending a lot of time to hack support into our GLFW fork, which someone will have to maintain in perpetuity, we can get it for free just by waiting for Microsoft to release their compositor, then forcing Wayland on Windows and not Xorg. |
Hi y'all. What's the status on this? |
There hasn't been any progress on this. |
That's unfortunate. |
I can confirm that kitty runs with hardware acceleration using NVIDIA's WSL2 enabled drivers with Microsoft's WSLg preview builds. EDIT: I have had to build Mesa from source in order to get the D3D12 backend working. |
I have been using kitty since at least 2017 on macos when iTerm started feeling sluggish. It has the best combination of feature set and performance. A project change means that I need to be on Windows but can't use WSL. (Also macos has now become cartoonish🤮) After trying various terminal emulators, I'm using https://github.com/microsoft/terminal. It works well but I miss all the features from kitty. It looks like a native windows port for kitty would be a non trivial undertaking, but it'd be awesome if we can get there. Meanwhile, wezterm is promising and I might switch to it for all the features it provides, if it holds up perf wise. Alacritty doesn't have tabs, mux like support or even ligatures support so it fails miserably for my use. I don't even understand what it's good for, since kitty has better performance than it. |
@Luflosi any progress ? |
If I need to install WSL ( which is a bit complicated because of security and admin issues ), should I ask WSL2 or WSL1 for a better support of kitty ? |
WSL2 has the GPU support and will therefore run much better due to kitty's abundance of GLSL shaders. |
Thanks ! |
@kovidgoyal You've closed this issue, but with the very welcome news and effort from @clo-yunhee that WSLg preview is out and its Wayland GPU support is working, I was wondering whether or not you wanted me, or another interested party, (perhaps she if she wishes!) to pen a guide for its compilation and use. Then Kitty can say it supports all major desktop OS, a major win! I can't wait to make the |
yes, by all means go ahead. I have nothing against windows support, I |
My request for WSL2 is rejected by security team, is there still any chance to make kitty work on Windows 10 ? |
Not affiliated: https://github.com/wez/wezterm. Authors: Please remove the comment if out of place. Thank you. |
Hey tried kitty on windows 11 today with wsl2 and wrote a short guide: https://github.com/danielbisar/settings/blob/main/guides/kitty-on-windows-with-wsl2.md |
hi, any update on this ? |
I just installed wsl 1, and I got same error. |
It won't work on WSL 1. |
It worked on wsl 1, my problem now is it doesn't work on CentOS 7.9 |
OK, it won't work well on WSL 1. Of course you can hack around the limitations with software rendering. |
Since the dev is not interested in support windows at all. Have a look at wezterm. |
That's an unfair statement, expecting a dev to 'just make it work on windows' is not taking into account the complexity between two completely different OSes. As @clo-yunhee mentioned, kitty works great in WSL2 w/ D3D12 ; personally I use it daily and I have ZERO expectations that I should just be able to run |
@sbradnick how you manage to show the kitty with the window decoration in WSL2? When I open kitty it's open with some ugly "default" window decoration :( |
I use VcXsrv vs. the |
I don't see why we can't consider better documentation and perhaps a command for running on Windows, but I'd say you're all right that WSLg is the way to go with this. I mean, making it work in D3D otherwise is…very complicated technically, I know, I have tried. |
(Kitty does not just have one developer, it has a very devoted maintainer, so writing "the dev" is a misunderstanding of how free software even works. It's not like Kovid tried and then everyone gave up. I know of at least one other besides myself who tried, until everyone agreed that WSLg is the best solution given the technical barriers.) |
Here are my 2 cents: I think neither D3D, nor WSL is required and huge mountain of work, whilst creating a rather heavy dependency. A lot of projects were ported to Windows via Msys2 + MinGW64. Once ported and linked natively, they are native win32 applications, requiring neither WSL nor other .dlls to run. GLFW runs perfectly well and I have written multiple applications, statically compiled and dependency free with GLFW via MinGW64. I imagine porting that custom GLFW version as mentioned by @kovidgoyal, wouldn't be particularly hard considering we have rolling GLFW releases for years in the package manager now now and threading is supported via pthreads. On the flip side, I'm sure there are painful platform dependent details a port would entail. Especially if if kitty makes heavy use of the |
After a quick search I saw that Kitty only uses @FrostKiwi, do you know if minGW implements |
posix_spawn is definitely available, but I don't know how the implementation details are. That being said, maybe I chose my words too harshly. The performance of fork() is really not that bad. It's just, that there are programs which makes heavy use of it and there was a performance degradation when switching to MSYS2 + MinGW64 + libwinpthread. Shouldn't be too bad. |
Do any of you know how to make a shortcut to launch kitty without having to launch wsl terminal first? |
if you are not going to port the unixism, cygwin is the only choice, msys is just a disabled cygwin fork to "cross-compile" from cygwin to real windows (no cygwin) |
Besides, solutions rely on cygwin/msys will not be performant, performance is always a key feature for kitty terminal. If we want kitty as performant as how it behaves on macos/linux, we have to rewrite the infrastructure & GPU rendering in a Windows way. |
No description provided.
The text was updated successfully, but these errors were encountered: