lively
lively copied to clipboard
rocksdanister
Linux port
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?
@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".
I'm greedy Linux user, but you can't have it all I guess :) Thanks for the answer, good luck with project !
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)
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
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.
@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.
https://user-images.githubusercontent.com/17554161/108311647-5dc68580-71db-11eb-845a-389d2866e038.mp4
🐧
Would love to see a flatpak of this app too, on the 🐧 side.
It would be so, dare I say, Lively then.
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
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.
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
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.
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!
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.
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
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
I agree on the flatpak, tarball and AppImages part.
Not really sold on the AUR part tho.
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.
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 :)
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?
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.
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!
Is the Linux version being worked on currently and when will it release?
@arghanath007 its currently being worked on.
I dont have an idea about the ETA, prob gotta ask rock on that
For now I made a separate repository for easier development: https://github.com/rocksdanister/lively-linux