Oh, Wikipedia
Apparently, xfmedia has a (tiny) Wikipedia entry. I find that... somewhat silly (if ego-boosting, in a way). Though I did learn something: apparently I haven't made a release in over a year. I suck.
Oh, Wikipedia
Apparently, xfmedia has a (tiny) Wikipedia entry. I find that… somewhat silly (if ego-boosting, in a way). Though I did learn something: apparently I haven’t made a release in over a year. I suck.
Xfce Update
I haven't really written about Xfce lately, I suppose. I've been hacking my ass off the past couple weeks, which has been great. In the past week or so I've closed around 20-23 bugs, and now xfdesktop is down to 9 bugs in bugzilla, a few of which I think might be either fixed or just irrelevant at this point. There's one more that I want to fix, and then I'm ok with releasing our second 4.4.0 release candidate (hopefully this weekend).
This last one is giving me some trouble. Well, fixing the bug probably wouldn't be that hard, but it's the icon view drag-n-drop code, and it's really a mess, a mess I'd like to clean up. Since I split the file icons out into three types (regular, volume, and special), a lot of the original code got copied and pasted, and then modified only slightly for the different icon types. Then the icon view itself handles some of the DnD (the part where you're just moving an icon from one place to another), and the icon view manager orchestrates some of the interaction with the various icons. It's really not terribly well designed, and I want to refactor the hell out of it. I'm having a hard time coming up with a good design, though.
On one hand, I have the simple part of DnD that just deals with rearranging existing icons on the desktop. Both the window icon and file icon modes use this, so it makes sense to have it in the icon view proper rather than duplicated twice in each of the two icon view managers.
However, the file icon manager needs an extra bit: you have to be able to drag one icon and drop it on another (in some cases, anyway; some icons aren't a drop destination). To accomplish this, the file icon manager hints to the icon view that it should allow "overlapping drops" in some situations. Or rather, the icon view allows them in all situations, but then asks the file icon manager if a drop destination is ok. I really dislike special-casing this.
Finally, for the file icon manager, we have a third mode of operation (well, third and fourth, but they're mostly the same idea): dragging icons from the desktop and dropping them in another application (like a file manager), and receiving drops on the desktop from other applications (like a file manager or web browser). The latter bit has two code paths to deal with whether the external drag's destination is on an open part of the desktop, or on an existing icon.
This gets really messy, because each of the three icon types are currently handling external drops on themselves individually. The code is mostly the same, but there are subtle differences in some cases (differences that can probably be factored out, or maybe just ignored entirely with a better design).
My first thought is to leave the 'rearrange DnD' in the icon view where it is now. This is a bit of a no-brainer: the icons themselves and the icon view managers don't deal with this at all right now (and I'd like to keep it that way), and pushing the code into the icon view managers would cause a bit of duplication. So that's fine.
But what about the overlapping drops? I think what I'd like to do is ignore them, at least in the icon view. Or rather, always handle them as if they're possible. So the idea is that when I drop one icon on another icon, the icon view manager gets a synthesised drop event (as well as drag-motion, drag-data-received, etc.) from the local icon; this way it doesn't even have to know it's local, and can treat it just like an external drop (thus using the same code path for something that's in two separate code paths now). For this to work, each icon is going to have to provide a list of source targets it supports, as well as allowed actions. And there needs to be a way for it to say "no, you can't drop me on anything else" (I guess just a NULL return from the supported source targets will do there).
Then, for external drops, I can just handle them much in the same way they're being handled now.
Actually, all this stuff is starting to make some sense. It's a bit late now, but I'll try to work on this tomorrow or Friday.
Xfce Update
I haven’t really written about Xfce lately, I suppose. I’ve been hacking my ass off the past couple weeks, which has been great. In the past week or so I’ve closed around 20-23 bugs, and now xfdesktop is down to 9 bugs in bugzilla, a few of which I think might be either fixed or just irrelevant at this point. There’s one more that I want to fix, and then I’m ok with releasing our second 4.4.0 release candidate (hopefully this weekend).
This last one is giving me some trouble. Well, fixing the bug probably wouldn’t be that hard, but it’s the icon view drag-n-drop code, and it’s really a mess, a mess I’d like to clean up. Since I split the file icons out into three types (regular, volume, and special), a lot of the original code got copied and pasted, and then modified only slightly for the different icon types. Then the icon view itself handles some of the DnD (the part where you’re just moving an icon from one place to another), and the icon view manager orchestrates some of the interaction with the various icons. It’s really not terribly well designed, and I want to refactor the hell out of it. I’m having a hard time coming up with a good design, though.
On one hand, I have the simple part of DnD that just deals with rearranging existing icons on the desktop. Both the window icon and file icon modes use this, so it makes sense to have it in the icon view proper rather than duplicated twice in each of the two icon view managers.
However, the file icon manager needs an extra bit: you have to be able to drag one icon and drop it on another (in some cases, anyway; some icons aren’t a drop destination). To accomplish this, the file icon manager hints to the icon view that it should allow “overlapping drops” in some situations. Or rather, the icon view allows them in all situations, but then asks the file icon manager if a drop destination is ok. I really dislike special-casing this.
Finally, for the file icon manager, we have a third mode of operation (well, third and fourth, but they’re mostly the same idea): dragging icons from the desktop and dropping them in another application (like a file manager), and receiving drops on the desktop from other applications (like a file manager or web browser). The latter bit has two code paths to deal with whether the external drag’s destination is on an open part of the desktop, or on an existing icon.
This gets really messy, because each of the three icon types are currently handling external drops on themselves individually. The code is mostly the same, but there are subtle differences in some cases (differences that can probably be factored out, or maybe just ignored entirely with a better design).
My first thought is to leave the ‘rearrange DnD’ in the icon view where it is now. This is a bit of a no-brainer: the icons themselves and the icon view managers don’t deal with this at all right now (and I’d like to keep it that way), and pushing the code into the icon view managers would cause a bit of duplication. So that’s fine.
But what about the overlapping drops? I think what I’d like to do is ignore them, at least in the icon view. Or rather, always handle them as if they’re possible. So the idea is that when I drop one icon on another icon, the icon view manager gets a synthesised drop event (as well as drag-motion, drag-data-received, etc.) from the local icon; this way it doesn’t even have to know it’s local, and can treat it just like an external drop (thus using the same code path for something that’s in two separate code paths now). For this to work, each icon is going to have to provide a list of source targets it supports, as well as allowed actions. And there needs to be a way for it to say “no, you can’t drop me on anything else” (I guess just a NULL return from the supported source targets will do there).
Then, for external drops, I can just handle them much in the same way they’re being handled now.
Actually, all this stuff is starting to make some sense. It’s a bit late now, but I’ll try to work on this tomorrow or Friday.
Code Search
Google has recently unveiled their code search feature, which lets you search the internet for open source code. I already have more respect for it than for its competitors. When I search "brian tarricone" in Krugle or Koders, I just get mention of my name in a file of Gaim's source, from a (small) patch I submitted to fix a plugin. When I try Codease, I just get a 502 Proxy Error. Great service, guys.
However, with Google's code search, I see my name in a bunch of Xfce- and Xfmedia-related files. Rock on. "Results 1 - 10 of about 12,800," it says. Awesome.
Code Search
Google has recently unveiled their code search feature, which lets you search the internet for open source code. I already have more respect for it than for its competitors. When I search “brian tarricone” in Krugle or Koders, I just get mention of my name in a file of Gaim’s source, from a (small) patch I submitted to fix a plugin. When I try Codease, I just get a 502 Proxy Error. Great service, guys.
However, with Google’s code search, I see my name in a bunch of Xfce- and Xfmedia-related files. Rock on. “Results 1 - 10 of about 12,800,” it says. Awesome.
Low Power NAS-like Device
Hey, lazyweb.
Recently I've been thinking about turning my desktop PC off to save electricity. Lately I haven't even been using it all that much, instead opting to sit in the living room using my Powerbook. However, my desktop PC currently hosts a public SVN, as well as some private web resources that friends use relatively often. I could move the SVN elsewhere (probably mocha.xfce.org), but the private resources are not feasible to move to an external host. I also use the box as a backup mail server, but I haven't needed it in some time (right now it's more of a backup to a backup).
My main issue is storage. I currently have about a TB of storage in my desktop PC, which acts as a media source for my HTPC in the living room. For various reasons (mostly physical space), moving the storage to the HTPC isn't really workable.
So, my next thought would be to build a NAS. In the process, I'd like to upgrade my storage to SATA, and use RAID5. However, this isn't strictly necessary; I'd be OK just moving my current hard drive setup to a new box and putting off the upgrade until later (which is more likely, as I don't really want to spend the money on 4 new 320 or 400GB hard drives right now).
So, here's what I want. A low-power NAS box that can take a minimum of four hard drives. It would be nice if could be expanded later to support eSATA so I could add external boxes if needed. The software running it needs to be completely open source (Linux preferred, though one of the BSDs would do), or easily replaceable with an open source NAS stack. I need to be able to run a web server on it, and it needs to be able to handle RAID5. Gigabit ethernet is a must, even though my home network doesn't support it (yet).
I also wouldn't mind building this. A low-power, heavily integrated motherboard with a low-power CPU and 4-8 SATA ports would be fine. One or two PCI slots would be good. If the motherboard doesn't have IDE channels, I'd need to get an IDE card for it until my storage gets upgraded. Ideally I'd like to be able to hook up a 512MB or 1GB flash card to it to host the OS so I don't have to waste HD space on that stuff.
Oh, and I don't want to spend any more than $350 or so on this (not counting hard drives). That might be tough.
Any thoughts?
Philly Orchestra Rocks
The Philadelphia Orchestra, arguably one of the best orchestras in the world, has a clue. They sell their recording online, and many of them are available for download. No proprietary formats? Check. No DRM? Check. Lossless? Check. They're using FLAC. Rock.
Foxybuntu
Very interesting mockup of a simplified user interface by Nigel Tao: check out the UI mockup.
It may not be directly obvious, but that sure looks like Xfce to me ;-)
Bye-bye, Kitty
This past Wednesday, one of our three cats, Blackie, died. She was a diabetic, and had apparently developed stomach and intestinal cancer recently. She hadn't been eating for a few days, and so couldn't have her insulin shots.
I knew she hadn't been in the best of shape over the past few months, but I was really hoping I'd be able to make it home to see her while she was still alive.
She was always the sweetest little cat. We found her back when we lived in NJ. She belonged to one of our neighbors down the street, but they treated her like crap. She spent all her time outside (and thus was coverd in fleas), wasn't well-fed, and hadn't been spayed. At a very young age she had already had a couple litters of kittens. From that, and beeing fed so poorly, she was a very small cat, and never grew that much. Anyway, she always used to come to our backyard, and we would feed and take care of her. Eventually we decided just to take her in and get her properly cleaned up and checked out. We of course took her with us when we moved to MD.
She was one of the friendliest cats I've known, but not in an annoying way: she would constantly want attention, but most of the time would back off if I was busy or just not in the mood. She just wanted to be loved, but respected my space. When she developed diabetes, we didn't expect her to last all that long, but she did. I don't recall exactly, but she would have been at least 15 or 16 years old this year.
I haven't really seen any of the cats that much since I stopped living at home during (at least) the summers, but she'll definitely be missed.