Add a default context menu definition in etc/menu.conf. It will be used
to populate the context menu.
The format is meant to be easily readable with just tabs as separators
and submenus denoted by indentation. It avoids complicating the builtin
input.conf like similar scripts do.
By not defining the shortcut keys in the builtin input.conf, menu
entries won't be associated to wrong shortcuts when the user's
input.conf changes key bindings without redefining the menu. Note that
external scripts don't have this issue.
I used 3+ spaces as separators at first but then realized that since we
have Windows users tabs will look better in editors with proportional
fonts like notepad, though it still won't be perfectly aligned depending
on the font. But I am still not sure what is better.
On a curious note, etc/menu.conf already existed in the past as mplayer
used to have a menu. git log -p etc/menu.conf will show commits from
2002 to 2011.
generated with the Icon Composer project:
actool ./icon.icon \
--compile ./ \
--app-icon icon \
--enable-on-demand-resources NO \
--development-region en \
--target-device mac \
--platform macosx \
--include-all-app-icons \
--minimum-deployment-target 10.15 \
--output-partial-info-plist /dev/null \
--standalone-icon-behavior all
actool will generate an Assets.car file which is compatible with all the
new Theme variants of macOS 26 (default, dark, monochrome, tinted, etc).
it also generates an old icns file as a fallback, only default style.
since the new Assets.car file can't be used from cocoa directly, without
using private APIs, we still use the icns file when used from CLI.
this also means that from CLI only the default icon is used and the
macOS theming doesn't have any effect.
the macOS theming mechanism only works with the bundle and a Assets.car
file. all icons are generated on the fly depending on the Theme. this
generation has no public API and the mechanism would need to be
replicated by hand. to replicate this behaviour at least three different
icns would need to be generated, tinting needs to be implemented,
several system events need to be subscribed, and this wouldn't guarantee
the same look as the system mechanism. also none of the tools make it
possible to generate macOS 26 compatible icns file, besides for the
default file, since it at least is missing the necessary padding.
This reverts commit 3840c98b36.
There are multiple reasons:
- the correct way to prevent tabs being mistakenly added is a CI linting step
- it can affect the editing experience of foreign source files
under mpv's tree (e.g. subprojects)
- at least one editor (BBEdit) misinterprets the values and also turns
soft tabs into 7 spaces
- it does not consistently apply to GH code view either
editorconfig configuration files hold editor style hints, and
is supported by many popular editors. See https://editorconfig.org/ .
The vast majority of the mpv source/text files are already styled as
4 space indentation, trailing newline at EOF, and UTF-8 encoding.
This commit adds a single .editorconfig root file which applies these
rules to all files using the glob "[*]".
If it turns out to be too inclusive then we can narrow it down later.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Guido Cella
der richter
sfan5
nanahi
NRK
Emil Velikov