OS X support about kitty HOT 38 CLOSED

Awesome, I agree. Thank you very much. It builds correctly against Homebrew installed deps for me on the latest Sierra.

Also. The issue I mentioned earlier about prompt not correctly rendering is fixed when I set my terminal type to xterm-256color instead of xterm-kitty.

from kitty.

kitty now builds and runs on my OS X machine -- it does not render any characters, which is likely some OpenGL bug or the other, which will need investigation.

from kitty.

It builds AND renders characters on OSX for me!

from kitty.

Where is your kitty.conf located. IIRC the default location on OSX is ~/Library/Preferences/kitty/kitty.conf if it is not there then use the --config option to specify its location

from kitty.

Yeah, this would be caused by this commit: fa15b2d

from kitty.

@shkm FYI kitty now builds against brew installed python3/glfw on Travis so it should be trivial to create a brew package for it.

from kitty.

Just want to thank @wezzynl. I was having issues with kitty and setting TERM completely fixed them for me (zsh-syntax-highlighting, tmux, ncurses apps like ncdu, newsbeuter, and anything else that didn't like TERM set to xterm-kitty).

from kitty.

Setting TERM in ~/Library/Preferences/kitty/kitty.conf works as expected. I did not understand that the problems I was experiencing related to TERM setting. This was user error. @wezzynl 's comment reminded me to check TERM value. iTerm2 uses "Profiles" to set TERM values so I didn't think of this setting in kitty.conf.

Thank you for making kitty.

from kitty.

This commit should fix the issue of the terminfo file not being picked up on OSX: 3cbb0b2

from kitty.

Here's a record of my OSX build attempt:

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)

I deleted the , '-l' + lib from setup.py because otherwise it errors with: ld: library not found for -lPython.framework/Versions/3.5/Python.

from kitty.

I already committed code to handle that issue, see #2

from kitty.

Ok, I'm getting further now. I think your fix helped, thanks.

It also turns out homebrew only has glew version 1.3, so I installed version 2 with:

wget https://sourceforge.net/projects/glew/files/glew/2.0.0/glew-2.0.0.tgz/download
mv download glew.tgz
tar xzvf glew.tgz
cd glew-2.0.0/
make
sudo make install

And now running python3 setup.py build produces this strange error:

glew >= 2.0.0 is required, found version: 2.0.0

from kitty.

I guess pkg-config --atleast-version=2 glew is not working on OS X? I suppose it could be replaced by parsing the output of pkg-config --version manually on os x.

from kitty.

Committed code to parse the version manually.

from kitty.

kitty now builds on OS X in Travis and all tests pass. A simple script to install the dependencies needed by kitty to build:

#!/bin/sh
export SWBASE=/Users/Shared/buildbot/sw 
export SW=$SWBASE/sw 

mkdir -p $SW && \
curl https://download.calibre-ebook.com/travis/kitty/osx.tar.xz | tar xJ -C $SW

This will install the deps into /Users/Shared/buildbot/sw (unfortunately, for technical reasons the path cannot be changed). Once this is done, you can build kitty itself with:

/Users/Shared/buildbot/sw/sw/bin/python3 setup.py build

Run kitty after building completes with:

/Users/Shared/buildbot/sw/sw/bin/python3 .

from kitty.

Finished replacing fontconfig+freetype with OS X native APIs. This has had only the most rudimentary of testing, so YMMV

from kitty.

Cool! I got it to build and run, and crash:

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_GUARD
Exception Codes:       0x4000000100000004, 0x00007fff8d32d2a8

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fffa03b383a close + 10
1   org.python.python             	0x00000001058062f7 os_closerange + 87
2   org.python.python             	0x0000000105736621 _PyCFunction_FastCallDict + 497
3   org.python.python             	0x00000001057b8327 call_function + 439
4   org.python.python             	0x00000001057b4b02 _PyEval_EvalFrameDefault + 27346
5   org.python.python             	0x00000001057b958d fast_function + 381
6   org.python.python             	0x00000001057b8301 call_function + 401
7   org.python.python             	0x00000001057b4b02 _PyEval_EvalFrameDefault + 27346
8   org.python.python             	0x00000001057b8d8f _PyEval_EvalCodeWithName + 2447
9   org.python.python             	0x00000001057adf74 PyEval_EvalCode + 100

This looks like it's something in OSX that detects an improperly-closed file descriptor: http://stackoverflow.com/questions/32429431/exc-guard-exception

from kitty.

Hmm, closerange is used in the forked process to ensure that no file descriptors other than the stdout/strdin/stderr are open. I'm assuming that some OS X system library is opening other file descriptors. Not sure what the solution for that is.

from kitty.

I disabled closerange on OS X -- see if it helps.

from kitty.

Nope, getting the same error.

from kitty.

One more place closerange() was called, although if the code has reached there it means something else went wrong earlier. There should be something printed to stderr (in any cae I have disabled that closerange() as well.

from kitty.

Glad to hear it!

I only have an ancient OS X mac mini which I keep around for building calibre -- so it's likely some OpenGL function is failing there that works on newer machines. Hopefully it works for most people.

from kitty.

This is working for me on OS X 10.11.6 using your bash script. Thank you, it looks very nice.

from kitty.

Cool, if it works for most people, I'll just forget about wasting time on figuring out the problem on my mini and just package it up into a dmg for easy installation. Fortunately, that is easy to do since I can re-use the build infrastructure I already have for calibre :) So those of you that want to run it on OS X please try it out and let me know if it works.

from kitty.

Alternatively / additionally, a brew (cask) formula would be great.

from kitty.

I'm not going to get into the game of creating packages for the various distro systems, on linux or OS X. However, I just committed some code to make the linux-package work on OS X as well. So now all that a creator of an OS X package has to do is (in psedo-code)

install dependencies: python >= 3.5, glfw >= 3.2
python3 setup.py linux-package
cp -ra linux-package/* ${installation_prefix}/

Where installation_prefix would be whatever the package system uses (/usr/local I suppose). Then run kitty with ${installation_prefix}/bin/kitty

See for example the ARCH kitty package https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=kitty-git

from kitty.

I also got it running on macOS Sierra (10.12.2). I run on a Retina MacBook Pro and it looks like the rendering is not Retina. Fonts look a bit blocky/fuzzy.

from kitty.

Hmm, hard to say as I cannot even get character rendering working on my ancient mac mini, let alone Retina! But, the first thing to check is if glfw is reporting the correct DPI, like this

kitty -c "from kitty.utils import *; from kitty.fast_data_types import *; glfw_init(); print(get_dpi())"

from kitty.

I can say that high dpi works fine on linux, where I use a 4K monitor (this was one of my motivations for developing kitty).

from kitty.

I am using MacBook Pro (Retina, 15-inch, Mid 2015) with 10.11.6 and the text looks great if a bit small. Kitty will not respond to font size changes I make to my local kitty.conf. I can successfully adjust font size by editing kovidgoyal/kitty/kitty.conf directly.

from kitty.

Output from kitty -c "from kitty.utils import *; from kitty.fast_data_types import *; glfw_init(); print(get_dpi())" is:

{'physical': (129.30909729003906, 129.4660186767578), 'logical': (129.30909729003906, 129.4660186767578)}

It seems however that the issue fixes itself if I first resize the window.. The buffer inside will start to flicker and turn red. When I then maximize the window, a couple of seconds later text re-appears and then looks correct. Before the resizing, the font is also smaller and seems like it's stretched horizontally.

Not sure if this is related to the rendering issue, but I use zsh and a themed "powerline" promt which seems to screw with the rendering. I get two prompts (it renders it twice) and when I type it'll render characters twice or even three times. When I execute bash which has just a simple prompt, that problem disappears.

from kitty.

I can confirm that the resolution increased in the newest git. In my old screenshot from git 2 days ago, each kitty pixel took up 4 of my macbook's retina pixels.

But now, everything rendered in the window uses retina pixels. Check it out, and notice that, compared to the old screenshot, the text is now smaller in comparison to the menubar:

from kitty.

Awesome work, @kovidgoyal! I'll take a look if I find some time and no one has done it yet.

from kitty.

It's odd that you need to set TERM -- kitty sets the TERMINFO env var to point to the terminfo file for xterm-kitty

Does the OS X version of terminfo not support TERMINFO env vars? On linux, zsh syntax highlighting, tig, vim, tmux etc all work fine with TERMINFO=/path/to/kitty/terminfo TERM=xterm-kitty

Maybe if you copied over the terminfo file into /usr/share/terminfo it would work without needing to set TERM.

from kitty.

The point is you should not need to change TERM at all, because kitty comes with a terminfo file of its own. But apparently, on OS X, ncurses/terminfo does not honor the TERMINFO environment variable. So run this instead,

tic /path/to/kitty/terminfo/kitty.terminfo

that will generate the terminfo database for kitty in ~/.terminfo and then you should not need to change TERM.

from kitty.

I can confirm this change worked as expected (thank you). Tmux, however, refuses to start unless I specify TERM to xterm-256color in kitty.conf. I don't view this as a problem per se, just sharing the information in case it is useful to anyone.

from kitty.

It's been a long time since I used tmux, but I vaguely recall it used to have a hard-coded set of acceptable TERM values, maybe that is the issue.

from kitty.

Closing this issue since I have now made a kitty .dmg available on the releases page.

from kitty.