mind can has mountains

I thought I’d document my process for finding and fixing bugs, just to see how I actually work. To begin with, I chose a fairly recently-reported snag that seemed to be straightforward; it’s [#18414] “Check boxes giving wrong columns”. It seems that the choices you make in Edit>Preferences “Visible Columns” aren’t always the same as what you get. Now, I seem to remember that these choices are held in gconf preferences, so I load up gconf-editor, navigate to apps and alexandria and see a set of boolean variables: col_own_visible, col_rating_visible and so on. I try turning them on and off via Alexandria, and it seems to affect the right gconf variables. But I can clearly see the “Rating” column disappear when I de-select “Own” - just as the report describes. The problem is in the listview display: lets have a look at listview.rb

Before I forget though, I have to record some incorrect behaviour I noticed through the gconf-editor - the cols_width setting saves column names in their translated form. This must be why I keep loosing the setting for column widths - I’m forever switching locale as I test out new translations. I’ll write that behaviour on a Post-it to deal with later.

Okay, back to listview.rb and I’ve found the column visibility code in the method setup_listview_columns_visibility. I can see that the set of booleans from the gconf prefs is being set up into an ordered array - cols_visibility - to be correlated with the ListView columns in a loop just below. The ordering must be wrong…. I split the Emacs editor window horizontally and try to find the order in which columns are added to the ListView in the upper pane while keeping the cols_visibility in the lower pane. Right! In setup_books_listview the title column is set up first (but it can’t be turned invisible, of course) the each of the columns in TEXT_COLUMNS are added in turn, followed by all the CHECK_COLUMNS and then the rating column. Oh, and a tags column that’s getting set up but not displayed (adding that to another Post-it!). Lets write all that in a list.

Now to compare it with the cols_visibility matrix.

Okay, I think we have the superficial cause of the problem identified. Let’s change the order in that array of booleans. First, though, my cat wants to say hello…

So after playing with Sibbie for a while, it’s back to Alexandria. I fixed the order of the variables in cols_visibility to match the columns - it’s a 3-line fix. Well, I’ve noticed a few other issues along the way, so while I’m at it, I touch up the preferences dialog a bit, rearranging the checkboxes and adding a preference option for Tags. I commit my changes to subversion, r958. Then I go to the bug report on RubyForge, add a comment and mark it closed.

So, that’s another snag uncovered and fixed. Now for the point of the article: why did this type of bug arise in the first place? Simply because the original code (Laurent’s, not Joseph’s, by the way) was designed for a small system in which it was easy for the programmer to check that the column array and the boolean array were in sync. It must have broken gradually as code was added and moved about, it was inevitable really. If the code were a bit more “type-safe” (using that term in its loosest sense) then the task of remembering the ordering of arrays would be left to the software, not the programmer. I haven’t even fixed that, so the weakness remains. This is the kind of weakness, present throughout the Alexandria code, that needs to be addressed in the future design of Alexandria.