Xfce Updates

I see the LXDE project get a good amount of attention lately, in large part (I think) because it uses somewhat less memory than Xfce.  Xfce is still going on strong, though, and plans are in the words for the eventual release of Xfce 4.8.

Jérôme Guelfucci recently provided a brief update on what’s going on with Xfce, and one of the big things is a push for updated documentation.  I’ll be contributing to that, and will likely be borrowing some of the user-help topic “stubs” that have been put-together by the GNOME Documentation team.  I’ll be sure to share any relevant topic stubs with them, too.

Jannis Pohlman has also started the process of forming an Xfce foundation.  Jannis notes that this would make Xfce a legal entity with a board of directors, and that it would help to raise funds through sponsors and other contributors for hackfests and other events.

My Documentation Projects

Lately I have been continuing work on gedit documentation and have also done some initial work on updating the Ubuntu Packaging Guide.  I should have the gedit docs well-drafted within another week or so, but I welcome suggestions and contributions with regards to the Packaging Guide.

Thus far, I’ve drafted the Packaging Guide in Mallard, and although Mallard is XML-based, it is much simpler than DocBook.  It is not difficult to learn, and you can draft-up a nice-looking, topic-focused documentation set with it rather quickly. I also know that there was a UDS session about the Packaging Guide today, so I welcome any feedback that resulted from that session, too.

Other Documentation Projects of Note

In non-Linux-help news, there are a couple of interesting DITA-related projects that I’ve been wanting to mention. If you haven’t heard of it before, DITA* stands for the Darwin Information Typing Architecture, an XML-based syntax originally developed (and later open-sourced) by IBM. The toolkit that processes the syntax, the DITA Open Toolkit, is Java-based, though, which I think has somewhat slowed its adoption in the Linux community. (Currently, only OpenSUSE packages DITA and the DITA Open Toolkit, but their implementation is a bit broken, perhaps due to an outdated version of Saxon in the OpenSUSE repositories.)

When people ask me what the big deal is about DITA**, I like to point them to this white paper (PDF).  It seems to provide a pretty clear picture of what DITA can help you do, even if it does make it look easier to implement than it is in real life.

There are a couple of DITA tools on the horizon that look to make it a bit easier to work with, though.  A group of Drupal developers are working with DITA developers to build a Drupal-based DITA authoring platform.  From what I can tell, it will be released under an open-source license.  They are just in the planning stages now, but I’ve relayed the Ubuntu Documentation / Ubuntu Manual / Ubuntu Learning Team’s requirements from what we talked about this past summer when considering the Ubuntu Learning Center.

Also, Don Day, the chair of the OASIS DITA Technical Committee, has put together a Free-as-in-Freedom web-based DITA platform.  It’s in its early stages, too, but you can get a look at it here. You can log in as a guest, and then select topic tools from the bottom of the page to have a go at editing the document.

A Docs Conference?  In Ohio?

Finally, there is word on the street about the possibility of a docs conference in Cincinnati during the first weekend in June.  I’ve expressed interest in helping with planning and organizing that conference.  For now I will keep my calendar open, and will post more news here as conference plans solidify.

*Whenever you do a Google search for DITA, it’s typically a good idea to exclude the phrase “Von Teese” from your search query.  That is, unless you want your documentation searches to also include results for a fabulous burlesque dancer / entertainer. If you do want dancer / entertainer results in your documentation search queries, then make sure to include the phrase “Von Teese” in your queries.

** Generally, people do not ask me about DITA.

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.