iPad Air M2 und Apple Pencil (der erste)

Apple selbst sagt, dass der erste Apple Pencil mit dem aktuellen iPad Air M2 inkompatibel ist. Man könnte meinen, dass diese Aussage eher daher kommt, weil Apple vielleicht doch lieber neue Hardware verkaufen möchte, denn mit ein wenig Trickserei funktioniert dieser auch immer noch, wenn auch nicht so angenehm, wie ein neuer.

Da das aktuelle iPad keinen Lightning-Anschluss mehr hat und stattdessen auf USB-C setzt, kann der Stift nicht direkt am Gerät geladen werden. Abhilfe schaffen hier Adapter, die man für ein paar Euro kaufen kann.

Lightning-auf-USB-C-Adapter

Ist der Stift geladen, benötigt man noch eine Software auf dem iPad: LightBlue. Mit dieser ist es möglich, den Stift via Bluetooth zu finden und zu koppeln. Wichtig: Der Stift wurde bei mir nicht erkannt bzw. gekoppelt, wenn er eingesteckt war.

LightBlue-Screenshot

Also:

  1. Stift ausstecken
  2. LightBlue starten
  3. Stift aus der Liste aussuchen
  4. Auf „connect“ klicken (der Kopplungscode lautet 1234)
  5. Stift funktioniert

Allerdings gibt es bei mir ein Problem: Immer, wenn ich den Stift lade, ist die Bluetooth-Verbindung „weg“. Der Stift wird, manchmal, dann noch über LightBlue angezeigt, eine Koppelung ist aber nicht möglich. Manchmal erscheint der Stift aber auch überhaupt nicht. Die Lösung, die bei mir funktioniert:

  1. Einstellungen -> Bluetooth -> Apple Pencil entkoppeln
  2. LightBlue starten
  3. Stift aus der Liste aussuchen
  4. Auf „connect“ klicken (der Kopplungscode lautet 1234)
  5. Stift funktioniert

Das ist natürlich nervig, aber für jemanden, der den Stift nur selten nutzt, ein gangbarer Weg, ohne 100 Euro oder mehr für einen neuen Stift auszugeben.

Affinity Produkte in Version 1.x stürzen beim Starten unter macOS Sonoma ab

Wer wie ich gerne die Produkte von Affinity nutzt, also

hat mitunter nach dem Upgrade auf macOS Sonoma das Problem, dass diese direkt beim Start abstürzen.

Affinity Photo Screenshot

Auf dieser Website „https://forum.affinity.serif.com/index.php?/topic/192499-known-issue-affinity-v1-apps-crash-on-launch-when-using-intelrosetta-on-macos-sonoma-with-light-ui-style/“ wird das Problem auch beschrieben und gelöst. Es liegt wohl an einem Problem des eingstellten UI-Stiels. Sofern dieser auf „Light UI“ eingestellt ist, stürzt die Software ab. Das könnte auch der Grund dafür sein, dass das Programm auf meinem anderen Mac funktioniert, denn dort ist das Default-UI eingestellt, weswegen ich verwundert war.

Das Problem ist laut Website einfach zu lösen, bei mir hat es direkt funktioniert:

  1. Terminal öffnen
  2. Alte Konfigurationen löschen
    • defaults delete com.seriflabs.affinityphoto (base)
    • defaults delete com.seriflabs.affinitydesigner (base)
    • defaults delete com.seriflabs.affinitypublisher
  3. Affinity Produkte starten

Extra-Mouse-Buttons unter macOS mit Mac Mouse Fix konfigurieren

Ich benutze Trackballs jetzt seit 2009. Bisher hatte ich immer zu Logitech gegriffen, die Qualität von Logitech ist allerdings, meiner Meinung nach, stark verbesserungswürdig. Aus Interesse griff ich jetzt zu einer anderen Firma, die günstige Trackballs herstellt. Ich erwartete nichts, wurde aber sehr positiv überrascht. Für gut 36 Euro bietet die Firma nulea günstige Trackballs an, die vergleichbar mit Logitech Ergo 575 sind. Sie bieten allerdings mehr. Sie haben einen integrierten Akku, bieten eine DPI-Auswahl als Hardwarebutton und auch zwei Bluetooth-Kanäle.

nulea Trackball

Genauso wie der Logitech Trackball, hat der Trackball von nulea zwei Seitentasten. Die sind eigentlich für „vor“ und „zurück“ im Browser. Ich belege sie aber gerne mit Exposé bei macOS. Das ging so aber leider nicht, da macOS hier nichts anbietet und nulea keine Treiber bereit stellt.

Gefunden habe ich Mac Mouse Fix, ein kostenloses Programm, mit dem sich Fremdmäuse und -trackballs einfach konfigurieren lassen. Vielleicht hilft es dem ein oder anderen ja.

Mac Mouse Fix

Ein interessanter Fehler beim Testen von Software

In der Firma, in der ich arbeite, ist mir ein Malheur passiert, und zwar beim Testen der von mir geschriebenen Software. Ich will (vielleicht darf) ich keine Details verraten, aber es geht um ein Programm, welches ein anderes Programm startet, überwacht und beendet. Nichts Großes, nichts Kompliziertes. Eine Sache muss man aber wissen: das Programm, an dem ich arbeite und das Programm, dass von meinem gestartet wird, soll auf macOS arm64 und macOS amd64 laufen und ist keine Fat-Binary, was bedeutet, dass es für die jeweilige Plattform immer ein Bundle gibt.

Jetzt ging es zum Glück nur um eine Testversion, die ich meinen Kollegen zum Ausprobieren geben wollte. Ich packte mein Programm also, zusammen mit dem Fremdprogramm. Einmal für macOS amd64, einmal für macOS arm64 (und noch weitere Plattformen). Faul, wie ich bin, hatte ich dafür ein Script geschrieben. Leider habe ich nicht weit genug automatisiert, denn hier passierte das Problem: Ich packte mein Programm für amd64 und das Fremdprogramm für arm64. Bevor ich meine Software zum Testen herausgebe, probiere ich diese immer einmal aus, zumindest im kleinen Rahmen. Eine CI-CD-Pipeline gab es in dem frühen Entwicklungsstadium leider noch nicht (Das ist ein Fehler! Kümmert euch direkt darum!). Jetzt hätte das Problem beim Testen auffallen müssen, aber hier beging ich den entscheidenden großen Fehler in der gesamten, sehr suboptimalen Kette: Ich probierte die arm64 und die amd64 meine Software und der Fremdsoftware nur auf meiner arm64-macOS-VM aus.

Wer aufgepasst hat, kann sich sicher denken, was jetzt passiert ist: Da Rosetta 2 lief, startete sie natürlich mein amd64-Programm und mein amd64-Programm startete das arm64-Fremdprogramm, ohne, dass ich was von einem Fehler mitbekam.

Ich lieferte natürlich die amd64-Version aus und es kam, wie es kommen musste: bei den Kollegen mit amd64 macOS funktionierte zwar mein Programm, das Fremdprogramm aber natürlich nicht, da es kein Rosetta-Äquivalent auf macOS amd64 gibt.

Dabei hatte ich den Fehler die ganze Zeit auf dem Schirm, denn mein Paketierungsscript lieferte Hinweise, wenn die Architektur der Fremdsoftware mit der Architektur meines Programms nicht zusammenpasst. Aber ein Hinweis lässt sich im Stress leicht übersehen. Hier hätte ich doch besser einen Abbruch eingebaut.

Was lernen wir daraus? Am Besten vollständig automatisierte Tests implementieren, aber wenn man für verschiedene Architekturen händisch testet, das dann auch direkt auf der jeweiligen Architektur durchführen und nicht in einer Emulation.

wxWidgets-Tutorial 007 – wxWidgets auf macOS – App-Bundles, Icons und Deployment

Dieses Video zeigt, wie ihr einfach App-Bundles inklusive Icons für eure wxWidgets-Programme auf macOS erstellen könnt. Ebenfalls gehe ich auf den dylibbundler ein, um ein einfache Deployment durchzuführen.

wxWidgets auf macOS - App-Bundles, Icons und Deployment
wxWidgets auf macOS – App-Bundles, Icons und Deployment

Hier noch die Dateien:

Info.plist

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleDevelopmentRegion</key>       <string>English</string>
	<key>CFBundleExecutable</key>              <string>wx</string>
	<key>CFBundleInfoDictionaryVersion</key>   <string>6.0</string>
	<key>CFBundlePackageType</key>             <string>APPL</string>
	<key>CSResourcesFileMapped</key>           <true/>
	
	<key>CFBundleVersion</key>                 <string>0.0.1</string>
	<key>CFBundleShortVersionString</key>      <string>0.0.1</string>
	
	<key>CFBundleName</key>                    <string>My wxApp</string>
	<key>CFBundleIconFile</key>                <string>AppIcon</string>
</dict>
</plist>

Script zum Kompilieren

#!/bin/sh

PROGRAM="wx"
BUNDLE="wx.app"
ICON="AppIcon.icns"

test -d "${BUNDLE}" && rm -Rf "${BUNDLE}"

c++ *.cpp -o wx -std=c++11 `/usr/local/Cellar/wxWidgets/3.2.1/bin/wx-config --libs --cppflags`
if [ $? == 0 ]
then
	mkdir -p "${BUNDLE}/Contents/MacOS"
	echo -n 'APPL????' > "${BUNDLE}/Contents/PkgInfo"
	mv "${PROGRAM}" "${BUNDLE}/Contents/MacOS/"
	cp "Info.plist" "${BUNDLE}/Contents/"

	mkdir -p "${BUNDLE}/Contents/Resources"
	cp "${ICON}" "${BUNDLE}/Contents/Resources/"

	mkdir "${BUNDLE}/Contents/lib" && ln -s "${BUNDLE}/Contents/lib" "${BUNDLE}/Contents/libs"
	/usr/local/Cellar/dylibbundler/1.0.4/bin/dylibbundler -od -b -x "${BUNDLE}/Contents/MacOS/${PROGRAM}" -d "${BUNDLE}/Contents/lib"
fi

Programmcode

#include <wx/wx.h>

class MyApp : public wxApp {

	public:
		bool OnInit();

};

class MyFrame : public wxFrame {

	public:
		MyFrame();

};

IMPLEMENT_APP(MyApp)

bool MyApp::OnInit() {
	MyFrame *myFrame = new MyFrame;
	myFrame->Show();
	SetTopWindow(myFrame);

	return true;
}

MyFrame::MyFrame() : wxFrame(nullptr, wxID_ANY, "Meine wx-App") {
	wxStaticText *staticText = new wxStaticText(this, wxID_ANY, "Hello World");
}

Hier geht es zum Video.

wxWidgets-Tutorial 006 – wxWidgets auf macOS installieren und ein erstes Beispielprojekt

In diesem Video zeige ich, wie man wxWidgets mit Hilfe von Homebrew auf macOS installieren kann.

wxWidgets auf macOS installieren und ein erstes Beispielprojekt
wxWidgets auf macOS installieren und ein erstes Beispielprojekt

Eine kurze Zusammenfassung:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install wxwidgets
brew install dylibbundler

So sieht es dann aus:

Beispielprojekt auf macOS
Beispielprojekt auf macOS

Hier noch der Programmcode zum Testen:

#include <wx/wx.h>

class MyApp : public wxApp {

	public:
		bool OnInit();

};

class MyFrame : public wxFrame {

	public:
		MyFrame();

};

IMPLEMENT_APP(MyApp)

bool MyApp::OnInit() {
	MyFrame *myFrame = new MyFrame;
	myFrame->Show();
	SetTopWindow(myFrame);

	return true;
}

MyFrame::MyFrame() : wxFrame(nullptr, wxID_ANY, "Meine wx-App") {
	wxStaticText *staticText = new wxStaticText(this, wxID_ANY, "Hello World");
}

Kompiliert wird das ganze via:

c++ *.cpp -o mywxapp -std=c++11 `/usr/local/Cellar/wxwidgets/3.2.0_1/bin/wx-config --libs --cppflags`

Wer wxWidgets auf macOS selbst kompilieren möchte, findet hier eine Anleitung.

Hier geht es zum Video.

Automatisch und halbautomatisch Software auf macOS aktualisieren

Ok, ich gebe zu, selbst nach Jahren … Dekaden … war das nicht auf meinem Schirm. Klar, ich habe HomeBrew und nutze es auch, einige Programme sind auch aus dem AppStore, aber was ist mit der ganzen „ich lade die Software herunter und installiere sie“-Software? Wie aktualisiere ich sie?

Natürlich: die meisten Programme bringen einen eigenen Updater mit. Man startet das Programm, und je nach Einstellung schaut es selbst nach, ob es ein Update gibt, lädt es und fragt nach, ob es installiert werden soll oder installiert sich dann automatisch beim Beenden und Neustarten. Doch was ist mit Software, die man nur selten oder fast nie startet?

In einem YouTube-Video sah ich „MacUpdater„. Das zwar nicht, wenn man es sinnvoll nutzen möchte, kostenlose, aber doch sehr kostengünstige Programm macht genau das: es zeigt an, welche Software installiert ist, kann sie entweder selbst aktualisieren oder zumindest das Installationsprogramm herunterladen und starten oder einen Hinweis darauf geben, dass man eine manuelle Update-Installation machen soll.

Oberfläche von MacUpdater
Oberfläche von MacUpdater

Ich habe mir die ca. 18 Euro teure Version gekauft, die ich auf bis zu vier Macs in meiner Familie installieren darf.

Vielleicht hilft der Tipp dem Ein oder Anderen. Ich bin auf jeden Fall recht begeistert.