Paint first appeared in 9front. The 9front license is reproduced in the related source files - the original repository is located at https://code.9front.org/hg/plan9front.

Fixes #98.

The only difference from the upscaled 16x16 is a one-pixel adjustment in the offset position, but this at least exercises setcursor2.

Using plain 'clang' does not work well for the new devdraw on macOS 10.14. But 'xcrun --sdk macosx clang' does work, for reasons no one understands. Hopefully this will be OK on all macOS systems.

This replaces the pixel-art scaling algorithm used for upscaling before. The results were not crisp enough to serve as everyday cursors.

Also add setcursor2, esetcursor2, and draw protocol encoding. Calls to the old setcursor, esetcursor create a 32x32 by pixel doubling when needed.

Add a new macOS cocoa screen, cocoa-screen-metal.m. Rewrite the macOS cocoa drawing code to use the builtin runloop, and use Metal to push pixels with CAMetalLayer. Remove all of the deprecated code, and simplify some of the logic. Modify mkwsysrules.sh such that the new code is used only when the system version is equal or higher than 10.14. Allow touch events to simulate mouse clicks: three finger tap for the middle mouse button; four finger tap for the 2-1 chord. Support Tresize. Scale 16x16 Cursor up to 32x32 with an EPX algorithm. Support macOS input sources including the basic dead keys and the advanced CJK input methods. Increase the communication buffers in cocoa-srv.c to allow more input, especially for long sentences prepared by the macOS input souces.

Both `upas/nfs` and `upas/smtp` call the currently broken `tlsClient()` from libsec. This commit copies a fix from upas/nfs into upas/smtp. In `imapdial()`, upas/nfs replaces a process call for tlsClient with `stunnel3` when not on Plan 9. upas/smtp calls tlsClient directly as a function, so imapdial was copied into mxdial.c as `smtpdial()`, and tlsClient+dial replaced with a call to smtpdial.

See https://plan9port-review.googlesource.com/c/plan9/+/1470 for discussion of the approach, especially Michael Stapleberg's comment: Note that chromium, firefox and others have tried this and then switched to using the Xft.dpi X resource, see e.g. https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/libgtk2ui/gtk2_ui.cc and especially http://sources.debian.net/src/gnome-settings-daemon/3.18.2-1/plugins/xsettings/gsd-xsettings-manager.c/?hl=824#L80 for some anecdata about why this approach doesn’t work out. The Xft.dpi resource is being set accurately by desktop environments (GNOME, KDE, …) and can easily be changed by users of niche window managers by editing ~/.Xresources. I suggest we check only Xft.dpi, without considering the DPI environment variable or the monitor width/height.

This seems to match Terminal. Fixes #145.