JWM background utility creates backup image? [SOLVED]

[geo_c]

It took me until now to figure this out. It seems that when using the background chooser included in JWM-desk, if the image is changed to fit the desktop, I believe using the "distort" option, then a backup image is created in a directory named after the source directory of the background and pre-pended with "Original" -- as in an image that came from /mnt/home/geobackgrounds that has been distorted to fit the monitor resolution will be saved in the source location under the original name, and the original file moved to /mnt/home/Original-geobackgrounds.

Since I collect backgrounds and load them from my collection directory, I don't like that it moves the original because it's confusing. Any one else notice this? I've been using this utility for a few years but it just now became clear what was happening. I initially thought that gimp was creating the backup directory when I edited an image, but I believe it's the background changer now.

[williwaw]

what app does jwmdesk point to for a background chooser?

[geo_c]

what app does jwmdesk point to for a background chooser?

This one here:

[williwaw]

I remember nathan's wallpaper setter from a while back, perhaps search the old forum? maybe its a script you can tweak, I know you work a lot with wallpapers and there might be a backend or dependency in nathans that you could run directly?

[williwaw]

https://wiki.archlinux.org/title/Feh

[mikewalsh]

@geo_c :-

I think you'll find this is all down to ROX itself, not the background switcher. And I doubt it's anything to do with JWM, either.

As a graphic artist, I do a lot of image editing. I noticed several years ago that, whenever you modify any image for the first time, ROX creates an 'Originals' sub-directory within the directory in which you're currently working......with a copy of the image you're working on, prior to modification.

After you modify any image for the second time - OR modify a second image - a blank, "photothumb.db" file will be created, followed the next time by a "Thumbs.db" SQL file.

ROX will do this in ANY directory containing images that get modified in any way at all.

---------------------------------------------------------------------------

It doesn't matter what you use to edit them with. The G.I.M.P; I use MooiTech's 'PhotoScape' running under WINE, which I started using in Windoze XP around 15 years ago; XNView; PhotoShop - I have the CS2 suite which I actually bought back in the early "noughties"; Shotwell; Fotoxx.....the point being, these modifications appear in ROX regardless of what the images have been modified WITH.

This is why I assumed that ROX itself is responsible. I may be wrong - I frequently AM! - but that's the conclusion I eventually came to.

Mike.

[MochiMoppel]

This is why I assumed that ROX itself is responsible. I may be wrong - I frequently AM! -

ROX has nothing to do with it. Here is what happens in Slacko5.6:
The background shuffle thing starts in /root/.xinitrc, i.e. during the boot process
If /root/.xinitrc finds no file /usr/share/backgrounds_original/ORIGINAL-default.jpg (or .png) it calls the script
/usr/sbin/background_reshape. This script does the actual shuffle (if needed manipulates an image file to fit the screen but in any case saves a copy of the original to a </path/of/imagefolder>_original folder). Other utilities like JWMdesk may use this script too but ROX definitely does not when you use ROX's "Set backdrop" dialog.

It seems that when using the background chooser included in JWM-desk, if the image is changed to fit the desktop, I believe using the "distort" option, then a backup image is created in a directory named after the source directory of the background and pre-pended with "Original"

The background_reshape script prevents distortion. It cuts top and bottom portions of the original file to fit the screen's x/y ratio. Example: The script cut a 600x480 image to 600x300 when I made the script believe that my screen resolution is 2000x1000, so both now have a 2:1 ratio and the 600x300 image can be scaled to 2000x1000 without distortion.

[geo_c]

Example: The script cut a 600x480 image to 600x300 when I made the script believe that my screen resolution is 2000x1000, so both now have a 2:1 ratio and the 600x300 image can be scaled to 2000x1000 without distortion.

What you say makes sense. My backgrounds folder is in constant flux with files being renamed and moved, chosen from different locations in the backgrounds directory tree. Those directories are located outside the system. Often I will boot up an infrequently used puppy and the last saved background will not be present anymore.

If I understand correctly, you're saying on boot if an image needs to be reshaped, then the originals directory and file is created at that time. So in the case of me shuffling my files, and booting into another infrequently used system, I'm forcing the creation of an originals file by eliminating the last active background before rebooting.

When building some backgrounds for KLV, I used gimp to create various aspect ratios and resolutions, did the resizing there and exported to jpg, which necessitates creating 5 or more versions of the same background. That seems the most sure method for achieving a consistent result, but it's the most time consuming.

More recently I've taken the approach of using backgrounds that are more friendly to being randomly cropped by the background chooser mechanism. Apparently my new method defaults the reshape task to the boot script.

I actually started using Viewnior a day or two ago to set the background. It works well. No options on how to reshape it though.

[MochiMoppel]

If I understand correctly, you're saying on boot if an image needs to be reshaped, then the originals directory and file is created at that time.

Not quite what I said. Even if the background image doesn't need reshaping or if no background image is used at all, at boot the .xinitrc will - via background_reshape script - force a the creation of a /usr/share/backgrounds_original directory and a copy of the default.jpg or .png image. An image with that name must reside in the )/usr/share/backgrounds, otherwise the script will do nothing. I think the idea is to ensure that, when a pristine Puppy starts with a PuppyPin, having default image as wallpager, that the wallpaper matches the ratio of the screen.

I actually started using Viewnior a day or two ago to set the background. It works well. No options on how to reshape it though.

Probably a better idea since no _original folders are created. Viewnior did nothing when I tried but maybe I did something wrong. In any case all kinds of reshaping/scaling can be selected in the ROX dialog.

[EDIT] I'm now in F96_4-radky6-CE. Completely different here. No background_reshape script anymore thus no _original folders. JWMdesk uses Nathan's Wallpaper changer, and this changer is appears to be a frontend for ROX's SetBackdrop SOAP command. It is the same as if manually dropping an image file on ROX's "Set backdrop" dialog window. What's missing in Nathan's script is the "Fit" option, probably because for obscure reasons this style can't be set with SOAP.

[geo_c]

Even if the background image doesn't need reshaping or if no background image is used at all, at boot the .xinitrc will - via background_reshape script - force a the creation of a /usr/share/backgrounds_original directory and a copy of the default.jpg or .png image. An image with that name must reside in the )/usr/share/backgrounds, otherwise the script will do nothing.

[EDIT] I'm now in F96_4-radky6-CE. Completely different here. No background_reshape script anymore thus no _original folders. JWMdesk uses Nathan's Wallpaper changer, and this changer is appears to be a frontend for ROX's SetBackdrop SOAP command. It is the same as if manually dropping an image file on ROX's "Set backdrop" dialog window. What's missing in Nathan's script is the "Fit" option, probably because for obscure reasons this style can't be set with SOAP.

That's all interesting stuff. I need to explore it more, because I've also been getting "originals" folders and images in locations that aren't /usr/share/ -- in other words in places where I've grabbed backgrounds from their original location.

[MochiMoppel]

I need to explore it more, because I've also been getting "originals" folders and images in locations that aren't /usr/share/ -- in other words in places where I've grabbed backgrounds from their original location.

That's just the way how background_reshape works. I propose you make a small test: Create a folder /tmp/testpics and put it some image files (must be .jpg or .png), e.g. a file foo.jpg. Then, from a console window, run background_reshape /tmp/testpics/foo.jpg and see what happens.

[geo_c]

Then, from a console window, run background_reshape /tmp/testpics/foo.jpg and see what happens.

Hey now that's really handy. It didn't change the desktop background but it created one to fit my current monitor. And of course it moved the original to /tmp/tespics_original.

So I guess what Nathan's wallsetter is doing is running reshape when the "distort" option is used. Other's like "fit" are just zooming on the image. Maybe "scale" runs reshape also. I'll have to check.

[MochiMoppel]

So I guess what Nathan's wallsetter is doing is running reshape when the "distort" option is used. Other's like "fit" are just zooming on the image.

No, it doesn't run background_reshape. Where do you see a "distort" or a "fit" option? Which distro you are using?

[geo_c]

Where do you see a "distort" or a "fit" option? Which distro you are using?

Normally I'm running jackalpup, which is pretty straight fossapup, and I have JWMdesk3.6 installed:

[MochiMoppel]

I can't access your linked image. Could you please use the BB attachment function?

[geo_c]

Screenshot(24).jpg.gz

(143.42 KiB) Downloaded 18 times

@MochiMoppel
remove the fake gz

[MochiMoppel]

OK, but that doesn't look like (Nathan's ) wallpaper application. What is it?

[geo_c]

It's called Wallpaper-0.7.7.0 written by Nathan Fisher in 2006 especially for Grafpup Linux according to the help-about.

I posted it earlier in the thread and @williwaw called it Nathan's Wallpaper, which is why I refer to it that way. Perhaps it's different.

[geo_c]

Also, they look the same, don't be fooled by my red gtk theme. Everything is laid out the same way except for those extra two options.

edit, no I take that back, there are some key differences, mostly the way the window is arranged.

Did @radky revamp it for JWMdesk?

[williwaw]

some history

https://github.com/step-/nathans-wallpaper#readme

[geo_c]

[That's just the way how background_reshape works. I propose you make a small test: Create a folder /tmp/testpics and put it some image files (must be .jpg or .png), e.g. a file foo.jpg. Then, from a console window, run background_reshape /tmp/testpics/foo.jpg and see what happens.

So I believe you said background_reshape is a script. Being that it's a script, does it accept wildcard characters in the argument? In other words could I reshape a directory full of images, and even recursively? Maybe like:

Code: Select all

background_reshape /tmp/testpics/*

[MochiMoppel]

Being that it's a script, does it accept wildcard characters in the argument?

No.