Subject: FVWM: FvwmRandomBack

From: Guido Berhoerster <[email-masked]>
Date: Mon, 5 Jan 2004 20:25:56 +0100

Hello,
some time ago I wrote a little perl script in order to set a
random background image and recently I added some features and made
an Fvwm module out of it. It's called FvwmRandomBack and it's
pretty simple but for me it does what it is supposed to do and I
thought that maybe someone else might find it useful. I put it up
for download at http://www.guido-berhoerster.org/downloads/ (at
the bottom of the page).
FvwmRandomBack depends on the Image::Magick perl module which is
part of ImageMagick (http://www.imagemagick.org). In order to
install FvwmRandomBack simply put it somewhere within Fvwm's
ModulePath and make it execuatble.
Here is its included manpage:
----snip----
NAME
       FvwmRandomBack - a FVWM module to display a random image in the root
       window

SYNOPSIS
       Module FvwmRandomBack

       FvwmRandomBack can only be invoked by fvwm. Command line invocation of
       the module will not work.

DESCRIPTION
       FvwmRandomBack recursively searches a directory for all images in GIF,
       JPEG, PNG, or XPM format, selects one randomly and displays it in the
       root window.

       If the image is bigger than the current viewport it will be resized and
       cropped accordingly. Otherwise it will either be tiled or optionally
       magnified.  FvwmRandomBack uses ImageMagick's perl module in order to
       modify and convert the image and fvwm-root to set the root window.

INVOCATION
       FvwmRandomBack can be invoked by fvwm with the command 'Module
       FvwmRandomBack' at any time. After setting the root window to a random
       image it will exit. It might be convenient to invoke FvwmRandomBack
       during initialization by adding

           AddToFunc StartFunction I Module FvwmRandomBack

       to the fvwm configuration file.

       FvwmRandomBack needs to be executable and must reside in a directory
       which is listed in ModulePath.

OPTIONS
       *FvwmRandomBack: ImagePath path
            The path where the images can be found.

       *FvwmRandomBack: TmpDir path
            Specifies the directory where a temporary copy of the image will
            be stored in.

       *FvwmRandomBack: Magnify
            Magnify images which are smaller than the current viewport instead
            of tiling them.

       *FvwmRandomBack: RetainPixmap
            Causes FvwmBacker to retain and publish the Pixmap with which the
            background has been set. For more information see the FvwmTheme
            manpage and the fvwm-root manpage.

AUTHOR
       Guido Berhoerster <[email-masked]>
----snap----
I'm not a perl hacker and I have hardly any experience in writing
Fvwm modules in perl, thus I would very much welcome any
feedback.
-- 
Guido Berhoerster    [email-masked]
                     http://www.guido-berhoerster.org/
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 5 Jan 2004 21:32:54 +0000

> Fvwm modules in perl, thus I would very much welcome any

There is no much to comment, since it is a small short-lived script.
But there are some notes that are correct for any FVWM module written in
Perl, so this may be useful to all Perl writers.

First, you may replace all 3 "use Some::Module;" lines with one:

  use FVWM::Module::Toolkit qw( File::Find Image::Magick );

This loads the specified perl classes, or shows a nice error window if
any of them are not installed on the user's system and exits.

Optionally, you may replace "new FVWM::Module" with "new
FVWM::Module::Toolkit", the first class writes all debug, errors and
messages to standard output, the second opens dialog windows instead,
this may be more user friendly or more annoying, depending on a module.

Run "fvwm-perllib man FVWM::Tracker::PageInfo" to see how to find the
screen dimensions in your module.

Regards,
Mikhael.

---

From: Guido Berhoerster <[email-masked]>
Date: Tue, 6 Jan 2004 11:50:08 +0100

> any of them are not installed on the user's system and exits.

Having an xmessage pop up is more informative than a log message,
I'll change this.

> screen dimensions in your module.

I must have overlooked this one, it's much better than relying on
xdpyinfo.

Thanks for your comments.

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 6 Jan 2004 23:42:55 +0000

> for download at http://www.guido-berhoerster.org/downloads/ (at

I just noticed that your script has a non GNU GPL compatible license.
(Or maybe it is compatible, hard to say, this is not really important.)

Not only this disallows the script to be included into fvwm in one or
another form, but I think this is not legal. Since this script depends
on the GPL'd library FVWM::Module, it should be GPL'd as well.

Of course, any private usage of the library for any purpose is welcome,
the issue only becomes relevant when you start distribute your script
(that happens to be an fvwm module) to others.

I hope you will correct the license.

Regards,
Mikhael.

---

From: Guido Berhoerster <[email-masked]>
Date: Wed, 7 Jan 2004 15:40:50 +0100

> (Or maybe it is compatible, hard to say, this is not really important.)

It is the modified BSD-License and compatible with the GPL, see
http://www.gnu.org/licenses/license-list.html#ModifiedBSD

> on the GPL'd library FVWM::Module, it should be GPL'd as well.

Since it is GPL-compatible it may very well be included into fvwm. The
module code itself does not contain any code from the fvwm sources but
uses the library at runtime, I would consider this as something like
dynamic linking against a library, please see
http://www.linuxgazette.com/issue38/kidd.html#free-software
(a quote from RMS)
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL (last
paragraph mentions this case) and
So in my understanding this is legal, please feel free to prove me
wrong.

> I hope you will correct the license.

Well, it's already publicly available, so I'm kind of
distributing it. Coming from a *BSD-background I prefer the
BSD-License since it has less restrictions but should it not be
legal (I'm not convinced yet) I will change it to GPL.
-- 
Guido Berhoerster    [email-masked]
                     http://www.guido-berhoerster.org/
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 7 Jan 2004 19:15:05 +0000

> So in my understanding this is legal, please feel free to prove me

Ok, I think I have no problem if the code in the script is under the
new BSDL (I didn't recognize it), and the resulting script executable is
covered by the GNU GPL, as quoted.

However I think it may be considered good if all code that depends on the
GNU GPL'd library is at least dual licensed, making derivatives under GNU
GPL trivial (or interoperability trivial, for this reason). Currently my
understanding is that the BSDL header should be left untouched in the
derived GPL'd work, that is a nonsense.

If my understanding is wrong and the BSDL header (anything under the
copyright notice) may be just replaced with the GNU GPL'd header then
there is no any issue.

Regards,
Mikhael.

---

From: Guido Berhoerster <[email-masked]>
Date: Thu, 8 Jan 2004 12:11:44 +0100

> copyright notice) may be just replaced with the GNU GPL'd header then

Well in contrast to the GPL the main point of the (modified)
BSD-License is to give credit to the author, so the copyright
line and the two license conditions and the disclaimer need to be
preserved. I think the GPL header is quite similar to this, see
http://www.gnu.org/copyleft/gpl.html#SEC4
But other than that there are no restrictions, everybody is free
to do whatever her or she wants to do with it, it may be included
in a GPL'd project or it may even be used in a commercial closed
source program. I prefer this kind of freedom but I have no
objections against the GPL either, it's a matter of philosophy
and personal preference. Should I ever write something which is
less simple and more useful or which might even be included in
fvwm I will put it under the GPL (which is probably longer than
this tiny module).
-- 
Guido Berhoerster    [email-masked]
                     http://www.guido-berhoerster.org/
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 8 Jan 2004 12:45:08 +0000

> fvwm I will put it under the GPL (which is probably longer than

Ok, I am glad you understand that having only one license in the project
enourmously simplifies all things, you should never ever think about
legal issues. The issue is very real, since maintaining multiple scripts
and modules always means patching all of them on many occasions.

Regards,
Mikhael.