stylix
stylix copied to clipboard
danth
stylix: support slideshows and animated wallpapers
My understanding is that stylix currently uses stylix.image for palette generation and wallpapers, and is mandatory. If one wishes to use stylix.autoEnable, they might be surprised to see that stylix is also setting wallpaper options. For users who wish to use a rotating set of wallpapers, this can be an annoyance as they would have to manually disable such modules. To accomodate users with sets of wallpapers, stylix should continue to use stylix.image but accepting a list, or expose a new option (stylix.wallpapers? stylix.images? Seems to complicate things for little benefit) which is a list of images. In order to accomplish the first solution (which I prefer), I would sugget taking the first or last element of the list when only one image is required.
A bit related to #54 . The point is that people want other things than just an image as wallpaper, so we need to support that. Maybe we could have an options stylix.wallpaper that is pretty free-form, and set stylix.image from it if it is set. I'll experiment with this idea and open a draft PR.
I agree, there should be a single option which takes one of
- An image
- A list of images
- An animation
Theoretically the palette generator could support all of these directly, as it's just selecting pixels at random and then improving on that selection. That would however be quite resource intensive, especially for video wallpapers, as the entire file needs to be loaded into memory to do the selection.
I think we should stick with the idea of picking a single image/frame to use in the generator for now.
How should we handle backwards compatibility with the creation of a new option? stylix.wallpaper cannot default to stylix.image, because the default image will depend on the wallpaper, which creates an infinite loop if neither of the options are set.
The answer is probably to not take stylix.wallpaper for granted: to place conditions in modules that would use it.
The default of stylix.wallpaper should be null. In the modules, simply check that stylix.wallpaper is not null. If it is null, try to use stylix.image as a fallback. This can probably be made a helper function as well.
It would be simpler if there was only one option, with a function to create a still image from it. If the value is already a still image then this can be passed through the function unmodified.
This way, we can rename stylix.image to stylix.wallpaper using mkRenameOption, which maintains backwards compatibility without introducing new possible values.
The helper function would work as follows:
- If the input is an image, return it unmodified
- If the input is a video, return a derivation which extracts a frame
- If the input is a list, choose one value and call the function again
This requires having some way to detect whether the input is an image or a video. As both paths and fetchurl preserve the original file name, we should be able to detect based on the file extension, and throw an error if it's unknown. This can also let us reject unusual image formats.
One limitation with this approach is that in the case of the list, we may want more features (for example how long to display each wallpaper, how to handle transitions...). I don't really have any good idea on how to handle it.
Is it possible to use a submodule type within an enum? If so, we could replace the list with a submodule having those extra options.
We can as long as there is only one such submodule (otherwise it gets complicated pretty fast I think), so it would work but if we want to support other kinds of wallpaper in the future it may get complicated, but I'm not sure how probable it is.
On further thought, we could represent all wallpapers as an attrset:
{
type = "image";
file = ./image.png;
}
{
type = "animation";
file = ./video.mp4;
}
{
type = "slideshow";
delay = 5;
files = [ ./image1.png ./image2.png ];
}
It's possible to define custom types with a validator function, which in this case would reject anything without a type attribute or not matching the specification for that type.
We can then add constructors to simplify and provide defaults:
mkImage ./image.png
mkAnimation ./video.mp4
mkSlideshow {
files = [ ./image1.png ./image2.png ];
}
This also avoids the need to parse file extensions, as the type of wallpaper is known.
What do you think?
Also, should there be a separate type for animated images (GIF, AVIF) vs video (MP4, AVI)? As these might need a different implementation.
it may be best to separate animated images and videos as mpvpaper is much less efficient then its cousins that only support animated images, at least on wayland, I dont know too much about the x11 side of things, i would recommend swww for the implementation of the slideshow and animated image types if we plan to go forward with this solution.
is this the plan for implementing this? because i think i might try my hand at it soon.
Custom types are the best solution I can come up with. Let's go ahead with that.
whats everyone's opinion on maybe moving the color scheme to the custom types like the image? then rather then setting the color scheme directly you use a constructor to set the base16 scheme like nord or any other scheme.
This is something I've thought about before - we could have a function to load a scheme from a file, and another to generate one based on a given image and settings.
The polarity and override options would become arguments to that generator function, which prevents those being used elsewhere. For example switching apps between light and dark mode based on polarity, which we should avoid because someone using a premade scheme won't have set the polarity correctly.
I think @danth's idea is great but I'd like to mention it is pretty easy right now to use official themes: see how I do it here.
One problem with using custom types is that it makes the option less self-documenting, so it should be avoid as much as possible. I actually don't know of any module where it's used, but it would be great to find some previous uses to see how they did it.
you guys are probably more knowledgable in this subject then i am so i dont really have much of an opinion on the matter
im personally in favor of moving everything over to the constructor but @danth what do you think?
I'm also in favor of the custom types, but it would be nice if we had a way to generate documentation for them
@danth it looks like the gnome module relies on the polarity option, perhaps it would be a good idea to retain the polarity option but not have it influence the generated colorscheme? because there are other modules that i can see said option being useful for like qutebrowser.
(As mentioned on Matrix) I think we should calculate polarity based on the background colour when it's needed for a module, as this will support handmade schemes too. So if the background colour is darker than a threshold, set the theme to dark, otherwise set the theme to light. Then the polarity option will only be used as a guide for the generated scheme.
Dumping additional slideshow feature suggestions.
- Randomly select an item from collection (
mkSlideshow.files). - Use a blurred image copy for the borders instead of black borders, if the aspect ration of the item does not match the aspect ratio of the drawing canvas.
- Add additional options for randomly selecting items (feature suggestion
1.): select only items that match the specifiedstylix.base16Schemescheme in order to remain in the same color scheme.
On non-nix-based systems, I currently use the following shell script to implement the first two feature suggestions: https://github.com/trueNAHO/dotfiles/blob/767b4ba1cc84ee2c980956cab72c708a958087f9/home/dot_local/bin/executable_set_wallpaper
