search

IgKh / katvan

A bare-bones editor for Typst files, with a bias for Right-to-Left editing
GNU General Public License v3.0
35 stars 3 forks source link

macOS Support #4

Open yonatankremer opened 5 months ago

yonatankremer commented 5 months ago

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 commented 5 months ago

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 commented 2 months ago

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

yonatankremer commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

IgKh commented 1 month ago

The following macOS specific fixes were done so far:

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 commented 1 month ago

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.

yonatanmgr commented 3 weeks ago

First of all, thank you for your effort with Katvan! I tried installing on MacOS with arm64 architecture - everything worked fine until running cmake --build build -t install -j which threw this error: c++: error: linker command failed with exit code 1 (use -v to see invocation) along with a bunch of errors related to the architecture not being supported. Is there any way to make the installation happen in arm based MacOS? @IgKh

IgKh commented 3 weeks ago

Hi @yonatanmgr it definitely works on ARM, since I developed the port on a M2 machine. The extra "bunch of errors related to the architecture not being supported" are probably the interesting part, can you post the entire build output to a pastebin/gist or something and link it here? Thanks.