GTK# front-end for Pacman

Lord_Bad · 2007-03-12 15:19:45

I am currently considering to implement a GTK# front-end for Pacman as a graduation project for my university. I would like to ask you for a few pointers on the subject. First, what would be the best approach - should I make the GUI issue console commands and then do some screen scraping or is there some better way to do it. If a where using C I could use the native pacman API, but with mono that option does not exist. So what would you recommend me?

Stalwart · 2007-03-12 17:08:22

Make bindings for libalpm probably?

arooaroo · 2007-03-12 20:07:54

Stalwart wrote:

Make bindings for libalpm probably?

Certainly a good idea. However, writing binds are trickier than people think. And given that libalpm isn't stable yet, then I'd leave it.

Screenscaping is not a good idea, unless you want to make a very slow front-end.

The approach that Jacman took was to get to grips with how pacman stores package data and implement the appropriate routines to discover which packages are available, what's been installed etc without involving pacman itself. However, when it comes to trying to do a package operation (install, update, remove) then simply call pacman and let it do what it has to do (it's what it's good at).

Lord_Bad · 2007-03-14 09:21:55

Well, I'm considering the bindings more or less, but the the problem is that the GAPI tools from mono are far from perfect and there may be more work involved in creating them, then in the GUI itself afterwards. Perhaps Jacman's approach would be better.

Dusty · 2007-03-14 13:12:22

I have no idea what the state of 'libified' pacman 3 is right now, but the most awesome and globally useful project would be one that used the new backend instead of trying to scrape pacman I/O. It would also be good help for phrakture and the others, you'll undoubtedly uncover a lot of bugs.

Dusty

STiAT · 2007-03-14 13:52:34

The API is stable. That's what matters.
Since pacman3 is out as release candidate, the ALPM API (considering the normal release progress) should not change any longer.
There might are bugs which need to be fixed, but since the API won't change, the bindings won't change either.

The jackman way is okay, but nothing more or less than this.
Consider: If pacman ever changes the data storage, your whole code will change. In the way of using an API (and that's why everyone should use apis instead of re-inventing wheels), your program will work as it did before, since just the ALPM code changes, and in a proper driven development the API won't.

Just take the way of pacman changing to a DB backend (like sqlite instead of file based), you'd need to rewrite code. Or if just the way files are stored is changed.

// STi

toofishes · 2007-03-14 13:58:08

STiAT wrote:

The API is stable. That's what matters.
Since pacman3 is out as release candidate, the ALPM API (considering the normal release progress) should not change any longer.
There might are bugs which need to be fixed, but since the API won't change, the bindings won't change either.

Ahh, let me set things straight. Yes, the API is stable...for the 3.0 release. We make no promises about it staying the same for future releases. As a matter of fact, I would guess it will NOT stay the same. The current problem is...it just isn't set up quite right, and we want to fix that sooner rather than later.

This isn't to say you can't go ahead and try to write another frontend- but you'll find it might not be as straightforward as a few library calls and everything then works. If you are really considering doing something like this, join the ML where you will be able to discuss this stuff in a lot more detail.

STiAT · 2007-03-14 14:18:04

I'm reading the pacman-dev ML daily, but could not find any thread about this (out of the last 1000 posts). Maybe it came up in some sub-thread i didn't notice to be important.

Anyway, as a personal choice i'd stay on API interfaces rather than on storage. If the API changes often, it failed to be an API, so i bull-headed stay with my opinion.

More than less, implementing the backend storage again would be the whole implementation of ALPM.
The developers who have plans for such an interface should sit together thinking about a clean ALPM API interface, and provide some help, i think the pacman devs would appreciate this.

// STi

phrakture · 2007-03-14 15:02:29

Here's the thing. Both Dan and I consider the libalpm API to be a bit.... unwieldy. It is hard to work with, and hard to make a front end with. Our choices are as follows: hold off the 3.0 release for another 2-3 months while we fix this, or release it now and change the API later. Writing a front end right now would be a pain in the ass.

Forcing backward compatibility in a API in the face of incorrect design, is a terrible choice. If you'd like some arguments on the point, try the LKML regarding why linus refuses to ensure a stable API between 2.6.X and 2.6.Y (I think the scope of the micro numbers does require no API changes, though).

STiAT · 2007-03-14 15:26:42

Don't get me wrong, but i don't consider the API of ALPM as complex in any way.

Pacman just provides a few features, and what's the interface about?
Values you get, values you return. And it should be quite clear what you expect as an argument for a given command, and what you want to return.

What's the ALPM about, or should it be?
An API interface, providing access to the information about packages and dependencies.
You most likely will expect a package name, or a list of package names.
You most likely will return a structure / list of nodes, providing the information.

There are some other functions, which require strings, return strings (or package objects / structures), as the -o command.

But at all, an interface should provide the base functionalities, and not require deep knowledge.

Writing wrappers / binds should be based on this, and i don't think the package information will have significant changes.

You said you have design flaws, since i dont know any documentation about the ALPM and i havn't read the whole public interface, i don't know what your API functions require and return.

Basically, if the current API usage is that bad, it would be the time to define for each ALPM functionality what the interface must look like (expects / returns). Afterwards, think about the backend and functionality, not the other way round .

I know i know, afterwards it's easy talking... i'm not the one who has never done this mistake himself ... also it happened more than once that i had to re design api interfaces (i hardly did anything else in my jobs than writing backends, libraries, apis for hardware / data interfaces etc).

Last edited by STiAT (2007-03-14 15:33:44)

phrakture · 2007-03-14 16:01:12

Yes, I understand all that, and know how to design an API. I've been doing it for some time. Suffice to say that the code Dan and I were brought into was not entirely ours, and many arch users were complaining about the development speed. So, the simplest solution to appease everyone was to correct what we could, and release when we can.

Fixes are on the horizon, but it's not feasible at this point in time. Both Dan and I do know what needs to be done, but from a management perspective, there are always other factors to take into account than just "good code".

Dusty · 2007-03-14 17:03:23

Ok, back to the original topic, what to do as a school project:

Do it in two parts. Write a pacman frontend that calls an imaginary API that works exactly like you would expect it to. Then write a simulated pacman backend that implements this API... ok, do the things together. The backend can be pretty simple, don't access a db or anything, just hardcode some crap in there. The key here is that you are actually defining the API that would work most naturally if you were writing a pacman frontend.

If done correctly, this would aid the pacman devs immensly in their quest to redefine the API in the future. Its possible you would even be able to adapt your frontend to work with the new API if the interface is well designed.

Personally, if I was marking such a project, I'd be quite impressed. Designing a good API is harder than writing a program to use one, and should demonstrate your skill in a lot of aspects of systems development.

Dusty

Lord_Bad · 2007-03-15 14:27:38

instead of bindbings a complete rewrite of the library in C#, but this is of course still only an idea...

Its doable. Xerxes2 did it in python, search gna for libpypac. I don't know if he keeps it up to date, but it might give you some ideas as to how difficult it is.

Dusty

Arch Linux

#1 2007-03-12 15:19:45

GTK# front-end for Pacman

#2 2007-03-12 17:08:22

Re: GTK# front-end for Pacman

#3 2007-03-12 20:07:54

Re: GTK# front-end for Pacman

#4 2007-03-14 09:21:55

Re: GTK# front-end for Pacman

#5 2007-03-14 13:12:22

Re: GTK# front-end for Pacman

#6 2007-03-14 13:52:34

Re: GTK# front-end for Pacman

#7 2007-03-14 13:58:08

Re: GTK# front-end for Pacman

#8 2007-03-14 14:18:04

Re: GTK# front-end for Pacman

#9 2007-03-14 15:02:29

Re: GTK# front-end for Pacman

#10 2007-03-14 15:26:42

Re: GTK# front-end for Pacman

#11 2007-03-14 16:01:12

Re: GTK# front-end for Pacman

#12 2007-03-14 17:03:23

Re: GTK# front-end for Pacman

#13 2007-03-15 14:27:38

Re: GTK# front-end for Pacman

Board footer