Im very happy with how responsive its being in general. Discover and gnome's store are actually really sluggish to use when scrolling through in low end hardware and this app is smooth as silk.
First impressions is I'm shocked by just how fast it is, Aside from the first boot which for some reason doesn't propagate apps and needs a reboot, it's extremely fast, Gnome software and Discover aren't even within the same league of responsiveness and speed. I didn't showcase Discover since I don't know where the cache files are to delete them.
Touchscreen for sure I wish was handled better. you can see I accidentally clicked an app in the last video instead of scrolling, but thats something that I assume will be fixed with time.
Not sure how long this will last, but here are some videos I took of it, try not to mind the crunch on the last one, I had to use qsv_vp9 for it since I was running out of time and space. Also don't mind the fist video's bad fps, I was compiling in the background and forgot.
You can also try it using arch for anyone curious, I have pkgbuilds for most things here https://github.com/Quackdoc/pkgbuild-scripts/tree/Master/cosmic-epoch (dont try meta-git it breaks things) I havent clean room tested them but i've slowly been working on making sure the dependencies for everything are up to snuff but they arent all there yet
Does this mean we will finally be able to mark/search mobile/TV compatible apps? i remeber there being talk about that supported with appstream metadata
The issue with flat packs is the more you use it, the higher the chance that you get less shared runtimes and the higher the chance of the duplication. And at some points it really does get to awfully ridiculous levels.
A while back, I had run everything I possibly could with Flatpak to the point I'd even make my own Flatpak to try and see how well it would work. Instead of using the AUR. And it worked great for the first little while. I'd installed all of my apps and it was fine, but as I kept using the system, kept installing new apps and not uninstalled the old ones, it really started to build up awfully quick, especially with older apps.
I feel like the usefulness of flatpaks is the inverse parabola, where it's extremely useful in the center use, but when you go to either side of it, it becomes less and less useful.
Apologies for any incoherentcy this was written with a speech 2 text.
I think having separate standard APIs for screenshots, screen capture, and video capture that aren’t married to one implementation makes sense.
The idea of a using a separate thing for it is fine, in itself, but necessitating it is an issue to me. There are a LOT of wayland compositors now, for all sorts of systems, each one also new needs a compatible xdg portals implementation (or whatever third party tool you like), in the case of xdg portals this also means pulling in things like dbus. It actually becomes a lot to build a "Minimal but fledged out" ecosystem. something which should otherwise be possible.
we’re talking about standalone desktop apps, they need some common building blocks no matter if they’re containerized or not, right?
sure but then you have xdg-portals denying actually useful a11y protocols because they "don't want to expose it to containers" -_- apparently they never heard of a permissions system? but this also highlights why the wayland ecosystem right now is so poor for select individuals (and why they get heated when told that they need to swap to wayland)
I have a couple of issues with portals. One is that we're putting too much eggs in the basket of something that is designed for containers. XDG portals Have rejected features that people have requested because they don't want to expose that functionality to a container and they are allergic to permission prompts apparently.
I also have other issues with the portals for instance video capture. It requires you to have a camera portal. It requires you to have a desktop capture portal. It also requires you to have an app to app, video, portal, which doesn't exist yet. All of these things require pipewire pretty much in most cases, so why can't we just have a single pipewire portal? It may not scale well in the future, but it doesn't scale well now anyways. If you want just a generic pipe wire stream, you're not gonna be able to have it, you're going to have to conform to one of the standards anyways. For a case in point example, the OBS pull request for Game Scope Capture is the perfect example of this over reliance in XDG portals.
I'm showcasing this just to highlight the fact that the XDG portals are incredibly poorly thought out, and I don't think that it's a reliable method for the future going forwards.
PS. Please pardon any oddities in this, I had to use speech to text, since my RSI is acting up.
I did and quite frankly it's trash, XDG portals are a clunky and quite frankly terrible and poorly thought out api. I'm not the only one that disagrees with this sentiment as multiple people are trying to get protocols like ext-screencopy-v1 for screen recording and ext-foreign-toplevel-* for window management upstreamed into wayland so that xdg portals aren't necessary for these use cases. I don't mind the reliance on pipewire too much, but I too think that It shouldn't be necessary for screen capture.
IMO It is one of nate's worst takes of all time if not the worst. Usually I agree with most things he writes, but not this, xdg-portals is a travesty, pipewire is nice and all, but I don't see why we should need an entire media system for basic screen capture capabilities. and clearly im not alone on this sentiment
not to mention the totally bogus comparison they preformed which is an insult to anyone who has a even an inkling into how image metrics and comparisons work and more then 30sec to compare
Quack Doc @ Quackdoc @lemmy.world Posts 1Comments 212Joined 2 yr. ago
Im very happy with how responsive its being in general. Discover and gnome's store are actually really sluggish to use when scrolling through in low end hardware and this app is smooth as silk.
even Fdroid stores on my phone are slower.