Reading view

There are new articles available, click to refresh the page.

A brief history of icons, thumbnails and QuickLook

One of the novel features in the original Finder in Classic Mac OS was the use of distinctive icons for different types of document in an extensible scheme.

Every file had its type and creator codes, each consisting of four single-byte characters. The Desktop databases contained indexes to those, to enable the Finder to display the appropriate icon for a text document of type TEXT created by an app with the creator code of ttxt, SimpleText, for instance.

Apps provided a custom icon in their Resource fork for each type of document they supported. Periodically, those Desktop databases became broken, and documents lost their custom icons. The solution was to rebuild those Desktop databases from the data in each app’s Resources, a procedure that every Mac user became only too familiar with.

At some stage, perhaps in System 6 of 1988, or System 7 of 1991, document icons such as images could be displayed as miniatures or thumbnails instead. This was accomplished by apps creating that file’s thumbnail and saving it as an ICN# resource in the file’s Resource fork. Amazingly, this still works in Sequoia, where I pasted a prepared Resource fork into a Zip file to give it an inappropriate thumbnail.

qlthumbnail1

The raw Resource fork is shown below in xattred as a com.apple.ResourceFork extended attribute.

qlthumbnail2

Initially, Mac OS X continued a similar system, including custom thumbnails, until Apple introduced Quick Look in Mac OS X 10.5 Leopard, in 2007. This came with built-in support for a wide range of common document types, extending to QuickTime media including audio and video. One curious omission at first was that animated GIFs weren’t supported as animations until OS X 10.7.

Display of Thumbnails used the QuickLook framework documented here. This enabled third-parties to extend coverage to their own document types using QuickLook generators with the extension .qlgenerator. Initially, they were installed into /Library/QuickLook from each app bundle.

Normally, when QuickLook generated a Thumbnail or Preview, that was stored in its cache database kept in NSTemporaryDirectory in the path C/com.apple.QuickLook.thumbnailcache/. Those could give revealing insights into images and other documents accessed recently, and Wojciech Regula and Patrick Wardle discovered that, in High Sierra and earlier, it was easy for malicious software to examine that cache. Apple addressed that in macOS 10.14 Mojave by making the cache completely inaccessible.

In-memory caching of Thumbnails has also proved controversial in more recent versions of macOS. To deliver smooth scrolling of Thumbnails in the Finder’s Gallery views in particular, the Finder has taken to caching them in memory for up to two days, sometimes using several GB in the process. That can readily be mistaken for a memory leak, until those cached Thumbnails are finally flushed.

I described how QuickLook Thumbnails worked in early 2019, in the days before the SSV.

getdocicon01

When you select a document in the Finder, a dialog, or somewhere else where you expect its icon to be shown, the Finder passes details of the document path and its type (UTI) to IconServices, to fetch the appropriate icon. This calls on its main service, iconservicesd in /System/Library/CoreServices, to check its icon cache.

Although the main icon store is locked away in /Library/Caches/com.apple.iconservices.store, there’s additional data in a folder on a path based on /private/var/folders/…/C/com.apple.iconservices, where … is an unreadable alphanumeric name. For icons used in the Dock, their cache is at /private/var/folders/…/C/com.apple.dock.iconcache. If the icon should be replaced by a QuickLook Thumbnail, such as in a Finder column view, QuickLook is asked to provide that thumbnail. That in turn may be cached in its protected cache at /private/var/folders/…/C/com.apple.QuickLook.thumbnailcache.

QuickLook then relies on there being an appropriate qlgenerator to create a thumbnail of that document type; if the qlgenerator is flawed or can’t cope with the document’s contents, that could easily fall over. For example, if you renamed a text file with a .jpeg extension so that macOS considered it was a JPEG image, the bundled qlgenerator might have simply resulted in the display of a busy spinner, rather than resolving to a generic JPEG document icon. IconServices should then deliver the appropriate icon back to the Finder to display it.

In macOS 10.15 Catalina (2019), Apple started replacing this system with a new framework named QuickLook Thumbnailing, documented here. That replaces qlgenerators with QuickLook preview extensions, in particular Thumbnail Extensions, as explained to developers at WWDC in 2019.

macOS 15.0 Sequoia has finally removed support for qlgenerators. That has resulted in the unfortunate loss of custom Thumbnails and Previews for document types of third-party apps that are still reliant on qlgenerators, and haven’t yet got round to providing equivalent app extensions. It’s almost as if the Desktop databases need to be rebuilt again.

如何在Mac OS X上结束一个进程?

刚才看论文做笔记时Evernote突然停止响应了,本打算用Activity Monitor强制关闭,转念一想,不如学下如何用terminal强制关闭程序吧!正好有人对kill的一些写法有疑问,放上来分享一下。

1. 活动监视器(Activity Monitor)

不论是Windows还是Mac OS X,一定有任务管理器或活动监视器可以查看进程。想要强制终止一个进程很简单,只要找到想要终止的程序,然后点击左上角的八边形带×按钮即可。
Screen Shot 2016-03-24 at 20.01.48

2. Mac OS X 终端(Terminal)

在Terminal上输入命令来终止程序也很简单。分两步走:1. 拿到想要关闭的进程的ID(即PID);2. 命令此ID的进程关闭。下面展示下操作过程:

假设我想把Evernote强制关闭,首先打开Terminal,输入:
ps -A | grep Evernote
ps是“process status”的缩写,意思是“进程状态”,“ps -A”会列出所有当前正在运行的程序,如果此时直接回车,那么你会在terminal上看到一长串的进程,想要找到Evernote的PID不是很方便……
Screen Shot 2016-03-24 at 20.22.03
为了更方便找到Evernote所对应的PID,我们要对这些让人看得头晕的输出进行小小的处理。“|”是个pipeline,会把当前输出的文本(也就是上头一大串进程)输入到右边的命令中。“grep”你可以把它理解成“抓取”,它会从前面输入的文本中抓出带有想要搜索的文字的所有行。看下图,是不是很简洁?马上就知道Evernote的PID是945了(另一个是EvernoteHelper,不用理会)。
Screen Shot 2016-03-24 at 20.29.10
接下来进入正题——杀死进程!输入:
kill 945
然后……就结束了……杀进程很简单吧?
来我们复习一遍:
找PID: ps -A|grep [进程名]
杀进程:kill [PID]
======
补充:
  1. 请勿随意使用强制结束进程,这是在程序无法响应时才使用的杀招,如果文件没有保存,强制结束进程可能会让你丢失未保存内容。
  2. kill -9 [PID]”也能结束进程,9其实是SIGKILL对应的号码,自然也可以用“kill -SIGKILL [PID]”来结束。大家可以输入“kill -l”查看各种对应代码。
Screen Shot 2016-03-24 at 20.44.18

❌