Posts Tagged software

Color optimization, take two

An anonymous commenter suggested I use CIE L*a*b* instead of HSV. I’ll let the results speak for themselves:


And that’s without any tweaks, fancy distance metrics, or pushing outside the region when the vector is too short. Whoever you were, thanks for the suggestion! Also, thanks to Madeleine Ball, whose suggestion I misunderstood, but is basically the same.

Update: with some vector extension code (slightly more contrast when colors are really close). The code is in xchat-gnome SVN for everyone to play with now.

Tags: ,

Overengineering beyond all reasonable limits: automatic color palette optimization

A while ago, it was suggested that GTK+ themes provide an ability to define certain colors. The reasoning behind this was that if a theme had a red background for something, just defining red as #ff0000 could result in unreadable text. As usual, some objections were raised, and IIRC nothing has yet happened with it.I was interested in this, because xchat-gnome is one of the very few things where it actually makes sense to define colors by name. It’s all well and good if a theme provides defined colors for heading and alert, but IRC allows people to mark text as red or aqua. Theme based colors weren’t an issue yet, because xchat-gnome worked on purely pre-defined color schemes for the conversation panel. Until now.

Perhaps it’s just been too long since I did any graphics programming, but when I thought this idea up in the shower (as an aside: I have, in the past, been known to take showers for the sole purpose of thinking up ideas), I just had to implement it.

Basically, instead of defining a color as a specific RGB triplet, we define it as a region in HSV space. HSV is a color space that matches more closely to how we as humans tend to define colors. It’s a cylindrical coordinate system where the angle defines hue, the radius defines saturation, and the vertical axis defines “value” (basically white to black). The colors within this cylindrical space fill a conic region.HSV_cone.png
The actual mapping between RGB and HSV forms a hexacone, due to colors in HSV that cannot be represented in RGB. Anyhow, we’re defining colors as a kind of wedge of this coordinate system. That means that when we say blue, we’re not actually defining a color, but a range of colors. Blue can be dark, it can be light, and it can range from purpleish-blue to cyanish-blue.

When the background color is not known a priori, some colors within this region may be too low a contrast to be readable. The background color is a point in HSV space, and by choosing the point within the region which is furthest from our background point, we get a foreground blue which is readable.

Of course, there are still some problems with this. The background color may lie right in the middle of a color region. In this case, even the furthest point within that region is going to have very low contrast against the background. To guard against this, if the hue of the foreground point is too close to the background and the saturation is high, the value gets pushed a little further out. Value (lightness) is a primary influence on how we percieve contrast, so by emphasizing it, the text becomes (mostly) legible.

color_optimization.png As a result of this, colors against a white background tend to be dark, while colors against a black background tend to be light. By defining white and black as regions which have some breadth in the value dimension, white-on-white text and black-on-black text become readable. When on a grey background, text gets pushed in either direction depending on whichever is furthest away in the HSV color space. For the most part, this works very well (you can see the purple color has some problems on this particular shade of grey). Because colors have some breadth in the H and S dimensions, even highly saturated colored backgrounds work well.

Of course, xchat-gnome allows image and transparent backgrounds, which are completely ignored by this. Nothing can deal with high-frequency high-contrast backgrounds, so I’m just going to say if you’re foolish enough to try that, you get what you deserve :). This code has landed in xchat-gnome SVN, and there’s been enough awesome stuff since 0.11 that a new release should be coming soon.

Tags: ,

alpha blended windows in python

Here’s a version of Mike’s alpha demo, in a python implementation that’s more pythoney (rather than a direct translation from C). GTK+/pygtk folks, any chance we could get that compositing-manager detection code out into the world before 2.10? :)

Tags: ,

Tagging love and community ire

A couple days ago, searching for something cool to hack on, I came back to leaftag. Shortly after I started updating the deskbar handler, Luis Villa posted on his desire for it, and a release got cut. It’s pretty incomplete and buggy, and not very useful right now, but still enough to get a number of people excited.

However, it’s also enough for people to start giving us their opinions. I really don’t know why, but for some reason there’s a large group of people who really want us to use extended attributes to store the tags. Even after giving them a bunch of reasons why it’s not useful for our purposes, they keep trying to tell us how to build our bike shed.

I don’t understand why xattrs are such a big deal, and I don’t understand why everyone cares so much about how our implementation works. They’re never going to touch the code, and as long as it does what they want, why should they care what’s under the hood? I’ve set to see one comment on Christian’s blog that asked for a feature that required xattrs without first saying we should use xattrs. It really felt like all the features they listed were just attempts to justify their position that xattrs are the coolest thing since sliced cheese.

I’m starting to understand why Novell kept Xgl’s development under wraps until things worked.

Maybe I’m only starting to see something that has existed for years, but it really feels like gnome is so encumbered by endless talk, bike shedding and stop energy that very little is happening. The cool things like gimmie, deskbar, nautilus search and leaftag only happen when someone goes off in a corner, shuts themselves out from the community for a while and actually writes some code. The mailing lists and irc channels were recently aflurry with conversation about what “community development” means, and just as quickly as it came, it was gone. A huge amount of time and effort was invested into that discussion, and absolutely nothing came of it. This isn’t an unusual pattern.

I’ve heard it suggested by a couple people that gnome needs a dictator, and I really think that’s the case. At the very least, gnome needs someone who can tell people to shut up and get back to work.

And for all you xattr fanboys, code speaks a lot louder than words. Show us that xattrs provide something useful and good, and we’ll talk. Until then, shut up and get back to work.

I’m usually not one for movie quotations, but I’m considering adopting one as my mantra. “Fuck the bozos!”

Tags: , , ,

A big web of data

I just spent about 30 minutes entering links into wordpress. It’s something I’ve been meaning to do for a while. As I was nearing the end of this process, I began to realize something.

A visitor to this humble page would get not only my ramblings, but links to a fair number of my friends’ journals, my bookmarks, my CIA stats and my photos. Along with all of these, they also get RSS for everything. This is a staggering amount of information, and there’s got to be something cool that can be done with it.

I’m starting to toy with the idea of a web service that would take a page, parse out links, follow things with proper XFN relationship tags and…err…do something with all that. Probably nothing will come of it (given my current projects situation), but it’s an idea that’s so tickly that it just might happen.

Tags: , , ,



Tags: ,

GNOME API documentation

No wonder GNOME (and linux?) doesn’t have very many ISVs. The platform really needs a new documentation system. Here’s why.

A couple weeks ago, while working on a gnome-vfs module for Chippy’s super-sexy tagging system, I noticed that gnome-python has no API documentation. No HTML, no docstrings, nothing. In order to find out a method signature, I had to look in the source code and decipher the python/C binding code.

Now, the python bindings are arguably somewhat further out in the gnome orbit. However, for an officially supported binding, this is pretty bad. The documentation for the C gnome-vfs API isn’t much better. When an ISV comes to gnome and takes a look at this, they’re going to run screaming. I know I did, and I’m willing to put up with a lot more of this crap because I know how hard it is.

How hard it is. Think about that for a moment. Setting up gtk-doc for a C module is a black art, full of copying strange build-system stuff and hours spent trying to figure out which XML files are auto-generated and which are safe to edit. If you’re lucky enough to be documenting something like gnome-python, all you have to do is write a bunch of docbook. Let me say it for the record: docbook is a total pain in the ass. I love the idea of using one source to generate HTML, pdf, etc all in one go. This is a well understood problem, and docbook is a great solution to it. Unfortunately, because docbook is such a pain to write, people aren’t doing it, and that’s the real problem.

I decided that because I was already taking the time to figure it out, I’d document it. gnome-vfs isn’t a huge API (and the python bindings are even smaller), yet it’s taking me at least two hours per object to get everything right.

The GNOME release team is requiring full API documentation for new modules, and that’s a step in the right direction from a policy standpoint. However, we need a lot of steps from a technical standpoint. gnome-vfs is pretty close to “fully documented” and yet completely impossible to use. Mono is doing something good here — anybody can edit API documentation, in a wiki-like manner; it’s not hard to find what to edit, and the commitment involved is minimal. I think if we got something similar across all of the GNOME platform (for every language), we might begin to see some real documentation. Writing API documentation isn’t hard. Writing API documentation using the current framework is a nightmare.

Tags: , , ,

paper tigers

Big flame fest going on over at regarding print dialogs, “usability” and features. Kind of entertaining reading, kind of frustrating reading.

The paper tiger here is the tendency to assume intent behind any particular result. In this particular case it’s the assumption that options provided by a PPD printer driver aren’t exposed in the gnome print dialog because they’re confusing to the user.

I’ve seen a number of people complain about my own software (xchat-gnome) using similar arguments. “Those idiots! They removed the ability to get user information!” “Those idiots! They removed the ability to detach individual channels from the main UI!” Seeing people I’ve never heard from before say things like that in public forums is painful — most of the time, xchat-gnome development is just me, and I’ve got school, work, and several other projects, in addition to a usually-failing attempt at a social life. A lot of these kinds of problems are nontrivial (such as detaching), and just because something isn’t there doesn’t mean it will never be.

I wonder if anybody really talked to the gnome-print developers about getting UI for the extra PPD options. Judging from my own experience as both a user and a developer, I’d be willing to bet that their answer would be “well, it’s hard and nobody’s figured out how to do it right” rather than “we decided that our users were too stupid to use those features.” I’m not really familiar at all with these projects, so I’m just guessing.

There’s an old adage: never ascribe to malice what can be adequately explained by incompetance. I’d like to propose an equivalent for the open-source world (and gnome in particular). Never ascribe to malice what can be adequately explained by a lack of time and manpower. I can’t think of any free software author who is willing to sacrifice truly useful functionality in exchange for a slightly lower widget count.

In the ML thread, the word “usability” came up quite a bit. For the most part, people seem to be (quite correctly) pointing out that it’s a pretty meaningless word. I got to wondering — what does usability mean to me? I’ve written a lot of GUI software, and I generally consider xchat-gnome to be pretty “usable,” but I’m not sure I ever really came up with a definition. After some thought, here it is: Software is usable when it provides the functionality a user requires to execute a certain task, in a discoverable (or at the very least least well-documented and learnable) way, with said functionality organized in logically and a minimum of extra distraction or clutter.

As always, there are people more eloquent than I who have considered this problem. “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

Tags: , ,

“Art and Computer Programming”

A while ago, I read Art and Computer Programming, and this post has been brewing since. I’m more than a bit disappointed in the responses I saw there. It seemed like everyone they interviewed approached the question from a purely practical point of view — whether or not they considered programming to be art, they all felt that they had specific (usually boring) problems to solve, and some of them considered the process of solving those problems to be art, and some didn’t.

Whatever happened to the beauty intrinsic in a solution? Who cares whether the problem is useful or not, or whether the software is written for a client or just for the sake of experimenting.

Personally, I think programming can be art, but most of it isn’t. A lot of the open-source code I’ve written is really pretty boring, designed to do a boring job with a minimum of fuss. However, at some points, beautiful things emerge which I consider art. A few of the algorithms and architectures I’ve designed have felt like something special to me. Every once in a while, when reading other people’s code, I come across something and think “goddamn that’s clever.” It may take an experienced programmer/computer scientist to appreciate the beauty of these things, but to me, that’s art.

But you can’t have one without the other, at least not in a working system. A brilliant algorithm is useless without a whole heap of boring code to set things up, present results to the user, etc.

Is all programming art? Hell no. However, I think that every so often, a small piece of the resulting system can be called art, but it’s a weird kind of art; art invisible to almost all of the people that see it, and that can only be truly appreciated by other artists.

Tags: ,

accidental epiphanies

Sometimes I say something to someone in jest, and it’s only later that I realize just how true it is.

Today’s edition: “Because I’ve gotten too lazy to actually visit web pages anymore”

In particular, I’m thinking of what some would call the “RSS Revolution.” Those of us who aren’t quite as apt to latch on to catch phrases might describe it as a change to subscription-based delivery. I only recently set up a feed reader, but I think I’m beginning to understand what everybody is so excited about. It’s definitely different to be able to get the latest updates from a bunch of web sites almost in real time instead of keeping a folder of bookmarks that would get checked weekly at most.

Even before I uttered this remarkably poignant statement, I’d been thinking about the nature of blogging. I remember being floored about a year ago when I was talking with my parents and tried to explain what a “web log” was, only to get the reply “we know what blogs are.” Back in the day, blogging was something only done by geeks like me. Back then, I called it a “news” page, and was under the rediculous impression that people actually read it. This time around, I started out thinking that the only person who would read it would be me. I was pretty shocked when I found out that at least one of my friends does read it.

Even stranger, a lot of my friends keep blogs. I don’t know what inspires them to do it, since it seems everyone who does has a different reason, and they’ve never broached the subject publically. I think the reason I’m doing it this time around is just because it’s a fun exercise to try to turn a bunch of jumbled thoughts about a subject into a coherent article. It’s also pretty handy to have a place to rant when I’m feeling particularly irked about something. For me, writing was always something I dreaded. Now it’s surprisingly addictive. From what I’ve read, it seems like a lot of other people have found that they enjoy writing when it’s in the form of a blog.

Whatever the reasons people use to justify putting their thoughts and feelings on a web page (and RSS feed!), the fact that they’re doing it is, in my opinion, an important shift in how society is working. A diary used to be something that you never let anyone read; I remember that they even sold diary books with locks on them. Now it’s something that people halfway across the globe can find with a simple technorati search. Feelings used to be something that people had to sense by observing body language and carefully determining the meaning behind what people said. Now bloggers are writing their feelings down in surprisingly honest terms and summarizing with a “mood icon.”

So what does it all mean? I’m still not sure. Whereever this “revolution” goes, I think it’s going to be exciting. Will the podcast become the new blog? Maybe. Will people start filming bits of their lives and “vidcasting”? Perhaps. Will the new, social face of the internet change the way people interact with one another? Definitely. I think it already has.

Tags: , , ,