ObjC > C
After spending 6 weeks at work learning Cocoa/OpenStep and Objective C and then writing some GUI apps, coming back to Gtk+ and C makes me kinda sad. I hate typing out really long function names. I hate the class casts required to do just about anything. I hate the boilerplate code I have to write every time I make a new GObject subclass (yes, I know about GOB, but just the presence of that code annoys me). I hate crap like G_OBJECT_CLASS(foo_object_parent_class)->finalize(obj) -- yes, I know you often have to do things like [super dealloc] in Objective C, but look how shorter that is.
I love Objective C. Is it perfect? No, of course not. Not having class variables seems a little weird (but a 'global' static variable in the implementation file will do). It's a bit slower than C (though probably only about 10% in a typical GUI app). Is the syntax a little weird? Yeah, but it's not bad. Having to type out method parameter names along with the parameters themselves can be a little annoying, but it's often more clear.
I really wish there was an up-to-date Objective C binding for GObject and Gtk+. I found GTKKit and GToolkit, but they were written for Gtk+ 1.2.
Anybody know of a more recent ObjC binding for Gtk+ that I didn't notice?
Oh, and on a side note, I also love Interface Builder. Maybe I should look at Glade sometime.
Best-of Best-of
I'm a huge fan of the Craigslist best-of list. For the uninitiated, Craigslist readers can vote for the best posts on the site, whether it's an amusing rant, a creative furniture ad, or a sappy story. Some are great, some are not. I present, without further ado, my best-of best-of list:
The that's incredibly gross but hilarious award (bonus points for toilet humor)
The aww that's so sweet and sappy award - Honorable mention, aww that's so sweet and sappy award
The cool-prof award
Honorable mention: short but sweet
New Phone
On a couple occasions (too lazy to find the post), I've written about cell phones, and what I'd want to see in my next phone. Well, I more or less decided to throw all that away, or, rather, to just concentrate on a few key features, and let the rest of the phone sort itself out.
Seb arrived last week from China, and he needed a new cell phone. I found Let's Talk, which cells carrier-branded phones and service contracts, but somehow manages to give ridiculous deals on phones such that you can often make money by buying a phone. This was too good to pass up, so I figured I might as well order a new phone (a Samsung T619) and new service (T-Mobile) myself.
I ordered the phone Thursday night, and it arrived on Tuesday, with free 2nd-day shipping. Not too shabby. I love the new phone, though it's not perfect. It's quite a bit thinner than my old phone, which is great, since I keep my phone in my side pocket. It has a 1.3 megapixel camera, which isn't particularly exciting or wonderful, but it's decent for taking quick shots of things where the quality doesn't matter and I don't have my real camera. I also realised that I like that the phone just has a camera, period, so I can take pictures of my friends to use as caller ID photos. Call quality is very clear, and it's able to make calls even when I have only one bar (my old phone had trouble with that, though that may not be an apples-to-apples comparison). It's a quad-mode phone, so I should be able to use it anywhere in the world (though I'd want to find an unlock code so I can buy regional SIM cards since T-Mobile's international roaming charges are pretty high, or so I hear). The UI is clean and the default setup is very pleasing, with light text on a black background. It has Bluetooth, and I've already successfully done file transfers with it (even using Linux on my PowerBook).
The downsides are few, but notable. The external screen turns off after a few seconds to conserve power. This means if I want to pull it out of my pocket to check the time, I have to hold down the volume up button for a couple seconds to make it turn on. It's a minor annoyance, I suppose, especially considering I've started wearing a watch again.
The earpiece volume is a little lower than what I'm used to, which could be a problem, but I've been ok so far.
Likely due to commercial interests, the phone is retarded when dealing with ringtones. If I transfer an MP3 to the phone over Bluetooth, it won't let me assign it as a ringtone. Apparently there's some trick you can do where you reencode the MP3 using AAC in a .mp4 container, and then rename the file to have a .3gp extension. This somehow "fools" the phone into letting you play it as a ringtone. I tried it, and it appeared to work, though the volume was too low (fixable, probably), and the first quarter- to half-second of the clip got cut off (probably fixable by prepending some silence to the file).
It uses a proprietary connector for the headset, which is super lame. Fortunately, it came with a (cheap) earbud headset, and I have a Motorola Bluetooth headset somewhere in one of my packed boxes.
One final thing it doesn't have (or at least I haven't found it yet) is the ability to vibrate and ring simultaneously. The vibrate function also feels a little weak, but it's not bad.
Overall, I think I'm pretty happy with the new phone, and with the service, at least so far.
Bastard Spammers
Last week, Xfce Bugzilla got its first spam. Someone created an account, and attached some HTML cialis ads to an existing bug. I quickly disabled the account, and marked the attachments as obsolete and changed their content types to application/octet-stream, so browsers wouldn't attempt to display them.
I figured, eh, whatever, it's a one-off thing.
Nope. Someone just did it again, with a new account.
So I figured I'd google a bit to see if I can find some Bugzilla spam solutions, and I came upon this mailing list thread. How fucking devious. The spammers are attaching their HTML ad files to Bugzilla bugs, and then linking to the Bugzilla attachment URL in email spam, or blog spam, or whatever, instead of using their own websites to host the ads.
There's talk of implementing some optional CAPTCHAs (which suck), but aside from active filtering of comments and attachments using some sort of heuristics (i.e., building an email junk filter into Bugzilla), there don't appear to be any solutions. If anyone has seen anything to combat Bugzilla spam, or has some tips to make this more difficult, please let me know.
God dammit.
Xfce Volstatus Icon 0.1.0
Yesterday I released the first version of my Xfce Volstatus Icon. It's a pretty simple little app; all it does is sit quietly (and invisibly) in your system tray until you plug in a removable device (like a USB flash disk or an iPod), and then it turns into a little icon that you can click to easily and safely unmount and/or eject the device so you can physically remove it.
The code for the icon itself is relatively simple; it's all less than 2000 lines of C. Another 2000 lines resides in 'ghal', a library I've written to act as gobject bindings for libhal and libhal-storage. Currently it's not documented at all, and it's not released as a separate library dependency, but included in the xfce4-volstatus-icon source package. I first wrote the libhal bindings for Airconfig, and then extended them for volstatus to include libhal-storage.
The upshot is that you can create a GHalContext object, and connect to gsignals on the object such as device-added and device-removed. You can enumerate devices (GHalDevice objects) on the system via their UDIs. Now ghal also knows about 'special' devices, which are subclasses of GHalDevice: GHalDrive, GHalVolume, and GHalVolumeDisc. The cool thing is that you don't have to know what they are explicitly. ghal_context_device_from_udi() will create the right kind of device and return it to you cast to a GHalDevice; you can use e.g. GHAL_IS_DRIVE() to determine if it's also a GHalDrive, etc. Currently you can use ghal_context_find_device_by_capability() to find devices of particular types if you know the HAL capability strings, but I plan to add convenience API to abstract the capability strings.
I'd also like to add more objects, like GHalComputer (the root computer object), and support for performing actions on particular devices (like mount/unmount for volumes, suspend/hibernate for the power management interfaces, etc.). I'm also debating including some parts of Airconfig in there as well (mainly the interface control stuff), though I'm not yet convinced that that's necessary or useful, especially since it currently relies on a custom HAL addon and method-invocation scripts. At any rate, I think it's pretty useful for people who want to use HAL just like any other glib/gobject-type services, and I'll turn it into a standalone library Real Soon Now[tm].
(Yes, I know about libhal-glib, written by Richard Hughes for gnome-power-manager. However, I don't really like the API that much, and it obviously has a decidedly power-management-slanted focus that I don't need.)
Xfce Volstatus Icon 0.1.0
Yesterday I released the first version of my Xfce Volstatus Icon. It’s a pretty simple little app; all it does is sit quietly (and invisibly) in your system tray until you plug in a removable device (like a USB flash disk or an iPod), and then it turns into a little icon that you can click to easily and safely unmount and/or eject the device so you can physically remove it.
The code for the icon itself is relatively simple; it’s all less than 2000 lines of C. Another 2000 lines resides in ‘ghal’, a library I’ve written to act as gobject bindings for libhal and libhal-storage. Currently it’s not documented at all, and it’s not released as a separate library dependency, but included in the xfce4-volstatus-icon source package. I first wrote the libhal bindings for Airconfig, and then extended them for volstatus to include libhal-storage.
The upshot is that you can create a GHalContext object, and connect to gsignals on the object such as device-added and device-removed. You can enumerate devices (GHalDevice objects) on the system via their UDIs. Now ghal also knows about ’special’ devices, which are subclasses of GHalDevice: GHalDrive, GHalVolume, and GHalVolumeDisc. The cool thing is that you don’t have to know what they are explicitly. ghal_context_device_from_udi() will create the right kind of device and return it to you cast to a GHalDevice; you can use e.g. GHAL_IS_DRIVE() to determine if it’s also a GHalDrive, etc. Currently you can use ghal_context_find_device_by_capability() to find devices of particular types if you know the HAL capability strings, but I plan to add convenience API to abstract the capability strings.
I’d also like to add more objects, like GHalComputer (the root computer object), and support for performing actions on particular devices (like mount/unmount for volumes, suspend/hibernate for the power management interfaces, etc.). I’m also debating including some parts of Airconfig in there as well (mainly the interface control stuff), though I’m not yet convinced that that’s necessary or useful, especially since it currently relies on a custom HAL addon and method-invocation scripts. At any rate, I think it’s pretty useful for people who want to use HAL just like any other glib/gobject-type services, and I’ll turn it into a standalone library Real Soon Now[tm].
(Yes, I know about libhal-glib, written by Richard Hughes for gnome-power-manager. However, I don’t really like the API that much, and it obviously has a decidedly power-management-slanted focus that I don’t need.)
Jerry Springer + Congress = Awesome
If US Congress was more like Taiwan's Parliament, I think many more people would be interested in politics.
Stupid Motherboard
Ok, this is retarded. About 2 years ago, I bought a DFI K8M800 MLVF motherboard to act as the foundation for my HTPC/PVR box. This was before I had my 6.1-channel sound system, so at the time, I was ok with the onboard VIA 8237 sound chip, which, without buying an extra connector bracket, would more or less just give me 2 channels.
However, after setting stuff up, I had no sound. I was not pleased. I googled and googled, and found that the ALSA driver for that chipset (snd-via82xx) was a little messy, and sometimes you had to pass special parameters to the driver to get it to work for your particular hardware. I tried a bunch of combinations, but had no luck. Eventually I gave up, and bought a cheap Turtle Beach card. By that time, I'd bought my surround sound system, and wanted something that could do digital S/PDIF out (though this card only does coaxial, not optical, but whatever).
Lately I've been thinking about reducing power usage on the HTPC, with the possible intent of retiring my desktop machine and moving all the data to the HTPC on a RAID array that I'd build and put in an external box using something like eSATA. I'd also need to free up a PCI slot: even though I'm only using 2 of the 3 slots, the 3rd slot is effectively blocked by the large fan on my AGP video card. So, I thought it would be a good idea to try to get the integrated sound working again.
So, I resumed googling, and messing around, and still, no luck. Tonight, I decided to google my specific motherboard. This led me to the ALSA bug tracker, where I put in a broader search query for all bugs related to the via82xx driver where there was no sound. With a little luck, I came across a post that said something about having disabled the rear outputs in favor of the front outputs on their multimedia-oriented case.
This rang a bell.
I dug out my motherboard's manual, and, sure enough, connecting the front in/outs on a case to the appropriate header on the motherboard will disable the rear outputs. Of course, I'd never done this, as I hadn't cared about the front audio jacks. But I thought I'd look anyway. Apparently, two pairs of pins on the header need to be shorted if you don't intend to use the front outputs. Otherwise the rear outputs still get disabled. You'd think that DFI would ship the motherboard with these pins already shorted, since you'd want to get some sound out of the box if you don't go and connect anything to the front outputs. But no, I see the header, plainly sitting there with its pins un-shorted. So, I dig out some jumpers, short the pins, boot the box, load the driver, unmute the mixer channels, and... voila... I have sound.
I can't believe the amount of time I wasted on this, and it turned out to be a hardware problem in the end! I was so afraid that it was a Linux software issue, and it was actually hardware. Sigh.
Time to go order that S/PDIF bracket...
Patented Farts
Those guys over at United Aircraft really take their flatulence seriously.
Stupid Words
I'm very curious as to where the words "orientate" and its opposite, "disorientate," came from. They sound incredibly stupid. What was wrong with "orient" and "disorient?" Fewer letters, and you don't sound like a retard when you say them. Dictionary.com even says that the longer versions just mean "to orient" and "to disorient." Everybody wins when you use the shorter form. Using the longer form means you like to kill puppies.