Add support for running script as a directory

[Commander07]

Adding support for running the script in/as a directory can make script management easier for the user while still allowing for installation/usage outside a directory without any changes to the current installation procedure. More information about script locations are available in the mpv documentation.

Advantages

• Easy updating for end users. By having support for the script to be loaded as a directory you would be able to download it via git clone and could even use it as a submodule for use in a version controlled mpv config. This would mean no update conflicts and easy rollbacks & modifications for the user.
• Easier sharing of mpv configs including the script. With the possibility of loading it as a directory, people can include the script via git submodule which allows both config publisher and potential user to more easily see differences between version included in the config and upstream. Git submodule example repo.

Problems

• The font would be located within the script directory which means an alternate font loading method or workaround would be required (not sure if this is possible).
• Extra scripts would always be downloaded but never activated. To fix this a config would need to be created which toggles on and off the require statements in main.lua

Implementation

Aside from the font loading issue implementation would only require adding a small main.lua file which requires the existing script and configurably requires the extra scripts. So something like this:

-- main.lua
require('modernz')

local opt = require("mp.options")
local extras = {
    pause_indicator_lite = false,
}
opt.read_options(extras, "modernz-extras")

if extras.pause_indicator_lite then
    require('extras.pause-indicator-lite.pause_indicator_lite')
end

Summary

If loading the font from the script directory is possible then it's possible to support the script running as/in a directory with just the above code snippet and the alternate font loading method.

[Samillion]

This was something on my mind, which I didn't implement for the exact same points you've listed under problems. Though they're not really breaking, it's just an adjustable behavior.

The extras script being downloaded can be solved with .gitignore => extras/.

The font, maybe I can add a hack to look for font style specifically instead of letting mpv load it. I'll tinker around with this to see the best implementation that wouldn't break any standards or rely on "hacks".

[Samillion]

Terribly sorry about the late response on this issue.

So, I've been thinking about this, and a possible way to load fonts the same way as we do modernz-locale.json

Worst case scenario, I can create a handler that looks for mpv config's font directory and ModernZ's directory.

I'll play around with it soon.

One question though. Are users generally comfortable with using directory based scripts over single file(s) placements?

I only ask to kind of see if I should support both at the same time, or move to one direction entirely, or stay the same.

[Commander07]

One question though. Are users generally comfortable with using directory based scripts over single file(s) placements?

I prefer directories but I'm not sure what the overall feelings towards them are. However a lua bundler such as Benjamin-Dobell/luabundler could be used to take a multi sourcefile project and turn it into a single script. But I'm not sure how well a lua bundler works for the purposes of a mpv script. Ideally both should be supported but if that is not possible then the most popular one should be used.

[Samillion]

This idea is tempting me more and more.

I've been trying to find any type of users' input on whether majority prefers directory or single files, but honestly, I found nothing solid.

What I found:

• All modern based osc forks, including origin are single files
• Stock osc.lua single file
• Other popular osc projects use directory (ie: uosc)

Using a directory would yield some great benefits, such as:

• Using a font that would make the osc look much better as @Keith94 pointed out. [fix: improve consistency for width and coordinate values #242]
• Can comfortably apply each locale language into its own file, with a locale sub directory
• Configuration is ensured
• Hell, we can even use different fonts for elements if we wanted to, to spice things up in the future

The one con:
Are users actually familiar with this methodology?

I am 100% overthinking this, the benefits outweigh the concern here, right?

I apologize for the random ping, I would love your input, guys: @Xurdejl @Keith94

[Keith94]

Wow, I didn't get the email for this; just saw this now @Samillion

Anyway, the benefits you listed are well worth it. 💯

Of course, add a note to the readme on how to install it, so users not familiar with it know what to do.