Monthly Archives: December 2007

Lazyweb: GtkMenu help needed

Whenever I try to do any GUI coding, I seem to be continually tripped up by what appear to be incredibly basic problems. I don’t know whether it’s just that I don’t think the same way as the toolkit designers do, or if the toolkits are just designed in the most complicated way possible.

I’ve read over and over the GtkMenu and GtkMenuItem documentation, but I cannot see any way of getting the index number of a GtkMenuItem that is clicked on within a GtkMenu. It seems to me like this would be a fairly common thing to want to do, in order to create GtkMenus with dynamic items.

Can any GTK experts out there give me some suggestions as to how I can get the index number of the GtkMenuItem clicked on, in the handler() function below? (Aside from supplying menu_item[i] in g_signal_connect_swapped and then looping through all of menu_items[] and comparing them, that is). Surely the GTK designers can’t assume that every menu item is going to be connected to a different handler function?

    /* ...  */

    GtkWidget *menu;
    GtkWidget **menu_items;

    /* ... set menu item labels in LABEL[NUM_ITEMS] ...   */

    menu = gtk_menu_new();

    for(i=0;i<NUM_ITEMS;i++) {
        menu_item[i] = gtk_menu_item_new_with_label( LABEL[i] );


        g_signal_connect_swapped(menu, "button_press_event",
                G_CALLBACK(handler), ??? );

        /* Alternatively: 
        g_signal_connect_swapped(menu_item[i], "button_press_event",
                G_CALLBACK(handler), ??? );


    /* ...  */

static gint handler (GtkWidget *widget, GdkEvent *event) {

        /* ... want to find out which menu_item (n) was clicked on ...  */

        printf("You clicked item number %25d
", n );

Combatting trolls on Usenet

Despite its bad reputation, I still read Usenet regularly. It’s far more convenient to use than web-based forums (and their invariably over-zealous moderators – we can’t possibly have two threads on the same subject!), and it’s much easier to subscribe to and unsubscribe from newsgroups than to sign up and remove oneself from individual mailing lists.

Usenet has gained much notoriety as being a haven for spammers. This is a tad unfair; while newsgroups certainly do get a little bit of spam, I believe that my email spam-filters catch more spam to my own personal email address each day than I would see on all 30 newsgroups that I read, combined.

No, Usenet’s biggest problem isn’t spammers; it’s trolls and children (often one and the same). Most Usenet readers tend to ignore spam – or report it, occasionally getting the spammer shut down. Trolls create a problem because otherwise sensible people cannot seem to stop themselves responding, and after a short period, you have newsgroups filled with off-topic rubbish. is a prime example. This was once an interesting newsgroup, but as the internet became mainstream, and the death-by-one-thousand-cuts of children was inflicted upon Usenet, has become a wasteland, inhabited by what one regular poster has described as “sockpuppet armies”, one or two people posting nonsense, under a variety of different names. The problem becomes noticeably worse around school-holidays. Add to that cross-posted political arguments from aus.politics, and it becomes rather difficult to see the signal amongst the noise – and yet, despite all of this, the signal is still there. Other newsgroups have similar issues; for example, American nationalists seem unable to keep themselves from crossposting anti-European material to

The biggest problem with trolls is that they cannot simply be killfiled; other people respond to their posts, so all that killfiling achieves is to remove the first post from a trolling thread. Killfiling the entire subject line of a post by a troll doesn’t work either, as sometimes they will respond to an on-topic thread, and this would have the effect of killfiling legitimate posts, too.

The best way to clean up trolling posts in a newsgroup is to killfile any thread that is started by a troll. I haven’t seen any newsreader with this feature yet, so I threw together a quick, kludgy method for doing it, although it is fairly specific to my newsreading setup, which uses Leafnode to spool newsgroups on my laptop and nn to read them.

The killfiler program consists of a perl script called threadkiller, which reads through the spool, searching for posts from people listed in a blacklist and then checking them to see if they are the first post in a new thread. Currently this is determined by looking for the absense of “Re: ” at the start of a subject line, but obviously a better test would be to check for the presence of a References header. Once completed, the script spits out a list of subject lines in nn’s killfile format, onto stdout, which can be appended onto $HOME/.nn/kill. The script keeps track of which newsgroup posts it has already read, so that it isn’t continually rereading hundreds of posts each time it runs.

A future enhancement that I plan to add is one to automatically killfile any thread that is crossposted to newsgroups that are completely off-topic; nn already has a method for doing this, but its operation is quite cumbersome and doesn’t always work. That, in itself, would probably remove around 30%25 of the rubbish in