Older blog entries for cinamod (starting at number 108)


Went kinda nuts today fixing and releasing a variety of packages that I maintain.

  • wvWare 1.2.1, includes fixes for handling WMF files on MSFT Windows
  • Enchant 1.2.3, includes Yiddish support and some bug fixes
  • librsvg 2.14.2, for the GNOME 2.14 release. Requires some fixes of mine in libcroco 0.6.1.
  • Link Grammar 4.2.0, with support for non-English languages
  • gtk-wimp, pushed a major speedup and some minor bugfixes onto the GTK+ HEAD and 2.8.x branches. Thanks due in large part to John Ehresman.
9 Mar 2006 (updated 9 Mar 2006 at 22:45 UTC) »

Saw (linked from Miguel's blog) screenshots of Novell's upcoming SuSe release. Did anyone else notice the last picture?

It includes a complete office suite, web browser and IM, supported open source solutions for for digital picture management and music management, plus dozens of other powerful business tools.

I can see the ads now: SuSe Enterprise Desktop - now featuring powerful business/productivity tools such as Klondike Solitaire!

/me ducks

I'd like to applaud the formation of the OpenDocument Alliance. Non-open file formats are defacto anti-competitive measures. Coupled with inane anti reverse-engineering and anti-circumvention laws such as the DMCA, these serve only to create oligopolies and entrenched vendor lock-in.

The data is mine and I have a right to it that supercedes any dubious "business interests" you might have in keeping your formats and protocols closed. Your product is only a means to my ends, and not an end in and of itself.

There's apparently a new Intel-based MacMini from Apple on the market. If you look closely at the schematics, there's a "security hole" built into the back of the device :)

Spent the President's Day holiday hacking AbiWord (it's been a while; felt good to get back into action). The result of a few hour's labour is that AbiWord can take advantage of GnomeVFS if it's present, letting users do all sorts of neat things with remote files. Patch with relevant info.

Does anyone else find it unsettling that the Linux Standards Base guys in charge of ABI compatibility don't appear to know the first thing about ABI compatibility? I'd expect better from an Intel employee, but at least he had good enough sense to ask the question. Or have people largely written off the LSB these days?

Quoteth the blogger:

I wonder how much intersect with Nokia Maemo, but that would be their interest to team up to create a viable ecosystem of software. Maybe this time we could have AbiWord on PlamOS?

Nooooooo, Hub! Otherwise, my threat in ap_EditMethods.cpp will become moot!

15 Feb 2006 (updated 15 Feb 2006 at 23:24 UTC) »

For my dayjob, I've been playing around with the software libraries referenced from the Jabber site, and have experienced nothing but frustration with them.

It seems that most of the libraries mentioned there suffer from one or more of the following defects:

  • Unmaintained
  • Has less documentation than an illegal immigrant
  • Has an unusual and bloated dependency list
  • Doesn't support encryption
  • Expects the Jabber server to be the same as the domain part of the JID (eg. it won't work if the server is talk.google.com and the user's JID is user@gmail.com)
  • Has other known bugs in it that stop it from working with popular servers like Google Talk
  • Is a forked copy of some broken library that fixes some of the above problems. But the fork has become tightly bound with some parent application, and the "library" frequently references singletons and functions found in the parent application, so that it's not usable as a library any more
  • Is written in some language like Flash or PHP or Javascript that I'll never be able to convince my boss to use

So, if anyone has a favorite Jabber library that works ok with Google Talk and isn't written in say, Flash, I'd love to hear about it. I haven't tried all of the ones listed (I'm walking the list in my preferred language order), so maybe some client will work.

Update Thanks for everyone who gave me hints and suggestions. For those who care, I've settled on Smack. It's super-spiffy.

There's been much talking about what it means to be a community on the Planet and desktop-devel-list lately. If you're in the Boston area, please feel free to come on over to John Harvard's tonight, have a beer, kick back, and relax with some of the community tonight.

More info here.

5 Feb 2006 (updated 5 Feb 2006 at 20:49 UTC) »

In a thoughtful email, I've been told that I didn't accurately address Davyd's concern in my last post, so let me excerpt the email and further clarify and qualify my statements.

In your reply to Davyd, you're basing your argument on a different use case than he. [snip] Its not about finding out the file-type. What Davyd talked about, and what I also regularly do, is the opposite: Finding files of a certain type. [snip] You are right in saying that simply putting the file-type as text into the icon might not be the optimal choice but so far, I at least am not aware of a better one.

So let's run with that.

Let's forget that you can probably do this based on the file's name easily enough. Let's put aside the fact that having this info embedded in a smallish image probably isn't ideal. Let's put aside the fact that representing text as an image is lousy for a variety of reasons and recommended against by the GNOME HIG (most likely for i18n purposes). Let's see what other tools Nautilus gives you to solve this problem.

If one wants to, one can organize the icons by their type. One can choose to display the file's type in its caption. One can also choose to use the list view, which includes the file's type in the view by default.

There are at least 3 other easy ways to view and use this information for that particular use-case. I contend that there are alternate (I'd contend, better) ways of viewing this information than having the information embedded inside the file's icon.


Christian has suggested that if you really want this behavior, it might be accomplishable via Nautilus emblems. Dave Camp's blog from yesteryear suggests that it might be possible.

As Christian mentions, breaking API/ABI isn't something to be done lightly, even if your module isn't constrained by GNOME's API/ABI policies. My argument doesn't concern itself with that, however, only with the apparent "loss of information and usability" that has been claimed.

Even if you think the puported usability arguments are thin, I think that I've shown that usability arguments for keeping them in are at least equally thin. In that case, please at least consider deferring to the HIG, which quite clearly says "no text in icons" and decide on a better way of achieving the semantics you're after.

99 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!