Sneak peek...

My Bad

A last minute change of mine caused glChess to fail in Gnome Games. Whoops... I must get put some unit tests in for the PGN code.

What would be great in the future is to have these unit tests showing up in Damned Lies about Gnome. Python has such a great test framework and this would be so useful.

Unfortunately my time is currently traded off between new features (FICS support is coming along in the sf.net version and will aim to have it in Gnome 2.18.1), and refactoring and testing.

Click 'N Run for major Linux distributions

Linspires' Click 'N Run service will soon be available for multiple distributions. I think this is going to be really really good for Linux. Ubuntu has already mostly solved this with "Add/remove" in the Gnome menus but this is going to make life simple for the "average" user. Only good things can come of this.

Better Bash Autocomplete

Found a positing on how to stop bash autocompleting all the hidden files. This had been bugging me for a while...

Simply edit ~/.inputrc and add:
set match-hidden-files Off

Hidden files are only matched if you explicitly type in the period.

Why is Gmail search so crap?

Why is Gmail search so crap? I can never find anything with it... For example today I was looking for my sisters phone number which is in an email conversation that is fairly unambiguous. So I search for "sarah phone", "sarah number", "sarah phone number" etc. These all come up with a few or no results but not the conversation that actually has the number. Finally I found it with "sarah's phone number".

I really expect Google to be a lot smarter with search - an apostrophe shouldn't stop it from matching a word! And ideally the search would be fuzzy so I could at least look through a list of conversations to find this one (thus training their search algorithm). I would even expect GMail to know/learn that "phone" and "number" should match conversations with long numbers in them. Perhaps the GMail team needs some of the core search guys to really spice things up.

#97

glChess has broken the top 100 in sourceforge.net! Looks like it may be another glChess new years?

There's been a lot of polishing progress in the last month. There seems to be enough people using it and generating a constant amount of feedback. Should be a lot more when Gnome 2.18 is released in March.

Writing software for maximum system compatibility

For historical sake, here is a link to a program that compiles/runs in five languages. I'm sure it could be modified to also include whitespace.

The end of KDE (for me)

For the last two weeks I have been stuck using KDE at work due to a lack of Internet access. This was quite good as it gave me a chance to evaluate it as I haven't properly used it for many years. I'm using Kubuntu Edgy.

What I like about KDE:

• Tiered menus - The KDE games menu subcategorises so that there are about 10 games in the base menu after installing the Gnome games. In Gnome the menu is huge.
• KSysguard is great - you are able to monitor all sorts of system signals (CPU, memory, sockets...).
• Kontact. Clean and simple it was immediately obvious what it did as soon as you opened it.
  

What I don't:

• KDE has far too much information. Right click on anything and you get hundreds of options. Each menu entry is a short sentence - it's like reading a page of text for every menu.
  
• Annoying use of on-top splashscreens.
  
• Excessive, excessive use of 'K'. Either name things imaginatively or descriptively. It's very hard to scan through a menu with everything Kthis and Kthat.
• KHTML. Not practical for actual WWW use.
• QT frames - the old fashioned surround everything with lines. Visual clutter that looks terrible against GTK+ frames (bold headings, no lines).
• Apply buttons. Just unnecessary.
• Katapult. No idea what this does. It just opened a splashscreen, no obvious information on what it is.
• The animation effects seem inconsistent.
  

General problems in both KDE and Gnome:

• Apps shouldn't automatically quit if they can't be immediately useful, e.g. xsane. I think it creates a bad experience if you can't see inside programs. In this case it should state there are no scanners and just disable the scan button. What if you wanted to connect a scanner while the program was open?
• Add the example content directory as a shortcut on the file open dialogs. Often when playing with a new app you just want to open something. There is a lot more content that could be added - anything that can be opened should have a default file.
  

And the final straw for me is printing a test page to the local printer. I incorrectly entered the URL as ipp://host which caused the printer to print out the ipp traffic as text. That's fine, it doesn't speak IPP. However since the printer was not sending back any responses it continued to send out more printing requests. Thirty pages or so I finally stopped it by doing killall ipp. This may be KDE specific or it may be CUPS specific but it's unacceptable. Test pages should only be retried by the user and the GUI should indicate if it's printing multiple pages. This seemed to bypass the CUPS queue so nothing was indicating where these print jobs were coming from. Printing has a long way to go before it works-out-of-the-box.

In summary; I didn't like KDE a few years ago and I don't now. It's got the details but still the basics are annoying. It's too cluttered for new users to find easy and for power users like me it's full of cruft that gets in my way.

Now installing Gnome...

Google Analytics

I just set up Google Analytics for my web pages the other day. Easy to set up and nice, interesting results.

For glchess.sourceforge.net:

Looks like I have a Norwegian fan club!

This blog looks like a sub-set of the above.

An interesting thing I noted is a reasonable amount of traffic is coming from GetDeb - a click-n-run style repository for Ubuntu I had not heard of.

What is wrong with computer scientists?

Today I spent pretty much all my time trying to get fricking Java to convert a 1D buffer of 8 bit colors (i.e. RGBRGBRGBRGBRGBRGBRGB...) into a viewable image. But no, Java has to abstract everything to death into Raster, DataBuffer, BufferedImage, ColorSpace, ColorModel, ComponentColorModel ... ad nauseum. There's been more or less no progress since I started. I still have a buffer in a perfectly valid format and it still isn't rendered.

Why can't it be as simple as this?

BufferedImage image = new BufferedImage(TYPE_BYTE, FORMAT_RGB, width, height, data);


Surely for a tool to be useful simple things should be simple and complex things should be possible. *sigh*

Summary of current open-source chess programs

XBoard is the old classic. Probably quite functional for experienced users but not very friendly and needs to be retired.

eboard is the XBoard replacement (?). I would have assumed it's dead but checking the site it seems a GTK+ 2.0 version is about to be released. It probably has the functionality that I've been aiming for with glChess but not the simplicity.

Scid is a database and analytics tool for hard-core chess players. It hasn't been updated since 2004.

Chessmonk is a modern replacement for Scid. It's still in early development.

Gnome Chess is long dead.

glChess is the new Gnome chess...

Pychess is the other modern chess interface for Gnome. We talked about merging but their goals are more power-user where mine are more simple. They've just release 0.6.0 - will look at "borrowing" any useful code!

Knights is the KDE interface. Looks fine and plan to check compatibility with it.

Slibo is a 3D chess application for KDE. It seems to be dead but the board looks a lot nicer than the glChess one. So should look into salvaging materials, reflections, shadows etc.

Brutal Chess is in the early stages of development. I think they're aiming for mostly graphics.

Dream Chess has very nice full-screen 3D graphics. It's early in development.

So when you list them all the market looks quite busy. I guess I predict that the old hands will fade away and we will be left with chessmonk+pychess, glChess and Knights as the dominant programs. But you never know...

UPDATE: 17 Dec - Added Chessmonk which is the program pychess is working with

OMG 1.0!

Well it's happened... After 7 years of mucking around glChess has hit 1.0! Many thanks to all those who have contributed patches, artwork, ideas and translations. This release transfers development from sourceforge.net the new Gnome version. I plan to backport changes periodically and not add any hard dependencies on Gnome.

Sourceforge.net subversion change

I'd been having trouble committing changes to the glChess sf.net subversion repository as I was getting HTTP 403 Forbidden errors when adding/moving/deleting files. After digging on the sf.net site status page I found that the subversion access method had changed:

1. Back up your repository


2. svn switch --relocate https://svn.sourceforge.net/svnroot/PROJECTNAME/trunk https://PROJECTNAME.svn.sourceforge.net/svnroot/PROJECTNAME/trunk

Works for me.

I'm not sure if I'm not reading the email that gets sent out but sf.net keeps changing things and it takes a bit of digging to find what's changed.

Universal Chess Interface

I think I finally have glChess working with proper Universal Chess Interface (UCI) support. After testing with the Fruit engine I found I'd made an assumption in the specification - UCI engines do not have to keep track of the board state. This section is not clear so I've sent an email to hopefully add some clarification to the document.

What I was doing was reporting each move as it occured, like:

position startpos
position moves g1f3
position moves d7d5
position moves e2e3
position moves c8g4

This worked fine for Glaurung, as by not specifying startpos it must have just appended the moves to the existing ones. However for Fruit it would assume 'startpos' was missing thus every move reported was considered the first move.

So the solution is to send every move before requesting a new one like this:

position startpos
position startpos moves g1f3
position startpos moves g1f3 d7d5
position startpos moves g1f3 d7d5 e2e3
position startpos moves g1f3 d7d5 e2e3 c8g4

Seems a little inefficient? I guess that the engines could do a string compare to check if this position command is just reporting one new move.

I've tested the new changes by letting Fruit and Glaurung fight it out:


It was just painful to watch - Fruit had to twist the knife by slowly promoting two pawns to humiliate Glaurung. No love lost between these two.

UPDATE: Dec 16th
I emailed Stefan Meyer-Kahlen at shredderchess.com and he confirmed that UCI engines are completely stateless and thus the correct behaviour is to send all the moves each time.

Shamelessly stolen links

Some stuff picked up from Planet Gnome:

• New Mesa release: Looks like OpenGL 2.0 support is almost there...


• Firebug: A fancy looking web debugger for Firefox


• Template for funky lamp: If you've seen these before they're pretty cool


• Comparing programming languages to women: Funny :)

RC3

Three little letters... Hopefully this will become 1.0! (Three more little characters). There are no new features I want to add so the only looking for major bugs and translations.

And about translations... I made a script to import the translations provided in the Gnome version. This was mostly done to stop duplicate work of people not knowing about the Gnome version. (Note to self: I need to get the translations pushed the other way so the Gnomers don't waste too much time too).

I guess a lot of them had been automatically done by some tool as they were completely junk! Then people pointed out they were "fuzzy" and thus are not actually used. Whoops...

There is now a good amount of translations for the following languages:

• English


• Finnish


• French


• German


• Italian


• Lithuanian


• Panjabi


• Spanish


• Swedish


• Turkish

But I want more! Send me your translations! Now! OK, not right now but very soon!

The Gnome and sf.net codebases now match for .py and .glade files. This means after 1.0 I will only work on the Gnome version and periodically backport the changes.

RC2 Away!

OK I did release RC2 a while ago... Turns out my bug doesn't seem to be a problem anymore. Not sure what's going on there - I was probably just tired. So RC2 has the changes previously mentioned and also it now autodetects the Diablo (I've packaged this) and HoiChess. Note to self: Check if a package already exists before packaging it...

These changes are in the Gnome Games CVS repository (I think some made it into 2.17.1). So hopefully at 1.0 the Gnome and Sourceforge version will be synchronised. At that point I'll only be making changes to the Gnome version - I will consider backporting at milestones to make glChess 1.1, 1.2 etc if users want it.

Release Candidate 2

glChess release candidate 2 is all ready to go... Except there seems to be a bug in dpkg-dev. So you'll just have to wait. It fixes a 64 bit bug, a 3D bug and adds fullscreen mode.

Changelog:

2006-11-02 vers. 1.0 RC2
o Fix to lib/glchess/scene/opengl/png.py to fix CRC check on 64 bit
systems (Bug found by Michal Bentkowski).
o Fix to lib/glchess/scene/opengl/opengl.py to stop exception
selecting outside board in 3D mode (Bug found by Michal Bentkowski).

2006-11-01
o Moved glade files to top-level directory.
o Make symbolic link so Glade can find the icon when not installed.

2006-10-31
o Added fullscreen mode.

2006-10-30
o Explicity kill the about dialog as Gtk+ 2.10 does not do it
automatically.
o Got rid of bogus GtkWarning from GtkComboBox on startup.


New open-source nVidia effort

There's a new project called Nouveau to make some open-source nVidia drivers for DRI. This sounds great as DRI seems to fit in well where nVidia just made up new architecture everywhere. From the Nouveau web-page it sounds like it's not too hard to write drivers - all you have to do is convert OpenGL calls to appropriate format for the hardware. All the OpenGL state machine work is done for you by Mesa (and is shared between all the DRI drivers so bugs get fixed once only).

Back in the day I used the Utah-GLX nVidia drivers which were quite buggy but then it was a bonus to have 3D support. The commercial ones were just that much more reliable that I eventually changed to them. I haven't bought a nVidia card since though. If these new ones turn out OK that would change :)

Go open-source!

Upgrading to Edgy Eft

So I've just started downloading the 1GB or so to upgrade from Dapper Drake to Edgy Eft. This is not automatic - but it makes sense as users should stick with the Long Term Support releases unless they know what they are doing (though an advanced GUI element would be nice).

Will report back on success/failure.

UPDATE: The next day...

Worked pretty much fine. Had to do at least one extra upgrade after it had finished to get everything updated, however this was shown by the automatic updater tool so normal users shouldn't have a major problem.

Firefox 2 is nice. Now uses the standard icon (Ubuntu decided they could live with that unlike Debian?). Movies work out of the box so can browse Apple.com trailers etc. It has crashed once on me so far (but new crash catcher seems nice). Hopefully Edgy will pick up the flash 9 plugin when it is formally released.

Startup screens etc seem more colourful and cleaner - a bonus for Joe User. The startup actually seemed slower, but that could just be because there is no boot text now. I must check if escape shows it as it can be very useful.

Aside from that haven't noticed any stand-out changes. I guess it's mostly just polish. I must try Rhythmbox/Banshee - I think they'll support my iPod now. Things like F-spot are formally supported (it uses Mono) so might start using that more.

Just realised that 3D acceleration is not working. But I think it's this bug and it currently marked as "High importance, fix released" so might be solved soon. Basically when I try and load the DRM module I get:
FATAL: Error inserting drm (/lib/modules/2.6.17-10-386/kernel/drivers/char/drm/drm.ko): Cannot allocate memory