desktop-background.el as a new library?

desktop-background.el as a new library?

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

I'm looking at teaching image-dired.el to set your desktop background.
Because A) this finishes a TODO that has been in that file for going on
15 years, and B) any respectable image viewer must know how to set your
desktop background.

However, this code is not really tied to image-dired.el; only one line
and the name of the defun ties it to that library.  For example, it
could be used in thumbs.el (that has similar capabilities), and it could
even be useful as a stand-alone command.

So I started thinking that just like the recently added gravatar.el,
perhaps we should put this stuff in a new library
lisp/image/desktop-background.el?

(Or some better name, suggestions welcome.)

Please see the attached tentative diff for image-dired.el to get an
idea.  (Please ignore the somewhat unwieldy defcustoms; I followed the
scheme in image-dired.el and intend to clean that up.)

Maybe this will even work automagically on other operating systems than
GNU/Linux, if the commands it uses has been ported to them.

[-- Attachment #2: desktop-background.diff --]
[-- Type: text/x-diff, Size: 3667 bytes --]

diff --git a/lisp/image-dired.el b/lisp/image-dired.el
index f6a263749f..0b357332a1 100644
--- a/lisp/image-dired.el
+++ b/lisp/image-dired.el
@@ -117,8 +117,6 @@
 ;; * From thumbs.el: Add an option for clean-up/max-size functionality
 ;;   for thumbnail directory.
 ;;
-;; * From thumbs.el: Add setroot function.
-;;
 ;; * From thumbs.el: Add image resizing, if useful (image-dired's automatic
 ;;  "image fit" might be enough)
 ;;
@@ -2818,6 +2816,71 @@ image-dired-save-information-from-widgets
        (dolist (tag tag-list)
          (push (cons file tag) lst))))))
 
+\f
+;;;; Setting background.
+
+(defcustom image-dired-set-background-program
+  (cond ((executable-find "feh") "feh")
+        ((executable-find "gm") "gm")
+        ((executable-find "display") "display")
+        ((executable-find "xloadimage") "xloadimage")
+        ((executable-find "xsetbg") "xsetbg"))
+  "Command to set the desktop background.
+You must also set `image-dired-cmd-set-background-options' or
+this will not work.
+
+Note: If you find that you need to use a different command on
+your machine, we would like to hear about it!  Please send an
+email to bug-gnu-emacs@gnu.org and tell us which
+command (including all options) that worked for you."
+  :type 'string
+  :version "29.1")
+
+(defcustom image-dired-cmd-set-background-options
+  (cond ((executable-find "feh") '("--bg-scale" "%f"))
+        ((executable-find "gm") '("display" "-resize" "%wx%h" "-window" "root" "%f"))
+        ((executable-find "display") '("-resize" "%wx%h" "-window" "root" "%f"))
+        ((executable-find "xloadimage") '("-onroot" "-fullscreen" "%f"))
+        ((executable-find "xsetbg") '"%f"))
+  "Options to pas to the program setting the desktop background.
+The default scales the image to fit the background.
+
+To see which options are available, see the documentation for
+your chosen `image-dired-cmd-set-background-program'."
+  :type '(repeat string)
+  :version "29.1")
+
+(defun image-dired-set-desktop-background (file)
+  "Set the desktop background to FILE in a graphical environment."
+  (interactive (list (or (image-dired-original-file-name)
+                         (read-file-name "Set desktop background to:"
+                                         default-directory nil t nil
+                                         (lambda (fn)
+                                           (string-match (image-file-name-regexp) fn))))))
+  (when (display-graphic-p)
+    (let* ((spec `((?f . ,file)
+                   (?h . ,(display-pixel-height))
+                   (?w . ,(display-pixel-width))))
+           (buf (format " *desktop-background-%s*"
+                        (random)))
+           (process
+            (apply #'start-process "set-desktop-background" buf
+                   image-dired-cmd-set-background-program
+                   (mapcar (lambda (arg) (format-spec arg spec))
+                           image-dired-cmd-set-background-options))))
+      (setf (process-sentinel process)
+            (lambda (process status)
+              (unwind-protect
+                  (unless (and (eq (process-status process) 'exit)
+                               (zerop (process-exit-status process)))
+                    (message "command %S %s: %S" (string-join (process-command process) " ")
+                             (string-replace "\n" "" status)
+                             (with-current-buffer (process-buffer process)
+                               (string-clean-whitespace (buffer-string)))))
+                (ignore-errors
+                  (kill-buffer (process-buffer process))))))
+      process)))
+
 \f
 ;;;; bookmark.el support
 

Re: desktop-background.el as a new library?

[Tassilo Horn]

Stefan Kangas <stefan@marxist.se> writes:

Hi Stefan,

> Please see the attached tentative diff for image-dired.el to get an
> idea.  (Please ignore the somewhat unwieldy defcustoms; I followed the
> scheme in image-dired.el and intend to clean that up.)
>
> Maybe this will even work automagically on other operating systems
> than GNU/Linux, if the commands it uses has been ported to them.

None of the provided commands will work for wayland compositors (I
think) which are becoming more and more the standard on GNU/Linux.  For
example, I'm using sway so when $WAYLAND_DISPLAY and $SWAYSOCK are set,
the background must be set using the swaybg command.  Similarly, with
GNOME, I'd say it's generally the best bet to set the wallpaper using
gsettings because that will work with both GNOME on X11 and GNOME on
Wayland.  But with gsettings, the set wallpaper would be persistent
whereas all other commands would set the wallpaper only for the current
session.

That said, I like the idea.  It's just that the program for setting the
wallpaper is not necessarily a user preference (defcustom) but can also
be a necessity dictated by the WM/compositor/platform.

Bye,
Tassilo

Re: desktop-background.el as a new library?

[Stefan Kangas]

Tassilo Horn <tsdh@gnu.org> writes:

> None of the provided commands will work for wayland compositors (I
> think) which are becoming more and more the standard on GNU/Linux.  For
> example, I'm using sway so when $WAYLAND_DISPLAY and $SWAYSOCK are set,
> the background must be set using the swaybg command.  Similarly, with
> GNOME, I'd say it's generally the best bet to set the wallpaper using
> gsettings because that will work with both GNOME on X11 and GNOME on
> Wayland.  But with gsettings, the set wallpaper would be persistent
> whereas all other commands would set the wallpaper only for the current
> session.

Thanks, this is very useful information, and reinforces the argument
that something like this belongs in a library, so that people don't have
to reinvent the wheel all the time.

I guess the only way to do this is adding stuff as it comes up and
improve on this over time.  The fix you pointed out sounds
straightforward: check if $WAYLAND_DISPLAY and $SWAYSOCK are set, and
use swaybg if they are.

Does anyone know how to detect if Gnome is in use?

BTW, there is an important difference, IIUC, with "gsettings" in that it
sets it not just for this session.  Perhaps that is okay, though?  That
just seems to be one of the features that Gnome provides over plain X11.

> That said, I like the idea.  It's just that the program for setting the
> wallpaper is not necessarily a user preference (defcustom) but can also
> be a necessity dictated by the WM/compositor/platform.

Thanks!

I agree that we might want to consider to what extent and how this
should be customizable to the user.  When it really comes down to it,
perhaps most users don't care at all what is being used, and is more
interested in customizing if the background is stretched or tiled out.

On a separate note, I have looked into what third-party packages do, and
it seems really common to just fire and forget a command like
"feh --set-bg".

Re: desktop-background.el as a new library?

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Does anyone know how to detect if Gnome is in use?

The environment will contain "XDG_CURRENT_DESKTOP=GNOME".

Re: desktop-background.el as a new library?

[Arthur Miller]

Stefan Kangas <stefan@marxist.se> writes:

> I'm looking at teaching image-dired.el to set your desktop background.
> Because A) this finishes a TODO that has been in that file for going on
> 15 years, and B) any respectable image viewer must know how to set your
> desktop background.
>
> However, this code is not really tied to image-dired.el; only one line
> and the name of the defun ties it to that library.  For example, it
> could be used in thumbs.el (that has similar capabilities), and it could
> even be useful as a stand-alone command.
>
> So I started thinking that just like the recently added gravatar.el,
> perhaps we should put this stuff in a new library
> lisp/image/desktop-background.el?
>
> (Or some better name, suggestions welcome.)
>
> Please see the attached tentative diff for image-dired.el to get an
> idea.  (Please ignore the somewhat unwieldy defcustoms; I followed the
> scheme in image-dired.el and intend to clean that up.)
>
> Maybe this will even work automagically on other operating systems than
> GNU/Linux, if the commands it uses has been ported to them.

Are you sure this is really interesting to people who use some kind of DE?

I personally have a simple systemd script that run periodically and change the
background by choosing a random image from a folder with feh.

Have you thought about doing it all with Emacs only. Would be something similar
as what some WMs, DEs do: a fullscreen frame below all other frames and display 
an image from a user customizable path with Emacs image functionality. You could
go extra mile and provide some scaling/centering for the image; but otherwise
you can just left to user to use images with appropriate resolution. Also it
would be trivial to provide a "desktop menu" on that frame. Would need some kind
of "desktop mode" for the buffer that displays image, but I don't think it is
lots of work.

Long time ago I played with that idea; but at the time I didn't know how to
disable input for the background frame, so I didn't continute with that.

That would require no external tools, integration with DEs and whatnot, would be
"all emacs" solution.

Re: desktop-background.el as a new library?

[Stefan Kangas]

Arthur Miller <arthur.miller@live.com> writes:

> Are you sure this is really interesting to people who use some kind of DE?

No, that's why I'm asking the question.  But I note that other image
viewers has such functionality.

> Have you thought about doing it all with Emacs only.

Not really, no.  It sounds like a lot of work.  :-)

Re: desktop-background.el as a new library?

[Arthur Miller]

[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]

Stefan Kangas <stefan@marxist.se> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Are you sure this is really interesting to people who use some kind of DE?
>
> No, that's why I'm asking the question.  But I note that other image
> viewers has such functionality.
>
>> Have you thought about doing it all with Emacs only.
>
> Not really, no.  It sounds like a lot of work.  :-)
:-) Njah ... :-)

Sorry for little bit late answer on this; but didn't have time to do it back
then, and later I forgott it. But I did a little test/sketch, it isn't very
difficult to get up a frame with a background image. It was really just 10 nin
thing, so no checking for errors, nils etc; just as a demo of the idea.

It has hardcoded path to a directory "~/wallpapers" from which it will choose a
random wallpaper. My wallpapers are all scaled to my desktop size, but it
wouldn't be much work to add like check for scaling and request image to be
rescaled.

I do see some problems, not sure if it is my wm (compiz) or Emacs:

If I add (fullscreen . t) for the frame parameter, Emacs goes nuts: I can't move
or rescale other frames despite frame parameter being only for the background
frame. Without fullscreen parameter there is tiny strip on the right and bottom
edges where real background comes through, and a tiny borders despite me setting
borders to nil. I have tried to make frame slightly bigger then my desk and to
move image to the right and down but those strips are still there.

Besides that, it seems to work fine. As extra bonus user could use "easy menu"
to create desktop menus with elisp and emacs. Could be usable for setups with
simple WMs without wallpaper and desktop menu features.

No extra libraries needed, just plain frame and Emacs compiled with image
support. More work required, if anyone is interested, I am not gonna work more
on it myself.


[-- Attachment #2: background.el --]
[-- Type: text/plain, Size: 3490 bytes --]

;;; background.el ---                                -*- lexical-binding: t; -*-

;; Copyright (C) 2021  Arthur Miller

;; Author: Arthur Miller <arthur.miller@live.com>
;; Keywords: 

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:

;; 

;;; Code:

(defvar bg-walpaper-dir (expand-file-name "~/wallpapers"))
(defvar bg-img-list nil)
(defvar bg-frame nil)
(defvar bg-buffer nil)
(defvar bg-curr-image nil)
(defvaralias 'bg-nd 'directory-files-no-dot-files-regexp)

(defun bg-init-buffer ()
  (unless bg-buffer
    (setq bg-buffer (get-buffer-create "  *bg-buffer*")))
  (with-current-buffer bg-buffer
    (with-silent-modifications
      (erase-buffer)
      (setq mode-line-format nil)
      (insert-image (create-image bg-curr-image)))))

(defun bg-init-frame ()
  (if (display-graphic-p)
      (unless bg-frame
        (let ((w (+ (display-pixel-width) 2))
              (h (+ (display-pixel-height) 2)))
          (setq bg-frame (make-frame 
                          `((name . "bg-frame")
                            (width . ,w)
                            (height . ,h)
                            (visibility . t)
                            (auto-raise . nil)
                            (skip-taskbar . t)
                            (no-focus-on-map . t)
                            (no-accept-focus . t)
                            (undecorated . t)
                            (unsplittable . t)
                            (z-group . below)
                            (no-other-frame . t)
                            (minibuffer . nil)
                            (tool-bar-lines . 0)
                            (menu-bar-lines . 0)
                            (left-fringe . 0)
                            (right-fringe . 0)
                            (border-width . 0)
                            (internal-border-width . 0)
                            (vertical-scroll-bars . nil)
                            (horizontal-scroll-bars . nil))))))))

(defun bg-kill-frame ()
  (when bg-frame
    (delete-frame bg-frame)
    (setq bg-frame nil)
    (kill-buffer bg-buffer)
    (setq bg-buffer nil)))

(defun bg-get-random-image ()
  (when bg-walpaper-dir
    (unless bg-img-list
      (setq bg-img-list (directory-files bg-walpaper-dir t bg-nd t)))
    (let ((index (random (length bg-img-list))))
      (if (not (equal (nth index bg-img-list) bg-curr-image))
          (nth index bg-img-list)
        (bg-get-random-image)))))

(defun bg-show-background (&optional image-name)
  (interactive)
  (setq bg-curr-image (or image-name (bg-get-random-image)))
  (bg-init-buffer)
  (unless bg-frame (bg-init-frame))
  (with-selected-frame bg-frame
    (switch-to-buffer bg-buffer))
  (unless (frame-visible-p bg-frame) (make-frame-visible bg-frame)))

(defun bg-hide-background ()
  (interactive)
  (bg-kill-frame))

(provide 'background)
;;; background.el ends here

New library wallpaper.el pushed to master

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

> I'm looking at teaching image-dired.el to set your desktop background.
> Because A) this finishes a TODO that has been in that file for going on
> 15 years, and B) any respectable image viewer must know how to set your
> desktop background.
>
> However, this code is not really tied to image-dired.el; only one line
> and the name of the defun ties it to that library.  For example, it
> could be used in thumbs.el (that has similar capabilities), and it could
> even be useful as a stand-alone command.
>
> So I started thinking that just like the recently added gravatar.el,
> perhaps we should put this stuff in a new library
> lisp/image/desktop-background.el?

I have now pushed the new library wallpaper.el and changed thumbs.el and
image-dired.el to use it.  It has the new command `wallpaper-set', and
the user option `wallpaper-commands' to control it.

I don't expect it to not work on anything but GNU/Linux for now, but
patches and suggestions are obviously very welcome.  (I hope that it
will be easy to add checks for different environments by adding new
`cl-defgeneric's.)

Thanks to Tassilo Horn for useful pointers in the previous discussion on
how to handle Sway/Wayland and Gnome.

Re: New library wallpaper.el pushed to master

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 13 Sep 2022 12:28:12 -0400
> 
> I have now pushed the new library wallpaper.el and changed thumbs.el and
> image-dired.el to use it.  It has the new command `wallpaper-set', and
> the user option `wallpaper-commands' to control it.
> 
> I don't expect it to not work on anything but GNU/Linux for now, but
> patches and suggestions are obviously very welcome.  (I hope that it
> will be easy to add checks for different environments by adding new
> `cl-defgeneric's.)

Thanks.

From casual reading, the code seems to be heavily biased towards the
assumption that setting a wallpaper requires invoking an external
program.  What about systems where this can be done by calling an API
(i.e., via a special-purpose Emacs primitive)?  Would you please amend
the code to make the feature more easily extended to use such methods?

In addition, are you sure it is a good idea to have a defcustom whose
value is list of lists of strings?  Users who wish to customize this
will have hard time, unless they are very proficient ion Emacs Lisp.
Can we come up with a defcustom that is easier to customize?

Re: New library wallpaper.el pushed to master

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> From casual reading, the code seems to be heavily biased towards the
> assumption that setting a wallpaper requires invoking an external
> program.  What about systems where this can be done by calling an API
> (i.e., via a special-purpose Emacs primitive)?  Would you please amend
> the code to make the feature more easily extended to use such methods?

I'm assuming you mean something like this

    (w32-wallpaper-set file)

?

If so, besides documentation changes, I imagine that all we would need
is something like:

diff --git a/lisp/image/wallpaper.el b/lisp/image/wallpaper.el
index 4c90559183..acc2f11420 100644
--- a/lisp/image/wallpaper.el
+++ b/lisp/image/wallpaper.el
@@ -115,7 +115,9 @@ wallpaper-set
     (error "No such file: %s" file))
   (unless (file-readable-p file)
     (error "File is not readable: %s" file))
-  (when (display-graphic-p)
+  (cond
+   (w32-use-native-image-API (w32-wallpaper-set file))
+   ((display-graphic-p)
     (let* ((command (wallpaper--find-command))
            (fmt-spec `((?f . ,(expand-file-name file))
                        (?h . ,(display-pixel-height))
@@ -141,7 +143,7 @@ wallpaper-set
                                (string-clean-whitespace (buffer-string)))))
                 (ignore-errors
                   (kill-buffer (process-buffer process))))))
-      process)))
+      process))))

 (provide 'wallpaper)

> In addition, are you sure it is a good idea to have a defcustom whose
> value is list of lists of strings?  Users who wish to customize this
> will have hard time, unless they are very proficient ion Emacs Lisp.
> Can we come up with a defcustom that is easier to customize?

I was actually going back and forth on this.

Could we change it into a list of strings, thereby assuming that you
won't need to specify any command line arguments containing spaces?
If so, I think that would be more user friendly.

Thanks for reviewing!

Re: New library wallpaper.el pushed to master

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 13 Sep 2022 13:09:48 -0400
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > From casual reading, the code seems to be heavily biased towards the
> > assumption that setting a wallpaper requires invoking an external
> > program.  What about systems where this can be done by calling an API
> > (i.e., via a special-purpose Emacs primitive)?  Would you please amend
> > the code to make the feature more easily extended to use such methods?
> 
> I'm assuming you mean something like this
> 
>     (w32-wallpaper-set file)
> 
> ?
> 
> If so, besides documentation changes, I imagine that all we would need
> is something like:

I though that would be considered unclean, given that you deployed the
cl-defgeneric machinery there.  At the very least, it would mean w32
users will not be able to use external programs to do the job, even if
they do have such a program.  Is that acceptable?

> -  (when (display-graphic-p)
> +  (cond
> +   (w32-use-native-image-API (w32-wallpaper-set file))
> +   ((display-graphic-p)

Btw, w32-use-native-image-API has nothing to do with this feature.

Also, the display-graphic-p requirement is IMO a gratuitous
restriction, since one can invoke these external programs from an
Emacs running in a terminal emulator as well, I presume.  The reason
you needed display-graphic-p is that you rely on display-pixel-height,
but is that really such an important requirement? why not let people
specify the height manually?

> > In addition, are you sure it is a good idea to have a defcustom whose
> > value is list of lists of strings?  Users who wish to customize this
> > will have hard time, unless they are very proficient ion Emacs Lisp.
> > Can we come up with a defcustom that is easier to customize?
> 
> I was actually going back and forth on this.
> 
> Could we change it into a list of strings, thereby assuming that you
> won't need to specify any command line arguments containing spaces?
> If so, I think that would be more user friendly.

I actually thought about computing the value of the defcustom
dynamically at run time, trying each candidate until one is found.
The template for the command's arguments doesn't need to be in the
value, you can use a separate default template for each executable.
Then all users will have to do is to specify a name of a program, and
perhaps a few optional command-line switches.

Re: New library wallpaper.el pushed to master

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I though that would be considered unclean, given that you deployed the
> cl-defgeneric machinery there.  At the very least, it would mean w32
> users will not be able to use external programs to do the job, even if
> they do have such a program.  Is that acceptable?

I don't know; I don't use MS-Windows.  But if we can do it natively,
perhaps it is acceptable to not be able to use an external command.

If we're fine with that limitation, I see that Po Lu added support for
Haiku, and I think MS-Windows could do something similar to that.

> Also, the display-graphic-p requirement is IMO a gratuitous
> restriction, since one can invoke these external programs from an
> Emacs running in a terminal emulator as well, I presume.

Please see my reply to Po Lu regarding this.

> The reason you needed display-graphic-p is that you rely on
> display-pixel-height, but is that really such an important
> requirement? why not let people specify the height manually?

Indeed, that could be changed.

> I actually thought about computing the value of the defcustom
> dynamically at run time, trying each candidate until one is found.
> The template for the command's arguments doesn't need to be in the
> value, you can use a separate default template for each executable.
> Then all users will have to do is to specify a name of a program, and
> perhaps a few optional command-line switches.

I like this idea.  Let me see what I can come up with.

Re: New library wallpaper.el pushed to master

[Stefan Kangas]

Stefan Kangas <stefankangas@gmail.com> writes:

> I don't know; I don't use MS-Windows.  But if we can do it natively,
> perhaps it is acceptable to not be able to use an external command.
>
> If we're fine with that limitation, I see that Po Lu added support for
> Haiku, and I think MS-Windows could do something similar to that.

BTW, thinking about this a bit more, I guess the limitation could be
lifted by just adding a new user option `wallpaper-prefer-command' or
something like that.

Re: New library wallpaper.el pushed to master

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> If we're fine with that limitation, I see that Po Lu added support for
> Haiku, and I think MS-Windows could do something similar to that.

I think wallpaper-set should strive to implement everything reasonable
that could be customized by changing the command(s) used itself, leaving
the use of commands solely an implementation detail.

Re: New library wallpaper.el pushed to master

[Stefan Kangas]

Stefan Kangas <stefankangas@gmail.com> writes:

>> The reason you needed display-graphic-p is that you rely on
>> display-pixel-height, but is that really such an important
>> requirement? why not let people specify the height manually?
>
> Indeed, that could be changed.

I have now done this (commit bfafe4aacc).

>> I actually thought about computing the value of the defcustom
>> dynamically at run time, trying each candidate until one is found.
>> The template for the command's arguments doesn't need to be in the
>> value, you can use a separate default template for each executable.
>> Then all users will have to do is to specify a name of a program, and
>> perhaps a few optional command-line switches.
>
> I like this idea.  Let me see what I can come up with.

I've now implemented this change on master (commit 8c3b40254b).

Please let me know if you have any comments.  Thanks.

Re: New library wallpaper.el pushed to master

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 14 Sep 2022 00:13:02 -0700
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I though that would be considered unclean, given that you deployed the
> > cl-defgeneric machinery there.  At the very least, it would mean w32
> > users will not be able to use external programs to do the job, even if
> > they do have such a program.  Is that acceptable?
> 
> I don't know; I don't use MS-Windows.  But if we can do it natively,
> perhaps it is acceptable to not be able to use an external command.
> 
> If we're fine with that limitation, I see that Po Lu added support for
> Haiku, and I think MS-Windows could do something similar to that.

I'd prefer something like battery.el, where we have a function that
isolates the system dependencies.  But I can also live with what we
have now.  However, the defcustom's should say in their doc strings
that they are only for GNU/Linux systems.

Re: New library wallpaper.el pushed to master

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I'd prefer something like battery.el, where we have a function that
> isolates the system dependencies.  But I can also live with what we
> have now.

That might make things cleaner, indeed.

Perhaps we can revisit it once we add MS-Windows and macOS support,
which will give us a clearer picture?

> However, the defcustom's should say in their doc strings that they are
> only for GNU/Linux systems.

We could add that, but perhaps we should say instead which systems don't
use them?  Currently, that's only Haiku.

- Hopefully, Someone (TM) will volunteer to write code for MS-Windows.
- If no one beats me too it, I intend to eventually look into macOS
  support.
- I believe that all other systems we support will be covered by the code
  we have already.

Re: New library wallpaper.el pushed to master

[Stefan Kangas]

Stefan Kangas <stefankangas@gmail.com> writes:

> - If no one beats me too it, I intend to eventually look into macOS
>   support.

I've now added support for macOS.  However, I only have access to a
macOS 10.13 machine, so more testing would be welcome.

Re: New library wallpaper.el pushed to master

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 14 Sep 2022 00:13:02 -0700
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I though that would be considered unclean, given that you deployed the
> > cl-defgeneric machinery there.  At the very least, it would mean w32
> > users will not be able to use external programs to do the job, even if
> > they do have such a program.  Is that acceptable?
> 
> I don't know; I don't use MS-Windows.  But if we can do it natively,
> perhaps it is acceptable to not be able to use an external command.
> 
> If we're fine with that limitation, I see that Po Lu added support for
> Haiku, and I think MS-Windows could do something similar to that.

I added support for this on MS-Windows.  Strangely, it works with some
images, but not with others.  On XP, only BMP images seem to work (and
I think I saw someone on the Internet saying this is all XP supports).
On Windows 10, I can set the wallpaper to JPEG images as well, but
some don't work.  I guess someone more knowledgeable than myself will
have to fix whatever needs fixing here.

Ken, the code is currently enabled only for WINDOWSNT, but if you
think it could work and be useful in the Cygwin w32 build, please
remove the conditionals.

Re: New library wallpaper.el pushed to master

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I added support for this on MS-Windows.  Strangely, it works with some
> images, but not with others.  On XP, only BMP images seem to work (and
> I think I saw someone on the Internet saying this is all XP supports).
> On Windows 10, I can set the wallpaper to JPEG images as well, but
> some don't work.  I guess someone more knowledgeable than myself will
> have to fix whatever needs fixing here.

Perhaps Emacs could convert the wallpapers to the appropriate format
using any installed external conversion programs?

Re: New library wallpaper.el pushed to master

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  Ken Brown <kbrown@cornell.edu>,
>   emacs-devel@gnu.org
> Date: Thu, 15 Sep 2022 21:39:47 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I added support for this on MS-Windows.  Strangely, it works with some
> > images, but not with others.  On XP, only BMP images seem to work (and
> > I think I saw someone on the Internet saying this is all XP supports).
> > On Windows 10, I can set the wallpaper to JPEG images as well, but
> > some don't work.  I guess someone more knowledgeable than myself will
> > have to fix whatever needs fixing here.
> 
> Perhaps Emacs could convert the wallpapers to the appropriate format
> using any installed external conversion programs?

Which ones?  The ones I know about are unlikely to be installed on
Windows.

And I don't know what are the requirements for "appropriate format",
so I wouldn't know how to invoke those programs, even if they are
available.  If you or someone else knows, feel free to make the
necessary changes.

(Btw, my trials with installing wallpapers all used only the images
that Windows itself succeeds to install, somehow, if one goes via the
Display->Personalize dialogs.  I never tried even a single image file
that is not under C:\Windows\Web\Wallpaper.)

Re: New library wallpaper.el pushed to master

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Which ones?  The ones I know about are unlikely to be installed on
> Windows.

I think ImageMagick is one of those.

> And I don't know what are the requirements for "appropriate format",
> so I wouldn't know how to invoke those programs, even if they are
> available.  If you or someone else knows, feel free to make the
> necessary changes.

Well, I was thinking of the formats that work, such as BMP images on
Windows XP.

> (Btw, my trials with installing wallpapers all used only the images
> that Windows itself succeeds to install, somehow, if one goes via the
> Display->Personalize dialogs.  I never tried even a single image file
> that is not under C:\Windows\Web\Wallpaper.)

I suppose Windows could be doing the conversion to BMP under-the-hood
somehow?

Re: New library wallpaper.el pushed to master

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> I have now pushed the new library wallpaper.el and changed thumbs.el and
> image-dired.el to use it.  It has the new command `wallpaper-set', and
> the user option `wallpaper-commands' to control it.

Why does it check `display-graphic-p'?
Setting the background image should work in a TTY as well.

Thanks.

Re: New library wallpaper.el pushed to master

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Why does it check `display-graphic-p'?
> Setting the background image should work in a TTY as well.

BTW, what about actions usually taken to modify the wallpaper such as
scaling, cropping, and offsets?  Shouldn't wallpaper-set take several
arguments to specify those?

Re: New library wallpaper.el pushed to master

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Why does it check `display-graphic-p'?
>> Setting the background image should work in a TTY as well.

If I'm not mistaken, under X, you would need $DISPLAY to be set for it
to work.  And that variable is not set by default in a TTY.

Testing this on the Linux console, it only works if I do:

    DISPLAY=:0.0 feh --bg-fill some-image.png

My assumption is that $WAYLAND_DISPLAY works similarly (but I've never
used Wayland so I have no idea really).

Do you have any ideas for how to do this better?  I guess that

    (setenv "DISPLAY" ":0.0")

will only work for single-user machines.  Maybe that's okay, though.

Or maybe we should just check if $DISPLAY and/or $WAYLAND_DISPLAY are
set first?

Or maybe we should just ignore any errors and let users figure it out?
But that seems a bit drastic, perhaps.

> BTW, what about actions usually taken to modify the wallpaper such as
> scaling, cropping, and offsets?  Shouldn't wallpaper-set take several
> arguments to specify those?

For now, the idea is that the user will be able to configure this by
changing `wallpaper-commands'.  Ideally, we would have a defcustom to
control the default operation while being agnostic of the actual command
used.  But then you have different capabilities in different software to
consider too.

Re: New library wallpaper.el pushed to master

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> If I'm not mistaken, under X, you would need $DISPLAY to be set for it
> to work.  And that variable is not set by default in a TTY.

That depends on the program.  On X systems, some program running in the
background typically manages the desktop background.  The value of
DISPLAY usually does not matter, and you can only set the background
image for the currently running local desktop anyway.

> Testing this on the Linux console, it only works if I do:
>
>     DISPLAY=:0.0 feh --bg-fill some-image.png

Isn't feh the odd one out here, since it actually displays the wallpaper
itself instead of changing a desktop setting?

> My assumption is that $WAYLAND_DISPLAY works similarly (but I've never
> used Wayland so I have no idea really).

Programs like feh cannot be implemented on Wayland as a matter of
principle, without protocol extensions provided by wlroots (and
wlroots-based compositors.)  So the approach of drawing to the desktop
will not work on, say, GNOME or KDE Wayland.

> Or maybe we should just ignore any errors and let users figure it out?
> But that seems a bit drastic, perhaps.

I'd prefer this, honestly, since most users will be using a desktop
environment where DISPLAY does not matter.

> For now, the idea is that the user will be able to configure this by
> changing `wallpaper-commands'.  Ideally, we would have a defcustom to
> control the default operation while being agnostic of the actual command
> used.  But then you have different capabilities in different software to
> consider too.

But on systems like Haiku and MS Windows, there are no commands to
customize, and system APIs are used instead.

I think all systems let you choose between scaling and cropping the
image to fit the screen, and leaving the image intact.  If it turns out
one of the programs we use does not, then that option can just be left
unimplemented.

Re: New library wallpaper.el pushed to master

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Isn't feh the odd one out here, since it actually displays the wallpaper
> itself instead of changing a desktop setting?

I'm guessing that xloadimage and perhaps a few others do the same.  But
I've added commands for KDE Plasma, and we already had Gnome so
hopefully that should already cover most use cases.  I'm looking into
adding XFCE support, too.

Are there any other important desktop environments that we would want to
support?

> I'd prefer this, honestly, since most users will be using a desktop
> environment where DISPLAY does not matter.

`wallpaper-set' should now work from a TTY, modulo the fact that some
external software (e.g. "feh") still won't.  Testing welcome.

Re: New library wallpaper.el pushed to master

[Stefan Kangas]

Stefan Kangas <stefankangas@gmail.com> writes:

> I'm looking into adding XFCE support, too.

Actually, I won't be doing that.  Someone with access to XFCE will have
to do it, as it seems to be a PITA to get right, e.g.:

https://unix.stackexchange.com/questions/596070/how-to-change-wallpaper-on-xfce-from-terminal

Re: New library wallpaper.el pushed to master

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Are there any other important desktop environments that we would want to
> support?

I will work on CDE if I get the time.  Otherwise, there's also Cinnamon
and Mate (both of these should probably be a matter of adjusting the
GNOME commands for renames, and some minor differences in command line
arguments).

Re: New library wallpaper.el pushed to master

[Sean Whitton]

Hello,

On Wed 14 Sep 2022 at 03:33PM +08, Po Lu wrote:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> My assumption is that $WAYLAND_DISPLAY works similarly (but I've never
>> used Wayland so I have no idea really).
>
> Programs like feh cannot be implemented on Wayland as a matter of
> principle, without protocol extensions provided by wlroots (and
> wlroots-based compositors.)  So the approach of drawing to the desktop
> will not work on, say, GNOME or KDE Wayland.

Here on Sway on Wayland, Emacs would have to do the equivalent of this:

  pkill swaybg && swaybg --image foo.png --output "*" & disown

-- 
Sean Whitton

Re: New library wallpaper.el pushed to master

[Stefan Kangas]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Here on Sway on Wayland, Emacs would have to do the equivalent of this:
>
>   pkill swaybg && swaybg --image foo.png --output "*" & disown

There is currently no support for running more than one command; the
assumption is that only one command is needed.  Perhaps this is not true
in the general case, so maybe that should be changed.

It also sounds somewhat dangerous to run the equivalent of "pkill
swaybg", so would we want to prompt the user before doing that?

Re: New library wallpaper.el pushed to master

[Sean Whitton]

Hello,

On Thu 15 Sep 2022 at 12:28AM -07, Stefan Kangas wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> Here on Sway on Wayland, Emacs would have to do the equivalent of this:
>>
>>   pkill swaybg && swaybg --image foo.png --output "*" & disown
>
> There is currently no support for running more than one command; the
> assumption is that only one command is needed.  Perhaps this is not true
> in the general case, so maybe that should be changed.
>
> It also sounds somewhat dangerous to run the equivalent of "pkill
> swaybg", so would we want to prompt the user before doing that?

Yeah.  Perhaps the 'wbg' command Felix mentioned already takes care of
killing off any other process that is trying to display wallpaper?  If
so, that'd be preferable.

-- 
Sean Whitton

Re: New library wallpaper.el pushed to master

[Po Lu]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Yeah.  Perhaps the 'wbg' command Felix mentioned already takes care of
> killing off any other process that is trying to display wallpaper?  If
> so, that'd be preferable.

BTW, none of these programs will work if the Wayland compositor in
question is not wlroots-based, and thus supports wlr_layer_shell.  So
even if wbg or swaybg are installed, they should only be used on Sway
and similar compositors.

Re: New library wallpaper.el pushed to master

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 14 Sep 2022 14:39:46 +0800
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Why does it check `display-graphic-p'?
> > Setting the background image should work in a TTY as well.
> 
> BTW, what about actions usually taken to modify the wallpaper such as
> scaling, cropping, and offsets?  Shouldn't wallpaper-set take several
> arguments to specify those?

No, I think it should just use the image.  If the user wants to modify
the image, he/she can do that using "other means", including the
lately introduced 'image-crop' command.  There's no reason to make
this simple facility understand too much about images and their
formats.

Re: New library wallpaper.el pushed to master

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> BTW, what about actions usually taken to modify the wallpaper such as
>> scaling, cropping, and offsets?  Shouldn't wallpaper-set take several
>> arguments to specify those?
>
> No, I think it should just use the image.  If the user wants to modify
> the image, he/she can do that using "other means", including the
> lately introduced 'image-crop' command.  There's no reason to make
> this simple facility understand too much about images and their
> formats.

I guess what Po Lu had in mind was supporting options such as the
following, from the "feh" man page:

  --bg-center
          Center the file on the background.  If it is too small, it will
          be surrounded by a border as specified by --image-bg.

  --bg-fill
          Like --bg-scale, but preserves aspect ratio by zooming the image
          until it fits.  Either a horizontal or a vertical part of the im‐
          age will be cut off

  --bg-max
          Like --bg-fill, but scale the image to the maximum size that fits
          the screen with borders on one side.  The border color can be set
          using --image-bg.

  --bg-scale
          Fit the file into the background without repeating it, cutting
          off stuff or using borders.  But the aspect ratio is not pre‐
          served either

  --bg-tile
          Tile (repeat) the image in case it is too small for the screen

I think it would be worthwhile to add some defcustoms for this, as this
is likely to be something that users will commonly want to customize.

But I agree with Po Lu that we should try to make this transparent with
regards to the tool.  Perhaps we could add a `wallpaper-default-method'
option with values like `center', `fill', `max', `scale', and `tile'.

Re: New library wallpaper.el pushed to master

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 14 Sep 2022 07:52:39 -0400
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> BTW, what about actions usually taken to modify the wallpaper such as
> >> scaling, cropping, and offsets?  Shouldn't wallpaper-set take several
> >> arguments to specify those?
> >
> > No, I think it should just use the image.  If the user wants to modify
> > the image, he/she can do that using "other means", including the
> > lately introduced 'image-crop' command.  There's no reason to make
> > this simple facility understand too much about images and their
> > formats.
> 
> I guess what Po Lu had in mind was supporting options such as the
> following, from the "feh" man page:

Slippery slope alert!  These options are likely to vary or even fail
to exist in other commands or methods that we want to support in
wallpaper.el, in which case we are introducing behavioral differences
between platforms for now good reason.

Re: New library wallpaper.el pushed to master

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Slippery slope alert!  These options are likely to vary or even fail
> to exist in other commands or methods that we want to support in
> wallpaper.el, in which case we are introducing behavioral differences
> between platforms for now good reason.

Yes, it is likely to be less clean than we'd like, unfortunately.

On the other hand, I think users might appreciate it.

Re: New library wallpaper.el pushed to master

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Slippery slope alert!  These options are likely to vary or even fail
> to exist in other commands or methods that we want to support in
> wallpaper.el, in which case we are introducing behavioral differences
> between platforms for now good reason.

I think what I proposed is a reasonable subset that is supported by
most, if not all, desktops and platforms.

Re: New library wallpaper.el pushed to master

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> I think what I proposed is a reasonable subset that is supported by
> most, if not all, desktops and platforms.

Makes sense to me, FWIW.