June 2005

libsexy – Doing naughty things to good widgets

I’ve been needing a label widget with support for embedded URLs lately for a couple of projects, but nothing was available that met my needs. So last night I put together libsexy, which will be my testing ground for experimental widgets that do things that I consider very wrong but very cool.

The first widget I put into libsexy is SexyUrlLabel. It’s an actual GtkLabel subclass with a custom sexy_url_label_set_markup() function. This function takes the same markup that gtk_label_set_markup() takes, except it also groks <a href=”…”>…<a>. The link turns into the standard blue text with an underline. Moving the mouse over the link changes the cursor to the standard hand cursor. Clicking it will emit a url_clicked signal, and right-clicking it will pop up a menu with “Open Link” and “Copy Link Address.”

Sexy URL Label

The only problem I have encountered so far is that if you have a link that spans multiple lines, the hyperlink won’t work on the second line except for parts below the top line’s link. I’d like to blame Pango for this, but I know someone will tell me a way to make this work 🙂 I’m currently getting the X and Y coordinates based on the range that Pango specifies for the attribute, but this doesn’t handle line wraps well. Suggestions are welcome.

This will be going into notification-daemon probably today. I won’t be around after today until next Saturday or Sunday. I’m going to Disneyland with my girlfriend and my family, and won’t have net access (nor do I want it). If anyone messes around with the widget and has any patches, please send them to me and I’ll get back to you when I’m next available.

Update: notification-daemon now uses SexyUrlLabel. Markup (as per the spec) is supported and links are supported. Have fun!

88 != 103. Incidentally, San Jose was lovely today.

I left work a little early today so I could pick up a package at the apartment office that just arrived before the office closed. I was on the phone as the bus pulled up, but I was busy fumbling for my bus pass, and didn’t read the number on the bus. There were two buses that went to that stop, and the 103 left, leaving the 88 to arrive. I assumed, therefore, that this was it. It wasn’t.

A long trip later, with plenty of stop and go traffic, I was in San Jose. I’m in Palo Alto. For those that don’t know, the bus route goes like this: Palo Alto, Mountain View, Sunnyvale, Santa Clara, and then San Jose.

A brief 10 minute wait in San Jose and the bus back home arrived. I fortunately managed to get a lot of work done on the libgalago GLib port on the bus.. And now I’m finally home. 3 hours later. Now I’m going to just sit here.. watch TV.. *yawn*

Silent Noise

So we don’t have flying cars. That’s okay, I didn’t think they were a great idea anyway. There are no personal android helpers. They’d just take up my closet space anyway. What I can’t figure out though is why we’re still using wired headphones. I know there are wireless ones available, and that wireless phone headsets are becoming more popular, but it sure is taking a while.

The wires a nuisance, I believe, but it seems most people have become accustomed to them. I still haven’t. I sometimes get my arms or backpack tangled in them. If I’m listening to my Rio and stand up without thinking, the Rio will fall to the ground. And they just look ugly!

I’d like to see a future world, maybe 3000 or so at this rate, where every earphone set can communicate wirelessly to devices through, say, Bluetooth. I want priorities in the devices where, if I’m listening to music and my cell phone rings, the music will mute and I’ll hear the ringing. Tap the headset/earphones and it’ll answer the phone. When listening to music, a tap could pause/unpause. No more pressing buttons on the device or changing volume if I need to listen to somebody who’s talking to me.

How hard would this be? We’d definitely need a standard for communications and priorities, and every upcoming CD player, MP3 player, radio, etc. would have to support it. The technology for actually doing the communication would have to fit inside the earphones/headsets, though that’s probably doable or close to doable now.

If we all wanted to look like cyborgs, there are other options if we kept these on or with us all the time. A TV in a bar or pizza place or even at home could mute its speakers and yet still broadcast the audio wirelessly. If you need to listen to the news real quick, and it’s too noisy in the restaurant, put on the headset and listen in clearly.

Just some stuff I was thinking about earlier.

Waterfalls and Wooden Steps

I decided to take some pics of the outside area of VMware the other day. I finally put them up. Walking past the pond and waterfalls and fountain and all that greenery is a nice way to start each day.

Outside VMware
I walk through here to go to my office every day.

I Can’t Believe It’s Not Chicken, now in gelatin style

Something I threw together the other night in Inkscape


I finally gave up with the whole “playing everything politically safe” with Galago and am now moving the whole library to GLib. It’ll take some time, and there’s a few things I need to figure out first. For example, a very useful feature that Galago’s object model let you do was connect a signal handler on a class itself, which would call the handler any time the signal of any object of that class was emitted. This of course didn’t translate to other object models or bindings well, and certainly doesn’t translate to GLib at all.

One of my potential solutions was to create a Manager class for each class where developers would want to do this. The Managers would be singletons and objects would emit signals on them as well as themselves. Maybe Manager is a bad name of the type of object… I’m still not sure what to do about this. It’s a very useful feature though, and the only alternative for everything that currently uses this is to set up a bunch of signal handlers for parent containers to know when these objects are added/removed and then register/unregister signal handlers every time the objects of interest are created/destroyed. It’s a lot of messy code, and would take up more memory than a manager interface. Still got to play around with the idea more…


I’ve begun work on porting libnotify and notification-daemon to D-BUS 0.3x. I plan to use a simple abstraction layer consisting of macros to keep compatibility with D-BUS 0.23.x for now. I have a lot of work to do this week at VMware, so I don’t have a whole lot of time to devote to it right now.

Mike Hearn and I had a talk earlier about extending the notifications spec. Sorry, we’re still not going to provide a way to embed Mozilla. One thing people have been wanting, though, is to be able to associate a notification with something on the screen, say, a notification icon. So what we’re going to do is provide support for X, Y coordinate hints. Since they are hints, the renderer will be able to just ignore them if they want. However, this would allow the battery applet (for example) to say, “I have a notification, and here’s my location!” and the renderer could pop up a notification near there with, say, a little arrow pointing to that X, Y location. This could be useful in a few situations, though hopefully it won’t be abused.

I have some future plans for the notification daemon. I’m going to put together a (for now at least) experimental daemon that has two types of plugins: Render plugins and Transition plugins.

The Render plugins will be responsible for rendering the notification. They could do the nifty folding thing that appeared on Planet GNOME a while back. They could do a bar sitting at the bottom of the screen, semi-transparent. They could do toaster popups. Whatever.

Transition plugins handle how the notification will be displayed. They could just show a notification, fade it in, slide it in, make a poof of smoke.

Again, it’ll be a while before I can start on this, due to life just being busy right now.


And this is one other reason why life is busy. My girlfriend Jamie and I are going with my family to Disneyland after next week. Unfortunately, this week is spent on some deadlines at work. But that’s just going to make the next week even more fun 🙂 We’re staying at the Disneyland Hotel, which will be a first for both of us. I’ll have plenty of pics when I return.

Scroll to Top