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.