Linux port

[Eated-Universe]

Very nice project! Love it! Would be awesome if there is any plan on a Linux version somewhere down the line.
Is there any chance for that?

[aqilc]

Come on, let us windows users have at least some reason to stay :P

[ShankarBUS]

@AqilCont, that made me chuckle.

@Eated-Universe, it would be a cumbersome task to port this project to Linux.

Most of the APIs this app uses depend on HWND (i.e. window handles) and some other Windows only APIS.

It would be a different project. It's better to keep this project "Windows Only".

[Eated-Universe]

I'm greedy Linux user, but you can't have it all I guess :)
Thanks for the answer, good luck with project !

[rocksdanister]

So my plan for Lively 2.0 is to make the Core and UI separate - for stability, portability and memory reasons (although GC does a good enough job already regarding memory.)
Currently wallpaper players (videoplayer and web browser) are separate programs from the main UI program... so some of the work is done already!

I know next to nothing about Linux programming, I can abstract away the Core implementations under some IDesktop interface and if someone willingly steps forward to implement and maintain linux code then its a possibility, I'll keep this issue open.

For the time being I want to do other things like making a wallpaper animator (just an excuse for me to play with Opengl haha)

[Eated-Universe]

I hope someone will step in at some point (I am an idiot for such things), and help with the project on Linux as well as Windows, and help the project grow.
good luck

[MoltenCoreDev]

There is a animated wallpaper app on ubuntu systems, it's named Komorebi 2. I have not tried it, but we can definetly contribute to make the linux app as close in ui to Lively.

[rocksdanister]

@MoltenCoreDev
The original project is not being developed, but there appears to be a updated fork..
https://github.com/Komorebi-Fork/komorebi

Don't worry too much about UI tbh, Lively is written in MVVM style and changing to a compatible framework should not be hard (exception: Preview window that host a separate program during wallpaper import will need a rewrite.. but its not essential for first release.)

What's important is make it compatible with all 100+ example wallpapers I posted here:
https://www.deviantart.com/livelywallpaper/gallery/
(Some of them require a custom schemehandler or localhost server due to cross-origin request issue.)

And the customizable web wallpapers require LivelyProperties API:
https://github.com/rocksdanister/lively/wiki/Web-Guide-IV-:-Interaction
and some newer api stuff for some of the newer wallpapers I posted:
https://github.com/rocksdanister/lively/wiki/Web-Guide-V-:-System-Data

mpv player is cross-platform and there are webview solutions for linux, so its certainly possible.

[rocksdanister]

lively_linux.mp4

🐧

[dreaddr]

Would love to see a flatpak of this app too, on the 🐧 side.

It would be so, dare I say, Lively then.

[WasteOfO2]

choosing between flatpak and snapd may req additional resources and additional development

Would love to see a flatpak of this app too, on the penguin side. It would be so, dare I say, Lively then.

Although virtually every distro may support both, it would still need development for 2 packaging protocols

it would prob be a decent idea to either have an AppImage for lively or the option to build from source

[skyemk]

AppImages works fine but I find it annoying when it comes to integration with the OS.

I like Flatpak apps so far, work's out of the box. On the other hand, I found snapd breaking on systems that don't use systemd by default.

However, AppImage is so far the best option.

[WasteOfO2]

The thing is, if u add smth to flatpak, it is only going to be natural for ppl to request snapd as well.

So either way if u go with snapd or flatpak, it is inevitable that at some point u have to maintain both

I understand the arguement for keeping apps contained. But I believe it is a good idea to have AppImages for smth like an alpha version of Linux port, while rockdanister figures out other possible options.

I too am looking forward for a flatpak release.

On the other hand, I found snapd breaking on systems that don't use systemd by default.

Heh, never happened to me™

TL;DR, keep AppImages as a temporary solution, (or permanent) when Linux port finally arrives. We can consider Flatpak and Snapd later down the road when the project picks up

[skyemk]

Heh, never happened to me™

Snap doesn't work on systems that use init instead of systemd.
An annoying problem I face with AppImage is that the apps don't really have an auto startup feature. Since lively is bound to have an auto startup that might be a problem.

That said AppImage temporarily sounds fine and then Flatpak support later will be great.

[WasteOfO2]

Snap doesn't work on systems that use init instead of systemd.

Majority of modern distros use systemd anyways, it's a low probability that someone using Puppy Linux will be using smth relatively GPU intense like Lively anyways.

Edit(made on 19 Aug, 2021): I realised while reading this again that there are ppl who do prefer other inits, Artix and Void being good examples.

But a point nonetheless

An annoying problem I face with AppImage is that the apps don't really have an auto startup feature.

I see. A way that it can be mitigated is just providing source code that can be compiled which launches the AppImage on startup.

For some ppl it is optional anyways.

Not sure if this is a practical solution, correct me if I am wrong.

And there is always compiling from source as a short-term and a long-term solution.

Good documentation is all that is needed!

[dreaddr]

The way I see it, building from source and providing AppImage files is not going to help distribution of the app to as many users as possible, since for building from source people need to know how to do so and for AppImage, they need to download from the web or some other source. (Something most Linux users just don't do, when they have native package managers.)

Snap is definitely an option, but seeing as popular distributions such as Mint come with Snap disabled and some outright not even including snap by default, it's a much harder sell. Snaps are also more hated within the community than they are liked. (I use snaps personally, but would prefer not to use them too)

Flatpak is unique in the fact that it tackles most of the problems above, except, like @VihagChaturvedi mentioned, the community will expect a snap version as well, if a flatpak is released. The way I see it, this could be solved by just making an unofficial release via snap.

[WasteOfO2]

I proposed that AppImages and building from source can be seen as a temporary option when the port is figured out.

Yes, we can just work on getting repos for various distros unofficially.

Tbh, snap hate is kinda unjustified, even if I don't use snaps myself. It is just a distribution method, just like flatpak but maybe with a few differences here and there.

So here is what I propose.

AppImages/Build From source --> Flatpak/Snap (whichever is agreed to be ported to first) --> .rpm and .deb binaries conversion --> ppl can then host repos for various package managers.

This is obv tedious and the fact that we need to provide 4-6 options just for a single package is kind of a long shot.

AppImages and building from source are universal, regardless of distros. Hence which is why I suggest we go that route first.

This ideology is also mirrored in my proposal for the distribution of the project.

Edit(as of 19 Aug, 2021): Corrected a few grammatical errors :P

[Eated-Universe]

I'd suggest going for tarball binaries and an AppImage. Those should be enough for all major distros, for now and avoid flatpaks and snap, at least for the time being.

Only special look I'd suggest is Arch and AUR as it will benefit to SteamDeck users once it launcher (I know it will be battery draining, but people will wanna rice and show it)
Maybe even publishing it on Steam as other similar app does https://store.steampowered.com/app/672870/ScreenPlay/ to make it even easier.
It would also be a MAJOR help with getting more users

[WasteOfO2]

I agree on the flatpak, tarball and AppImages part.

Not really sold on the AUR part tho.

[dreaddr]

After a tarball is released, I'm betting someone using Arch will make a PKGBUILD and maintain it on the AUR. Might not be necessary for the lead devs/maintainers to get involved.

I agree an AppImage would be nice for testing at first, although later on other options might have to be considered. AppImage updates and maintenance is not really a convenient thing to do.

[WasteOfO2]

I am also going to be learning RPM Packaging.

So I hope I am able to do a good enough job for like... Half the linux distros.

No pressure :)

[WasteOfO2]

Also, since Microsoft Edge is soon coming over to linux, I am curious how this will be affecting the linux port.

Afaik, one of the players(?) used MS is Edge.

Anyone who got an idea?

[rocksdanister]

Great.. so much discussion going on.. I understood some of the things 😅

@VihagChaturvedi
Edge would help, otherwise can use Firefox or Chromium.

For video I was thinking of using https://github.com/mireo91/Mpv.NET-lib- or just let user install mpv player (like in the demo video above.)

I'll post the code soon, been busy lately with personal stuff.

[WasteOfO2]

Great.. so much discussion going on.. I understood some of the things 😅

Heh dw, linux community gotchu, I am willing to help :)

@VihagChaturvedi
Edge would help, otherwise can use Firefox or Chromium.

Well I suggested edge cuz that's what is currently used in the Win10 release

For video I was thinking of using https://github.com/mireo91/Mpv.NET-lib- or just let user install mpv player (like in the demo video above.)

Actually a good choice! MPV is fairly popular with the community. Lightweight, powerful, open source, nothing else u can ask for

I'll post the code soon, been busy lately with personal stuff.

It's alr man, keep it healthy!

@rocksdanister Looking forward to it!

[arghanath007]

Is the Linux version being worked on currently and when will it release?

[WasteOfO2]

@arghanath007 its currently being worked on.

I dont have an idea about the ETA, prob gotta ask rock on that

[rocksdanister]

For now I made a separate repository for easier development:
https://github.com/rocksdanister/lively-linux

[WasteOfO2]

Woohooo

[dreaddr]

Alright, so will this issue remain open or...?

[arghanath007]

Can me make it run through like Proton or wine? Just a thought

[dreaddr]

@arghanath007 Its possible but unnecessary, most of the software used here for lively can be used in linux natively as well. In fact lively has an open repo for the linux port here.

[arghanath007]

I just recently switched from windows to linux. Until the native port is ready, the people who want to use lively on linux can use it via wine/proton. I don't know much about linux after using it for 2 weeks now, still learning.

[uiytt]

I just recently switched from windows to linux. Until the native port is ready, the people who want to use lively on linux can use it via wine/proton. I don't know much about linux after using it for 2 weeks now, still learning.

Does it works well ?

[arghanath007]

about

Nope they are still working on it. That's why I suggested to make it work through wine/proton until the native port is out.

[Arjun31415]

Hey there, I have made a small lively (like) app in rust which is able to display webpages, as wallpaper using webkit2 instead of CEF as being used here.

I am stuck on how to send the mouse inputs to the webbroswer. Could you please guide how you achieved that.
output_file.webm

As of now I have implemented it in Rust(idk c#) and on Nixos

[xandaaah]

KDE has animated wallpapers via a plugin which I cannot remember, it was called just like 'Animated Wallpapers' or something.

[KweezyCode]

For now I made a separate repository for easier development: https://github.com/rocksdanister/lively-linux

is it frozen? last update was 2 years ago

[rocksdanister]

As I mentioned earlier, I am not familiar with Linux system programming, and I don't use Linux regularly enough to be motivated to learn it. However, the project is still open for contributions, and I can assist with developing the user interface, but I will need help with the system API side.