You are not logged in.
Hello,
We have an opening for a GUI frontend developer
I am aware that there are several projects in progress that address this but we need someone willing to make a few modifications and we'd rather have the right people for the job. This is not a one off shot either, we need someone who is happy to continue to participatein the project and hone their contributions.
: UPDATED :
The project will now support an abs style CVS checkout system
What we need:
· The main purpose of this frontend is to supply a simple interface to pacman but most importantly allow users to download large tarballs of source data from their original server and build and install them with srcpac. We wish to avoid supplying the pkgs themselves via our server to save bandwidth
· You can either fork an existing project, combine several or start a fresh one
· we need an easy GUI fronted for pacman with rollback capabilities that can also support a srcpac "select a pkg from the list of pkgs and build it" command
· In addition to this we would like the screen to display the current disk usage (as a shaded bar ideally) and the current disk usage of each installed package. We would also like to include extended functionality that reports the total size of the pkg after it has been installed (same thing i guess). this should allow functionality that prevents an install that exceeds available disk space.
If you have questions, suggestions or wish to volunteer please post here:
Offline
Sounds a lot more than a simple front-end! I don't mean that in a bad way, other than it's not a trivial task you're asking for.
For those who are interested, Jacman will have roll-back support in v0.2. I'm just trying to get a CVS server for the project to make it easier for others to contribute or fork.
Is there any restriction in the language that can be used for this app?
Offline
none at all as far as i am concerned
Offline
Well, just be aware that if you're spinning off from the Archie live CD, then Java isn't on it because it eats up a hefty amount of space. (The arch pkg is 30Mb will balloons to 90Mb when uncompressed.)
Offline
I'm planning to make something like this.. but not now first I have to play with FLTK/C++ and then maybe I'll try do do something like this (after "few" weeks)... I was thinking about something simillar to srcpac but basing on an PKGBUILD database, not pacman DB...
Offline
Note to nobody: Python would be ideal for this, it's already on the Arch/GIS liveCDs, and there's xentac's awesome pacman python library, which would simplify the task massively -- you wont have to parse pacman's input.
iphitus
Offline
And which UI toolkits with python bindings are already on board?
Offline
none yet - this is an archie GIS version not Archie + GIS, will get rid of stuff we don't need.
We were going to inlcude java anyway as we have some java apps - you think that is a bad idea then?
Offline
none yet - this is an archie GIS version not Archie + GIS, will get rid of stuff we don't need.
We were going to inlcude java anyway as we have some java apps - you think that is a bad idea then?
z4ziggy has *refused* to put java in standard archie because of it's size. 90mb is huge on a liveCD.
Offline
none yet - this is an archie GIS version not Archie + GIS, will get rid of stuff we don't need.
We were going to inlcude java anyway as we have some java apps - you think that is a bad idea then?
OIC. Well, that makes sense.
I don't think it's a bad idea, especially as you have other Java-based apps. Iphitus was telling me that he was hoping to get Jacman on Archie, but the lead dev couldn't justify using up so much space just to satisfy the dependencies of one app. You can understand that, when CD space is limited.
All I'm thinking is that if Java's there, then Jacman could obviously be a candidate for forking. Sonix has already modified Jacman and submitted a patch, so I assume it's not that difficult to understand the code.
Offline
maybe other javas could run jacman.. like kaffe.. sources have 9,5MB
Offline
maybe other javas could run jacman.. like kaffe.. sources have 9,5MB
I have been meaning to try for a while, but I'm pretty sure it won't cope. Kaffe uses ClassPath, which I know isn't upto scratch on UI areas, particularly complex Swing components like tables and trees.
Offline
Archie ISO is pretty small anyway - The Archie GIS is going to be the full 700Mb monster whatever happens!
Offline
Archie ISO is pretty small anyway
That's surprising. Seems to me to be a case of all or nothing. S'pose it saves bandwidth.
If I'm burning a CD, I want it filled! Monster, monster!
Offline
If you don't mind hungarian as the main language you can also contact the Frugalware developers!
Microshaft delenda est
Offline
dibblethewrecker wrote:Archie ISO is pretty small anyway
That's surprising. Seems to me to be a case of all or nothing. S'pose it saves bandwidth.
If I'm burning a CD, I want it filled! Monster, monster!
With the compression mechanism used, the bigger the compressed file on the CD (squashfs), the slower it gets. And performance is of prime importance for Archie.
Also, I think z4ziggy planned to make the rest of the disk writable, so you could store your settings on disk.
dibble: Ok, I'll do this, and take a look at it once I'm done with the hdinstall. I'll make some mockups in glade, and you can tell me what you think.
iphitus
Offline
a py/gtk solution should be the ultimate solution imho. i started making a pacman-update wizard using py/gtk - if someone is intrested in this buggy skeleton i can upload it. i think best thing is combine the great work of xentac's pacman library with a cool frontend.
i know this "pacman frontend" issue has been discussed to death (i think even i started a thread on that in my earlier days...) - but as much as i like the cli, having an icon for quick pacman-update is always something i'll find usefull, and i think so will others. and ofcourse - i think it will boost Archie usability for non-Arch users...
Offline
mmmm - i think we are "safe" here as we are not talking about introducing it into Arch
Offline
So long as the program doesnt manage the system for the user, but the user uses it to manage the system, we're OK, and we aren't breaking any Arch philosophy.
iphitus
Offline
Given the size of Java we may, in fact, need to leave it off of the live-cd!
However, we have always intended to have an extra cd, that goes along with the live-cd. As you can't even use pacman or srcpac with a live-cd we can simply include the frontend on the extra cd along with the java apps and pkg we hope to include
Basically, this puts jacman back in frame, which IMHO, is the best pacman front end around. Can jacman be altered to support srcpac? Basically our system for AEGIS will allow CVS checkout of all the build files in the same way as abs so srcpac can be used in exactly the same way for this project! We just need a srcpac front end!
Offline
yes, jacman can be altered to include srcpac.
I can write some code for it after Im done with my dissertation in middle of september..
Offline
Excellent
Offline
Thanks for the quick reply SoniX! We haven't gone too public about our intended vision with Jacman just yet. We wanted to take a little breather. However, we had planned to include srcpac (by begging to sudcow1 to come on board - otherwise nicking his srcpac Java front-end!)
I've also tipped off the guys at Frugalware about Jacman and they've packaged it up. So, I'm hoping more comments, suggestions and hopefully contributors will come on board to add further polish to the program.
Offline
arooaroo - this is all great news for the project. - sudcow1 (is that right?) java srcpac frontend then?
Offline
oops! I mean't sudman1! sudcow is someone else!!! He doesn't know that I want him to contribute - I'm writing a begging letter now, otherwise myself and SoniX will have to do all the hard work.
Offline