Xfce 4.4 release candidate 1
Another step forward to 4.4.0. Get it while it’s hot!
Another step forward to 4.4.0. Get it while it’s hot!
I just released Thunar-0.4.0rc1 and libexo-0.3.1.10rc1 as part of Xfce 4.4RC1. The separate tarballs are provided for users of Xfce 4.2.x that don’t want to upgrade yet, and users of other desktop environments. As suggested by the name it is not yet a final release, but is considered to be somewhat stable.
You will need atleast libxfce4util 4.2.2, GTK+ 2.6.4, shared-mime-info 0.15 and desktop-file-utils 0.10 to build and run Thunar. In addition Gamin or FAM are highly recommended to enable file system monitoring in Thunar. For HAL support on Linux, the libhal-storage-devel package is required (0.5.0 or above). Furthermore if you want to use the trash panel applet, you will need the Xfce Panel 4.4BETA1 or above and D-Bus 0.34 or above. The README
file contains a complete list of dependencies and optional packages.
The official announcement is available at: http://thunar.xfce.org/news.html#2006-09-03
Additional (updated) screenshots are available at: http://thunar.xfce.org/screenshots.html
The source tarballs and the graphical installer can be downloaded from: http://thunar.xfce.org/download.html#0.4.0
Installation instructions and documentation are available at: http://thunar.xfce.org/pwiki/
Please report bugs to the Xfce Bug Tracker (product Thunar) at: http://bugzilla.xfce.org/
About a month ago Thunar 0.3.2beta2 was released as part of Xfce. Much has happened since that time, and we’re nearly ready for the first release candidate of Xfce 4.4.0 now, which should be available in two or three weeks. So, it’s time to sit down and check what we have in the pipe for Thunar 0.4.0rc1.
Below is the list of features - focussing on the three most visible changes (to users) - that are already available in the development version and will definitely be part of the first release candidate. This list will hopefully be extended with some additional features if time permits, but most probably not in time for 0.4.0rc1. The most interesting pending feature here is network support for Thunar, which will include atleast browsing Samba shares and connecting Samba shares (and probably other network file services as well) via smbfs or FUSE.
Probably the most notable change when starting Thunar after upgrading will be the addition (or better re-addition) of the trash support, which implements the Desktop Trash Can Specification (but is currently limited to the home trash).
So when you delete files now, they will not be lost forever, but instead will be moved to your trash can, and can be recovered easily by right-clicking on the file or folder and selecting Restore from the context menu. If the location from where the file or folder was moved to the trash is no longer present you’ll be ask whether to recreate the required folders in order to be able to restore the trashed resource.
If you want to permanently delete a file, you can either move it to the trash and then delete the file in the trash, or hold down the Shift key while pressing Del or selecting Delete from the menu. You’ll still need to confirm the permanent removal of files, so you don’t accidently remove an important file without any notice.
You can also move files or folders to the trash by dropping them onto the trash can in the
shortcuts or tree pane, or by dropping them onto the trash panel applet, shown in the screenshot
above. The panel applet displays the current status of the trash can and allows you to empty the
trash can from the context menu. You will need to build Thunar with D-Bus support in order to be able to use
the panel applet, because the applet does not monitor and manage the trash itself (to avoid any
additional overhead), but instead uses the new org.xfce.Trash
interface to talk to
Thunar and lets Thunar do all the hard work.
It is expected that xfdesktop
will also get a trash can for 4.4.0rc1, using the
org.xfce.Trash
interface as well. But that is still work in progress.
With the addition of rubberband selection to GtkTreeView
in GTK+ 2.10 it is finally
possible to use rubberband selection in Thunar’s detailed view.
Unfortunately that didn’t work as smooth as it should, so there was some additional work put
into ExoTreeView
to be able to really use the rubberband selection with GTKs own
Drag’n’Drop mechanism! With the work-arounds in place you can now start a rubberband selection
in the detailed list view by pressing the left mouse button on a not selected row (it still not
possible to start the rubberband selection in an empty area of the detailed list view and there’s
unfortunately no way to work-around this GtkTreeView
bug, but hopefully this will
be fixed in one of the next GTK+ releases).
With exo 0.3.1.10rc1 it will be even easier to create launchers for applications on your system, that are registered via the freedesktop.org menu system. No need to look up the name of the binary for the application and search through large icon directories to locate the appropriate icon for the application anymore. Just start typing the name of the application or the applications purpose in the Name box and a list of possible applications with that name or purpose will appear.
Select the application you are looking for from the list of matching applications and all the required values are filled with the applications settings.
Of course this release will also include a bunch of bugfixes and improvements. For example when selecting an image file in Thunar, the statustext will also include the dimensions of that image, so you don’t need to fire up the properties dialog to find out the width and height of the image.
The dependency of the thunar-vfs
library on GConf is gone and startup time was
thereby improved (actually not the startup that much, but the time when the first thumbnail is
loaded). The GNOME thumbnail generators (i.e. Evince for PDF, Totem for video, etc.) are now
collected by an external utility and stored into an mmap()
able cache file.
File dates - the time of the last access and modification - are now displayed in a more human readable format. The overall memory usage was again decreased by using the new slice allocator in GLib 2.10 and above where appropriate.
Thunar - and other Xfce components as well - is still looking for contributions, may it be knowledge, time or money. If you feel like donating any of this to Thunar, visit the Contribute to Thunar page and be sure to subscribe to the thunar-dev mailinglist.
Please send your feedback to the thunar-dev mailinglist.
So, the trash framework finally made its way into Xfce SVN. Still a bit rough around the edges, but that’s mostly cosmetic fixes.
In other news, I wasted four hours hunting down a bug/incompatible change in GTK+ 2.10, where the GtkTreeModelFilter doesn’t behave properly anymore, which means that people using Thunar with GTK+ 2.10 and the tree pane will most probably not be able to run Thunar. The suggested solution for now is to switch to the shortcuts pane instead (or downgrade to GTK+ 2.8).
According to the responsible GTK+ maintainer that was an intentional break in the expected behavior of a GtkTreeModel
. Of course, in a perfect world, toolkit maintainers would let application developers know of such breakage instead of waiting for other applications to crash… Thunar is now switched to the new behavior and will therefore work with GTK+ 2.10 again. Now we’ll wait for the next crash. Maybe its worth the time porting Xfce to Qt; not that Qt is perfect, but atleast (if you have commercial support) you get useful comments about breakage in Qt that may cause trouble in applications.
Because this feature was requested quite often, and it somewhat makes sense for a file manager, I’ll add trash support (based on the trash specification) for the next release (most probably RC1).
Trash support will be transparently available to all applications using thunar-vfs (no API/ABI breakage, just a few special methods added), and it should be easy to develop a panel plugin that displays the trash can or add a trash can to xfdesktop.
Unfortunately the problem of interoperability of trash:
-URIs remains, but that should be a minor problem as long as people don’t try to use the trash as primary storage for their documents.