【Mac】ユニバーサルコントロール / ディスプレイ が頻繁に途切れる ときの対処法

一つのキーボードで複数の Mac を操作し、ディスプレイも行き来できる「ユニバーサルコントロール」。

便利なのだが、頻繁に途切れると、逆にイラッとする。

👉 ユニバーサルコントロールが時々切れる - Apple コミュニティ hatena-bookmark
👉 ユニバーサルコントロールがすぐ切れ、再設定しても、なかなか安定しない - Apple コミュニティ hatena-bookmark
👉 「キーボードとマウスをリンク」が頻繁に切れる- Apple コミュニティ hatena-bookmark
👉 ユニバーサルコントロールでマウスを他のデバイスを行き来できますが、戻ってこれなくなる現象がでていて困っています - Apple コミュニティ hatena-bookmark
👉 iMac のユニバーサルコントロールを接続する候補として MacBook Pro が表示されず、接続できない状況が頻繁に生じます - Apple コミュニティ hatena-bookmark

Apple 公式フォーラムにも多数のコメントが上がってます。

 

🧑🏻‍💻 途切れたときの再接続方法

「設定」から「ディスプレイ」を開く と再接続されます。

開いたら何もせずに、接続を確認できたらそのまま閉じるだけです。

 

🧑🏻‍💻 ショートカットに入れておくと便利

結構不安定で、頻繁に切断されるので。

いちいち、切れるたびに「設定」-「ディスプレイ」と開くのもだるい。

コマンドラインなら、「『設定』-『ディスプレイ』を開く」の動作は、


open "x-apple.systempreferences:com.apple.Displays-Settings.extension"

なので、ショートカットに入れておくと簡単に接続できて便利です。

ショートカットのコンポーネントとしては、

Scripting の

「Run AppleScript」か「Run Shell Script」か

Web の

「Open URLs」

でいけそうです。

などの詳細は以下より。

👉 【便利】Mac パスワードマネージャー を メニューバーのショートカット や コマンドラインから開く方法 hatena-bookmark

 

🧑🏻‍💻 まとめ

以下のようなショートカットにしておきます。

開いて、3秒待ってから、閉じます。


【Xcode】ローカルと GitHub のソース管理連携設定

GitHub で久々に新規にリポジトリ作成してみたら、

もしかして、表示されなくなりました? こういうスクリプト。


Quick setup - if you've done this kind of thing before
https://github.com/your-account/sample.git


// ... or create a new repository on the command line

echo "# sample" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/your-account/sample.git
pit push -u origin main


// ... or push an existing repository from the command line

git remote add origin https://github.com/your-account/sample.git
git branch -M main
git push -u orign main

👉 Github Quick setup — if you’ve done this kind of thing before hatena-bookmark

困ったので以下のやり方でやったらいけた。

👉 XcodeとGitHubの連携方法 #macOS - Qiita hatena-bookmark

ローカルにプロジェクトのソースはある。として、

そこからの「連携」の手順を最小限で覚えておく。

Control + クリック、かまたは 右クリックから


「New "PROJECT-NAME" Remote...」 で新規作成

で、リモート側(GitHub側)のリポジトリを作成して連携できる。

リモート側(GitHub側)にすでに作成済みの場合は、


「Add Existing Remote...」で既存リモートに接続

と選択すれば、あとは流れで分かる。

GUIからのキーバインド的なやつ。知らんと見つけるのつらいので書いておこうとな。

👉 Configuring your Xcode project to use source control | Apple Developer Documentation hatena-bookmark

続いて.gitignore はこちら。



【macOS】 時代遅れのアプリ配布形式なのか「dmg」vs「zip」

こういう記事を見かけて。

Having a wrapper just to tell you "please drag the app to /Applications" feels like an outdated practice to me.

「アプリを Applications フォルダ にドラッグしてください」とだけ伝えるラッパーがあるのは、時代遅れのやり方のように思います。

かなり同感できるので2つの形式の違いを調べることにしました。

そもそも、ユーザー側から見ると、今のダウンロードな時代に、

ディスクイメージのマウントとかイジェクトとかも分かりづらいのではないかと思ってます。

その他、pkg 形式とか Homebrew とかの話はここでは無視。

 

🤔 Chrome をインストールする場合の手順 ( dmg 形式 )

その時の手順の流れは、


1. .dmgファイルをダウンロードし、
2. ダウンロードしたフォルダを開き、
3. .dmgファイルをマウントし、
3. 2つ目のフォルダーを開くか、サイドバーをオンにし、
4. .app フォルダをアプリケーションフォルダにドラッグし、
5. マウントされた .dmgファイルをイジェクトし、
6. ダウンロードした .dmg ファイルをゴミ箱に捨てる。

となります。

なんか良く考えたら、だるい !!

 

🤔 VSCode をインストールする場合 ( zip 形式 )

手順。


1. .zipをダウンロードして解凍し、
2. ダウンロードしたフォルダを開き、
3. .app フォルダをアプリケーションフォルダにドラッグします。

簡単で良い !!

 

🤔 有名アプリはどっちの形式なのか


dmg 形式
- Chrome
- Firefox
- Gimp
- VLC
- IINA
- LibreOffice
- Keka
- WhatsApp
- Skype


app 形式
- Visual Studio Code
- Telegram
- iStat Menus
- Plex Media Server

dmg 形式のほうが多いです。

 

🤔 みんなの意見

いろいろ言っております。

最終的には、ソフトウェアを .dmg ファイルとして配布するか .zip ファイルとして配布するかの選択は、開発者の好みと、アプリケーションとそのユーザーの特定のニーズによって決まります。

Apple は単純に ZIP 形式を活用することもできたが、そうしないことを選択した。Apple は独自の歴史があるため、一般的に独自の方法で独自のことを行っている。それはそれでよいことだ。Apple が採用しているモデルには利点があり、その利点はより一般的なメカニズムを使用して別の方法で構築することもできたが、物事はそのままでいることもある。

DMG を使用すると、インストール エクスペリエンスが向上します。DMG に背景画像を設定したり、利用規約に同意するための EULA を提供したりできます。「インストールするにはここにドラッグしてください」などの内容の DMG を開くと、実際には背景画像とアプリケーション フォルダーのエイリアスが表示されます。DMG は通常、読み取り専用として配布されるため、ユーザーはアーカイブして後で使用できるように保存し、アプリケーション フォルダーに簡単にドラッグできます。DMG は、ソフトウェア ディスクを購入してコンピューターに挿入し、デスクトップにマウントするエクスペリエンスを模倣しています。DMG には、PKG ファイルまたは prefPane ファイル (設定ベースのアプリ インストーラー) が含まれる場合があり、これらは単独で配布できます。ただし、DMG のカスタマイズ機能は、視覚的なエクスペリエンスをユーザーにアピールしたい開発者にとって魅力的です。

DMG を生成するのがもっと複​​雑でした。なぜなら、DMG を作成するための簡単な開発者スクリプトがなかったからです。誰もが DMG を使用していましたが、今ではスクリプトがあるところでは zip ファイルに移行しています。これもまた歴史の皮肉です。

好みの問題か、.dmg ファイルの作成方法がわからないということだと思います。

ls(1) コマンドを使用してコマンドラインから確認すると、.app ファイルは実際にはファイルではなくディレクトリであることがわかります。したがって、.app ファイルが配布されることは決してありません。それらは何かにアーカイブする必要があります。

.app はファイルではなく、ファイルが入ったディレクトリです。一般的なファイル転送プロトコルで送信したい場合は、そのディレクトリをファイルに変換する必要があります。2 つの明らかな選択肢は、zip ファイルとディスク イメージです。

zip ファイルはシンプルで、ダウンロード フォルダから解凍したアプリをアプリケーション フォルダにコピーするだけです。ただし、ディスク イメージにはいくつかの利点があります。ユーザーにライセンスへの同意を求めるように作成したり、Finder ウィンドウにイメージ背景の形式でブランドを追加したり、複数の部分から成るインストーラを簡単に配置したりできます。

などなど...。

👉 Why are most MacOS applications distributed as .dmg files rather than .zip? - Quora hatena-bookmark

 

🤔 まとめ

いきなりまとめます。

dmg 形式の利点として、


- 「アプリを Applications フォルダ にドラッグしてください」と表示
- カスタム背景
- ライセンス契約、リリースノートの追加

dmg 形式のほうができることが少し多いようです。

しかし、作成手順が面倒なので、

環境に合わせて、以下のツールなどを使うと良さげです。

👉 create-dmg/create-dmg: A shell script to build fancy DMGs hatena-bookmark
👉 create-dmg — Homebrew Formulae hatena-bookmark
👉 dmgbuild · PyPI hatena-bookmark
👉 sindresorhus/create-dmg: Create a good-looking DMG for your macOS app in seconds hatena-bookmark
👉 LinusU/node-appdmg: 💾 Generate your app dmgs hatena-bookmark

ひとつ使って簡単に作成してみました。


まあ、dmg 形式にしとくのが無難なんでしょうね。

 

🤔 参考

以上、以下の issues を見ながらのエントリーでした。

👉 [macOS] Use Drag to Install idiom in published DMG releases · Issue #4062 · transmission/transmission hatena-bookmark

👉 Use .app bundle instead of .dmg file for macOS distribution · Issue #6783 · transmission/transmission hatena-bookmark