Notes from the Mousepad

I’m at the GNOME documentation hackfest in Brno, Czech Republic, and we’ve been updating help for GNOME platform and applications in advance of GNOME 3.4.

As part of the event, we’ve been reviewing our use of the Mallard syntax, making sure that we’re getting the most out of some of the new features. One newer feature in Mallard allows users to expand or hide portions of the help as needed. This helps users can more easily scan through possible topics, and to open the ones that are relevant to them. It also has the added benefit of saving space on the screen. This feature is in an experimental namespace for now, but we’re please enough with the results, and it is likely to be moved into the primary schema shortly. It will be in limited use in our help releases for the 3.4 cycle.

Here’s a brief example of what this looks like in action (note: you might need to view the page directly rather than through a feed aggregator if you want to see the video):

Also, here’s a portion of the code that makes it work. All that’s required is a the “ui:expanded” attribute on the appropriate element. It accepts values of “yes” and “no.”

<table rules="rows" frame="top bottom" ui:expanded="yes">
  <title>Tab-related Shortcut keys</title>
    <thead>
      <tr>
        <td><p>To Do This</p></td>  <td><p>Press This</p></td>  
      </tr>
    </thead>
    <tbody>
      <tr>
        <td><p>Switch to the next tab to the left</p></td> <td><p>Ctrl + Alt + PageUp</p></td>  
      </tr>
    </tbody>
</table>

It’s possible to use this attribute on any element that contains a title, so you have the ability to use it on tables (as I’ve done here), lists, steps, or even entire sections. Thus far we’ve only used them on tables, and the style rules have yet to be ironed out.

The hackfest has been good thus far, but we still have much to do over the next couple of days. I am focusing on some updates to GNOME user docs, as well as writing new docs for Seahorse Encryption Manager, Rhythmbox, and am doing some GNOME docs team wiki work. Florian Nadge and Petr Kovar of Red Hat have been more than gracious as hosts, and the food on Brno is plenty meaty. Plus, there is cheap beer.

Of course the food and drink is even less expensive when Shaun McCance of Syllogist.net sponsors a dinner for us (thanks, Shaun!). Many thanks, as well, go to the GNOME Foundation for their sponsorship of our travel and accommodations.

As I mentioned in a recent post, gedit snippets can help you write code more quickly, and with fewer errors, than writing all of your code manually. Snippets work by expanding small chunks of text into complete combinations of code boilerplate and variable/attribute placeholders. Using these pre-configured combinations of boilerplate and placeholders frees you to focus on the bits of code and text that are materially relevant to your work at hand.

You can enable the gedit snippets plugin by selecting Edit > Preferences > Plugins > Snippets.

There are four components to using snippets: confirming the language or syntax setting, entering the snippet ID, activating the snippet, and completing the snippet by entering the appropriate attributes or variables into the placeholder text areas.

The first thing is to make sure that the file type is set to correspond with the type of file you’re working on. If you’re starting from an existing file, gedit will attempt to set the file type for you automatically. If you’re starting a brand new file, or if gedit hasn’t correctly identified the file type, you can also manually set or change the file type.

Once you have that in place, the most difficult part is actually remembering the snippets that are available. You can view, edit, and create snipppets using the Manage Snippets window (see Tools > Manage Snippets). Once you know the relevant snippet IDs, all you need to do is type a snippet ID, and press the tab key. The tab key is what activates the snippet.

After you press the tab key, gedit converts that brief snippet of text into a combination of boilerplate text and appropriate variable or attribute placeholders. Pressing the tab key again will move the cursor to the next placeholder area.

Here’s an example. I’m starting from a blank page, and am writing a new Mallard XML file. The snippet ID to start a new Mallard page file is just the word, “page.”

Simple enough! Just enter the snippet ID, press the tab key, watch as gedit inserts the boilerplate text, and then use the tab key to maneuver through the placeholder areas.

There are currently snippets for numerous languages and syntaxes, but coverage of each language varies, and some snippets may not include the most recent language features. Give gedit snippets a try. If you don’t see a snippet feature that you’d like to use, file a bug in the gedit bug tracker.

I’ve been maintaining the gedit documentation since the run-up to the gedit 3.0 release, and doing so has helped me to get to know some of the ins-and-outs of the program. What can I say, it’s one of the perks of writing documentation – you get to know the software that you’re documenting.

With that, though, I thought I’d pass along some of the basic configurations that help me to write documentation more quickly, and in a more consistently-formatted way.

Here’s a quick run-down of some settings that you may find helpful:

View Preferences – Edit > Preferences > View:

• Check the following items:
• Display line numbers (this helps with locating validation errors)
• Display right margin at column (80 characters) (breaking lines at 80 characters makes diffs look prettier)
• Highlight the current line
• Highlight matching brackets (optional: I don’t use this feature, but some people prefer it)
• Uncheck:
• Enable text wrapping (not needed if you’re breaking lines at 80 characters)

Editor Preferences: Edit > Preferences > Editor

• Tab Width: 2
• Check
• Insert spaces instead of tabs
• Enable automatic indentation
• Uncheck
• Create a backup copy of files before saving (not needed if you’re using revision control, like git or bzr)

With regards to plugins, I recommend enabling the dashboard plugin (which will be available as part of gedit 3.4, included in Ubuntu 12.04, Fedora 17, OpenSUSE 12.2, etc.), and the gedit snippets plugin. In the near future I’ll be writing up a post about using gedit snippets.

One other neat feature that I often use with gedit is the keyboard shortcut for moving a line up or down within the text. If you position your mouse cursor on any point in a line, and then press Alt + Up Arrow, it will move the entirety of that line up within the text. Pressing Alt + Down Arrow will move that line down within the text. Simple enough! (The complete list of gedit shortcut keys is available in the user help, by the way. Just open up gedit and press F1.)

Do you have any suggestions or tips for using gedit to write documentation? If so, I’d appreciate you sharing them with me in the comments.

Trying to write documentation for both Gnome 3 and Ubuntu 11.04 had many of the documentation contributors a bit strapped for time, but we are making progress on user help for 11.04.

Here is a quick peek at what we are doing:

Click to play

This is all done with Mallard and Yelp.

KDE, you can have this, too. Talk with Shaun McCance. Shaun has revamped the back-end of yelp so that it wouldn’t be crazily difficult to put a Qt front-end on it.

Just imagine it . . . You could call it “kelp.”

As for the docs, there is still much more to be done. Join us on #ubuntu-doc on IRC, or join the Ubuntu Documentation team mailing list to see how you can help out.

Although I’ve primarily worked on Xubuntu documentation in the past, this cycle has seen me contribute quite a bit to gedit documentation. Unfortunately, I’ve asked, and the gedit team isn’t going to be making an additional release for the 2.3x branch, so these updates won’t be included in Ubuntu 11.04. : /

Update: I’ve spoken with another gedit developer, and have been given the ok to get the 2.3x docs updated once the 3.0 docs are ready. Obviously, 3.0 is the priority, but I will make this happen for Ubuntu + OpenSUSE. : )

For now, though, I’m at the Gnome 3 documentation hackfest with Phil Bull, Shaun McCance, Johannes Schmid, Tiffany Antopolski, Natalia Ruz, and Germán Póo-Caamaño. Scott Nesbitt of DMN Communications and Words on a Page fame plans to stop by over the weekend, and Ryan Lortie has been playing the part of gracious local host, doing airport pick-ups and coordinating our hotel stay / work locations. (Thanks, Ryan!)

So, what are we doing here? The primary focus for Shaun, Phil, Tiffany, Natalia, and myself is to re-work the Gnome User Guide for Gnome 3. We are using the Mallard syntax to write more topic-focused help, addressing specific needs of users rather than providing help in a long-form manual format. We’re currently on day three of the hackfest, but we have three and a half more days to go. We will need every day–there is still much to cover.

An additional focus of the hackfest is to write Gnome platform and developer documentation. This is primarily the focus of Johannes and Germán, but Shaun will be helping with this as well. Thus far, Johannes has been working on implementing Gnome-related programming tutorials in several different languages. Some of his tutorials feature sounds, and we hear bleeps and bloops coming from his laptop every now and then . . . he’s making some pretty good progress.

Some of you may recognize Phil Bull’s name, as he is on the Ubuntu doc team, too. That means two Ubuntu users contributing to upstream Gnome documentation. Phil is even writing parts of the shell documentation from within Unity. (Ok, he looks over at my laptop which is running Gnome 3). But still . . . Group hug, Ubuntu / Gnome. Group hug.

Finally, I know the rule of “pics or it didn’t happen, so here are a couple of images to tide you over for now.

(Yes, I know that the pics are a little too big for my blog settings for now . . . I’ll have to fix it later.)

Thanks to the Gnome Foundation for sponsoring my hotel stay, to Syllogist.net for the muffins in the morning, and to Seneca College Centre for Development of Open Technology for providing the space.

I ran into a couple of roadblocks in trying to use entities with Mallard recently, and thought I would share how I worked around them in case anyone else needed to do the same thing. Although my examples deal with Mallard, what I note here will also work for entities in DocBook 5 documents, or any other RelaxNG-based XML documents.

Entities?

Before I start, though, if anyone is wondering what I’m talking about when I say, “entities,” they are a handy variable-like feature of XML and a couple of other markup languages. For example, they allow you to type something like &exaile; into your document, and then have it magically parsed as:

<guiseq><gui>Applications</gui><gui>Multimedia</gui><gui>Exaile</gui><guiseq>

The final, rendered result would be a familiar GUI click-path like, "Click Applications > Multimedia > Exaile." While entities have their limitations and are not ideal for all use-cases, they serve a purpose. This web page gives a good overview of entities and how to use them.

Using Entities in Mallard / RelaxNG documents

To set up and use entities in your XML-based document, you basically need three things. You need a file that contains the entities you want to use*, you need to declare where those entities are tracked, and you need to actually use the entities in your document.

The Entities File

Previously, step one was very easy. You would just create a file that contained values like this:

<?xml version="1.0" encoding="UTF-8"?>
<!-- MENUS -->
<!ENTITY abiword '<guiseq><gui>Applications</gui><gui>Office</gui>
<gui>AbiWord</gui></guiseq>'>
<!ENTITY about-me '<guiseq><gui>Applications</gui><gui>System</gui>
<gui>Users and Groups</gui></guiseq>'>

However a somewhat recent change in libxml** prevents these entities from being parsed as they used to be, making things slightly more involved. (If you’ve been bitten by this bug, libxml will throw up a, “Namespace default prefix was not found” error message.) To resolve this, you need to include the relevant XML namespace in the entity. For Mallard-based documents, the resulting changes look like this:

<?xml version="1.0" encoding="UTF-8"?>
<!-- MENUS -->
<!ENTITY abiword '<guiseq xmlns="http://projectmallard.org/1.0/"><gui>Applications</gui>
<gui>Office</gui><gui>AbiWord</gui></guiseq>'>
<!ENTITY about-me '<guiseq xmlns="http://projectmallard.org/1.0/"><gui>Applications</gui>
<gui>System</gui><gui>Users and Groups</gui></guiseq>'>

Out of the Woods

Once you make it past step one, the rest is a walk in the park.

Step two is to declare your entities in the start of your documentation files. I modified a DocBook 5 example to come up with this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE page [
<!ENTITY % entities-xubuntu SYSTEM "libs/xubuntu.ent">
%entities-xubuntu;
]>
<page xmlns="http://projectmallard.org/1.0/"
      type="topic" style="task"
      id="music">

Wrapping Things Up

Step three, using your entities in your documents, is no different than what you would have done with DocBook 4 or any other XML-based syntax. For example, typing &abiword; will be parsed as:

<guiseq><gui>Applications</gui><gui>Office</gui><gui>AbiWord</gui></guiseq>

and will cause “Application > Office > Abiword,” to magically appear in your rendered documentation.

If you have any questions, corrections, or suggestions (as I’m sure you’re all keen to be chatting about XML entities), feel free to leave me a note in the comments.

* I’m using external entities, which requires a separate file, but you can also use named or charater entities.
** Apparently the namespace of the parent node is no longer inherited by the entities, so you need to declare the namespace in the entity itself.

Here’s a somewhat quick run-down of some projects with-which I’ll be participating, and some other projects that, while I might not be a direct participant, I am curious to watch develop.

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.

Edit: I recommend checking out Paul Frields’ post about Emacs and nXML mode, and also looking at the Fedora wiki page that he created.  I think his approach is a bit simpler and cleaner than what I’ve provided below.  Feel free to peruse what I’ve written, though, as some of my links to “getting started” references should still be helpful.

---

I’ve been doing some documentation work with Mallard and DocBook 5 recently, and have been looking for software that supports them well.  The trick is that both Mallard and DocBook 5 are based on RelaxNG schemas, and while there are many XML tools out there, there are few that are open source, and fewer still that support RelaxNG.

After perusing my options, I decided to try Emacs with nXML-mode.  Emacs’ nXML-mode provides real-time validation for RelaxNG-based documents, something which no other open source authoring tool provides. But while nXML-mode can validate XML documents on-the-fly, the default installation is not set up to validate against the recently-developed Mallard and DocBook 5 schemas.

Thus, to take full advantage of the latest in duck-based documentation technologies, I needed to modify my .emacs file and the nxml-mode files themselves.  What follows is an overview of exactly what I did in the hopes that others can make use of the same changes, too.

An nXML-mode foundation

Before we get started, though, you should know that much of what follows is derived from information on this website.  I encourage you to visit the site, as it provides an introduction to how nXML-mode is configured, and enough of an introduction to using nXML-mode to make you at least modestly productive right away.

Part One: Setting up your .emacs file

The first step in setting up nXML-mode for Mallard and DocBook 5 is to make a few changes to your .emacs file.  If you are new to Emacs, your .emacs file sits in your home directory, and serves as a personalized Emacs configuration file.  You may need to create the .emacs file if it doesn’t already exist.

;; /usr/share/emacs/site-lisp/tcc-nxml-emacs:  Add these lines
;;      to your .emacs to use nxml-mode.  For documentation of
;;      this mode, see http://www.nmt.edu/tcc/help/pubs/nxml/
;;--
;; Add the nxml files to emacs's search path for loading:
;;--
(setq load-path
      (append load-path
              '("/usr/share/emacs/site-lisp/nxml/")))
;;--
;; Make sure nxml-mode can autoload
;;--
(load "/usr/share/emacs/site-lisp/nxml/rng-auto.el")

;;--
;; Load nxml-mode for files ending in .xml, .xsl, .rng, .xhtml .page
;;--
(setq auto-mode-alist
      (cons '("\.\(xml\|xsl\|rng\|xhtml\|page\)\'" . nxml-mode)
            auto-mode-alist))

The above .emacs configuration tells Emacs where to look for detailed XML processing instructions, and also causes Emacs to automatically use nXML-mode for XML-related files.  (Did I tell you that Emacs might have a bit of a learning curve?  Yeah, that’s true.)

Part Two: Modifying the nXML-mode configuration files

The second step is to modify the nXML-mode configuration files themselves. This will add the appropriate nXML-mode secret sauce to handle Mallard and DocBook 5 documents.

Fortunately for you, I grabbed the latest nXML-mode source files from the nXML-mode website, and made the appropriate modifications myself.  You can download my customized nXML-mode files from this archive.

Here’s what I changed from the default setup:

• I added the docbookxi.rnc and mallard-1.0.rnc schemas to the schemas directory
• I modified the schemas.xml file, thus including the docbookxi.rnc and mallard-1.0.rnc schemas as part of the XML-validation process.

Note that I have used the DocBook 5 “docbookxi.rnc” schema which allows for xinclude functionality.  If you want to use the schema that does not allow for use of xinclude features, you’ll need to adjust the files accordingly.  The current DocBook 5 schemas are available here.

Part Three: Copy your nXML-mode files to the proper location
The final step is to copy the nXML-mode files to the proper location on your file system.  As indicated in our .emacs file, that location is:  /usr/share/emacs/site-lisp/nxml/.  Thus, you should copy all of the files in the downloaded “nxml” folder into that directory.  You will need administrative privileges (using root or sudo) to do this.

Wrapping up

That’s it, though.  You should now have a functioning nXML-mode environment that will allow you to fire-up Emacs and start writing Relax-NG-based documents, getting all of the real-time-validation features that Emacs provides. If you can think of any ways in which I could improve my approach, please let me know.  Otherwise, I encourage you to head-on over to the nXML-mode website, and view some of the nXML-mode information and resources that are available as you get started.