Category: FreeGuide

I have requested a Sourceforge project for DIYBlog, and it just struck me again how utterly fantastic Sourceforge is. What would the Free and Open Source Software world be like now without Sourceforge? A lot poorer, I reckon.

I’m desperately trying to find time to test FreeGuide for a 0.10.2 release. So far it looks like although my favourites have been imported, they are not working. In fact, when I create a new favourite it works for that run but when I restart the program they are not highlighted. Hmm.

We’ve already had a bug report/feature request for the ATV Palm plugin Alex wrote, so it’s obviously going to be pretty popular. It’s really great that Alex is doing so much work on FreeGuide at the moment. We are having our disagreements here and there, but FreeGuide is getting a lot better all the time.

FreeGuide is hopefully nearing a new release. Alex has been working on the plugins system, and hopefully I will be able to test it this week. If it works ok, we’ll release it as unstable, and then with a few bug fixes we should be able to make the next release stable. Alex has refactored the code so that the main program is just another plugin. This is pretty cool as it means we can upgrade everything without restarting the program (hopefully, although in practice we think we may hit problems with resources not being freed). We are currently discussing exactly who should be able to upgrade what plugin when. I am keen that users be able to get a new listings grabber as soon as they need one without needing their admin to do it for them. On the other hand, probably only the admin should be able to upgrade the main app. The way jEdit does these things seems to work pretty well.

Been discussing with Alex about the dangers of re-implementing – he wants to simplify the command-line arguments code in FreeGuide, but rather than modifying the existing code, he’s re-written it. The problem with re-writing is that old code usually has lots of non-obvious bug fixes in it which you will have to re-implement all over again as they are reported. Alex has re-written a few things, and generally he’s improved the code structure, but we have both then had extra work to do fixing the bugs that are inevitably introduced. That can seem like a waste of time if they’re bugs that I have already fixed in the past.

It always feels easier to write your own new version instead of understanding what’s already there, but in reality, unless you’re changing the output, it’s never a good idea completely to re-write the internals. There’s a good article by Joel Spolsky on this.

Take a look at the latest TODO list. There are several categories of things on it:

1. Already done e.g. “Add firefox to the possible browsers.”
2. Completeness features e.g. “Use Java’s printing capabilities to print”
3. Feature creep e.g. “Automatically make a channel set when you right-click a channel and choose
   “Move up” (or even drag!)”
4. Difficult-to-trace bugs e.g. “Make it not say no listings after midnight”
5. Difficult features e.g. “Minimize to system tray”
6. Subtle UI improvements e.g. “Remember where you were in the Options screen”
7. Major features we are in the middle of e.g. “Run an exe when a programme is about to start and/or end” (this is actually recording)

I should go through and make sure everything is relevant, but also I need to prioritise what to do before 1.0 if we are ever going to get there. 7s are being done by Alex and others, 2s really need doing if we are going to call it finished, 4s should get cleared up during the beta stage (hopefully), most 5s are likely to get dropped, and 3s and 6s are good potentials for a public vote – then the most wanted ones will get done and the others will have to be post-1.0.

I may go through the list and actually classify them this way, and then we can see what we’re doing.