#Maypaper - Dynamic Wallpaper tool based on QTWebEngine

75 messages · Page 1 of 1 (latest)

livid cave
#

Hey gang, just wanted to share this wallpaper tool I've been recently making, essentially it puts a webpage (local or remote) as your wallpaper. This means you can have completely dynamic wallpapers, with input and shit, and there's minimal resource usage in all areas apart from RAM (nature of chromium, which is what QTWebEngine uses).

It's fully functional in a minimal state, currently, i'm still adding additional APIs that websites designed for maypaper can use, an example of one implemented is seeing if the wallpaper is focused or not, which is used in the parallax template to only render as needed

Other major thing to work on is expanding the templating tool to make it easier to generate websites that are wallpapers you'd want. I was exploring how wallpaper engine wallpapers are made and they're more like a game engine in that you declare stuff, so for equivalent stuff i'd need to make a library easily accessible that allows particle spawners, bloom etc

https://github.com/Mayware/maypaper

#

Here's the demo on the github, but just reposted here

#

no embed permissions lmao

#

I'm currently also working on a wayland compositor that communicates with a window manager you write over IPC you can write window managers for wayland without doing the entire compositor / server (like x11)

lime umbra
#

@livid cave i think maybe you are better off using firefox as provider?

#

instead of qt web engine

livid cave
#

only chromium does, or webkit

#

webkit (via gtk) had issues (it was originally webkit), i migrated to chromium (via qt)

lime umbra
livid cave
lime umbra
#

which means you can just forward the rendered picture to your own wallpaper layer

livid cave
#

you cannot just forward it i believe

#

i would also have to handle input manually

#

chromium is also just a more efficient engine

lime umbra
#

i mean

#

i think thats what browsh does at least

#

or partially what browsh does

livid cave
#

isnt it text based

lime umbra
#

yeah but

#

they do render pictures as pixels and such

livid cave
#

i think they do it as a form of ascii art atleast looking at their github

lime umbra
#

yeah it is

#

unicode blocks to be exact

livid cave
#

either all current codebase sits at like 1000 lines iirc

#

offscreen rendering would be much more jank and would be mangitudes larger than the current codebase

#

and performance would be worse

#

if firefox had a chromium equiv (they shot down the idea) i would've used it but sadly they don't

lime umbra
#

hmm

livid cave
#

it's why i tried webkit2gtk first, but that had issues with repeated playback

#

the way browsh works looks extremely janky

lime umbra
#

icic

#

alright then

livid cave
#

thanks for the suggestion however

#

i did want to avoid chromium if possible (i used webkit before fully made it with that)

#

but atleast on nvidia video repeats have a small black frame right after the video restarts breaking loops

lime umbra
#

okay uhh

#

this is kind of a hack but

livid cave
#

the same occured in gnome browser

lime umbra
#

what if you did something like bumblebee

livid cave
#

chromium offered 33ish% lower gpu usage

#

and more stability

livid cave
lime umbra
#

y know

#

the thing before prime?

livid cave
#

i haven't heard of it before

#

nor prime

lime umbra
#

the thing that lets you choose which gpu to use?

livid cave
#

i only got one

lime umbra
#

before official support bumblebee did it by having a headless gpu only x11 session

#

separate from the main one

#

and render any window in the headless x11 session & forward to current one

livid cave
#

browsh from what i read does headless firefox

#

and then uses remote debugging

#

to get the pixels

#

which is very janky

lime umbra
#

sounds hacky yeah

livid cave
#

this i believe is pretty much the same as to what they do

#

chromium does have a monopoly but they do got one because they're the only one with a working toolkit lmao

#

that others can use

lime umbra
#

yeah unforutnately

#

its costy to make browsers

livid cave
#

yea

lime umbra
#

hmmm

livid cave
#

QT also integrates it very nicely

lime umbra
#

i mean there has got to be a way to jack into firefox somehow

#

like the x11 method maybe?

livid cave
#

browsh does it

#

it's just extremely janky

#

ultimately firefox would be less efficient too

#

especially since it's a full browser aswell

lime umbra
#

fair enough

#

sigh fine i guess ill accept the

#

evil chromium