Below is a list of features I plan to implement for 4.8. I would consider the first three “mandatory,” and the rest are “nice to haves.”

Please note that this is not an all-inclusive list: I will probably implement smaller features as well. Nor does this list have anything to do with bug-fixing.

The “Status” lines are accurate as of 2009/09/18.

Jannis has ported Thunar to use GIO as its VFS backend, replacing and deprecating thunar-vfs. Xfdesktop will need to be ported as well. I do not expect this to be difficult, beyond the initial learning curve associated with the GIO API.

Included in this feature will be better support for some functions that don't currently work properly (or at all) with the current setup, such as multiple file copying using drags.

Status: 0% complete.

The GIO port of Thunar required a bump in the ABI version of the thunarx-1 library. Porting xfdesktop to thunarx-2 should be trivial.

Status: 0% complete.

The current menu implementation, libxfce4menu, suffers from several limitations (which I won't discuss here). A new implementation now exists, called Garcon. Xfdesktop should be ported to use Garcon instead of libxfce4menu.

Status: 0% complete.

The icon view's drawing and repaint routines are poorly designed, fragile, and hard to maintain. There are a few bugs filed relating to flicker and repaint problems that are not solvable with the current architecture.

Status: 95% complete. Merged into master. There are a couple hacks in place in the code to work around drawing errors that should be fixed properly, but the impact on the user should be minimal to nothing.

The original keyboard handling for the icon view is a custom GtkWidget::button-press-event handler in XfdesktopIconView. It is messy and doesn't work properly (the wrong icon is selected sometimes when navigating with the arrow keys). GtkBindingSet should be used instead, and the routines should be rewritten to handle keys properly.

Status: 100% complete. Merged into master.

XfdesktopIconView was originally designed to only allow icons to be placed on a fixed grid. This has obvious usability disadvantages, but, at the time, had significant implementation advantages (complexity and time to completion). The icon view should be refactored to allow free positioning, but still allow the user to “snap” all items to a grid on demand, or even keep the current behavior.

Note that this is a bit of an ambitious project, and may be pushed to 4.10.

Status: 0% complete.

Version 4.6.0 brought many improvements to the usability of the right-click context menu when file icons are enabled. As a side-effect, the old root applications menu gets moved to a submenu when file icons are enabled. While many people were happy (and less confused) due to the usability improvements, a seemingly-equal number of people are unhappy with the apps menu being less accessible.

If possible, it would be nice if the menu construction could be more flexible to allow different behavior. The original 4.4 behavior, which did not show desktop context items at all when right-clicking on an empty area of the desktop, will not be resurrected. However, it would be helpful to be able to swap between which menu (either the desktop context menu or the apps menu) is the “primary” menu, with the other being relegated to a submenu. Whether or not the position of the submenu (top, bottom, or other) within the toplevel menu should be configurable is an open question.

Implementation of this feature should fix the brokenness involved with the context menu when the icon view mode is set to “Minimized Application Icons.” (In actuality, the feature discussed here will be a side-effect of fixing this bug.)

Status: 0% complete.