Real-transparent Terminal (yet again)

• November 11, 2006
• Mike Massonnet

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

• November 6, 2006
• Brian Tarricone

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

• October 30, 2006
• Brian Tarricone

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

• October 19, 2006
• Brian Tarricone

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

• October 5, 2006
• Brian Tarricone

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.

Foxybuntu

• October 3, 2006
• Jasper Huijsmans

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 ;-)

Transparent future

• October 1, 2006
• Jasper Huijsmans

Not being able to set my mind to doing anything useful, I played a little with rgba windows. For a future version of Xfce that can depend on cairo-based versions of Gtk, it should be possible to only make the panel background transparent, while keeping text and icons fully opaque.

Just changing the panel window and the base plugin classes, I got the following result:

Not too bad. All widgets that have their own X window, or that do some custome drawing are not transparent, but the others are. I had to choose a theme with white foreground text to make labels somewhat readable. That will require special attention to get right. Shadows or outlines maybe…

KDE memory usage

• September 13, 2006
• Olivier