DoctorMo's Blog

Thanks to everyone that tested Ground Control yesterday and today. Your bug reports and ideas have been a boost to refining for a new version. We also got some wonderful merge requests from people who fixes things as a simple as spelling to as interestng as making project directories have bzr control configurations. Wonderfully it’s all been top notch and everything’s been merged.

So what do we have for the next version:

• A way to restart nautilus or request restart when you install.
• A way to make the projects directory if it doesn’t exist, or select a different directory.
• Dealing with pulling the parent directory back in (updating), but will only be available _before_ a merge request.
• Allow the merge request information to change the status so successfully merged branches should do a different thing.
• We do need someone who can add in translation support, it’s still beyond my ability to get that working, volunteers neded
• Bazaar gtk has a wonderful diff view I may take advantage of, save a lot of coding inside the project.
• Already I’ve improved some of the displays etc to add in an icon for the project and remove the description as it’s unwieldy

The next version will hopefully be 1.1.0, I’ll post here on my blog when it’s released and get you to test it again!

Post below or into the Launchpad Bugs your ideas and problems.

Hey everyone, I’ve released version 1.0.6 of ground control into my PPA, this is a fairly stable Beta which I hope everyone will give a good testing.

For new users: Ground control is a project that hopes to bring the collaboration of launchpad and bazaar branches to every day users abilities. It does away with the need for a command line and has removed a lot of the complex distractions leaving a simplified workflow for users to follow. It uses all the existing libraries and practices of the community, so if you need to move back to the command line you can continue were you left off.

It’s also flexible enough to allow you to manage your existing bazaar checkouts via nautilus. If your want to.

To show you what it can do I have done a video (you have to click into my blog article to see it):

[blip.tv ?posts_id=3161227&dest=-1]

What I need now is more testing and perhaps a design review to make it easier to use. Let me know your ideas, thoughts and if you think this will be useful for getting course writers into the Ubuntu Learning project, comment below and bug reports here.

If you do have a problem and it crashes at some point, do create an empty file in your home directory called groundcontrol.log this will quickly fill up with a useful log of what’s going on and you can attach it to the bug report.

Update: I’ve made sure it’s available for both Karmic and Lucid releases.

I have to remember not to try workarounds for new installations of Ubuntu Karmic to get the nvidia driver working until _after_ I’ve performed all the updates. If you do it before, you’ll find the nvidia packages are naturally broken for some chipsets and produce bad resolutions. We ran out of time at a client’s home this evening, so I’ll have to go back next week to sort out any remaining problems, I’m just hoping the very slow download of update packages fixes everything.

Oh and I have a new release of ground control, I would have posted about it today but there’s a scheduled launchpad downtime that’s stopping my video creation and I want to show you all how it works.

I’ve making a generic gtk class which will allow me to set up threading for a nautilus python extension, the idea is to set off a new gtk main loop with a window (using gtk builder) and set off a thread. To bind them together I’m using gobject timers with stacks of calls which cross the boundaries.

So far it works and has improved the load speed and usability of the ground control project. The generic classes mean I can expand it and reduce code complexity.

What are your thoughts on this problem? Is this the right pattern to use?

I’ve been trying to come up with some kind of brand for my ground control project, and it’s a bit of a hard one since I think my head is far too much in the code to be able to come up with something that is both easy to recognise and visible at small pixel widths.

This is my idea:

Thoughts?

This is what python threading does to people:
My work on groundcontrol is trialling thanks to nautilus being based on gtk and the Thread class which is supposed to provide easy threading. And bzrlib, which may or may not be thread safe, but never actually functions in a thread even when self contained in one thread.

It’s turning into a real dogs breakfast and advice from other devels says to avoid threading in python… that may not be acceptable for this project. I’ve managed to solve now most problems via not having threads but instead loading at opportunistic times. but it’s ridiculous to me how badly Thread, gtk and bzrlib mix and how much time I’ve wasted trying different solutions. So desperate was I that I even tried using subprocess to fork out a separated script.

Now I know a lot of this is due to not knowing the precise operating functionality of threads in python… but the subject seems to operate on some kind of uncertainty principle where the more a person knows the less likely they are to explain how it works, conversely the less someone knows the more likely they are to try and explain it wrong.

So anyone know any _really_ good guides on python threading that explain it and demonstrate it? So far the guides I’ve found have been wrong.

Update: The community does not disappoint… a great simple guide in the form of a pygtk faq was most helpful, provided by M.K. Erlandsen below in the comments. Also useful is the multiprocessing explanation provided by Jess S.