Theme meta issue

[mikebeaton]

There are some approved upcoming changes to how themes work, listed below.

There are also some additional issues (at least as perceived by me) which may or may not be changed.

1) Change theme directory structure - APPROVED

Currently themes are identified by file prefixes in a flat directory structure, e.g. Selector.icns, OldSelector.icns, ModernSelector.icns.

This is to be replaced by a [vendor]/[theme] directory structure, with the existing Acidanthera themes directories named for corresponding macOS codenames:

Acidanthera/Chardonnay/Selector.icns, etc.  [was Old]
Acidanthera/Syrah/Selector.icns, etc.       [was Default]
Acidanthera/GoldenGate/Selector.icns, etc.  [was Modern]

PickerVariant = Auto, Default, Old and Modern will be still be supported as special cases, so users will just have to update OcBinaryData as normal when this change is made.

In future, all other PickerVariant values should be [vendor]/[theme], but can also be just [theme] in case there is no vendor subfolder. Unlike now, there must be at least one subfolder.

2) Hardcoded tool names - for discussion

The hardcoded tool names "Reset NVRAM" (which is usually added as a boot entry via Misc/Security/AllowNvramReset, but can also be added manually in the Misc/Tools section) and "UEFI Shell" (which must be added manually in Misc/Tools, as per the sample plist files) are mapped to theme icons ResetNVRAM.icns and Shell.icns respectively. (Actually these special entry names also trigger the appropriate audio prompts in boot picker audio assist.)

• It seems strange that these are mapped by entry name - e.g. what if I would like to rename my shell entry to "Open Shell"? Could they be mapped at least by tool name OpenShell.efi and CleanNvram.efi?
• Note that these icons are per-theme, they are already part of the main theme directory

3) Custom tool icons - for discussion

Tool custom icons can be put next to the tool. E.g. for Tools/OpenShell.efi we can put in place Tools/OpenShell.efi.icns.

• The fact that this exists is somewhat non-obvious, especially as this image location is not output in the log file if searched for and not found (perhaps at least this should be changed, so that this image search is logged?)
• This only works when PickerAttributes OC_ATTR_USE_VOLUME_ICON is set. To me this was very non-obvious, although the idea is that these files are logically equivalent to .VolumeIcon.icns files.
• These icons are not per-theme (since there is just one of them, they are not part of the main theme directory).
• Also, you cannot have more than one icon for the same tool; e.g. ResetSystem.efi previously could (in fact, still can) be used to provide Shutdown and Restart boot entries, but it is not possible to set a different icon for each of these. Although this case is now more or less replaced by the new Shutdown and Restart buttons in both pickers, it seems reasonable in principle to want to apply different icons to the same tool, when called with different arguments in different boot entries.

4) Custom OS icons - for discussion

Apple macOS and Windows support per-theme icons Apple.icns, ExtApple.icns, Windows.icns, ExtWindows.icns.

• In addition to the above, some themes ship with themed icons for other OSes (e.g. several different icons for the several different flavours of Linux), but to use these a user has to manually copy one of them in as .VolumeIcons.icns in the appropriate location near to the relevant OS boot file
• So, apart from Apple and Windows, there is no way to set up a per-theme OS icon

5) Resolution-specific backgrounds - for discussion

Background.icns is searched for and used as a background.

• Various themes ship with more than one background at different resolutions; the appropriate sized image required for the user's system must be manually copied into the theme directory

I'm mentioning this because one of the current requirements for themes (see below) is that the average normal user should not need to edit their theme directory, and can (e.g.) easily just pull updates from the theme's repo. However, this is one example where that already does not work.

6) Supported theme icons without implementations in the default themes - for discussion:

Some supported theme icons (e.g. ResetNVRAM.icns, Apple.icns, ExtApple.icns, ExtWindows.icns) are supported as part of custom themes, but have no implementation in the shipped themes.

• This may be a non-issue, mentioning it separately because it is somewhat relevant to 4 above and 2 below.

THEME REQUIREMENTS

1. The average user should not be expected to edit or alter the theme directory, for example so that they can easily just pull updates from the theme's repo
2. Important: not showing the variant Ext... icon (e.g. ExtHardDrive.icns instead of HardDrive.icns) when the OS is on an external drive is a security risk. (As noted in Configuration.pdf, using .VolumeIcon.icns violates this, but this is an exception and not desirable behaviour.)
3. Theme providers should NOT be expected to support every possible OS and every possible tool; not even from /Tools, never mind from elsewhere

SUGGESTION
Despite the above Theme Requirements, I feel it would be desirable to allow per-theme custom icons for tools and OSes beyond the ones in the fixed set of support.

In order to allow for per-theme custom icons for Tools, I would propose adding a new string CustomIcon key to each Misc/Tools and Misc/Entries entry. The value of this could be, e.g., Shell to select the standard Shell.icns from the theme directory, or SysRestart to select the custom SysRestart.icns. (Note: searching for icons this way could work whether or not OC_ATTR_USE_VOLUME_ICON is set, which I believe is desirable.)

In order to allow for custom icons for other OSes, I would propose adding a new Misc/CustomIcons section, e.g.:

<Misc>
    ...
    <CustomIcons>
        <dict>
            <key>PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0x0,0x0)/HD(6,GPT,00000000-0000-0000-0000-000000000000,0x00000000,0x0000)/\EFI\ubuntu\grubx64.efi</key>
            <string>Ubuntu</string>
        </dict>
    </CustomIcons>
    ...
</Misc>

This assigns the per-theme custom icon Ubuntu.icns to the specified boot entry (if this icon exists in the current theme, or default OS icon otherwise). This only makes sense if at least several theme providers provide e.g. Ubuntu icons. I believe they already do.

In terms of priority, I would suggest that these custom icons are searched for first when specified, and if not found (or not specified) all existing locations are searched next as now.

Probably both the above suggestions only make sense if we accept that users do do some manual editing and placing of their themes files, but I believe they already do, both for different sized backgrounds and to allow for (e.g.) different Unix flavour OS icons.

NB I am not suggesting that any such additional icon names become required or recommended defaults. One theme provider might provide Ubuntu.icns, SysShutDown.icns and SysRestart.icns, another one might provide equivalent icons but call them something else. The aim is only to allow theme providers to provide additional icons and to allow users a way to select them.