SVGWall - SVG Wallpaper Utility for Xorg

grimpirate · 2024-06-17 20:48:00

HOMEPAGE

USAGE

Usage: SVGWall-x86_64.AppImage [-chuV] -j=FILE
  -c, --check             Check for SVGWall-x86_64.AppImage update(s) and exit.
  -h, --help              Show this help message and exit.
  -j, --javascript=FILE   SVG generator JavaScript file
  -u, --update            Update SVGWall-x86_64.AppImage and exit.
  -V, --version           Print version information and exit.

SCREENSHOT

BE ADVISED

~70MB AppImage (embedded JRE and appimageupdatetool)
Batik SVG used as rasterization engine
SVG can be generated with Javascript code or modify existing local/remote file
Scales to fit screen
Only affects the default display/screen/root

The application is developed in Java and uses JNI with Xlib. If you have security concerns:

firejail --appimage SVGWall-x86_64.AppImage -j svg.js

Should you want to inspect the package contents:

./SVGWall-x86_64.AppImage --appimage-help

2024-06-25 Added the Mozilla Rhino library to dynamically control the text overlay using javascript. It seems possible to generate a completely dynamic SVG using this library in combination with Batik.

2024-06-26 Application now uses the Rhino JavaScript engine to dynamically generate the SVG background. Two host objects are provided to facilitate creation with their respective properties/methods:

Platform.version version app
Platform.time system time
Platform.width screen width
Platform.height screen height
Platform.os_ver system version
Platform.os_arch system architecture
Platform.jvm Java version

SVG.load(String uri) loads a local/remote SVG file and returns the document Element
SVG.blank(Object attributes) returns a blank SVG document Element with the supplied attributes; attributes in POJO format {attribute: value,...}
SVG.element(String type, Object attributes, String content) returns an Element of "type" with the supplied attributes and inner text "content;" attributes in POJO format {attribute: value,...}

The sample svg.js file shows loading a remote file and appending "style" and "text" tags to display information.

Last edited by grimpirate (2024-06-27 00:18:16)

seth · 2024-06-17 21:48:21

Rainbows aside, why is this (70MB) better than just "feh --bg-fill some.svg" or "feh --bg-scale some.svg"?

grimpirate · 2024-06-17 23:56:31

With all due respect, that's a subjective take I'll politely decline to engage with. Should you have a particular feature in mind that you think could be useful, I am open to hearing your thoughts. Thank you for your interest.

Trilby · 2024-06-18 00:06:57

HA, are you kidding? Seth wasn't critical - he was literally just trying to understand the value of your project. If you don't want people to see value in your project why are you sharing it here?

That reply tells me all I ever needed to know about whether I'd even look at your software. Pass.

grimpirate · 2024-06-18 01:02:13

No I'm not kidding, people can use whatever software they choose congruent with whatever their "values" are, that's one of the hallmarks of GNU/Linux. The explanation of what the software is designed to do is in the post. Prescribed "value" is inherently subjective. Under the Community Contribution description it plainly reads "Share your own created utilities with the Arch community." Arch has been useful to me for a variety of endeavors and so I'm sharing. Dare I say, as encouraged?

@Trilby: However, since you've chosen to respond with unwarranted and markedly rude demeanor I will retort that petulant remarks such as yours are precisely what discourage other users from engaging with this community. You can feel free to espouse the tautology of Arch Linux doesn't "baby" its users, or "gets down to brass tacks", but the front page itself says "Our strong community is diverse and helpful." As a senior and "respected" forum member, be more measured in your responses. Be better, courtesy and empathy cost you nothing, and your expertise/skillset don't imbue you with a right to belittle others.

I've seen seth's posts, and I consider him an expert Archer. Any reason I could give him, I'm sure he could find a counterpoint, which is why, respectfully, I declined to engage in a comparative between applications. feh has many contributors and is a well known, oft installed/utilized, image utility. It would be remiss of me to try and claim my utility does anything particularly comparable. That seems a fruitless discussion to me (as I would be plainly outmatched), which is why I prompted him to share if he had features in mind; precisely because he is an expert, is more knowledgeable, has experience with feh's features and perhaps it could be a feature worth implementing that would make my utility more "valuable" to others. Lastly, I am GENUINELY thankful that he took the time to read my post and be curious about my utility. I hope we can have meaningful future discourse regarding.

@Trilby: Perhaps you misunderstood the tone/demeanor of my response to seth, but implying you made a mistake would likely "offend" your sensibilities further. Suffice to say I won't miss, nor am I seeking, your brand of "help." For all intents and purposes, please direct some of your misplaced commentary inwards. Hard pass.

schard · 2024-06-18 05:25:15

Is there any particular reason for the program's source code not being included in the upstream repo you linked to above?

seth · 2024-06-18 06:40:01

You're asking people to use a 70MB appimage to do a very specific task a 208kB image viewer, most of the target demographic likely already has, fulfills - the latter with more options and without unconditionally cluttering the desktop with random information like the JRE version in the appimage.

So many users will ask themselves "why would anybody ever do that?" and you could make a -very subjective by nature- pitch "why this is better than what you have and worth installing a 70MB appimage to set a wallpaper".
Or not.
I don't really care.
I just noticed this rather crucial aspect was missing in your OP and you maybe wanted to address it.

@schard, you're undermining all the "but its gots to be written in the rust so it will be safe!!!" zealots

ewaller · 2024-06-18 13:37:10

This is quite the thread to go with my first cup of coffee in the morning. My main takeaway, if it is supposed to be a rainbow, colors are in the wrong order.

Please be civil people.

grimpirate · 2024-06-18 15:13:26

@schard: I will be uploading the source code at a later date. I'm still trying to figure out how to best organize the various components that comprise the AppImage in a thoughtful way.

@seth: The only real selling point here is that it's an AppImage and it works across distributions. feh isn't really that size, the main binary is sure, but in order to work with SVGs it has imagemagick as a dependency which is significantly larger and itself has dependencies. I would also cautiously make the claim that imagemagick doesn't evaluate SVGs as well as Apache Batik (the library under the hood that my application uses for SVG rasterization). To have a more apples to apples comparison, if we ignored the JRE and appimageupdatetool, the compiled Java files of my application are under 100kb. However, that would mean the end user would need to have a JRE already installed and they would be responsible for updating to the latest release. I could build an AppImage that has just the compiled Java classes and significantly reduce its size, but that would defeat the purpose of the AppImage format. I like Java, it's unfortunate I don't see it used more. I also think the AppImage format is interesting. I wanted to see if I could try some small JNI and work with Xlib. It's a personal project that I'm satisfied met all my criterion and decided to share it, caveat emptor to any who care to use it.

@ewaller: The screenshot is a gruvbox theme. The rainbow pattern it produces when you don't supply an SVG file is more like a color picker selection box that floods the entire screen.

grimpirate · 2024-06-27 00:33:54

@seth: Thanks for the push. I think the app may have a worthwhile "hook" now in that it can generate dynamic SVGs using a javascript file.

In case you feel obliged to test it out you can add this piece of code to svg.js to include the Arch Linux logo:

svg.appendChild(SVG.element('path', {
	d: 'm 105.8125,16.625 c -7.39687,18.135158 -11.858304,29.997682 -20.09375,47.59375 5.04936,5.35232 11.247211,11.585364 21.3125,18.625 C 96.210077,78.390904 88.828713,73.920352 83.3125,69.28125 72.7727,91.274163 56.259864,122.60209 22.75,182.8125 49.087628,167.60733 69.504089,158.23318 88.53125,154.65625 87.714216,151.1422 87.2497,147.34107 87.28125,143.375 l 0.03125,-0.84375 c 0.417917,-16.87382 9.195665,-29.84979 19.59375,-28.96875 10.39809,0.88104 18.48041,15.28242 18.0625,32.15625 -0.0786,3.17512 -0.43674,6.22955 -1.0625,9.0625 18.82058,3.68164 39.01873,13.03179 65,28.03125 -5.123,-9.4318 -9.69572,-17.93388 -14.0625,-26.03125 -6.87839,-5.33121 -14.05289,-12.2698 -28.6875,-19.78125 10.05899,2.61375 17.2611,5.62932 22.875,9 C 124.63297,63.338161 121.03766,52.354109 105.8125,16.625 z',
	fill: '#1793d1',
	transform: 'translate(380, 20) scale(0.5)'
}));

Last edited by grimpirate (2024-06-27 04:59:56)

Arch Linux

#1 2024-06-17 20:48:00

SVGWall - SVG Wallpaper Utility for Xorg

#2 2024-06-17 21:48:21

Re: SVGWall - SVG Wallpaper Utility for Xorg

#3 2024-06-17 23:56:31

Re: SVGWall - SVG Wallpaper Utility for Xorg

#4 2024-06-18 00:06:57

Re: SVGWall - SVG Wallpaper Utility for Xorg

#5 2024-06-18 01:02:13

Re: SVGWall - SVG Wallpaper Utility for Xorg

#6 2024-06-18 05:25:15

Re: SVGWall - SVG Wallpaper Utility for Xorg

#7 2024-06-18 06:40:01

Re: SVGWall - SVG Wallpaper Utility for Xorg

#8 2024-06-18 13:37:10

Re: SVGWall - SVG Wallpaper Utility for Xorg

#9 2024-06-18 15:13:26

Re: SVGWall - SVG Wallpaper Utility for Xorg

#10 2024-06-27 00:33:54

Re: SVGWall - SVG Wallpaper Utility for Xorg

Board footer