Pacman GUI for KDE?

tafsen · 2007-04-24 11:31:44

I've searched the forums and found a couple of apps but they all seemed to be "dead", and there was no activity in the thread.

So I was wondering if there was a app that I was missing or if someone wanted to help me make one?

PS: I didn't really know where to post this, so just move it if it's on the wrong place.

aRcHaTe · 2007-04-24 11:54:10

jacman is still functional gtkpacman too...look better !!

tafsen · 2007-04-24 12:18:13

Yeah, but that's java and gtk based. I want a gui that I can put on the kicker

raymano · 2007-04-24 12:30:43

tafsen wrote:

Yeah, but that's java and gtk based. I want a gui that I can put on the kicker

You can add jacman or gtkpacman to the kicker. I use sudo and put jacman and pacman in sudoers for my user. To kicker, I have added a non-kde application with command "sudo /usr/bin/jacman". Not the most elegant solution but it works.

tafsen · 2007-04-24 12:34:08

raymano wrote:

tafsen wrote:
Yeah, but that's java and gtk based. I want a gui that I can put on the kicker
You can add jacman or gtkpacman to the kicker. I use sudo and put jacman and pacman in sudoers for my user. To kicker, I have added a non-kde application with command "sudo /usr/bin/jacman". Not the most elegant solution but it works.

Wouldn't it be better to make a QT app for KDE users?

equadon · 2007-04-24 13:23:26

tafsen wrote:

Wouldn't it be better to make a QT app for KDE users?

It would for sure. But somebody need to develop one. Now with the release of pacman3 it's fairly simple to integrate pacman in a GUI.

STiAT · 2007-04-24 14:42:49

I often thought about implementing a KDE/QT interface for pacman3 once it's out.

Though, since the developers stated that the api of libalpm will change lots of within the next releases i don't want to rely on this "unstable interface", and wait until the api can be considered as stable, since i don't want to base an application on-top of an unstable api, noone knows yet what will change within data structures and similar.

Last edited by STiAT (2007-04-24 14:43:20)

toofishes · 2007-04-24 15:55:14

Yeah, I would not plan on libalpm staying exactly how it is. Our biggest reason for getting pacman 3.0 out was the amount of bugfixes that have landed there for issues that exist in pacman 2.9.8.

equadon · 2007-04-24 16:06:34

STiAT wrote:

I often thought about implementing a KDE/QT interface for pacman3 once it's out.
Though, since the developers stated that the api of libalpm will change lots of within the next releases i don't want to rely on this "unstable interface", and wait until the api can be considered as stable, since i don't want to base an application on-top of an unstable api, noone knows yet what will change within data structures and similar.

I didn't know that about libalpm, but I had a feeling that was the case. I had a KDE/Qt, as well as a console client (written in C++) in mind. Since I assumed that libalpm would be changed in the future, I used a wrapper class for libalpm, so changes to libalpm would be easier to handle. Other plans I had was to design a new library to handle AUR and ABS, which new clients could use.

If we had a clean base to work from like this we could easily create new clients (also including python bindings) using ncurses and GTK.

tafsen · 2007-04-24 21:13:55

So we should wait until Pacman 4 or something?

aRcHaTe · 2007-04-24 21:37:58

iwasnt pacman 3 supose to have allready colors?

equadon · 2007-04-29 15:39:15

I took some time yesterday to integrate Arch into KPackage. I got the basic functionality going but it's not the most optimal software for a package management GUI together with pacman. It would be easier to use with a newly designed GUI specifically for pacman. However, it's still usable.

I've got install/uninstall working and listing installed packages. Not using libalpm yet, though.

I'm thinking of something written using PyQt could be good.

Misfit138 · 2007-04-29 17:39:32

I hope this takes off, I think pacman, being one of the most powerful package managers, deserves an equally powerful GUI!
I currently use a panel button which calls jacman, by doing sudo jacman, though I typically just use pacman through the console. 8)

STiAT · 2007-04-29 17:54:28

equadon wrote:

I didn't know that about libalpm, but I had a feeling that was the case. I had a KDE/Qt, as well as a console client (written in C++) in mind. Since I assumed that libalpm would be changed in the future, I used a wrapper class for libalpm, so changes to libalpm would be easier to handle. Other plans I had was to design a new library to handle AUR and ABS, which new clients could use.
If we had a clean base to work from like this we could easily create new clients (also including python bindings) using ncurses and GTK.

Strange, i thought about similar as you did.
I've been implementing a c++ lib, bringing the functionality as a clean api interface, for my and other clients. Though, in my mind was, that it might be written in C, to provide a stable API. But in this case i feel as if it's the job for the pacman devs.

I don't mind using C libs in C++ code though. So it's probably a good choice not to split again (what i hate in linux) into 200 parts. Arch is a small distribution, we should actually keep resources we have not too busy (also the ones of users / contributors), and still wait for the alpm .

If you write a wrapper, nothing changes. When our beloved developers did their final changes into libalpm or at least change the alpm, we still need to provide patches for the wrapper, what's basically not what i intended. Also, wrapper classes can be implemented directly to the client... how many c++ interfaces will we have?
GTK/GNOME/XFCE are all C based desktops, as most desktops around.

I started out a c++ lib already (pacpp) handling packages, installs, removes, updates, so most basic features (not as full featured as alpm currently is). Also, i didn't use libdownload .

I think it's best to stick with the "core", so alpm, and simply hope there will be a (quite) stable api for major releases (x.0.0), or at least minor release based (x.x.0). As i read this on the lists, they plan to bring a quite stable interface, what would be enough. I had a discussion with Aaron about interfaces, and not even the kernel apis are sure not to change in subreleases.

I've not much clue about python (once wrote a ticket system with wxpython and a python daemon as server with a mysql db as backend about 4 years ago). But i also think, if we have more developers thinking about this, we should start out one program, and not even more. I'd prefer c++ though, also for a QT interface. But if you can tell me python can implement C libs, i'm with the thought of this, just for learning to know python a bit better.

I didn't even think about implementing pacman in kpackage, i always disliked kpackage for a reason i don't know ... maybe just the way it was.

STi

Last edited by STiAT (2007-04-29 18:08:41)

equadon · 2007-04-29 19:36:06

STiAT: Interesting. Any chance for us to have a look at what you've done so far with the C++ library?

I don't mind that alpm is written in C, although I think it's a bit strange to use C since it's quite time consuming, and Arch doesn't have that much man power. The reason for implementing the C++ wrapper is so we don't have to change for eventual libalpm changes in the rest of the code, just the wrapper. Of course it's not desirable to modify the wrapper, but it's better than the rest of the code.

Since the underlying, and heavy operations, are handled by alpm, I don't see a problem with using Python as the language for the GUI. C++ will work good too. The python bindings for Qt are very similar to the ones of C++, so it's not a big deal to learn it. Personally, I'd like to see a Qt GUI for Pacman. The reason I mentioned python bindings is because I don't use, nor plan to develop a GTK GUI. If someone wants to do that, it's good to have bindings for that (since C++ doesn't seem to be too popular among GTK apps). I also have no problem using python or C++ for Qt, both are great.

I haven't used KPackage before. I got a tip the other day that an interface for Arch could be cool. The good thing about KPackage is its interface implementation, but other than that it's not the way I'd want to have it.

mangus · 2007-04-29 20:27:56

It sholud be simple to use a kommander script like pacman frontend..I've made this for gathering info about my package
may be I miss kpackage too much?? :-)
http://www.deprecated.it/download/Archinfo.tar.gz
cheers
Fede

STiAT · 2007-04-30 08:04:11

equadon wrote:

STiAT: Interesting. Any chance for us to have a look at what you've done so far with the C++ library?

As i mentioned, i don't want several pacman libs to be used. You could also look at the alpm code, i've taken out quite a lot of logics from the original library (though, changed to maps / vectors, iterators for the data structures, and object-orientated code organisation).

equadon wrote:

Since the underlying, and heavy operations, are handled by alpm...

My starting point basically would be: how to access C functions out of python. As i said, i developed some python, but with pure python mods, and i'm not that experienced yet. I simply don't have enough clue about this, but i've some good books about oo python and python at home, and will start out for such an implementation soon (i had plans on taking a closer look on python, since i'm searching some alternative to perl).

equadon wrote:

I haven't used KPackage before. I got a tip the other day that an interface for Arch could be cool. The good thing about KPackage is its interface implementation, but other than that it's not the way I'd want to have it.

I'd like to know your reason why it's not the way you'd want to have it. I havn't taken a real closer look on the interface and how to develop a addin for kpackage, and it seems as if you have some experience with it. This could be a quite simple way to get an interface for arch / kde.

I'll start out tonight / tomorrow for some python. Sounds like a good project to get some deeper look into python. Also i'll provide a dedicated svn for this project. I'll be blogging most info about how i get along with the tasks.

Kind regards,
STi

equadon · 2007-04-30 13:31:44

STiAT wrote:

My starting point basically would be: how to access C functions out of python. As i said, i developed some python, but with pure python mods, and i'm not that experienced yet. I simply don't have enough clue about this, but i've some good books about oo python and python at home, and will start out for such an implementation soon (i had plans on taking a closer look on python, since i'm searching some alternative to perl).

I'm in a similar situation. I'm learning Python as an alternative for C++ for deploying applications faster. I hope I didn't seemed to be a Python expert, I'm not. I'm checking this out: http://www.riverbankcomputing.co.uk/sip/ which seems like a perfect starting point.

STiAT wrote:

I'd like to know your reason why it's not the way you'd want to have it. I havn't taken a real closer look on the interface and how to develop a addin for kpackage, and it seems as if you have some experience with it. This could be a quite simple way to get an interface for arch / kde.

I agree. It's a good place to get a KDE GUI ready in short time. What I don't like about it is that the GUI is not designed in a way to easy alter it. Any changes will be required to be done in the GUI source files, which might not fit DEB, RPM, and Gentoo packages. For example, the right side of KPackage consist of the tabs; Properties, File List, and Change Log. For Arch, the Change Log is useless (which can be disabled) and maybe we want to add other tabs. We can add a "Special" menu entry for Arch, which can handle upgrading and updating, as well as other things, easily. Currently, there are four tabs for checking packages, "Installed", "Updated", "New", "All". Not sure how to apply that to Arch. I would rather see something like "Installed", "Current", "Extra", ..., "ABS", "AUR", etc.

We can of course modify the GUI source, but my hope was that this could be done in a non-intrusive way. Doesn't look like it though.

The good things about KPackage is that the interface class is good and functionality like drag&drop of *.pkg.tar.gz is already working.

Here are the two interface files for KPackage that I made for Arch. At the moment, it just list the installed programs, and show basic information as well as files belonging to the program.
http://www.devdesigner.com/arch/archInterface.h
http://www.devdesigner.com/arch/archInterface.cpp

STiAT · 2007-04-30 13:52:48

This definitely makes sense. KPackage also isn't the choice for gentoo packages. They got a "own" kde package manager, which is quite nice.

We'll see. First of all i start out a libalpm binding in python. After this it makes sense thinking about an interface.

As i said, i'm currently doing most jobs to deploy applications fast in perl. But due to the non object orientated design of perl and the current "hype" around python, it's worth a try. Some years ago, when i developed in python, i had a quite similar impression about python as a language as perl. It's package based, not object based, but since i have a book about object orientation in python, i'll give it a try.

Perl of course has object orientation implemented by modules as Class::MethodMaker and similar, but that's not what i think object orientation should be like (public, private, protected, polymorphism).

Well, as i said i'll start out with the basic setup for a project for me this night, and will see. Depending on my spare time (and the last frw weeks i had plenty of this rare good) it takes longer or shorter to complete.

You're welcome if you want to provide helping hands in any way, ideas, code, sources to python documentation and similar. But as i know python is quite good documentated.

equadon · 2007-04-30 14:07:16

Yeah, KPackage wasn't the best choice for Gentoo either.

As for Perl and Python, both are good but I really like the way Python is designed. Coding object oriented is something many overdo and use it where it's not supposed to be. Python handle both which is great.

Since I'm actively studying Python at the moment, I'm sure I'll be able to help out. I will do a few Python binding test together with libalpm (or some other library) myself and learn from it. I'm interested in helping out with the PyQt version of the GUI as well.

STiAT, where is your blog located regarding this project? I'd like to stay updated.

STiAT · 2007-04-30 16:37:28

It's my personal blog, i set it up some time ago but i did not use it (http://blog.grabler.net).
I might do a own blog for the project as soon as a name exists.

I'd say we meet on IRC to discuss a little. I don't know now where you are located, but it would be fine. The SVN repo will be up some time this eve', i'll blog this as well.

If you find me on IRC, feel free to message me directly (STiAT in archlinux or archlinux.de).

Last edited by STiAT (2007-04-30 18:29:06)

phrakture · 2007-04-30 22:58:07

STiAT wrote:

It's my personal blog, i set it up some time ago but i did not use it (http://blog.grabler.net).
I might do a own blog for the project as soon as a name exists.
I'd say we meet on IRC to discuss a little. I don't know now where you are located, but it would be fine. The SVN repo will be up some time this eve', i'll blog this as well.
If you find me on IRC, feel free to message me directly (STiAT in archlinux or archlinux.de).

Seeing as the channel isn't used all that much, feel free to use #archlinux-pacman for this discussion - that is what it's there for 8)

s26c.sayan · 2007-05-22 19:50:37

Inspired by Mangus's Kommander script, I'v created by own .kmdr GUI wrapper for pacman !

Here is PacKommander : http://www.esnips.com/nsdoc/863fc34f-0b … 6a11c6c7de
Screenshots : http://www.flickr.com/photos/sayanriju/ … 268333286/

It is surely not what Synaptic is for apt-get, yet! (After all, I'v seen Kommander for the first time just yesterday ! )

Last edited by s26c.sayan (2007-05-26 12:49:23)

Bogart · 2007-05-23 22:44:39

s26c.sayan wrote:

Inspired by Mangus's Kommander script, I'v created by own .kmdr GUI wrapper for pacman !
Here is PacKommander : http://www.esnips.com/nsdoc/863fc34f-0b … 6a11c6c7de
Screenshots : http://www.flickr.com/photos/sayanriju/ … 512052322/
It is surely not what Synaptic is for apt-get, yet! (After all, I'v seen Kommander for the first time just yesterday ! )

Nice

One thing I like is that it works fast, unlike other frontends I've tried before. I had to edit a few things, like the size, since I use 1024x768 and I couldn't see the bottom of it. Also when clicking the install/uninstall buttons nothing happened, since it uses gksudo. Since it's a KDE app, wouldn't it make more sense to use kdesu instead? It works for me. Didn't try to switch to konsole from xterm, but it could be a better idea too (I didn't have xterm installed for whatever reason and had to install it).

Good first try

s26c.sayan · 2007-05-24 07:45:59

Thank you for your comments!

I had to edit a few things, like the size, since I use 1024x768 and I couldn't see the bottom of it.

Yes, that bothered me too! Now, I'v edited the script a bnit so that you can see the bottom for maximized and normal window size.
I'd like to do a bit more with the layout, so that the whole thing expands/shrinks with change of size of window. But layout design on Kommander is a bit tricky, it seems!

Since it's a KDE app, wouldn't it make more sense to use kdesu instead?

Hmm...the script can easily be configured to do so. Just open up the *.kmdr file in a decent text editor, and replace all occurances of 'gksudo' by 'kdesu'.
Personally, I use only gtk apps in my Fluxbox environment, and this is the only QT app so far. Hence the choice of gksu! Besides, I dont seem to find kdesu in the repos! (Not much idea with KDE apps actually!)

Didn't try to switch to konsole from xterm, but it could be a better idea too

This should be possible too....replacing xterm with konsole, xfce4 terminal or gnome-terminal, etc. But I chose xterm coz it is the lightest!

Right now I'm attempting to enable install/remove multiple packages at a time! But the Kommander parser is not very powerful and quite complicated it seems. Besides, I'm not a very good programmer as well!!

UPDATE :

PacKommander can now do more!! Using a 'Package Queue', it can install MULTIPLE packages at a time!! Check it out: http://www.esnips.com/nsdoc/ca0ac91e-17 … e8ed47f4ef

Last edited by s26c.sayan (2007-05-26 11:45:40)

Arch Linux

#1 2007-04-24 11:31:44

Pacman GUI for KDE?

#2 2007-04-24 11:54:10

Re: Pacman GUI for KDE?

#3 2007-04-24 12:18:13

Re: Pacman GUI for KDE?

#4 2007-04-24 12:30:43

Re: Pacman GUI for KDE?

#5 2007-04-24 12:34:08

Re: Pacman GUI for KDE?

#6 2007-04-24 13:23:26

Re: Pacman GUI for KDE?

#7 2007-04-24 14:42:49

Re: Pacman GUI for KDE?

#8 2007-04-24 15:55:14

Re: Pacman GUI for KDE?

#9 2007-04-24 16:06:34

Re: Pacman GUI for KDE?

#10 2007-04-24 21:13:55

Re: Pacman GUI for KDE?

#11 2007-04-24 21:37:58

Re: Pacman GUI for KDE?

#12 2007-04-29 15:39:15

Re: Pacman GUI for KDE?

#13 2007-04-29 17:39:32

Re: Pacman GUI for KDE?

#14 2007-04-29 17:54:28

Re: Pacman GUI for KDE?

#15 2007-04-29 19:36:06

Re: Pacman GUI for KDE?

#16 2007-04-29 20:27:56

Re: Pacman GUI for KDE?

#17 2007-04-30 08:04:11

Re: Pacman GUI for KDE?

#18 2007-04-30 13:31:44

Re: Pacman GUI for KDE?

#19 2007-04-30 13:52:48

Re: Pacman GUI for KDE?

#20 2007-04-30 14:07:16

Re: Pacman GUI for KDE?

#21 2007-04-30 16:37:28

Re: Pacman GUI for KDE?

#22 2007-04-30 22:58:07

Re: Pacman GUI for KDE?

#23 2007-05-22 19:50:37

Re: Pacman GUI for KDE?

#24 2007-05-23 22:44:39

Re: Pacman GUI for KDE?

#25 2007-05-24 07:45:59

Re: Pacman GUI for KDE?

Board footer