xfce eyecandy
All right, I finally did it. I went for the eyecandy. I've never set up any thing having to do with composite, transparency, etc., but I figured that since as long as I'm living on the p.masked Xfce edge anyway, I might as well use its built-in compositor. And...it's interesting. I don't particularly like how the panel automatically gets translucent whenever the mouse isn't on it, and it's actually distracting when I have a terminal superimposed on both Firefox and another terminal...I was surprised that the backgrounded Firefox itself becomes clear enough to see the other terminal underneath it.
And yet people dig this stuff? Or maybe they just dig the effects of more nifty compositing window managers like compiz. Anyway, I don't know if I'll stick with it or not. I'm pleased to say that after a little tweaking, it's a minimal resource hit even for my ancient integrated nVidia GeForce2 Go chip. (One of the very first dedicated mobile GPUs, a whole 16MB memory.)
Interestingly, I seem to be running only semi-hardware-accelerated, as I call it. running "glxinfo" gives a segfault, as it can't find the GLX extension to load, despite the visual results. Problem is, I can't enable "AllowGLXWithComposite", as that results in random hard lockups, which is the fault of being forced to use nvidia-legacy-drivers. These older 7xxx drivers are known to have such bugs, but the newer 8xxx drivers don't support my vintage 2001 hardware. Ah, well. At least adding "RenderAccel" to xorg.conf lets me run this stuff with very little noticeable slowdown. I suspect that I am getting hardware accel; it's just confused.
I think I'll bring along this composited laptop to SCALE and show off the wonders of unstable Xfce and the latest eyecandy. Which reminds me, now I need to see about getting all the effects of compiz, but without using that WM or unmerging yet more masked packages. I want to see what else this old graphics hardware is capable of. 
moved on
...to Xfce4 4.4, that is. I've finally heeded the urgings of my fellow Xfce enthusiasts dostrow, nichoj, et al, and moved my laptop over to the latest Xfce 4.4 prerelease. Sometimes as a developer, you have to live somewhat on the bleeding edge, in this case, a couple of dozen entries in package.unmask. Yow! Hot stuff. The new Xfce has changed considerably since 4.2. It more resembles a traditional desktop environment, but it still retains the speed and ease of use that it had from the older days. That said, some configuration changes have been made. Configuring the panel is a little less intuitive; the same control works for both the icon strip at the bottom and the window list at the top. (So don't just kill the panel process entirely!) No more xftaskbar4 to kill. 
There are still a few outstanding bugs, such as missing icons from things like the main configuration window, missing panel plugin icons (none for cpu-freq), and missing icons for mail and webbrowser in the terminal Applications menu. Also missing is the old ability to change the icon spacing in thunar. Though a host of other features have been added, folder views take up way too much space. Need the icons to be spaced about half as far apart as they currently are.
Also, the new battery applet is not nearly as helpful as the old one. For example, even though lm_sensors doesn't work on this laptop whatsoever, the basic thermal zone info from ACPI was parsed by the battstatus applet (don't ask me why, I'm just glad it did). It displayed temperature, battery charge, and an indicator whenever the fan turned on. Handy, right? Well, the fan indicator is still there, but there's no provision for temperature display anymore. WEAK. Grr. I'd downgrade, but the stable version blocks the masked version. Anyone know a fix-it for this?
Speaking of WEAK, my back has taken a sudden turn for the worse over the last couple of days. Earlier this week (i.e. before I started my new schedule on Wednesday), I was almost back to normal. I could walk without limping, at least most of the day. And now...now I'm not doing so hot. Some excrutiating twinges, and constant pain every step. It's a little better than it was yesterday, but I for sure need to get to the doctor's office and get that x-ray done. The doc said it'd take a minimum of six weeks to heal, and at the end of that time, I can say that I'm definitely not recovered. %$^&# sciatica. And at my age, too. I'd hoped to be well by my wife's birthday and Christmas, but doesn't look like that will happen.
Maybe I'll be fully healed in time for SCALE in February?
wiping out, moving on
There were some good comments on my last journal entry, thanks to everyone who responded. I'm happy to say that some of the problems have been dealt with. I've been talking to several developers who are rather likeminded; just check Planet's entries for the last week or so.
Anyway, I've decided to give my trusty ol' lappy das boot, by which I mean "the boot" rather than "the boat." 
It's had Gentoo (Jackass! 2005.1, yay for my old project) installed on it since August 31, 2005. And what with one thing or another, it's just been slowing down. It's got a strange partition layout on it, too. A whole unused 10GB ntfs partition (never got around to installing Windows), a smaller Linux test partition, and the main desktop stuff. Rather inefficient usage of the 60GB disk, considering its recent use. The slowness, combined with space issues, and the fact that I haven't updated it since before gcc-4.1.1 went stable on x86 means that I've decided to just reinstall. Why spend a week compiling when everything will likely break if I try to simultaneously migrate to modular Xorg and switch from gcc-3.4, as well as all the crazy kernel/udev/nvidia/madwifi updates?
Time to wipe the disk and move on to something more recent. I've spent today moving /home to my new USB key and dumping it to my AMD64 box. It really highlights the slow-as-molasses USB1.1 on the laptop, as well as the crappy I/0 and slow system bus. I'll be doing some smarter performance tuning this time around, as well as installing only Xfce. I've been running mostly in Gnome because of some weird Xfce/Fluxbox issues, but with only 128MB memory, any and all workloads are just about unbearable.
Of course, the simpler solution would have been to just plug the laptop drive straight into the IDE cables on the AMD64 box for the updates, but unfortunately, the drive uses some weird laptop-only ATA/power combo connector, not the standard IDE connector. Oh well. I don't mind trying out the Installer LiveCD, especially since I'll have nothing to lose.
Guess I have to go re-read all the changes I've been making to the installation handbooks.
Following Directions
Sigh. I know people don’t read directions. I know that, when you want to get someone to read something, brevity is better: the less there is to read, the more likely the recipient is to read it.
But when the first line of a Bugzilla mail says “Do not reply to this email. To comment on this bug, please visit: (URL)”, you’d think that people would, you know, just click on the damned link. How is it easier to hit reply, delete “bugzilla-daemon@xfce.org” from the “to” line, and paste my email address in there?
(Ok, spambots, have at the bugzilla-daemon address. It goes directly to /dev/null anyway.)
So now, Xfce Bugzilla emails start with this: “DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person whose email is mentioned below. To comment on this bug, please visit: (URL).”
Hopefully that’s clear enough, and not too long for the ridiculously lazy among us to read.
Auto update the background list for Xfdestkop
I have written a quick script to update the list of the images for the background in Xfdesktop.
#!/bin/sh
# Update the background.list so the new downloaded wallpapers are available
# to show up in Xfdesktop.
LIST=$HOME/.config/xfce4/desktop/background.list
echo "# xfce backdrop list" > $LIST
find $HOME/images/background/ -type f >> $LIST
Note: change in the last line the folder to the backgrounds.
This script can be either putted in an .zshrc file. Or better, if you use Xfce, save the script, under the name update-desktop-list.sh for example, to your personal bin folder (in my case $HOME/.local/bin) which is correctly set in the PATH, and run xfce4-autostart-editor. You can add the command update-desktop-list.sh.
Finally you have to set up Xfdesktop to use the list (located at $LIST) of backgrounds. Go to Settings > Desktop manager, and select the list as the file. If it doesn't exist run the script a first time.
Real-transparent Terminal (yet again)
I have looked around the patch for gnome-terminal from Kristian Høgsberg and also the one for Terminal from Benny, and I managed to do the same for Terminal again since the vte libs have been modified, and support for real-transparency has been added. It was really simple, just init the rgba colormap, and call vte_terminal_set_opacity :) It requires version 0.13.3 or higher of vte.Now someone could come with a good solution to integrate this nicely in Terminal. I think about a hidden option in ~/.config/Terminal/terminalrc, or even a slider.
Here is a first patch. It sets a hard-coded color for the alpha channel (0xDDDD).
Edit: And here comes a second patch which adds a hidden option for the opacity (ColorOpacity). It has to be in decimal, where 0xCCCC is 52428. Don't apply it over the first patch.
Edit 2: Benny commited changes to the trunk with support for real transparency, and a check for the version of libvte.
Xfce 4.4rc2 Released
This weekend, we just released the second release candidate in preparation for Xfce 4.4.0. Check out the list of changes from rc1, or go ahead and get to the downloads.
I’m really happy with this release (where xfdesktop is concerned, at least). I closed something like 26 bugs, and I’m much more comfortable with xfdesktop’s stability level. There are still some features that I wanted to get in for 4.4 that aren’t going to make it, but I think the desktop manager is pretty usable and stable, and works well at this point. Give it a try.
Oh, and if you’re bothered by the fact that icons that ‘fall off’ the screen (due to the icon size being too large) never reappear when you lower the icon size, grab the patch from this bug and apply it to rc2.
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.
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.