Then comes another time where I'm trying to refactor #FrostWire's search provider architecture. I ultimately didn't get to completing it (#AI helped do that instead) but in doing so I noticed that the new Knaben search performer, written by #Copilot, was one hell of a class to say the least. There were unnecessary checks, fields, and all sorts of things that just bloated the class and were quite frankly unnecessary. However, the search performer did work, so this issue is more of code quality than bugs, but code quality is just as important because maintenance burdens are real.

Anyways, so that gets fixed. Fast forward to yesterday after being busy with school and #Tenacity (where I don't use AI) and I decide to run the latest development version of FrostWire on my laptop. Recently, the media player was dropped, so I was interested in seeing those changes. When I go to run it, however, FrostWire simply exists with a message in the terminal that it doesn't support #Wayland. Having used FrostWire previously, it worked just fine under Wayland, so I'm not sure why all the change was made to not make FrostWire work under Wayland.

Anyways, I found the change pretty quickly and reviewed its contents. It appears that FrostWire now forces the XRender Java 2D backend instead of letting the backend be automatically selected, while also disabling the OpenGL backend too. It also disables "sun.java2d.pixmaps" and "sun.java2d.accelblit", all in the name of stability. On my end, I have never experienced rendering issues with FrostWire, and from what I've seen, FrostWire does little custom rendering that I would presume it to be prone to such graphical glitches. However, judging by commit 4b44c9a0f6c9df2343e40523d5511d65e921e9c7 (https://github.com/frostwire/frostwire/commit/4b44c9a0f6c9df2343e40523d5511d65e921e9c7), it seems like there might've been some rendering issues on aarch64 Linux because it mentions a "runARM64" task that appears to have never existed (I would assume private changes that never were made public).

(Continued below).

I have a story about #AI hallucinations for you! If you're interested, get your favorite snack, find a cozy place to settle down, and enjoy the story! 😄

So I'm certain some of you guys are aware of #FrostWire. I have contributed to the project before after starting my own private fork. I have been responsible for a few things so far:

- New FlatLaf light theme
- Fixes for several search providers (Internet Archive, MagnetDL, and idope)
- Reduction of precompiled native binaries on Linux.
- Some miscellaneous cleanups (especially related to the prior point above).

So things are going well and I decide to find some other bugs to fix. There was one issue where the clear button overlapped the text in the search bar (https://github.com/frostwire/frostwire/issues/1044). The maintainer initially tried to fix the issue with Copilot, but it seemed to go nowhere. Then I decided to look into it by doing a bisect, and I discovered the bad commit. I later figured out it was because BuddySupport.addToComponentHierarchy() was forcing a BorderLayout on a given component, while one of the added components had a different layout. Removing this check fixed the issue. I then highlighted this in my PR, and the maintainer states that "it's probably AI slop" that was introduced while trying to fix theme switching crashes. The commit that actually wrote the code didn't state it was coauthored by AI, but I take the maintainer's word for it right now. Either way, that's my first experience of AI messing something up.

But wait! There's more (continued below)...

So I remember saying that I would upstream part of my private #FrostWire fork upstream. Here's the original post: https://social.linux.pizza/@gperson/115030801742685950

Well, that's taken a turn...

Not only have I upstreamed the Linux helper app options removal that's now been merged, but I also ended up fixing a bug with the search bar layout. I've also continued further with upstreaming things such as refactoring the codebase to eventually get rid of prebuilt binaries and a new light theme. I also want to introduce some open-source packaging so other people can finally package FrostWire rather than having to rely on their distribution that uses private build scripts (as I presume at the moment). However, Gradle is a bit outside my range of experience, but I'll eventually learn it.

I honestly did _not_ expect to get this far involved, but I figured I can perform some housekeeping around the codebase. Am I interested in new features? Not particularly, though I might look into writing a full-fledged audio player for FrostWire if that means getting rid of prebuilt #mplayer binaries. That's currently far-reaching right now (well, somewhat; I might've started experimenting with that).

Well, I've now upstreamed part of my private #FrostWire #fork! The changes that were accepted were getting rid of Helper Apps options.

Next, I'll work on getting rid of precomputed binaries next. This way, we can increase transparency around its codebase.

The #upstreaming has begun with my private #FrostWire fork!

Up first: getting rid of the Helper Apps options on #Linux. This will simplify things more and drop some native code.

⚠️ This post is pretty long, so please bare with me here ⚠️

So https://social.linux.pizza/@gperson/114905015424913738 aged perfectly...

Once again, I've forked #FrostWire for private experimentation, but I've also been giving my friend updates, and honestly, it's probably why I've kept at it for as long as I have now. I've also learned so much about the FrostWire code base (at least further than I previously have; I'm still learning it).

The changes have mostly been superficial, such as removing social and donation buttons, but I've also made the settings dialog scrollable for lower resolution displays and added a new light theme based on FlatLaf. The branding is still the same because this is a private fork, so I'm not interested in changing it right now.

One of the biggest downsides about FrostWire is how it ships native binaries for a custom library in Git. Having seen the xz-utils backdoor unfold, that's a big no-no for me because they aren't easily inspectable. To clarify, the source tree also has the source to the binaries, so it's not completely opaque. Still I would prefer they are compiled at build time instead. On the other side of this issue, I've been working on fixing this.

One of the involved libraries is libSystemUtilities, which just contains utilities written in native code. On Windows and macOS, this is used plenty, but on Linux, it wasn't used whatsoever. I therefore dropped the Linux version of it and removed Linux support for it. At least on Linux, that's one less opaque binary to worry about. Alas, more work still has to be done, either by getting libSystemUtilities to compile at build time and getting rid of all precompiled binaries or by rewriting the code in Java using external libraries instead. This'll take some time.

Finally, according to IntelliJ, there's a lot of unused declarations, so I'll resolve that before moving on with anything else. Maybe that'll make build times a bit faster? Speaking of which, my mom's 11 year old laptop builds FrostWire pretty quickly, in about a minute or so. That's amazing! 🤯

Historically, I've forked #FrostWire to make a few changes only to throw them all out. It's always like a cycle for some reason.

Would anyone be actually interested in such a #fork? I'm already thinking about doing it again, but probably for my own private #experimentation.

Sometimes I'll occasionally take a look at #FrostWire to see what's happening. Years ago, I used to use it as a #BitTorrent client. Nowadays I don't use BitTorrent, and I'd likely use #Transmission instead.

However, I've previously forked it to see what I can do with it. I never really get anywhere with it however, so then I just end up deleting the repo.

What are your thoughts on FrostWire?

Download Manager: FrostWire 6.13.2 verbessert SoundCloud-Suchfunktion https://www.computerbase.de/2024-05/download-manager-frostwire-6-13-2-verbessert-soundcloud-suchfunktion/ #FrostWire

📬 FrostWire: Populärer BitTorrent-Client wieder im Google Play Store
#Filesharing #AngelLeon #Badshah #BitTorrent #BittorrentClient #Frostwire #GendaPhool #GooglePlayStore #IcePhoenix #LimeWire https://sc.tarnkappe.info/7b4c58

FrostWire Returns to Google Play Store After Music Industry Takedown

https://torrentfreak.com/frostwire-returns-to-google-play-store-after-music-industry-takedown-240115/

#BitTorrent #Technology #frostwire

📬 LimeWire – Filesharing-Client wird zum NFT-Handelsportal #Filesharing #FrostWire #JulianZehetmayr #LimeWire #MuWire #NFT #PaulZehetmayr https://tarnkappe.info/artikel/filesharing/limewire-filesharing-client-wird-zum-nft-handelsportal-216994.html

Yes, I know of @fdroidorg@mastodon.technology and no, the article does not say why the #FrostWire team is not considering this as an option.

After an 8 year presence on #Android store, and with 80% of their user base being solely on Android, open source software #FrostWire has been kick banned from the store by #Google and is throwing in the towel. http://feedproxy.google.com/~r/Torrentfreak/~3/6rsJ3nsSkRk/

Who said Google is an open source champion?

Google a un monopole, tout ce qu'il faut pour abuser de son pouvoir :
https://torrentfreak.com/frostwire-team-calls-it-quits-after-google-deletes-android-app-180928/

#dmca #FrostWire