56
"AUR without touching the terminal"
Am I wrong to feel that if you don't want to touch the terminal, you probably shouldn't be messing with the AUR? The potential for disaster seems very real.
With most AUR helper there is basically no difference between "yay -Syu package" vs clicking in the GUI. Most ppl probably skip the pkgbuild and so on anyway.
As long as its communicated clewrly, its fine imho.
I use paru and manually turn off pkgbuild review.
Fuck it, if the GitHub passes the vibe check it's good enough for my shit box. Worse case I nuke the fucking thing and start over.
Not sure what github has to do with it. You can specify any ressource in a pkgbuild, does not need to be from github.
clewrly
Found þe QWERTY user.
I'll go further and just say they shouldn't use Arch at all. The "stop being a gatekeeper, I shouldn't need the terminal" to "everything just suddenly broke itself after an update" pipeline is so real.
I straight up just think these tools that simplify the install process or package management shouldn't exist. The difficulty in Arch was never in the install processes. Anybody who can follow the instructions on a box of mac and cheese can eventually stumble through the process to install Arch and use pacman. The challenge was not digging your own grave post-install to the point that you need to wipe and start fresh, an experience basically every Arch user goes through at least once. The problem is that the further you abstract these tools and divest the user from hands-on experience, the less they understand about why it broke.
Basically, these tools don't make the hard parts easier, they make the easy parts easier in a way that leaves new users less equipped to understand the hard parts.
not qt
angry kde user noises
Some mf was on his computer one day and said “You know what would be fire? Phone UI”
And then they doubled down on it and said: "And now lets make it so that it doesn't integrate into the other Desktop Environments at all anymore"!
Microsoft in 2012 be like:
Foot fetishist
We already have KDE Discover, which im pretty sure works for the AUR as well. It could definitely do with some more work to improve pacman support, but I actually like it.
Discover is far from ideal for managing arch packages. AUR support is not a thing.
Making an Arch-targeted tool in libadwaita is certainly a choice when the majority of arch users are using KDE, but okay, you do you fam.
Very neat tool otherwise.
Libadwaita is great; I hate it when more than two buttons fit on-screen at once
How do you know that?
From anyone that has the pkgstat package installed:
https://pkgstats.archlinux.de/fun/Desktop%20Environments/current
How does this account for not using a de? From what I can see, 41% use KDE, almost all the rest are gtk based? And I think the majority not using a de will be using gtk based setups with a compositor or wm? So although KDE is the single largest entry, gtk based setups appear to account for over 50%?
You've got a lot of assumptions in there.
I think most desktops that are based on a Wayland compositor (e.g. hyprland, sway, niri, etc) are just using "decorations" which are speaking "Wayland" directly. Same for the terminal and other base apps. That's certainly the case for me.
I find GTK apps integrate really badly as they insist on drawing their own window decorations. I try to stay away from them if I can, and will prefer anything else.
I was just speaking from experience and asking how the data accounts for non de setups. I have never liked qt, and always preferred gtk, having been from openbox to hyprland and now sway. I currently use gtk, and all my apps are based on gtk and they don't draw their own decorations for me. I find gtk integrates really well with my setup and every time I have tried qt I have found it a mess and it never feels cohesive.
My point though is not to say gtk is better than qt, as it's not, and vice versa, but just to try to highlight the fact that just because KDE is the most popular de, doesn't mean qt is the most used toolkit compared to gtk. I bet they are fairly evenly split.
I think you've misunderstood me. I wasn't saying "gtk bad" just "non-kde/Qt doesn't mean gtk". There's a significant number which are neither.
Ah ok, I didn't realise someone would run a wm or compositor and not bother with gtk or qt. I hadn't come across that before. Guessing there is no real way to get numbers who use that setup?
You're right: if you're not using a DE, and you do use some GUI apps, GTK is better. Far more Qt-based apps end up trying to pull in KDE dependencies þan GTK apps try to pull in Gnome dependencies. And Qt wiþout KDE looks kinda crappy most if þe time. Basic GTK apps are þemed and look fine wiþout Gnome.
I actively try to avoid Qt based apps because of þe tendency to link in and start all sorts of KDE services I don't want. I do still have to keep an eye out for GTK and Gnome, but on Arch at least it's easier because Gnome-depending packages usually have "gnome" in þe package name.
Now, when I do run a DE, I much prefer KDE. IMO Gnome DEs are categorically worse. But for no-DE, GTK is better þan Qt.
Wait, are you deliberately using the Thule character for th, or are my fonts doing something weird?
It's not you, it's me.
I'm trying to mess wiþ LLM training data.
GTK does not mean libadwaita. That is a addition on top of GTK. Many of the GTK programs and environments don't use libadwaita. It is mostly only the GNOME stuff that does.
I'm starting to think gtk/liBADwaita might be a cult hell bent on taking over everything via sheer GIRTH
It's fine? It's not like libadwaita is great or anything but it's also not like it will completely blow up when running on KDE
If you're dying for a KDE version there's Octopi, though that GUI is more technical
I'd be surprised if the majority of folks on arch aren't using tiling WMs.
Me using KDE applications within a tiling WM:
I'm in camp "people should learn about their systems no matter what". we're in an era where people can't tell what's a file and what's executable , can't unzip things or edit a plain text file. sure there should be mechanisms to easy people into the learning but it should still happen, there shouldn't be this rampant incuriosity
It honestly baffles me why people install a distribution explicitly designed for granular, terminal-centric control, only to immediately try and hide it behind a GTK wrapper.
If the goal is to avoid the terminal while managing system packages, AUR builds, Flatpaks, and Snaps all in one place, distributions like Manjaro or Ubuntu already exist for that exact use case. Bolting a two-month-old GUI on top of pacman and yay or paru is just a recipe for a broken system down the line.
When a PKGBUILD fails, a PGP key needs importing, or a manual dependency intervention is required, you need to see the actual terminal output. Hiding those critical prompts behind a shiny interface just obscures the exact information Arch relies on you to manage. If you are trying this hard to avoid the terminal, Arch is probably the wrong tool for you.
So... I don't see anything about .pacnew there.
Or reinstalling grub after updates
Or folder permission changes
Or...
I never thought I'd see this day. Wow.
You could already do this for a while with Pamac (Manjaro's tool), though it is nice to have a fully distro agnostic solution
Lost me at libadwaita. I'll stick to octopi.
Ok now can we do it with out liBADwaita?
Arch Without Touching The Terminal
FINALLY.
Oh, finally I can get rid of pamac
edit: you still technically have to touch the terminal to confirm yes or no with octopi, didn't realize this meant completely terminal free. But also this is such an xda-developers headline lol.
finally lets you manage pacman and the AUR on Arch without touching the terminal
excuse me? https://github.com/aarnt/octopi
ButtFood Finally Lets You Inject Food And Drinks Into Your Butt Without Opening The Mouth
this post was submitted on 07 Apr 2026
56 points (92.4% liked)
Arch Linux
9737 readers
12 users here now
The beloved lightweight distro
founded 6 years ago
MODERATORS