macOS build in here [1.11]

[gingerbeardman]

loose:

• 1.11 lite-osx.zip
  • now named lite-osx to prevent clashes during build, feel free to rename locally

lite.app + mac plugin:

• 1.11 lite.app.zip
  • only one extra plugin (macmodkeys) bundled
  • now quits with Cmd+Q

notes:

• both support macOS 10.8 upwards
• requires SDL2 to be installed
• see other issues for outstanding problems on macOS

my fork and branch with changes:

https://github.com/gingerbeardman/lite/tree/macos-build

I'm happy to do a new build with every release, if that helps the project.

[wq163]

dyld: Library not loaded: /usr/local/opt/sdl2/lib/libSDL2-2.0.0.dylib

[gingerbeardman]

@wq163 please make sure SDL2 is installed on your Mac.

You may want to use brew install SDL2 but there are other ways.

[brechtm]

I'm happy to do a new build with every release, if that helps the project.

Please consider providing a Homebrew cask if you can find the time.

[gingerbeardman]

Please consider providing a Homebrew cask if you can find the time.

Sorry, I do not support the homebrew project due to a past instance of them bullying users (myself included).

[brechtm]

Lovely to see a lightweight editor that may replace TextWrangler for me. Two obvious things that are still missing IMHO (not implying anyone should implement this):

• Use Cmd instead Ctrl of for shortcuts on Mac
• An application package so it can be started from Spotlight/Alfred

[rxi]

@brechtm Regarding your first bullet point there's a macmodkeys plugin in the plugins repo which remaps ctrl/alt to command/option. In another issue I suggested someone could maintain a "mac fork" for better integration with macOS (high DPI support, application packaging, macmodkeys plugin by default, up-to-date builds etc.), given I have no way to test on that platform myself and it seems to be a little more involved to accommodate for in contrast to other platforms.

Happy for this issue to remain open indefinitely if these builds are useful to people!

[brechtm]

I had a quick go at building an application bundle, but I'm not getting anywhere. I'm not sure, but I think the issue is related to signing the app bundle, which I'm not familiar with.

[gingerbeardman]

(unsigned) lite.app bundle above, includes macmodkeys and some other plugins, but note that you will have to force quit it.

Open it using right click menu to avoid some nags.

Not really an ideal long-term solution, just an experiment in packaging.

[brechtm]

(unsigned) lite.app bundle above, includes macmodkeys and some other plugins, but note that you will have to force quit it.

This has the same issue as the App bundle I created: You have macOS 10.13.6. The application requires macOS 10.14 or later.

Running lite from the command line works fine however. A message in Console.app triggered by launching lite.app made me believe this was related to the bundle missing a signature.

[gingerbeardman]

Hmm, min OS version is set in the app plist to 10.8.0 so the message must be coming from somewhere else. When does it appear? Try changing the app plist?

I am on 10.14 and built on there so the requirement may come from that.

[brechtm]

I am on 10.14 and built on there so the requirement may come from that.

I suspect this is the reason. This requirement must be encoded in the lite executable somehow, but it's only being checked when running it from an application bundle?

[brechtm]

The otool -l lite output might indicate this:

  platform macos
       sdk 10.14
     minos 10.14

[gingerbeardman]

Cool, in that case I need to figure out how to build against older SDK as part of a modified build.sh

[gingerbeardman]

OK, builds updated to support macOS 10.8 upwards

[gingerbeardman]

just updated the builds again

doing otool -l ./lite shows

Load command 9
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.8
      sdk 10.14

[brechtm]

@gingerbeardman Thanks! The app bundle is working on macOS 10.13.6 now. Including the macmodkeys plugins is a welcome addition as well.

[gingerbeardman]

Excellent!

[krisalyssa]

Can the macOS version be built from source in this repo, or is that version closed source?

[gingerbeardman]

Can the macOS version be built from source in this repo, or is that version closed source?

It builds from this repo source; I use a slightly modified build script to get 10.8+ compatibility and bundle more plugins.

[darkwark]

@gingerbeardman hey, can you please add 10.12 support for the lite.app+plugins? It currently requires 10.13 to run (the loose version works fine from the command line). Thank you!

[gingerbeardman]

done! I left a wrong version number in the app Info.plist

[darkwark]

done! I left a wrong version number in the app Info.plist

Awesome! Thank you!

[gingerbeardman]

Updated for 1.05, app now quits with Cmd+Q

[brechtm]

Another thing I noticed: Cmd+W will close the Lite windows instead of just the active tab. I think this requires removing the default Window>Close menu item. I haven't found a way to do this with SDL2, so we might need custom macOS code for this.

[andsve]

Another thing I noticed: Cmd+W will close the Lite windows instead of just the active tab. I think this requires removing the default Window>Close menu item. I haven't found a way to do this with SDL2, so we might need custom macOS code for this.

I have a macos fork for lite that also has some context and app menu extensions. Currently I set the app menu empty on init just to avoid Cmd+W closing the app. Haven't pushed these changes since I'm in the middle of other stuff, need to clean it up but I can share it once I do?

[gingerbeardman]

I'm not sure of the best way to proceed

Let's try my fork... for now.

[andsve]

I'm not sure of the best way to proceed

Let's try my fork... for now.

I’m not saying to switch fork, just that I have code on my branch that you could take to fix the Cmd+W/menu issue.

[gingerbeardman]

Thanks @andsve I'll take a look!

[rxi]

@gingerbeardman @andsve If either one of you (or anyone else) wants to take on the role of maintaining an "official" mac fork, let me know! I'd be happy to link to it from the main repo's readme -- it'd be good to establish a home for the mac-specific changes as they seem somewhat fragmented at the moment.

To clarify why I don't want the mac specific code integrated in the main project: it's code I can't run, can't test and can't build -- if someone submits a change I have no way of properly gauging the repercussions of it (does it break something else? does it even fix the issue?), it puts me in a position where I have to blindly merge pull requests of questionable quality. Alternatively those pull requests aren't even made, in which case there are lingering bugs in the parts of the codebase I can't run, and thus can't fix.

[gingerbeardman]

I need to figure out if I have the time to maintain a fork more than just building quickly once every so often.

[krisalyssa]

To clarify why I don't want the mac specific code integrated in the main project: it's code I can't run, can't test and can't build -- if someone submits a change I have no way of properly gauging the repercussions of it (does it break something else? does it even fix the issue?)

CircleCI, at least, offers CI builds on macOS, which means you get unit tests as well. Whether that's something lite currently has or can add, I don't know.

it puts me in a position where I have to blindly merge pull requests of questionable quality.

What if you adopted an official policy that PRs specific to a platform you can't build or test yourself need to be approved by at least one of a set of maintainers who can build or test on that platform? For instance, @gingerbeardman and @andsve appear to be both qualified and interested in macOS support for lite.

I would volunteer for that task myself, but I haven't downloaded or run lite yet since it's not clear to me that macOS is going to be supported by lite in the future. Sort of a catch-22, I realize.

[rxi]

What if you adopted an official policy that PRs specific to a platform you can't build or test yourself need to be approved by at least one of a set of maintainers who can build or test on that platform? For instance, @gingerbeardman and @andsve appear to be both qualified and interested in macOS support for lite.

This unfortunately results in the same problem: if the mac maintainer on the main repo no longer has time to contribute to the project it leaves me again in the position of having code I can't fix, run or test. In that case I'm stuck between the two bad choices of either leaving broken code in the project indefinitely, or stripping out all the macos stuff which puts us back at square one.

Additionally this stalls things like releases on the main repo as it now requires the cooperation of several people before one can happen.

Also note the work around to get highdpi rendering working on macos (a rewriting of the entire renderer) is a change I would be unwilling to bring into the main repo and as far as I know is the only way anyone has been able to get highdpi working on macos.

[andsve]

To clarify why I don't want the mac specific code integrated in the main project: it's code I can't run, can't test and can't build -- if someone submits a change I have no way of properly gauging the repercussions of it (does it break something else? does it even fix the issue?)

CircleCI, at least, offers CI builds on macOS, which means you get unit tests as well. Whether that's something lite currently has or can add, I don't know.

Good idea! I have GH workflows building a macos binary on my branch now, feels like it should be sufficient.

@rxi Totally understand, I also feels like the best way forward is to have a separate macos fork. The changes to the rendering isn't very nice, but sadly I haven't found a prettier workaround, maybe someone more familiar with SDL could give it a stab.

[gingerbeardman]

updated to 1.06

not yet had time to look at @andsve code

[wallabyway]

FYI. the build from @andsve has sharper text than the build from @gingerbeardman

[gingerbeardman]

@wallabyway

• see other issues for outstanding problems on macOS

[gingerbeardman]

updated for 1.07 (same caveats apply)

[gingerbeardman]

updated for 1.08 (same caveats apply)

[gingerbeardman]

updated for 1.09 (same caveats apply)

[gingerbeardman]

I noticed GitHub offers macOS runners through it's Action feature.

[gingerbeardman]

1.10 updated, same outstanding macOS issues

[andsve]

I noticed GitHub offers macOS runners through it's Action feature.

Yes, as I said above this is what I use on my fork+branch to get these builds: https://github.com/andsve/lite-macos/actions/runs/151367501

[wallabyway]

@andsve - any chance you could add the following changes to your build?

• add plugins/macmodkeys.lua (https://raw.githubusercontent.com/rxi/lite-plugins/master/plugins/macmodkeys.lua)
• change core/init.lua line 473 ... system.sleep(0.025); line 476 ... system.sleep(math.max(0.001, 1 / config.fps - elapsed))
• change core/view.lua, lines 127 & 128 self:move_towards(self.scroll, "x", self.scroll.to.x, 0.1) self:move_towards(self.scroll, "y", self.scroll.to.y, 0.1)

(this helps CPU idle, smoother wheel-scroll, and Mac keys )

Two Styling Tweaks:

• replace the font/monospace.ttf font with this one (monaco.ttf) https://github.com/todylu/monaco.ttf/blob/master/monaco.ttf?raw=true
• change core/config.lua: line15... config.line_height = 1.0

[gingerbeardman]

@wallabyway why not put those changes in a PR?

[gingerbeardman]

1.11 download above

[icedman]

Did you try an iOS build?. Would be interesting.

[pazos]

@rxi @andsve @gingerbeardman.

I'm interested in a mac build too. I would love to see the changes upstream but I do understand the point @rxi made.

The changes to the rendering isn't very nice, but sadly I haven't found a prettier workaround, maybe someone more familiar with SDL could give it a stab.

Not familiar at all with the render here, but sdl should take care of everything if NSHighResolutionCapable is set in Info.plist. To create an app bundle the code in @gingerbeardman branch is fine. If any I would like to build SDL as part of the program to avoid xcode commandline tools & brew dependencies.

[gingerbeardman]

I've only just got a retina external display, so now I can see what's wrong here.

With NSHighResolutionCapable = YES in the Info.plist I do not see any changes, the fonts sizing is OK, but the text is rendered in low-resolution.

Contrast the editor text with the window title:

[dubesoftware]

Please consider providing a Homebrew cask if you can find the time.

Sorry, I do not support the homebrew project due to a past instance of them bullying users (myself included).

Rather sad. This would help with smooth updates along with other packages instead of having disparate installation methods.

I just tried v1.11 and it won't install on macOS catalina.

[gingerbeardman]

@dubesoftware what's sad? those guys bullying me or my refusal to deal with them because of it? Either way, good luck with this.