macOS Support

[yonatankremer]

I've been using typst for university for a few months with the vscode extension. Only major issue so far is editing rtl text doesn't seem to be natively supported in vscode. If it is nicer on your app, would love to see a macos version, or some aspects of it as a vscode extension for editing rtl text!

[IgKh]

Hi!

I'll address the VSCode bit first, as it is unclear as to what aspects exactly could be made into an extension. The things that give typing RTL text, especially when interlaced with math notation, "correct" feeling in my opinion and experience are:

1. Correctly applying the Unicode BiDi algorithm within a single directionality run.
2. Giving each paragraph / line its "correct" base direction, so different directionality runs in the same line are properly arranged (this is not just aligning RTL paragraphs to the right, in fact visual alignment is the least important aspect of it).
3. Isolating sequences of math (which consists of mostly characters with nuetral directionality according to the Unicode standard) into a separate directionality run so that surrounding RTL text doesn't "bleed in".
4. Logical cursor movements, so arrow keys and keys like Home and End work as expected regardless of the directionality run the cursor is placed on.

All of those are things that the text layout engine which lies at the base of the editor have to support. (1) and (4) are typically obtained "for free" from any underlying infrastructure written in this century, but (2) and (3) - not so much, and code editors typically don't want the tradeoffs involved. This is true in particular for Monaco (VSCode's text editor control), with its' developers stating it as a non-goal. I really don't think something like that can be taped over with an extension, and everything else doesn't really matter if the basic feel isn't there.

As for macOS support, I don't own a Mac nor have continuous access to one, so I personally don't need a macOS port and can't really develop one. Qt does support macOS natively, and Katvan doesn't use any platform specific libraries, so in theory it should compile and run as-is on macOS. The integration of it will likely be somewhat poor (things like file associations, dock icon, menu arrangement, spell checking dictionary locations, etc need some work to get right). If you'd like, please try building it and see if it does build, and if the experience is tolerable for you.

Thanks!

[yonatankremer]

I've been trying to run the windows executable instead using whisky/wine with windows 10/11 without success. Any idea why?

[yonatankremer]

update: I finally got it to build. all that was needed is to set the libarchive module path manually to the according location - opt/homebrew/Cellar/libarchive/3.7.4/include.
would be nice if you'd add an OS check, and if it's mac, go for this directory. I know 0 cmake, so this wasn't too fun of a process :P. anyway, thank you! Very likely I'll work with it from now on. I'm kind of a programming newbie, so it isn't too likely I'll be able to help with development, at least not without a few weeks of learning first. I am though willing to support in any other way you need. I am likely to study for a math BA, and a tool like this will be very helpful, well, as long as I study in Israel...

[IgKh]

That's great!

I've updated the CMake build to look for libarchive via homebrew, and added a macOS build to the CI to ensure that it keeps building going forward.

As far as help is concerned - since I'm not a mac user, and don't really know the ins and outs of macOS, the most valuable thing you can help with is pointing out anywhere that functionality seems broken, or where Katvan feels very out of place visually or behavior wise (some is unavoidable, given that it is a Qt application and all).

From a brief inspection I already see that there is a lot of work to do - no dock Icon, menus are unbalanced, colors contrast poorly in dark mode, spell checker doesn't work, etc etc. It will take some time to work that out, and there is surely more that it I just can't notice.

[yonatankremer]

Thank you! Yes, it's far from perfect. I will help.

[IgKh]

The following macOS specific fixes were done so far:

• Dock icon
• Icons removed from menus, and using system icons (SF Symbols) in all other places
• Consistent application of color scheme
• Make Windows-style direction override keys work (Ctrl + L/R Shift, and it is actual Ctrl not Cmd)
• Use the system spell checker
• The build system produces an application bundle that can be dragged to the local Applications

There are still two bigger gaps that I'm aware of:

1. Visually, the tool buttons in the status bar and find bar look pretty off. The dock widget headers aren't too hot either.

2. Katvan is built around the typical Linux/Windows model for SDI apps of 1 process = 1 main window = 1 document, but macOS has a 1 process = N windows = N documents model. Finder is very insistent on not allowing more than one instance of the application, which means that you can only work on one file at a time - not great. Implementing the macOS model isn't too hard by itself, but supporting both models is quite hard and is a very disruptive refactor.

The latter means the current approach is a bit of a dead end, and additional Finder integration (like a file type handler) isn't all that meaningful right now. Longer term, a macOS port of Katvan needs a completely separate native Cocoa shell into which the business-end (editor component, previewer) are embedded. But this is a large investment, and as noted above I'm not a Mac user and would prefer to focus on other things first.

So for now, I think this will be about as good as it will get - not great, but should be workable (and there is always the open -n -a workaround).

I'll make a release this week, and I would appreciate if @yonatankremer (or any other interested party) could check it out and see if there are other low hanging fruit that can be tackled within the current framework.

[yonatankremer]

thank you. I'll test it for sure, will let you know of anything wrong.

first update: compiled using the script in the readme just fine.