Editing Your Linux Wallpaper

[Alexzee]

A tutorial I just put together for editing wallpapers in GIMP.

Editing Wallpapers For Your Linux Distribution

Now that you have the Linux operating system you want installed, you can fancy up the desktop with a custom wallpaper.I'll cover how to do that here using GIMP. GIMP is short for the GNU Image Manipulation Program.Now you'll need to find a wallpaper website of course of your style of choice...

writerforlinux.wixsite.com

 

[Alexzee]

Here are some other really cool websites for desktop wallpapers:

https://www.freepik.com/search?format=search&last_filter=page&last_value=4&page=4&query=digital+wallpapers+1920+x+1080#uuid=592d0884-a684-419e-8744-9e493fef76e3

Art wallpapers full hd, hdtv, fhd, 1080p, desktop backgrounds hd, pictures and images

1920x1080 best hd wallpapers of art, full hd, hdtv, fhd, 1080p desktop backgrounds for pc & mac, laptop, tablet, mobile phone

wallpaperscraft.com

Moon 1920x1080 Resolution Wallpapers Laptop Full HD 1080P

Download 1920x1080 Moon Wallpapers For Laptop Full HD 1080P Devices in 1920x1080 Resolution

hdqwalls.com

Enjoy the day!

 

[MikeWalsh]

@Alexzee :-

I tend to find my backgrounds through the application of mucho "DuckDuckGo-fu" (an expression I've shamelessly 'borrowed' from JasKinasis. I like that!)

As for the editing side of things, well; you've all seen several of my desktop backgrounds by now, in the 'Post a screenshot of your Desktop' thread. I DO use the GIMP plenty, for quite a bit of stuff.....but for my desktop backgrounds, I've yet to find anything that can touch MooiTech's PhotoScape, running under WINE.

PhotoScape - Wikipedia

en.wikipedia.org

PhotoScape

www.photoscape.org

For the way I like to do things on my desktops, it cannot be beaten; I began using it in very early 'beta' form back under XP, around 2008/9.....and got really, really 'handy' with it. It's one of very few image editors that really can be called "intuitive". I was extremely chuffed to find it ran perfectly under WINE.....but if I'm honest, most XP-era graphic editors seem to.

Thanks for the tutorial though, mate. It's the kinda thing that's ALWAYS appreciated..!


Mike.

 

[Alexzee]

@Alexzee :-

I tend to find my backgrounds through the application of mucho "DuckDuckGo-fu" (an expression I've shamelessly 'borrowed' from JasKinasis. I like that!)

As for the editing side of things, well; you've all seen several of my desktop backgrounds by now, in the 'Post a screenshot of your Desktop' thread. I DO use the GIMP plenty, for quite a bit of stuff.....but for my desktop backgrounds, I've yet to find anything that can touch MooiTech's PhotoScape, running under WINE.

PhotoScape - Wikipedia

en.wikipedia.org

PhotoScape

www.photoscape.org

For the way I like to do things on my desktops, it cannot be beaten; I began using it in very early 'beta' form back under XP, around 2008/9.....and got really, really 'handy' with it. It's one of very few image editors that really can be called "intuitive". I was extremely chuffed to find it ran perfectly under WINE.....but if I'm honest, most XP-era graphic editors seem to.

Thanks for the tutorial though, mate. It's the kinda thing that's ALWAYS appreciated..!


Mike.

Good info on PhotoScape.
I see that the program is available on the Wikipedia page for Linux as a snap pkg.

Snaps, AFAIK, won't work on my Slackware 15 system.

Writing articles for the Linux Community is my way of giving back.
Thanks, Mike

 

[MikeWalsh]

@Alexzee :-

Good info on PhotoScape.
I see that the program is available on the Wikipedia page for Linux as a snap pkg.

I'll be damned. I missed that! However, I've GOT to laugh.....because SnapCraft have done precisely what I did myself around 3-3½ years ago.

~~~~~~~~~~~~~~~~~~~~~~​

Out of all the Linux 'portable' formats, I've always preferred the AppImage. They don't need a 'support' framework permanently installed before they'll function - unlike Snaps or FlatPaks - and their ONLY requirement is that FUSE be installed (Filesystem in USEr-space). This allows them to unpack their contents into a sand-boxed, virtual file-system they create in /tmp for the duration.....and it's from here that they in fact run.

A correctly-assembled AppImage contains absolutely everything it needs to run......and FUSE is pretty much standard across most distros these days.

When WINE builds began to be available as an AppImage - I get mine from here - I immediately sussed-out that this was by far the simplest way of running WINE in Linux. All that is needed is for the WINE AppImage to be sym-linked into /usr/bin 3 times.....as 'wine', 'wine32', and 'wineserver'. It's as simple as that. Then you just run

wine winecfg

....in the terminal to set up your 'prefix', where the virtual Windows install exists.

~~~~~~~~~~~~~~~~~~~~~​

PhotoScape has for a long while been available as a Windows 'PortableApp', from here. Anyway, I got to thinking (given my proclivities for building 'portable' applications, you can see where this is going, can't you?); put a WINE AppImage AND the portable build of PhotoScape together in a single directory, script the AppImage to link itself into /usr/bin, followed by the 'prefix' being created the first time you use it, then immediately followed by the portable PhotoScape firing-up. After the first run, PhotoScape just fires-up as though you were running it natively in Windows (although securely sand-boxed in /tmp).

The final pieces of this puzzle are provided by Puppy's ROX-filer FM, and hinge on its very powerful (and versatile) sym-linking function, along with its ability to create & use what are known as "executable directories". As long as a file called "AppRun" - just a sym-link to the launcher script will do - is present within the directory, a single click on the directory itself is all that's needed to set things in motion.

When you're finished, the app shuts down & the WINE symlinks in /usr/bin disappear into cyberspace. I've also set things up so the 'virtual Windows' (within the 'prefix') ALSO lives within the 'portable' directory, being sym-linked into position when the whole shebang launches. Nothing is left within the file-system at all when it closes.

I built this self-contained 'portable' version of PhotoScape for anybody who may want to run PhotoScape & play around with it, without having WINE permanently installed. I thought I was quite unusual in using PhotoScape, but it turns out - over the last few years - that the app is well-known and pretty widely used by an awful lot of people.....many of whom would like to be able to temporarily run it within Linux without actually having WINE installed.

~~~~~~~~~~~~~~~~~~~~~~~~~​

Doubtless the Snap build does exactly the same as my own solution, with one big disadvantage; Snaps have to be within the file-system when you run them, whereas the WINE AppImage/portable PhotoScape combo can live completely outside the OS.....and run purely via sym-links.

It works beautifully.......and you've seen some of the results I achieve with it.

(Since the WINE AppImages are so simple to use, I also produce self-contained 'portable' builds of it for the Puppy community (with scripts provided to 'link' or 'unlink' them).. I have half-a-dozen different WINE builds set-up - for different purposes - on my big secondary data drive.....and built my own GUI (using YAD) that permits easy 'swapping-over' between builds, AND lets me see at a glance which version is currently linked in to the system.)

With the exception of needing to modify user-permissions throughout the application (remember, Puppies 'run-as-root' all the time!), I can't see any reason why this wouldn't run in a mainstream distro.

Sorry for the length of this missive.....and for perhaps dragging your thread off-track!.....but I felt a bit of background would be helpful, too.


Mike.

 

[Alexzee]

@Alexzee :-



I'll be damned. I missed that! However, I've GOT to laugh.....because SnapCraft have done precisely what I did myself around 3-3½ years ago.

~~~~~~~~~~~~~~~~~~~~~~​

Out of all the Linux 'portable' formats, I've always preferred the AppImage. They don't need a 'support' framework permanently installed before they'll function - unlike Snaps or FlatPaks - and their ONLY requirement is that FUSE be installed (Filesystem in USEr-space). This allows them to unpack their contents into a sand-boxed, virtual file-system they create in /tmp for the duration.....and it's from here that they in fact run.

A correctly-assembled AppImage contains absolutely everything it needs to run......and FUSE is pretty much standard across most distros these days.

When WINE builds began to be available as an AppImage - I get mine from here - I immediately sussed-out that this was by far the simplest way of running WINE in Linux. All that is needed is for the WINE AppImage to be sym-linked into /usr/bin 3 times.....as 'wine', 'wine32', and 'wineserver'. It's as simple as that. Then you just run

wine winecfg

....in the terminal to set up your 'prefix', where the virtual Windows install exists.

~~~~~~~~~~~~~~~~~~~~~​

PhotoScape has for a long while been available as a Windows 'PortableApp', from here. Anyway, I got to thinking (given my proclivities for building 'portable' applications, you can see where this is going, can't you?); put a WINE AppImage AND the portable build of PhotoScape together in a single directory, script the AppImage to link itself into /usr/bin, followed by the 'prefix' being created the first time you use it, then immediately followed by the portable PhotoScape firing-up. After the first run, PhotoScape just fires-up as though you were running it natively in Windows (although securely sand-boxed in /tmp).

The final pieces of this puzzle are provided by Puppy's ROX-filer FM, and hinge on its very powerful (and versatile) sym-linking function, along with its ability to create & use what are known as "executable directories". As long as a file called "AppRun" - just a sym-link to the launcher script will do - is present within the directory, a single click on the directory itself is all that's needed to set things in motion.

When you're finished, the app shuts down & the WINE symlinks in /usr/bin disappear into cyberspace. I've also set things up so the 'virtual Windows' (within the 'prefix') ALSO lives within the 'portable' directory, being sym-linked into position when the whole shebang launches. Nothing is left within the file-system at all when it closes.

I built this self-contained 'portable' version of PhotoScape for anybody who may want to run PhotoScape & play around with it, without having WINE permanently installed. I thought I was quite unusual in using PhotoScape, but it turns out - over the last few years - that the app is well-known and pretty widely used by an awful lot of people.....many of whom would like to be able to temporarily run it within Linux without actually having WINE installed.

~~~~~~~~~~~~~~~~~~~~~~~~~​

Doubtless the Snap build does exactly the same as my own solution, with one big disadvantage; Snaps have to be within the file-system when you run them, whereas the WINE AppImage/portable PhotoScape combo can live completely outside the OS.....and run purely via sym-links.

It works beautifully.......and you've seen some of the results I achieve with it.

(Since the WINE AppImages are so simple to use, I also produce self-contained 'portable' builds of it for the Puppy community (with scripts provided to 'link' or 'unlink' them).. I have half-a-dozen different WINE builds set-up - for different purposes - on my big secondary data drive.....and built my own GUI (using YAD) that permits easy 'swapping-over' between builds, AND lets me see at a glance which version is currently linked in to the system.)

With the exception of needing to modify user-permissions throughout the application (remember, Puppy run as root all the time!), I can't see any reason why this wouldn't run in a mainstream distro.

Sorry for the length of this missive.....and for perhaps dragging your thread off-track!.....but I felt a bit of background would be helpful, too.


Mike.

Hands down, you won't get any resistance from me on AppImage's.
They just work!

Thanks for the confirmation that the Wine AppImage/PhotoScape doesn't have to be a part of the system for functionality. I could give that a spin in a vm on one of the other Debian based systems I've got installed.

In 13 years I think I used Wine one time. It worked on Windows XP/Ubuntu 10.04 about 11 years ago.

Have you thought of becoming a Puppy Linux dev Mike?

 

[MikeWalsh]

@Alexzee :-

Have you thought of becoming a Puppy Linux dev Mike?

Uh-uh. Nah. No way.

You get into that side of things, people start to expect things of you. Expect you to keep publishing new stuff. Expect you to keep everything up-to-date all the time, and then folks want to put in feature requests, etc.....so you end up having to code (whether you want to or not), having to keep re-building, having to keep re-publishing, along with maintaining a location to let folks download that stuff from.....

Before you know where you are, it's turned into a job. One that you're not getting paid to do.....and whilst I love Linux - and Puppy in particular! - I don't love it enough to want to dedicate every waking minute to meeting other folk's expectations. I DO have a life in the real world, and it's one that increasingly has to take precedence.

~~~~~~~~~~~~~~~~~~~~~~~~​

This has only ever been a hobby for me. It's a "fun" thing, y'know? I code as and when I feel like doing so, and initially only ever for myself. I found early on that I had a bent for packaging.....or more correctly, re-packaging stuff into Puppy's unique package formats. As time went by, I started playing around with scripting and, ATM, have reached the stage where I can knock together scripts that are good enough to put small utilities together.

I take the view that if I can build something for myself that will work consistently well enough to meet my own fussy standards, then - and ONLY then - am I happy enough to "share". By Puppy community standards, I'm still a raw 'noob' when it comes to scripting'n'stuff like that. Compared to some of our actual "devs", I'm a second grade 'freshman' compared to an honours degree university graduate. Seriously. Some of the stuff our devs create is so far above my pay grade it's not even funny; it's like so much double-Dutch as far as I'm concerned. These guys can read, write and even think in code as naturally as the rest of us breathe. I can barely read it, never mind understand it!!

Nah. It's a nice idea, but the fact is that such a goal is forever beyond my simple talents. I just haven't got the patience for all that stuff! When the day comes that I no longer enjoy scripting, etc, or reach the point that I've finally lost interest, I shall pack it all in and just be a 'user' once again. Simple as that, mate.


Mike.

 

[Alexzee]

@Alexzee :-



Uh-uh. Nah. No way.

You get into that side of things, people start to expect things of you. Expect you to keep publishing new stuff. Expect you to keep everything up-to-date all the time, and then folks want to put in feature requests, etc.....so you end up having to code (whether you want to or not), having to keep re-building, having to keep re-publishing, along with maintaining a location to let folks download that stuff from.....

Before you know where you are, it's turned into a job. One that you're not getting paid to do.....and whilst I love Linux - and Puppy in particular! - I don't love it enough to want to dedicate every waking minute to meeting other folk's expectations. I DO have a life in the real world, and it's one that increasingly has to take precedence.

~~~~~~~~~~~~~~~~~~~~~~~~​

This has only ever been a hobby for me. It's a "fun" thing, y'know? I code as and when I feel like doing so, and initially only ever for myself. I found early on that I had a bent for packaging.....or more correctly, re-packaging stuff into Puppy's unique package formats. As time went by, I started playing around with scripting and, ATM, have reached the stage where I can knock together scripts that are good enough to put small utilities together.

I take the view that if I can build something for myself that will work consistently well enough to meet my own fussy standards, then - and ONLY then - am I happy enough to "share". By Puppy community standards, I'm still a raw 'noob' when it comes to scripting'n'stuff like that. Compared to some of our actual "devs", I'm a second grade 'freshman' compared to an honours degree university graduate. Seriously. Some of the stuff our devs create is so far above my pay grade it's not even funny; it's like so much double-Dutch as far as I'm concerned. These guys can read, write and even think in code as naturally as the rest of us breathe. I can barely read it, never mind understand it!!

Nah. It's a nice idea, but the fact is that such a goal is forever beyond my simple talents. I just haven't got the patience for all that stuff! When the day comes that I no longer enjoy scripting, etc, or reach the point that I've finally lost interest, I shall pack it all in and just be a 'user' once again. Simple as that, mate.


Mike.

I get it bro-

Hobby's are great and don't have a lot of demand behind them. Got a few myself:-

How do you get those utilities together in a script to provide the working tool?

 

[MikeWalsh]

How do you get those utilities together in a script to provide the working tool?

@Alexzee :-

Heh. Slowly.....deliberately.....and VERY carefully!!

Nah, it's one of those things. What I do can't be easily be condensed into a tutorial.....and the way that I approach this stuff won't necessarily work for, OR be the best approach for somebody else.

I think most folks that code, script and/or assemble stuff in Linux are pretty much self-taught. You learn "the art" bit by bit; a command here, some scripting there; you experiment a lot in the terminal to see how things work. IF you want to create a user-friendly interface, a GUI of some sort, you have to learn how to create those on top of making the utility itself functional!

You learn how to use the 'ldd' command, to find out what dependencies may be wanted (I tend to work with pre-compiled binaries that others have created, since my own compiling skills are atrocious! Either that, or I create 'things' that make use of standard utilities already in the system). Over time, you get to understand the file-system layout, where things are 'supposed' to go.

Different people take a different approach to assembling things.....especially here in Puppyland. We don't tend to have "official" guidelines as to how things SHOULD be assembled, for the simple reason that Puppy's package management is totally unlike anything you'll find anywhere else. Some like to script everything into one single long script. Me - like some others - I take the more simplistic approach (the Unix "way", if you like) of having a small separate script for each main 'action', so one script calls another, which may (or may not) then need to call yet another. Etc., etc....

It's not easy to describe all this to someone else. It's even harder to lay-out a detailed 'workflow' so that somebody else can follow your train of thought AND the processes you use. In short, although you often find queries online as to "how do you build a package?", you very rarely - if ever - find a blog-post or tutorial anywhere that attempts to detail the process from start to finish.

Most coders are too busy coding to have the time OR patience to explain to other people exactly HOW they do what they do.....

(Please don't take that as me being rude. I'm not.....just trying to detail WHY it's hard to explain, in the simplest terms I can.)

(shrug...)


Mike.

 

[Alexzee]

@Alexzee :-

Heh. Slowly.....deliberately.....and VERY carefully!!

Nah, it's one of those things. What I do can't be easily be condensed into a tutorial.....and the way that I approach this stuff won't necessarily work for, OR be the best approach for somebody else.

I think most folks that code, script and/or assemble stuff in Linux are pretty much self-taught. You learn "the art" bit by bit; a command here, some scripting there; you experiment a lot in the terminal to see how things work. IF you want to create a user-friendly interface, a GUI of some sort, you have to learn how to create those on top of making the utility itself functional!

You learn how to use the 'ldd' command, to find out what dependencies may be wanted (I tend to work with pre-compiled binaries that others have created, since my own compiling skills are atrocious! Either that, or I create 'things' that make use of standard utilities already in the system). Over time, you get to understand the file-system layout, where things are 'supposed' to go.

Different people take a different approach to assembling things.....especially here in Puppyland. We don't tend to have "official" guidelines as to how things SHOULD be assembled, for the simple reason that Puppy's package management is totally unlike anything you'll find anywhere else. Some like to script everything into one single long script. Me - like some others - I take the more simplistic approach (the Unix "way", if you like) of having a small separate script for each main 'action', so one script calls another, which may (or may not) then need to call yet another. Etc., etc....

It's not easy to describe all this to someone else. It's even harder to lay-out a detailed 'workflow' so that somebody else can follow your train of thought AND the processes you use. In short, although you often find queries online as to "how do you build a package?", you very rarely - if ever - find a blog-post or tutorial anywhere that attempts to detail the process from start to finish.

Most coders are too busy coding to have the time OR patience to explain to other people exactly HOW they do what they do.....

(Please don't take that as me being rude. I'm not.....just trying to detail WHY it's hard to explain, in the simplest terms I can.)

(shrug...)


Mike.

Yup, self taught indeed.
In 2011 I gained favor and humbled myself to a Slackware Guru. He taught me a lot about Slackware, Linux in general and how to run it. That got me started.

Agreed, most coders and dev's have a heavy workflow. They don't have the time to explain much less write articles like @KGIII and I do.
Some of the articles I write are in depth but I'm only one man trying to make a difference.

The hardest part is getting my head out of Linux Geek/Guru mode and getting brain focus to explain in a more simpler way to explain to new users.

I'm all for a simplistic approach of doing things like you.
I can appreciate how the Puppy's Package Management system is unlike anything users will find any where else.
KUDOS to the Puppy Linux Team and to you too, mate!

Slackware is the same. It has it's own unique Package Management System and practices. I've never see anything close to other distributions that most of the Linux Community boot for every day use.

Dependency hell was rectified by me learning how running Slackware. I'll write about that in the future.

Slackware doesn't perform dependency resolution. The user has to install each dependency in the order in which it needs to be installed before the final package of the program get's installed.
Those scripts can take a really long time to run. Once the scripts finish the pkg can then be installed.

Now (3 years now) I'm off and writing articles on my blog for the Linux Community and love it!

#!--^-------------------------------------------------^--!#

Back to editing wallpaper for the desktop.

I've got Virtual Box installed on my Devuan system. I should be able to give Photo Scape a spin.

Is the GUI of PhotoScape an all white interface?

 

[MikeWalsh]

@Alexzee :-

Is the GUI of PhotoScape an all white interface?

Yep. Should look like this:-

Mike.

 

[Alexzee]

@Alexzee :-



Yep. Should look like this:-

Mike.

My eyes can't handle those blinding white GUI's. Spent many a night with blinding okular migraines until I figured it out.

@JasKinasis taught me a cool practice to remedy that.

Once there are a few qt5 pkg's installed (can't recall what they are right now) you can set and environment variable in the /root/.xinitrc file.

QT_QPA_PLATFORMTHEME=qt5ct

Works flawlessly on Slackware and all my KDE programs have a dark background/dark theme. Zero eye strain.
I'm not sure if this will work on my Debian 12 installation.