1) Why do I need a program like this? After all it is alien to Slackware’s philosophy!

Slackware’s basic philosophy is to keep things simple. When it comes to package management,
Pkgtools is second to none. Some years ago, came SlackBuilds project and applications like sbopkg to fill the gap
of installing third-party software.

QTGZManager is not alien to those concepts. For instance, it’s dependencies lies upon software that are stock since
Slackware 13.0 (mainly Qt4.5.x libs). It uses Pkgtools to deal with package removal, updating and (re)installing.
And it works out of the box regardless of the user’s preferred desktop manager being KDE or Xfce.
Needless to say it doesn’t go beyond Pkgtools goes. Putting it simply, it doesn’t deal with package dependencies.

2) But it is not a command line solution, so it hurts KISS badly!

Well, what would be the point in creating another CLI version of pkgtools?
Besides, one of the main targets of QTGZ was to offer an instant graphical overview of the user’s package collection.
To make users being able to move packages between directories, knowing their state against the installed ones.
That’s the file manager philosophy that resides in QTGZManager. And it borrows very much from it.

3) So it is a Pkgtools frontend. Just that? Seems really little to make someone excited.

Yes, we can say QTGZ is a Pkgtools fronted. But it’s also more than that.
When it comes to the file manager part of QTGZ, it can create/remove directories, move package between dirs, open terminals inside the selected directories, open/edit files inside packages, search for files inside installed/non installed packages, search for packages inside dirs, view differences between different versions of a package, open/save snapshots of installed packages, being reminded and download latest official Slackware packages, among other features.

4) So it goes *beyond* Pkgtools goes!

Regarding the file manager nature of QTGZ, yes. Regarding the package actions, no. In fact it does less than Pkgtools does. For instance, it does not create packages, as it makes no use of makepkg command.

5) Ok. But why Qt4??? Why a KDE application? KDE is bloated and slooooow!

Oh, QTGZManager is not a KDE app. It needs Qt4.5.x, indeed, but it runs smoothly in Xfce, Lxde, Mate and even KDE 3.x desktops. It doesn’t rely on any KDE dependencies. I chose Qt4 because it is feature rich and takes the burden off the developer when it comes to have hard algorithms implemented. Besides, I have a bias toward C++  😉

6) Humm… you’re lying. QTGZManager relies on kdesu for root privilege escalation! So in the end, it depends on KDE.

True, it uses kdesu when you have it installed on your system. But it’s also compatible with ktsuss 1.x (version 2.0 stopped working with QTGZ) and gksu. But I insist: QTGZManager is not a KDE application.

7) Humm, I don’t know… I’m still afraid of using such a tool.

Most people are afraid of the unknown. Fact is QTGZManager does very low harm to your system. It runs without root privileges and asks for it only when you want to deal with package actions (the Pkgtools frontend part).
It is basically a management solution for your package collection.
NOT a diabolic app to take slackpkg’s, sbopkg’s, pkgtools’, slapt-get’s or any other tool’s place. It CAN coexist pacifically with all of them. In fact it shines brightly when the user does exactly like this. Just give it a try! You’ll be surprised.

8) Hummm… you promise me it won’t grow donkey ears on top of my head?

Yeah. I think it’s safe to promise this, as I use QTGZManager for more than six years and my head is still the same.

9) You are lying again… You have visibly less hair than you had, back in 2006.

Sad but true.

10) Humm… seems you like Metallica/heavy metal. Maybe you have salvation, despite this nasty heresy called QTGZManager.

And it seems you’re hard to convince. Well, at least I’ve tried…

11) Of course I’m hard to convince. I’m you!