This makes sense. Yes, I have paid in the playstore for this app (and I would do it again and again). But if I understand it correctly this would also mean, I could download their v4.3.8-ose from the official GitHub repo for free, and it would be updated automatically from Playstore to v4.3.8-gplay version (which is not free). Strange.
But this app is worth every penny.
Oh thats my standard browser. I need Chromium only for testing my webextensions and for Geforce Now. Since the last will not work with Firefox.
I can give it a try, but I would prefer a more "native" approach. I don't like this flatpack/snap concept. But yes, it's an alternative.
Yes, that's my understanding of xdg. But I have no idea what this means for Ungoogled Chromium package. Base Chromium itself isn't degoogled. It has most of the Google service's active and enabled. Only a minor subset, like bookmark sync is disabled (but technically available). With Ungoogled Chromium, most (not all) Google dependencies are patched and inactive. At least this was the case as I last checked it. Since I prefer a mostly Google free environment, I would like to use Ungoogled Chromium for testing and a patched Firefox browser for standard web things.
I absolutely never trust blindly in such things. I have never seen a plausible explanation why this is a security feature.
When there are dev's from X11 involved, this is fine and it seems that this leads to decisions which prevent from current X11 issues. But it absolutely is no guarantee that everything is trustable. I'm not that expert, but your mentioned link points in the right direction. But as long this isn't supported in the wide mass, it's only a wish...
That window titles can be easily changed is quite true, so all applications I know monitor such changes and abort the autotype on request when a change is made. But as already said, this is not a security feature, at least not a useful one.
Monitoring the application itself makes no sense for a password manager. As you write yourself, it's easy to customize the title. All applications make use of this. It is already changed when the tab in the browser changes, a new page is loaded or similar. The same is true for non-browser applications. Windows also allows read access to window titles.
What the Wayland developers do is, in my opinion, gross mischief or ignorance regarding window titles. The password manager needs a simple way to assign a window to an entry, which should be the same for all applications. This should be the same for all DE's, window managers and OS. The simplest is the window title. The status bar makes no sense and an API would have to be the same or at least similar across all DE's, window managers and OS. Such a thing does not exist. To implement something like that only for KDE is too niche. This would have to be implemented and established, if already for the broad mass. So also for Gnome, Mate, Cinnamon and all the others. Not to forget, this must also work for Windows and MacOS in a similar way.
This is because Wayland doesn't allow it to read window titles. Keepass and KeepassXC uses the window title to identify which entry to use. If you have no title, you can't find the entry. That's why it will not work with Wayland and never will work, until Wayland allows it to read window titles.
XWayland, which is forced with your workaround, is not Wayland.
That's at least for me, the main reason not to switch to Wayland. I have no idea why Wayland doesn't allow reading window titles. There is absolutely no security or performance benefit of this behavior. For me it's either a bug or a design failure. Or simply bad behavior.
Regarding SFTP. You can have the server on the PC or the phone. It's up to you which fit's better your needs. Having the server on the PC is more common. Then you can use any file manager to get the needed files from your server/PC. You can also use USB, Samba or other services, but at least here SFTP is the fastest variant.
Media Monkey uses SQLite as database. I have used Media monkey to, before I switched to Linux. So I extracted the last played timestamp and play count with a simple SQL select and migrated this info to strawberry, which uses also SQLite. But be aware that both stores the date in an incompatible way. It's not that easy to spot in Media monkey database.
You can also use a Windows program like Media Monkey or Musicbee on Linux through Wine. So you don't have to migrate your database. Syncing will work for both with Media Monkey and Musicbee.
My music workflow is the following: I'm using dynamic playlists based on last played timestamp. If a song was played, it gets a new timestamp and is removed from the playlist. Now a new song comes automatically in to the playlist where the timestamp doesn't exist or is older as x-days. That's easy to setup on strawberry and other applications. This playlist will be synced via whatever you want to your phone. In my case a SFTP service to keep it wireless. On the phone I use the same playlist with every player you want. Additional I'm using lastfm to scrobble the played music. This keeps the last played timestamp on the phone and can be synced with strawberry. I don't know if other applicants can do the same.
Sounds complicated at first but after initial setup it's a automatic process.
Can this client automatically update the installed apps? What advantages does the client have in detail compared to the standard F-Droid client?
Oh there is a APK, when using Chrome or Samsung Internet (installed via Samsung Store). The store is generating and signing the APK. Only with such a signed APK OS Level functions will work. A good example is the share_target functionality. If this is enabled by the PWA and installed as APK, you can share text and links with the PWA. The same applies for PWAs on the Desktop, for example with Edge on Windows.
If you use the same PWA with Firefox or Samsung Internet installed from Play Store, it can only add a shortcut on the home screen, without share_target functionality.
Additionally some service worker functionality is very basic on some browsers. On one hand this is bad for functionality, but good for privacy. Assume a PWA uses a background sync service for example. This can exchange a lot data and sync it with any target in the web, without user consent. This is only a small part where service workers do not respect users privacy.
If you look at that we come in fast steps to this insane and total crazy manifest v3 webextensions. They are completely privacy nightmare at least how Chromium designed them. The Mozilla implementation is a lot better, but incompatible to Chromium.
Welcome to the ugly world of new web technologies.