-
-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stylix: support slideshows and animated wallpapers #63
Comments
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 |
I agree, there should be a single option which takes one of
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? |
The answer is probably to not take The default of |
so is this the plan were going through with? |
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 The helper function would work as follows:
This requires having some way to detect whether the input is an image or a video. As both paths and |
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 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 |
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.
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 |
i've implemented video background in my own setup (sway) i specifically had to solve the issue of differently sized monitors, so if anyone wants to steal that for a proper stylix solution please be my guest https://github.com/cramt/nixconf/blob/main/homeManagerModules/features/sway/default.nix#L6-L29 |
My understanding is that stylix currently uses
stylix.image
for palette generation and wallpapers, and is mandatory. If one wishes to usestylix.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 usestylix.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.The text was updated successfully, but these errors were encountered: