Separate font.lib-like file for user interface state?

[justvanrossum]

Currently we don't differentiate between lib items that contain important custom data for a project and lib items that hold some UI state for an editor. UI state usually is not desirable to put under version control.

An optional font.ufo/uistate.plist file could solve this, as it could be easily ignored by version control systems.

[typemytype]

I assume the data folder can be uses for this: any editor can save a com.myAppName.requiredUIData.plist file. It can be any format, or even binary custom data..

If there are common UI states across multiple editors a public lib key can be made.

[justvanrossum]

Good point.

I think the spec should say lib is not for ui state, and apps should store it in the data folder.

[belluzj]

Yes, that sounds like a good idea to separate the two. For example in glyphsLib we're storing open tabs (called "display strings") in a lib key, and that creates some not very useful diffs.

[typesupply]

@typemytype

I assume the data folder can be uses for this

@justvanrossum

I think the spec should say lib is not for ui state, and apps should store it in the data folder.

These are both great ideas. I'll take this on since it's just some writing. I'll think about it over the next few days and write a draft here.

[justvanrossum]

I guess fontParts could implement this as a lib-like api. For example, I don't think RF extension developers should have to do this directly with ufoLib or even a raw font.ufo/data api.

[benkiel]

Yes, it could do, and then it could be more generic than just RF.

[typemytype]

small comment: fontParts has not yet support for the data folder (this is a different issue in a different repo)

[typesupply]

Here's a draft with the bulk of the normative language copied/pasted from lib.plist so it should be good to go unless there are other suggestions for the file name or lib recommendations.

---

Addition to /data documentation:

public.interfaceLib.plist

This file name is reserved for a property list containing arbitrary interface settings in a lib structure identical to [lib.plist]. The property list data consists of a dictionary at the top level. In order to prevent conflicts in the lib, keys in the top level should follow a reverse domain naming scheme. The pattern "public.*", where * represents an arbitrary string of one or more characters, is reserved for use in standardized lib keys. It is recommended that the data stored as a value be as shallow as possible.

---

Addition to lib.plist documentation:

It is recommended that interface data be stored in the public.userInterfaceLib.plist file within the [data directory].

---

Addition to GLIF <lib> documentation:

It is recommended that interface data be stored in the public.userInterfaceLib.plist file within the [data directory].

[chrissimpkins]

easily ignored by version control systems.

+1