This means that desktop users will be able to access their networked files and folders via a couple of clicks.   Users of previous versions of Thunar who wanted to access network folders would have to hack around with FUSE file systems, or use a separate application altogether.  Configuring a special file system, or having to open a different file manager application to get files and folders on a network do not represent user-friendly approaches to networked computing.  Thus, providing network-share support from within the file manager represents a major improvement to the Xfce user experience.

Admittedly, for long-time GNOME and KDE users (or even for Windows or Mac users), adding network-share support to the file manager may not seem like a big deal. The respective GNOME and KDE file managers, Nautilus and Konqueror (or Dolphin), have provided network-share support for some time.  However, Xfce is a much smaller project than GNOME or KDE, so I’m sure that people can appreciate the effort of a small group of developers working to add important end-user functionality such as this.

For long-time Xfce users who don’t want or need the new network share support, and would prefer that things stay as simple and lightweight as possible, there is good news for you, too.  Jannis will be issuing a maintenance release of Thunar that includes several of the improvements from the 1.1.0 release, but uses the previous back-end of Thunar, called Thunar-VFS.  Thunar-VFS does not support native access to network shares.  Thus, individuals who package Thunar for their Linux/BSD distributions will be able to choose whether or not they want to incorporate the new network-share features into their packaged version of Thunar.

While the network-share support is the most prominent improvement that comes with this release of Thunar, several other improvements are also included.  Have a look at the release notes (best viewed in Firefox) if you want the full-scoop on the improvements and new features that come with this new release of Thunar.

[edit] as John Carr indicated in the comments, the GIO/GVfs back-end is the result of the hard work of GNOME developers, so credit is due to them, as well.  Also, the performance of the GIO/GVfs back-end has not been tested in comparisons against the Thunar-VFS back-end.  Thank you for the comment, John.

Before I do that, though, let me pause to reflect on the fact that I haven’t updated this blog since the month of May.  In the words of a wise master, “Sorry, I’ve been trying to think of stuff to put here.”

Back to considering documentation, though.  Per my post to the Xfce developer mailing list, I have proposed that any newly-written Xfce end-user documentation be licensed under the Creative Commons CC-by-SA 3.0 Unported license.  This would be a change from the documentation’s current license of GPL v2.

My post to the mailing list covers several of the advantages of using a CC-by-SA 3.0 license for end-user documentation, but I’m hoping to get some additional input on items that we may want to consider as part of making such a switch.  For example:

• Although the CC-by-SA 3.0 license would apply to new content, what qualifies as “new content,” when some of our content may include instructing users where to click to perform certain actions?  Certainly, a good portion of this language may remain the same in such cases.
• Is it possible to license code snippets under the GPL, while the rest of the documentation is licensed as CC-by-SA 3.0?  If the answer to that question is, “Yes,” would a GPL-specific notice need to be provided alongside the code sample, or could the GPL notice be provided in a less visually-obtrusive spot within the documentation?  (As a note, I don’t forsee a great deal of code samples within the end-user system documentation, but I want to make sure we have our bases covered in this regard.)
• What else might the group need to consider as part of making such a switch?

Thus far, the reception to using CC-by-SA 3.0 has been good amongst the developers, and several of them have already indicated a willingness to relicense their GPL v2 documents as CC-by-SA 3.0.  That, combined with the fact that I think contacting any existing Xfce documentation contributors would be much easier than in larger projects, leads me to think that re-licensing existing content isn’t out of the picture, either.

I know that a number of other projects have recently made a switch to CC-by-SA 3.0, though, so I am hopeful that I’ll be able to get some good input from others, and we can get this settled in short order.  Thanks very much!

I’ve also been working on the documentation for Xubuntu 9.04, which has been rebased off of the Ubuntu 9.04 documentation for this release.  What this means is that I’ve been able to use bzr to merge in changes from the Ubuntu documentation as they happen, applying them directly to the current branch of Xubuntu documentation.  This is different from prior Xubuntu documentation efforts that had been based off of a much earlier set of Ubuntu docs.

In that sense, I was starting at a bit of a disadvantage – each release brings changes and updates, not only to X/K/Ubuntu itself, but also the associated documentation.  However, by using the current branch of Ubuntu docs as a starting point for this release, and merging in updates as they get applied to Ubuntu documentation, I’ve been able to leverage the ongoing contributions of the Ubuntu documentors and keep the Xubuntu docs more up-to-date.

Using this approach took a little bit of experimenting to find a good workflow for myself, but Bzr has proved to be a more-than-adequate tool for this particular scenario.  For example, the bzr command that I’ve used most frequently as of late involves merging in the specific changes from one Ubuntu documentation revision to another into the Xubuntu documentation branch.  To do that, I’ve just reviewed recent changes to Ubuntu documentation, navigated to my local folder of the Xubuntu documentation branch, and issued a command similar to this one:

bzr merge -r211..212 lp:ubuntu-doc

Here I’m telling bzr to merge in only the differences between revisions number 211 and 212 from the Ubuntu Documentation branch.  Merging in changes between specific revision numbers allows me to cherrypick – I can merge the changes that I want, and skip the changes that I don’t want.  This is helpful because Xubuntu docs will not include the Ubuntu Server Guide (my apologies to Adam Sommer, who has done a ton of great work on the Ubuntu Server Guide for this release), so I have skipped revisions that include updates to the Server Guide.  : /

If there are no conflicts between the merged files, bzr just identifies the changes as modified files – no problems.  Files that contain conflicts are identified by bzr, too, and it is up to me to resolve those conflicts.  Once fixed, I can then use bzr to mark the conflicts as resolved.  The process still requires some manual review on my part, but reviewing someone else’s changes is much easier than writing my own stuff, and gives me more time to focus on documenting the elements that are specific to Xubuntu.

I’m still writing additional documentation that is specific to Xubuntu, but have a little bit of time remaining before string freeze.  : )  At the end of next week, I am going to be travelling to Seattle to visit a friend and her husband, and also attend a documentation conference out there.  I’m going to focus on the Design Strategies, Content Development, and Open Standards tracks.  It should be a great time, and should make for a great learning experience, too.

from          Stephan Arts <stephan@xfce.org>
date    Thu, Feb 26, 2009 at 6:30 PM
subject    Xfce 4.6.0 Released!!!

After more than two years of development, Xfce 4.6.0 has just been released.

Xfce 4.6 features a new configuration backend, a new settings manager,
a brand new session manager and sound mixer as well as several huge
improvements of its core components. A list of all the changes since
the last release candidate can be found on this page.

A visual overview of Xfce 4.6 is available here:
http://www.xfce.org/about/tour

Download Xfce 4.6 from the Downloads section of the Xfce website:
http://www.xfce.org/download

Regards,
The Xfce development team.

All interested parties should take a quick peek at the desktop tour that is linked-to above, but Xubuntu users won’t need to download anything from the Xfce website – Xfce 4.6 will be included by default in Xubuntu 9.04. 

CONGRATULATIONS to the entire Xfce development team!

To enable backports, go to your menu and select Applications > System > Software Sources.  You will be prompted to enter your password, and once the application is fully launched, click on the Updates tab, and place a check in the “Unsupported Updates (intrepid-backports)” box.  Once you’ve marked that box, click on the close icon.  You will be prompted to refresh your software sources, and new updates should then appear.  The upgrade to Xfce 4.4.3 should be included in that set of updates.

Of course, you could update your sources via the command line, too.  I need to run to the airport now, so I’ll leave well enough alone and assume that, if you’re interested in updating your sources list using the command line, you would know how to do so. 

Interested parties can view the Xfce 4.4.3 changelog here.