Possibly switch to fork of Discover as a base for the software center

Hey, i believe that instead of trying to make like a really standalone application for the Software center currently available in Manjaro, it’d be better to just use the KDE Discover program’s code and just to add pamac stuff on top of it for maximum compatibility. I know discover looks odd on non-kde desktops at times but so does the current software center, using a Discover fork’d lift a bit of weight from the application maintainer’s back too, while allowing for better UX.

The only problem i’ve had since i first started daily driving Manjaro (been a while) was with either pamac (updates to packages included) or the software center, i believe a slight bit of revamping both of those would make Manjaro much better.

Have you checked out octopi? It’s qt-based, it is even available in Arch proper, and it’s a lot more stable than pamac. It does not offer access to FlatPaks and Snaps, but it uses pacman in the background, as well as an AUR helper of choice — yay is in the Manjaro repositories, but you need to explicitly enable it in octopi. It also has a built-in terminal emulator and it can show you the individual files of installed packages in a filesystem tree outline.

1 Like

I just use CLI but just sometimes look back at the status of the built-in application, anything that uses pacman is probably issue-free as pacman itself is very stable.

Is that KDE?

1 Like

I must confess I keep forgetting about Octopi.

I use pacman almost exclusively for most tasks, as I find it generally more reliable; without the added complication of having containerized apps and the unsupported AUR thrown into the mix.

Sometimes all that is needed is a simple, and easy to navigate, list of packages available in the official repositories…

  • no problematic flatpaks,
  • no unmaintained AUR packages
  • no unnecessary cruft

Octopi ticks all the boxes, for me; and that it defaults to using pacman, makes it a no-brainer – if only I’d remember to install it. :smile:

Now it’s again imprinted on my mind, I’ll do just that.

Thanks. :octopus: :octopus: :octopus:

1 Like

Discover, among other things, uses packagekit for package management which is buggy and a security vulnerability.
It should not be used an Arch/Manjaro for general package management.

(it is acceptable as a frontend for store.kde.org though)


Are you referring to pamac-cli and pamac-gtk respectively - so just pamac then?

It’s good for themes and KDE extras, but it sucks as a software manager for anything Archy… I’m curious if it works better on 'buntu based distributions.

Pamac works better if you want to search and find available packages across all channels - including Flatpak, even Snap.

Octopi works - but doesn’t include flatpak.

If you’re worried about having missed updates, after updating just run ‘Topgrade’ which will catch anything you missed.

You say that as if it’s a bad thing. :scream:

In any case, Pamac-Manager already supports flatpak;
I, for one, like to keep that handling separate.

1 Like

Aye, it is. :wink: Theme info below. :wink: :point_down:

  • The Plasma theme ─ i.e. the panels and widgets ─ is Opal.
  • The window decoration is Mojave Dark Aurorae.
  • The application theme is Glow Mojave Dark ─ it’s a kvantum theme.
  • The icon theme is WhiteSur.
  • The mouse pointer is from the oxygen-cursors-extra package from the AUR.
  • The font is Noto Sans ─ should be installed by default.


I guess the developer of that theme must have taken it offline. :man_shrugging:

Sorry, no. We won’t be forking Discover or GNOME Software.

1 Like