Closed allanday closed 4 years ago
A quick sketch of what the portal UI could look like in a GNOME context:
This doesn't cover cases where the image size or format are problematic.
I started implementing this some time ago, but without a UI, so I guess I could propose an implementation for this.
@allanday would you also like to expose wallpaper options such as tiling or zoom? This currently can be set in GNOME Tweaks.
Also, from an implementation point of view, where would be the best place to store the image? XDG_CONFIG_DIRS/wallpaper.png ?
I wonder whether KDE has requirements/specifics that they would like to have in the portal. cc @grulja
p.s.: We should probably use the word Wallpaper from now on when it comes to this portal, so it is not confused with the Backgrounds portal that handles the "Run in the background" feature for apps.
I don't think that from KDE side there is a need for this portal or specific requirement, because the only way how to change wallpaper is through Plasma configuration (when you click with the mouse right button on a desktop). Given the Plasma config file is quite complicated and the wallpaper is basically a plugin, then I don't think any app would support changing Plasma wallpaper.
Ok, I was wrong, there is a way to change wallpaper through Plasma framework, but I don't think I have seen this implemented. Anyway, I assume the requirements will be most likely same as for Gnome in this case.
One feature you sometimes find in wallpaper apps is the ability to set rotating wallpapers, similar to slideshows. It's a bit unclear how this would fit into the "ask every time" model.
One feature you sometimes find in wallpaper apps is the ability to set rotating wallpapers, similar to slideshows. It's a bit unclear how this would fit into the "ask every time" model.
One option here might be to use an ask once approach - so that setting the background once grants the app permission to set it again in the future. I assume that the portal would still be available even if permission has been granted, so that apps can use the UI it provides even when they already have permission to change the wallpaper.
@allanday I started working on a proper implementation for this. Would you like to expose to apps the wallpaper options? "color-shading-type", "picture-opacity", "picture-options", "primary-color", "secondary-color", etc...?
If yes, I thought that a good API would be:
@allanday I started working on a proper implementation for this. Would you like to expose to apps the wallpaper options? "color-shading-type", "picture-opacity", "picture-options", "primary-color", "secondary-color", etc...?
Can you point me to documentation for those options?
Can you point me to documentation for those options?
I couldn't find anything better than the schemas themselves https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/blob/master/schemas/org.gnome.desktop.background.gschema.xml.in look at their <description>
tags.
I have built a working prototype for this that can copy the image and also shows the image preview.
It doesn't: handle permissions, handle the lockscreen, handle options (like the ones discussed above).
Makes me wonder why can't we have two dialogs instead: one for Wallpaper and the other for the LockScreen Wallpaper (avoiding the toggles in the mockups). They might seem confusing. Toggling both means using the same image for both? Untonggling "Background" and toggling "Lock screen" will just set the lock screen image?
Also, do we need the permission-store involved here at all? The user is always indicating consent when they are visualizing the preview dialog and clicking [Set].
I have built a working prototype for this that can copy the image and also shows the image preview. ...
Yay!
...
Makes me wonder why can't we have two dialogs instead: one for Wallpaper and the other for the LockScreen Wallpaper (avoiding the toggles in the mockups).
One of the things we have in the latest GNOME settings designs is a button to set an image as both the desktop and lock screen backgrounds - it'd be a single action. We're quite keen on this.
They might seem confusing. Toggling both means using the same image for both? Untonggling "Background" and toggling "Lock screen" will just set the lock screen image?
Maybe switches aren't the best way to go here. I can experiment some more with the UI.
Also, do we need the permission-store involved here at all? The user is always indicating consent when they are visualizing the preview dialog and clicking [Set].
I think the question is how to handle apps which want to keep updating the background themselves.
Would you like to expose to apps the wallpaper options? "color-shading-type", "picture-opacity", "picture-options", "primary-color", "secondary-color",
I think not. :smile:
Thanks for your quick reply!
I think the question is how to handle apps which want to keep updating the background themselves.
Aha, that makes sense. This way you are implying that some apps would have an API to update the background without having to display the Preview? (that's doable).
This way you are implying that some apps would have an API to update the background without having to display the Preview? (that's doable).
Right, apps that want to automatically update the background need to be able to do so without showing the preview each time.
The solution we came up with for this was to just enforce asking for permission the first time the app wants to set the background. However, I'm totally open to different solutions. You could make this a separate permission and have a generic confirmation dialog instead, for example.
You could make this a separate permission and have a generic confirmation dialog instead, for example.
Thinking about it, this does seem like a better approach. Updated mockups can be found here.
@allanday the permission dialog requires an icon in the left side. Can we add the icon of the requesting app? Or "preferences-desktop-wallpaper-symbolic"
@allanday the permission dialog requires an icon in the left side. Can we add the icon of the requesting app?
We don't use the app icon in the other portal dialogs. I'd just use a symbolic for the permission type; maybe preferences-desktop-wallpaper-symbolic
.
@allanday the permission dialog requires an icon in the left side. Can we add the icon of the requesting app?
We don't use the app icon in the other portal dialogs. I'd just use a symbolic for the permission type; maybe
preferences-desktop-wallpaper-symbolic
.
Great! That's what is in the current state of the pull request. Thanks!
Sorry it took me so long to look at this. I've finally trried it out.
I must say I'm not a fan of the super-wide dialog with double preview. A single preview would be enough, as far as I'm concerned. And I think the switches are awkward here.
I also don't like the ShowWallpaperPreview method name (since it is really about setting the wallpaper too), and the fact that it is a separate method in the first place. I think we should just have a single SetWallpaper method, and add options to it - 'show-preview' could be an option to give a hint to the portal, but it should really be up to the portal whether to show a dialog or not.
Shotwell desktop slideshow doesn't work Fedora Linux 37 Silverblue. Is there some other need to be installed? I have xdg-utils.
I can see the images were imported into ~/.var/app/org.gnome.Shotwell/data/shotwell/wallpaper/
Allowing a user to set a background on the system is a fairly common feature in apps - it would be good to provide a portal for this.
Design considerations:
From a UX perspective it is probably good to provide a preview of what the background image will look like in use.