• Supports recursive directory support now, where the old release was limited to one depth of a package.foo directory
• Improved creation, deletion, and renaming of files. You can now rightclick in the leftpanel on the desired file and get these options as well
• Copy and Paste support now implemented
• When editing an entry you can now hit tab to save the change and move to the next editable field.
• When adding a new file, reverting, deleting, or a similar operation is executed the folder you were currently in is now reselected after GPytage reloads its database

GPytage should be hitting the Portage tree in the next few hours. A simple

should net you package for testing. It will be keyworded ~arch, so stable users will need to add an entry to package.keywords to install it.

While this is a release candidate, there should not be any bugs floating around. If you find any bugs or want to suggest an improvement don’t hesitate to either post it here or at https://gna.org/projects/gpytage/

GPytage-0.3.0 RC1

Looking forward to hearing everyone’s feedback.

written with PyGTK. The application is coming along nicely with its new backend, but still has a bit of a way to go before a rc is released. I’d say the current svn trunk is about beta status at the moment, it’s safe to use but all the features just aren’t implemented yet. Basic editing works right now as does saving and creating new files. It also supports infinitely recursive folders and files which the older version did not.

A quick list of the top of my head that I’ve still got to implement:

• Deleting files
• Renaming files
• Copy, Paste, Cut, etc
• Possibly drag and drop support
• Figures out sane keybindings for adding and deleting a row. I was thinking ctrl+e for inserting a new row and ctrl+d for deleting a row but I really have no idea, recommendations are welcome
• Converting a configuration file into the directory layout like the older GPytage did

That’s all I can think of off the top of my head. The svn trunk should be good for testing right now, I promise not to horribly break it. It would be appreciated if people would checkout the current trunk and give it a whirl and comment about how you liked, disliked, hated, loved, or would change about GPytage.

For testing purposes after checking out the svn trunk just cd into the scripts directory and run

. Then you should see the application in all its glory. If you feel uneasy about letting GPytage have actual access to your portage files, simply create a /etc/testportage directory that is identical to the old one such as

. This way GPytage can’t cause any harm. If you use the /etc/testportage directory, you would launch GPytage with

.

Feel free to drop by and say hi in #gpytage on the Freenode irc network.

trunk r230

the chroot was sane again and ready for developer work. Now I can stop slacking so much and help squish some amd64 bugs. (Also, why isn’t –keep-going default? Sigh, maybe I’ll just alias it along with nice and ionice.)

Besides working on Gentoo I’ll be ramping development back up on my two pet projects: GPytage and Zito.

GPytage is currently undergoing a near complete rewrite to support recursive folders and file structures under

. Currently reading in all the files and constructing the internal database is functional and so is a basic UI. Saving still needs to be reimplemented among a variety of other things. I plan to eventually redo all of the accelerator shortcuts into something more sane and to recode glade-based dialogs and windows into pure pygtk.

Zito is currently still in development and undergoing Internationalization refactoring. After that is done, some code tidying and perhaps UI changes are due. I’m still at a loss on how to actually package something like Zito being a java project. I know Ant can do it, but I’m still not exactly sure how to use Ant in the sense of coding a build and install file for it. Seems quite a pain setting up the XML file for Ant.

On a related note, I can say that I am fairly happy with bzr now. I used to be a large git supporter, but many git commands require extensive knowledge of syntax, flags to pass, and just isn’t as user friendly. Bzr I’ve found is very easy to work with and I have not had any problems with it so far. Most of my projects I’ve converted locally to bzr repositories. In my observation, Bzr knows what “the right thing to do” is most of the time and prevents most repository screwups.