I Love perl
Sleeping is lame! Instead, I added perl bindings for libxfce4panel to xfce4-perl. This means people can write plugins for the Xfce panel in perl. Yeah, I think it's pretty awesome too.
This is really my one accomplishment for the weekend, aside from getting an oil change for my car and buying groceries.
My Poor Overheating Computer
Ever since I added a fifth hard drive to my computer, along with a higher-end video card (some of those higher-end features of which I'm now actually using), my machine has been overheating a bit, to the point that it sometimes locks up while performing long compiles. Not fun.
I've had my current computer case (affectionately named UPOS, aka Ugly Piece Of Shit) for over six years now. Despite having been around computers for a long time before that, it was the first computer that I built, as all the ones I had played with previously had been machines my dad had brought home from work. Anyway, my dad and I didn't really know as much as we should have about building a computer, and our extensive research left out a rather important piece of the pie: the case. And so, we went for something relatively cheap, which, as it turns out, had terrible cooling and noise characteristics. To install a usable fan in the front of the case, we ended up cutting holes in the sheet metal and plastic bezel. Originally, I also "modded" the 5.25" drive bay bezel to hold a smaller fan in the drive bay. Eventually, after I added a second CD-RW drive, I had to remove the extra fan. At that point in time, I still only had one or two hard drives, so it wasn't a terribly big deal.
Now, I have five hard drives and a single DVD-RW drive, taking up all of the bays. The interior is rather cramped, and all but one of the PCI slots are filled. The power supply is also a larger model than the one in it before.
So, I bit the bullet today (it was tasty) and ordered a new Antec P180 case. It's pretty awesome. It has more drive bays than I currently need, and is constructed in such a way to deal with common thermal problems, and also to reduce noise levels. While I've gotten used to my relatively-noisy PC in my bedroom over the past 6 years, it'll be nice to reduce that a bit. I'm not totally thrilled with the front-panel cover, as I always feel like they're unnecessary and just get in the way, but I guess I really don't use the DVD drive often enough for it to be annoying. Since it's pretty heavy, I opted for the longest, cheapest shipping method, so unfortunately it probably won't be here for about a week and a half, but fortunately it'll be here before I leave for Maryland.
It belatedly occurs to me that I could have asked for this as a Christmas present and saved myself $150. Oh well.
NVidia drivers updated
NVidia has finally released a 8xxx version of its driver for Linux.
The 7xxx had a serious problem with accelerated render, and was causing random freeze with Xfce WM embedded compositor. The 8xxx version seems to be a lot better in this regard.
So if you use xfwm4’s compositor with NVidia, make sure you get the latest driver from here: http://www.nvidia.com/object/unix.html
Fun With Jogging
Fun things that happened during my jog tonight:
I forgot about left-turning cars and the green left arrow, and almost got run over. It's amazing how fast you can run when there are cars coming straight at you and they don't look like they're slowing down.
I saw a tall Asian dude walking down the sidewalk smoking a joint. Weird.
Rain
It's rainy and windy today, and not at all sunny. I know I joke a lot, but I really do miss the rain. It actually is pretty boring to have sunny, warm days all the time. Not that I want to move back to Ithaca or anything, but it would be nice to have some rainy days distributed evenly throughout the year out here in CA, rather than getting 2-3 months of almost nonstop rain. Ah well. Nobody's perfect, even mother nature.
DRM for Cars
Seriously, no joke, this system is as bad as DRM.
The trouble with DRM is that it essentially treats content owners as criminals, restricting their use of property they own, even when that use is legal.
I don’t know how it works outside of the USA, but you own that car, payments or not. A contractual defaulting of that property to someone else in the case of failure to meet payment does not make it any less your car.
Presume this: you buy a house with a loan from the bank, using the house you are purchasing as the collateral – a mortgage. What if the bank made it so that the key to your house doesn’t work? It’s not their house! Yes they loaned you the money, and yes it is within their legal right to create a contract that makes your life a living hell (by not letting you into your own freakin’ home) if you don’t pay. But it ain’t ethical.
Eight is Special
Update: A quick grep through the gaim sources for the current CVS head shows that gaim_add_eight() isn't actually used anywhere in the code (anymore, at least). Ah well.
Xfmedia Refactoring
I've finally started my huge Xfmedia refactoring project. The idea is to make it a lot more maintainable and modularised. I've been doing this in tiny pieces for many months now (XfmediaPlaylist, XfmediaVideoWindow), but I can't really go any further without ripping huge pieces of the codebase apart and stitching them back together the way I want everything to be. I realise it's been a couple months since I released 0.9.1, but it'll likely be a couple more months (at best) before 0.10.0. I think 0.9.1 is fairly stable and featureful. Unfortunately, 0.10.0 probably won't have many user-visible changes, but I expect the plugin interface will finally be stable, or at least in a state where I can promise backward-compatibility for future releases.
Anyway, here's an initial sketch of how my current thinking looks with regard to object structure:
XfmediaApplication: This is more of a meta-object, but it'll keep track of "global" data and handle starting up the app, as well as tearing it down. I haven't decided yet, but it eventually may make sense to allow XfmediaApplication to instantiate multiple xfmedia main windows in the same process, so you can have multiple copies of xfmedia running in the same process space. I'm not really sure what this means for plugin interaction yet, so this may never become a reality. I doubt 0.10.0 will have this ability, but maybe in a future version.
I'm a bit less certain about how the next two objects fit.
XfmediaPlayer will be a very thin layer on top of XfmediaXine. It will know how to play streams and handle usual playback operations, as well as interact with the GUI.
XfmediaMainWindow is a GtkWindow representing the controls/playlist window. It'll act as a container for the XfmediaPlaylist, and hold the time label, song/status label, and control buttons and slider.
I'm not sure if XfmediaPlayer should be the container for XfmediaMainWindow, or the reverse. On one hand, it makes sense for the window to contain the player, but I think I'd rather have the player as the super-object, which will hold the main window, and know that it should do some UI-related things when playback events occur. E.g., if a stream is started from the stop state, the play button in the UI should change to a pause button. There doesn't seem to be a great way to handle this case with the reverse relationship.
So I guess the object relationships should go like this:
XfmediaApplication
XfmediaPlayer
XfmediaXine XfmediaMainWindow
- XfmediaInfobar
- XfmediaPlaylist
- XfmediaPlaylistQueue
XfmediaVideoWindow
XfmediaTrayIcon (?)
There will be only one XfmediaApplication per process, and this can be considered as a pseudo-global. The various XfmediaPlugin objects (one per plugin) will live as sort of a peer to XfmediaPlayer, and can (obviously) control playback, and probably modify or interact with some parts of the UI. I'll have to be careful to compartmentalise this properly, as I'm sure there are parts of the UI plugins shouldn't be allowed to touch. Fortunately, the XfmediaPlugin object shouldn't have to change, aside from adding new object signals.
There are a few other things that are just floating around.
There's the settings system, which isn't an object at all: just a set of global functions that act on a global settings store. That's definitely a problem if I want multiple xfmedia instances in a single process, since, e.g., you might not want a systray icon for each instance, or you might not want each instance to be sticky on all workspaces. This is going to be a bit of a pain, because all the xfmedia_settings_get_*() calls have only one argument for convenience. Also, when xfmedia exits, which instance gets to write out the settings file? Only the first one? This sounds a bit messy. But supporting multiple settings files for each instance is pretty messy too.
The remote control interface isn't an object either, but it's probably ok (almost) as-is, since it knows how to operate on a specific "session" of xfmedia.
Next we have the keybindings system, which probably needs to be mostly redone. Fortunately it currently acts on a specific XfmediaMainwin instance (which will become XfmediaMainWindow), so it should be relatively easy to modify it to operate on an XfmediaPlayer, and thus be multi-instance-safe. However, all the keybindings are stored in the same file, so I'm not sure it's useful to have separate keybindings for each instance. Also, I'd rather use a standard GTK mechanism for doing keybindings, so I'll probably rethink this at some point (GtkAction?).
The mediamarks editor and menu are keyed to a particular mainwin instance, but, again, I'm not sure it makes sense to make this per-instance. There's only one mediamarks file, supporting more than one in a "smart" manner is pretty difficult, and if you look at them like bookmarks, a web browser doesn't have different bookmarks per window.
The tray icon is something I'm not sure about yet. Having multiple tray icons for each instance sounds a bit silly. I'm thinking about the possibility of a single tray icon being able to control all the instances of xfmedia in the same process. The problem with this approach kinda defeats the purpose of the tray icon: to offer a few simple features of xfmedia just a couple quick mouse clicks away. Increasing the complexity of the tray icon directly contradicts this. At some point I might move the tray icon into a plugin.
Next there's playlist-files.h, which is mainly a set of utility functions for reading and saving various playlist types. It mostly operates on a XfmediaPlaylist instance right now, which I think is fine. The playlist files don't need to know about the player engine at all; they just need to know the contents of the playlist (or just how to load stuff into it).
The "jump to file" box is a bit awkward right now. Originally it was a separate window, but now it's integrated into the XfmediaPlaylist widget. So it's in a separate file, somewhat kludged into playlist.c. This needs to be integrated properly (though it really does work fine as-is) for maintenance's sake.
The last piece is the equaliser window, which I never finished because xine handles EQ in a rather weird way, and I never figured it out well enough to make it work right. I might come back to this at some point, in which case it'll just be a child of XfmediaPlayer, and nobody else needs to know a thing about it, except perhaps how to show and hide it.
A final question is what to do about XfmediaXine: should plugins be able to interact with it directly. I'm thinking no. This allows me to support other playback engines in the future (which probably won't happen, but it's not wise to close the door on the possibility), and helps make sure I've abstracted player details into XfmediaPlayer properly.
So I guess that's about it. Comments? Questions? Not saying I'll listen, but I'm curious to know what people think...
Television
I just watched 5 solid hours of television.
I haven’t watched “real” television since May 7th 1989.
Status
I just quit my job. Whether or not I’ll wind up with a new job in the technology sector remains up in the air. I would prefer not, but it just pays better than any other job you can get with a high school diploma.
That said, I’m hoping to free up some energy for programming efforts I actually like. The problem with working a job in a field that you consider your hobby, is it saps your energy to pursue your real life, and to pursue your hobby as a hobby. Perhaps now Mousepad will get back into shape.
I have a roadmap of sorts for Mousepad. My goal is to get the Mousepad rewrite up to the functionality of the last release. The only real difference should be that Mousepad will be more maintainable than the old Leafpad mess, and potentially faster. This should only take a day or three, should I find the time. This will become the 0.3.0 release. The 0.3.0 “series” (har har) will be the last of “classic” Mousepad.
The goal for the 0.3.0 series is to have a text editor that opens fast, provides no real frills, and has no dependencies outside of those provided by or required for the current stable version of Xfce.
0.3.1 – recent file support. I have a half finished little lib that handles the spec, which I will likely polish off.
0.3.2 – session support. If 4.4 is out, we can just depend on libexo outright, if not, we’ll probably want have a little “miniexo” inside the Mousepad tree.
At this point, I’d like to begin taking Mousepad in a somewhat more feature heavy direction. That may upset some people, who are just looking for a Notepad clone. These people may fork with my blessing. They can move to requiring libexo for session support, using the recent file support that will appear in Gtk+ 2.10, and maybe even using D-bus to keep all Mousepad windows shoehorned in the same process. Up to them. I need a little more from my text editor than that.
The new goal of Mousepad is to be a fast and slim general purpose text editor, much in the vein of BBedit (the classic Macintosh editor) and Nedit (the greatest editor ever that doesn’t use Gtk). Tentatively this is the direction at that point.
0.4.x – Syntax highlighting (with GtkSourceView, or possibly Scintilla)
0.5.x – Tabs.
0.6.0 – Miscellania – templates, open as copy, revert to saved, yadda yadda. The tiny little time savers release.
0.7.0 – Scripts. Little snippets of code in any language which can either process the whole document, or just a selection.
0.8.0+ – The future! GtkSpell, maybe? Toolbar perhaps? A real plugin system? A function browser?
Syntax highlighting and tabs are no brainers as features, and will likely be simple to implement. After that, I’ll need a little input from users, so all of this is subject to change.
A real concern I have is that by adding features I lose what makes Mousepad appealing now (speed, simplicity) while not bringing enough to the table to be useful relative to older text editors (Vi, Emacs, Nedit, or my console editor of choice, Joe), thus bringing the Gedit hell to Xfce. I think I can walk that line. We’ll just have to wait and see.