标签: macOS

Mac 迁移指南

引言

苹果今年为 Mac 产品线带来了不少有意义的更新。适逢年末,不少人可能已经有了升级换新的计划。

但在享受新机带来的喜悦同时,还有一件不得不做的麻烦事——数据迁移。尽管听起来只是初始设置中的一个步骤,但数据迁移的效果很大程度上影响到新机的使用体验和之后的工作效率,因此须加重视。苹果官方有一些指导教程,包括出售、赠送或折抵 Mac 前应该执行的步骤,如何将内容迁移到一台新的 Mac 等,但都略嫌简略,不足以解决迁移过程中的很多常见疑问。

对此,本文准备结合自己几次迁移的经验,从可选途径、考虑因素和具体步骤等方面介绍在 Mac 间迁移数据的方法,希望能为有此需要的读者提供帮助。

由于本文较长,为查阅方便,文中涉及的关键步骤如下图所示(或下载 PDF 版):

一、可选途径

(一)使用「迁移助理」工具

作为系统内置和官方推荐的工具,迁移助理是大多数情况下最简单、效果最好的迁移方式

迁移助理
迁移助理

迁移助理的使用方式很多样:既可以作为初次开机时「设置助理」的一个步骤运行,也可以在完成初始设置、进入系统后单独运行;迁移数据的来源可以是另一台通过雷电、USB 或无线网络等方式连接的 Mac,也可以是外置磁盘上的 macOS 安装或时间机器备份。

但是,和大多数苹果系统的内置功能类似,迁移助理同样具有简洁度有余、灵活性和信息量不足的缺点。在迁移范围的选择上,除了少数几个语焉不详的选项,用户并没有太多定制的空间,迁移过程中显示的进度条和时间预测也基本属于娱乐性质。

此外,迁移助理能否成功运行有一定运气成分,在 MacRumors …

在 M1 芯片 Mac 上使用 Homebrew

Homebrew 是 Mac 上管理软件包的最实用工具之一。但截至目前,它还没有对搭载 Apple silicon 的新 Mac 机型完成适配。根据维护者在 GitHub 上发布的说明,Homebrew 正在积极适配新架构的过程中,但目前还面临一些较大障碍,如缺少基于 ARM 架构的持续集成框架、很多软件包依赖的框架或编译器(gogccqt)未适配等。

但是,Homebrew 目前在新 Mac 上仍然是可用的,并且已经发布了原生支持 ARM 架构的试验性版本。本文总结我在设置过程中探索出可行、相对实用的做法。

概括而言:

  • 在不同路径分别安装针对 X86 和 ARM 架构的两个 Homebrew 版本;
  • 优先使用 ARM 版 Homebrew

译文 | Marzipan 带来的期待

译者按:本文原题为《What to Expect From Marzipan》,是国外知名设计团队 Iconfactory 的博客文章。文章讨论了苹果预计将在今年 WWDC 上正式发布、用于将 iOS 应用迁移到 macOS 上的 Marzipan 框架,及其对开发者和设计师两个群体的潜在影响。文章指出,尽管 Marzipan 让从 iOS 到 macOS 的过渡看起来只是点开一个开关的功夫,但实际工作远没有那么简单。相反,优秀的应用必须针对 Mac 平台的键鼠操作、屏幕尺寸和多窗口等特性作出功能和设计上的适配,并考虑到更专业用户群体的需求。文章反复提及了苹果系统历史上的数次类似变迁,并对 Marzipan 在短期问题后的最终成功表达了乐观态度。文章最后以一段巧妙而应景的植入式广告结尾。

钟颖对译文的初稿提出了宝贵的专业意见,在此表示感谢。


今年的 WWDC 很显然会是不同寻常的一届。我们此前在本站写过关于黑暗模式的思考,现在该来谈谈即将走进 Mac 的 iOS 应用了。

我指的当然就是 …

挖掘 Safari 阅读列表的潜力

Safari 阅读列表是 macOS 和 iOS 上一个比较容易被忽视的功能。该功能最初出现在 2011 年的 OS X Lion 和 iOS 5 系统中,但除了在次年加入了离线缓存,它基本就在这八年间一成不变,与 Pocket、Instapaper 等专职的稍后读服务相比显得十分简陋。

我自己之前也很少使用阅读列表功能,而是用 Pinboard 结合 Instapaper 解决稍后读的需求。这套组合虽然总体让我满意,但也不是尽善尽美,最明显的不足就在于添加链接时的繁琐。特别是在那些没有分享按钮的界面,每添加一个链接都要经历长按链接—选择「分享」—点击应用图标三个步骤。在需要连续保存很多链接时(例如阅读 newsletter 或播客的 show notes),重复这套繁琐的步骤接近一种折磨。另外,Instapaper 的同步也受到 iOS 对后台进程的限制,在信号不好时添加的链接,往往需要事后手动刷新一次才能反映在其他设备上。

相比之下,作为系统自带功能,Safari 阅读列表具有第三方应用难以企及的特权。「添加到阅读列表」的选项几乎无处不在,并且总是处于第一级菜单的显著位置,新增链接在任何时候不会需要超过两次点击。不仅如此,阅读列表作为一个系统服务,可以始终保持后台运行,并且通过 iCloud 近乎即时地在各设备间同步。

发现了这些优点后,我在近几个月试着更多地利用 Safari 阅读列表。为了扬长避短,我主要在两种场景下使用这一功能:其一,将阅读列表作为暂存空间,用来处理一些不需要长久保存的页面;其二,将阅读列表作为第三方工具的「前端」,利用它保存链接时的便捷,然后通过脚本将其内容自动同步到其他稍后读服务。…

PDF 复制中的文字重复问题

前两天,编辑 @⽂⼑漢三 在 Slack 上发给我一个 PDF 文件,问我知不知道为什么从里面复制出的中文会出现「重字」现象。他还提到,这个问题只在用系统自带的预览 app 打开时会出现,用其他 PDF 阅读器复制文字是正常的。

用预览 app 复制出的「结巴」文字

文刀拿这个问题来问我,恐怕是因为我之前写过一篇解释 PDF 格式的文章,觉得我大概会知道答案。不过他其实高估了我的知识水平——我刚开始也不知道这是怎么回事。不过,经过一番搜索,我最终初步搞清楚了问题成因。因为这个问题涉及到一些很有意思的细节,这里把探索的过程写出来,供有类似疑问的朋友参考。


出现问题的 PDF 文档是由一篇少数派文章导出而得的。首先尝试复现问题:用预览 app 打开并随手复制一段,确实出现了很多重复的文字,看起来就像是「结巴」了一样,有一种莫名的喜感。换用 PDF Expert 打开再尝试复制,则没有这样的问题。

虽然不知道问题的具体成因,但根据经验,文字复制中的故障往往与编码有关,而 PDF 格式正是编码问题的大户。

我在之前的文章中提到,PDF 格式是「不识字」的。在显示文字时,阅读器只是机械地根据 PDF 语句的指令,将字体资源中特定码位的字形绘制在坐标指定的位置,而并不关心自己画出来的到底是什么字。只有在进行复制、搜索等操作时,PDF 才会根据内嵌的 CMap,将内部字体的编码和 Unicode 编码对应起来。因此,如果 CMap …

macOS Mojave 动态桌面功能探析

前不久推出正式版的 macOS 10.14 (Mojave),应该可以称为四年前的 Yosemite 以来,macOS 在用户界面上变化最大的一次更新。千呼万唤始出来的原生「黑暗模式」让人耳目一新,也引发了第三方应用的适配热潮。

相比之下,另一项用户界面的新功能——动态桌面(dynamic desktop)受到的关注则少得多。这是一项默认关闭的功能,启用方法是打开「系统偏好设置」>「桌面与屏幕保护程序」,从「动态桌面」中选择系统自带的两套壁纸之一。

新增的两套动态壁纸

显然,如此低调的功能很难引起用户的注意,大多数评测文章都选择将其一笔带过。苹果自己的态度似乎也是一样:在六月的 WWDC Keynote 演示中,Craig Federighi 留给动态桌面的台词只有一句话

Your desktop actually subtly changes throughout the day from morning, to afternoon, to evening. 你的桌面[背景]将随着一天从早上、到下午、再到晚上的推移而微妙地改变。

乍听起来,这确实并不稀奇,也没有任何技术门槛。随时间变化切换壁纸是很多桌面美化软件的基础功能,更别提十多年前的 Windows Vista 就已经原生支持视频壁纸了。

但问题实际上并不只是「按时间切换图片」

如何临时修改 macOS 应用程序的显示语言

一般情况下,应用程序的界面语言会和系统语言保持一致。但有些时候,我们也会希望临时换用一种不同的界面语言。例如,一些程序的中文翻译词不达意,有必要参考英文界面来确定功能的准确含义;又如,一些网页会强制按照浏览器语言显示不同版本,因此必须通过切换浏览器语言来控制网页语言。

问题是,并不是所有的应用程序都提供了切换界面语言的选项。事实上,大多数 macOS 的内建应用都没有这样的设置。如果每次遇到这种需求都去临时改变系统语言,未免过于耗时和麻烦。

这个问题可以通过终端命令来解决。macOS 允许在运行应用程序时向其传递特定参数,其中,-AppleLanguages 参数就是用来控制应用程序的语言的。例如:

# 以简体中文界面启动 Safari 浏览器
$ open -a /Applications/Safari.app --args -AppleLanguages '(zh-CN)' 

# 以英文界面启动 Pages
$ open -a /Applications/Pages.app --args -AppleLanguages '(en)'

如果想以其他语言启动某个应用程序,只需要修改上述命令最后的地区代码。其他一些常用的代码包括繁体中文(zh-TW)、日文(ja)、法文(fr)、德文(de)等。

要知道一个应用都支持哪些界面语言,可以在 …

根据电源连接状态自动切换默认浏览器

Safari 和 Chrome 是 macOS 平台上最主流的两个浏览器,如何在它们之间取舍也一直是热门话题。虽然两者性能、速度孰优孰劣并无定论,但 Safari 更加稳定省电、Chrome 在功能和扩展性上更优则是没有疑问的。因此,对于 MacBook 而言,用电池供电时使用 Safari 是更经济的选择,而连接电源时则可放心使用 Chrome,享受其丰富的扩展程序带来的便利。但显然,每次插拔电源后手动切换默认浏览器是十分麻烦的,如何将其自动化呢?

我们可以使用一款名为 ControlPlane 的免费工具来达成上述目的。该软件的机制非常类似于 IFTTT,即当检测到一定条件发生时,自动触发相应的操作。据此,前述需求实际上可以表述为:如果连接电源适配器,则将默认浏览器设置为 Chrome;如果拔下电源适配器,则将默认浏览器设置为 Safari。下面介绍如何利用这套机制实现文首提出的需求。

首先下载安装 ControlPlane。打开后,可以看到「通用」(General)、「情境」(Contexts)、「迹象」(Evidence Sources)、「规则」(Rules)、「动作」(Actions)、「高级」(Advanced)等选项卡。上述几个概念的逻辑关系是:当特定的「迹象」出现时,触发相应的「规则」;软件将据此判断电脑当前处于何种「情境」,从而执行与其关联的「动作」。

软件主界面

首先在「通用」(General)选项卡中,勾选「登录时启动 ControlPlane」(Start ControlPlane at login),允许其随系统自启。

然后,切换到「情境」(Contexts)选项卡。点击「+」,新建一个名为「Battery」的情境。

新建情境

接着,在「迹象」(Evidence Sources)选项卡中,勾选「连接的电源适配器」(Attached Power Adapter),允许将电源连接情况作为判断情境的标准。

允许将电源连接情况作为判断情境的标准

在「规则」(Rules)选项卡中,点击「+」>「添加『连接的电源适配器』规则…」(Add ‘Attached Power …

[macOS] 如何在全屏 App 或拥挤的桌面间便捷拖动文件

「拖动」是 macOS 图形界面操作的精华。但是,在很多情况下,拖动并不像我们希望的那样随心所欲。例如,在当前 app 处于全屏模式的情况下,如何将其他桌面上的文件拖动到该 app 中?在桌面堆满了窗口的时候,如何在桌面和众多 app 间互相拖动文件?在屏幕空间局促的 MacBook 上,这种问题显得尤为突出。

拥挤的 macOS 桌面

针对这种需求,市场上出现了大量充当拖动操作「中转站」作用的 app,如 Unclutter、Yoink、Dropzone 等。这些 app 的共同点在于,当检测到用户拖动文件时,会在屏幕边缘弹出一个容器;用户可以将文件先拖动到该容器中暂存起来,然后切换到目标 app 中,再将文件从这个「中转站」里拖到对应位置。

用 Dropzone 作拖动的中转站

这种方法固然能达到目的,却未免有些隔靴搔痒;何况,购买这些 app 也是一笔额外的成本。其实,macOS 已经提供了解决问题的全部工具,只要进行很少量的配置,就能一步到位地实现高效拖动文件的需求。

1. 在全屏 app、桌面和 Dock 间拖动文件

1.1 在全屏 app 和桌面间拖动文件

1.1.1 使用触摸板/鼠标

如果打开的桌面全屏 app 数量不多,或目标位置与当前桌面相邻,那么只靠触摸板或鼠标就能实现目的。以将桌面上的文件拖动到处于全屏状态的 Pages 中为例:

  1. 从另一个桌面上找到所需的文件并将其拖动到屏幕边缘,驻留一段时间;