Operations and other mysteries

Andrew Cowie is a long time Linux engineer and Open Source advocate, Java developer, Haskell aficionado, and GNOME hacker!

Professionally Andrew consults in IT operations, business leadership, and tries to help people remove the bottlenecks in their processes so they can run their technology more effectively.

Contact...

Tue, 18 Jan 2011

Use commas in FontDescriptions

Tip: always use a comma ',' when constructing a new Pango FontDescription. Otherwise, if your font family has a space in its name (as most do), the font name parser may mistakenly assume the last word of the font name is a size or variant or…

The error I was getting was that

desc = new FontDescription("Times New Roman");

was giving me "Times New" — which, since it doesn’t exist, was resulting in a fallback to the system default font "Deja Vu Sans". Shit. The fix was to use the comma separator even though I wasn’t specifying weight or size in the string:

desc = new FontDescription("Times New Roman,");

Of course, if I read the documentation I wrote years ago for our binding of pango_font_description_from_string() I’d see that I said:

The trailing ‘,’ on the family list is optional but a good idea when a font family you’re targeting includes a space in its name

so apparently I already knew this. Grr. Turns out if I’d just used setters I would have been ok too:

desc = new FontDescription();
desc.setFamily("Times New Roman");
desc.setSize(16.0);

and so on. But if you’re using the useful pango-view command line tool, be aware that the --font option is a font description string that’ll be parsed and you’ll need the comma.

Don’t worry. I’m not using corefonts for anything important :). Just needed it to make make a screenshot.

AfC

Wed, 12 Jan 2011

Where’s the black shiny cuboid?

Monolith

2010 has come and gone, and still no monolith. There’s no rotating space station, no psychotic computer, and Zarathustra hasn’t spoken up yet. I’m a tad disappointed, really.

AfC

Fri, 31 Dec 2010

java-gnome 4.0.18 released

This post is an extract of the release note from the NEWS file which you can read online … or in the sources from Bazaar.

java-gnome 4.0.18 (23 Dec 2010)

My compressed original is better than your uncompressed copy

This was a bug fix release. A serious crasher was occurring when you requested a the underlying [org.gnome.gdk] Window backing a Widget, as is often necessary before popping up context menus. Thanks to Kenneth Prugh and Guillaume Mazoyer for their help in duplicating and isolating the problem.

Better image rendering

While we’re at it, we’ve merged work in progress offering coverage of the librsvg Scalable Vector Graphics loader. This allows you to draw an SVG image as a vector graphic to Cairo (which itself works in vector form, of course), and is a substantial improvement over just loading the .svg with gdk-pixbuf (which rasterizes the graphic to a bitmap first, of course). Load the image with Handle, then draw it with Context’s showHandle().

We’ve also added coverage of Cairo Surface’s new setMimeType(), which allows you to embed the the original [ie JPEG, or to a lesser extent PNG] image in PDF output rather than just the decoded, rasterized, and very huge bitmap image that Cairo uses on screen and would otherwise have used in PDF and SVG output. So 100 kB JPEGs stay JPEGs instead of turning into 12 MB bitmaps. Yeay.

java-gnome now depends on Cairo 1.10 and librsvg 2.32.

You can download java-gnome’s sources from ftp.gnome.org_, or easily checkout a branch from_ ‘mainline‘:

$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome

though if you’re going to do that you’re best off following the instructions in the HACKING guidelines.

AfC

Thu, 2 Dec 2010

Which dictionary?

Here’s an interesting problem:

You have a proper name or other term your language’s dictionary doesn’t know about. You Add the word to your dictionary. Then you share a document with someone else. That word will be marked “mispelt” for them.

Well that sucks. After all, you, the author, went to the trouble of annotating that the word was correct! But if you’re using Enchant, say, and the program uses Dictionary‘s add(), the word ends up in your custom word list at ~/.config/enchant/en_CA.dic or so. And that of course doesn’t get sent anywhere when you give someone else your document. Presumably that’s where Ignore comes in, but astonishingly most applications treat ignore as “ignore it for this session” and when you restart your word processor unbelievably the red squiggly is back and you’ve got to ignore it again!

So really, Add should mean “add to this document’s dictionary”, right? Which implies each document has its own dictionary. Ok, we can figure that out; Enchant has something called “personal word lists” via Enchant.requestPersonalWordList() which ought to make things simple.

Except then there’s the question of the next document you write with the same proper name; you’ll be back to having to add your name. Again. So maybe the right thing to do is to add it to both the putative document word list as well as the user’s word list. THAT seems a bit presumptive, though, and doesn’t actually help the next document which you share with someone else. Hm.

If the document’s word list is in an easy to find location (ie, right beside the document) then it would be easy to copy it from one work to the next. That has possibilities.

AfC

Mon, 29 Nov 2010

java-gnome 4.0.17 released

One of the lovely things that happens in open source is the opportunity to work with people from around the world. I was in Spain last month and took the time to go a bit off the beaten track up to A Coruña in Galicia where Vreixo Formoso Lopes lives. Vreixo was the original architects of java-gnome and one of the most prolific contributors to ensuring the internals and memory management work right. It was a pleasure to finally meet him!

The rest of this post is an extract of the release note from the NEWS file which you can read online … or in the sources from Bazaar.

java-gnome 4.0.17 (18 Nov 2010)

All dictionaries are equal. But some dictionaries are more equal than others!

After some 6 months of development, this release includes substantial improvements across the library. Thanks to Guillaume Mazoyer, Michael Culbertson, Douglas Goulart, Vreixo Formoso, Mauro Galli, Thijs Leibbrand, and Andrew Cowie for their contributions to the library, and also to Yaakov Selkowitz, and Alexander Boström for their updates to the build system.

Enchant Dictionaries

Improve the utility of the Enchant library by exposing functionality to test wither a dictionary exists for a given “language tag”, and to list all available dictionaries. Add speciality functions to the Internationalization class facilitating the translation of language and country names so you can present the list of available languages properly translated in the user’s language.

GTK improvements

Introduce Icon as a strongly typed class to wrap “named icons” available in an icon theme, complementing the previous coverage of “stock icons” provided by the Stock class. Add methods to DataColumn, TreeModel, Image, and Entry making these available. Also in TreeView land, Vreixo Foromso contributed a change to make DataColumnReference generic, noting that this was his “one great irritation” with java-gnome. Itch scratched, apparently. :)

A fair bit of work went into polishing coverage in various classes. We now have coverage for Adjustment’s various properties (necessary if you want to drive a scroll bar around yourself without using one built into a ScrolledWindow). We’ve also introduced a new signal in the Assistant. You can now define the behaviour of an Assistant using the ForwardPage signal with the setForwardPageCallback() method. It can help you to skip pages when you need to. When going back, the Assistant will also skip the previously skipped page. java-gnome now supports GTK+ 2.20 and introduces the new Spinner widget that can be used to display an unknown progress. We added coverage for another utility function, this time the one that escapes text in strings so that it can be safely included when Pango markup is being used. And meanwhile if you need to ensure whatever has been copied to the clipboard is available after your application terminates, you can call Clipboard’s store().

Thread safety

Fixed a fairly serious bug in the interaction between the memory management code and the thread safety mechanism. Amazing we got away with this one so long, really. Thanks to Vreixo Formoso for helping with analysis of the crash dumps, confirming the diagnosis, and double checking the proposed solution. The problem only showed up if you were making extensive use of something like TextViews which (internal to GTK) did its drawing in a background idle handler.

Also fixed a crasher that turned up if your cursor theme didn’t have a certain named cursor. ENOTGNOME, but anyway.

More drawing

The Cairo graphics library continues to be a joy to use and we continue to make minor improvements to our coverage as people use it more. In particular, based on help from Benjamin Otte and others we’ve refined the way you create a Context in a Widget.ExposeEvent, improving efficiency and taking advantage of some of the underlying support functions more effectively.

Looking ahead

With GTK 3.0 coming closer to reality, we’re keeping close track of the activity there. GTK 3.0 is a pretty vast API and ABI break from 2.x with some fairly major changes to the way Widget sizing works, along with an overhaul of the drawing system. We’ll be updating java-gnome to meet these changes in the months to come.

You can download java-gnome’s sources from ftp.gnome.org_, or easily checkout a branch from_ ‘mainline‘:

$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome

though if you’re going to do that you’re best off following the instructions in the HACKING guidelines.

AfC

Fri, 15 Oct 2010

java-gnome 4.0.16 released

Ok, so this was a while ago; got a bit behind on my blogging, and it’s time to catch up. This post is an extract of the release note from the NEWS file which you can read online … or in the sources from Bazaar. We’ve also released 4.0.17-rc1.

java-gnome 4.0.16 (17 Jun 2010)

Accelerating is good for you

Accelerators

java-gnome now has full support for accelerators, the key bindings (such as Ctrl+Q for “quit”) typically used to activate MenuItems and Actions. The heart of the API is in the AcceleratorGroup class, although you actually use it care of MenuItem’s setAccelerator() and Action’s setAccelerator(). Huge thanks are due to Thijs Leibbrand for having navigating the almost incomprehensible native API and figured out how we could best add coverage for Java programs.

Cairo Operations

Though we’ve had support for Cairo’s various “operators” (different modes for combining what’s being drawn with what’s already on the surface) for some time, we didn’t really know what we were doing. Thanks to the careful work of Kenneth Prugh, we’ve now got full coverage in the Operator class along with a magnificent series of illustrations. These are the same pictures as are in the underlying Cairo documentation, but like our screenshots, ours are generated automatically by java-gnome programs whenever you build the documentation.

Miscellaneous improvements

The style CENTER has been added in ButtonBoxStyle.

Coverage of GTK’s new InfoBar Widget was added by Guillaume Mazoyer, who also made numerous touch ups to various core classes. The Activatable and Editable interfaces got some love. And methods to get “human readable” byte sizes have been added to the Glib utility class.

Finally, we exposed the code needed to force GDK to revert to the pre GTK 2.18 behaviour of using native X Windows for every Widget. This shouldn’t be necessary — the whole point of major changes like the “client-side windows” branch are is that they are supposed to Just Work (and more to the point Just Work better, over time) — but it does give a workaround for unusual corner cases where either GTK, java-gnome, or the developer is constrained and needs some help. You can call org.gnome.gdk[]‘s ensureNative() if you need it.

You can download java-gnome’s sources from ftp.gnome.org_, or easily checkout a branch from_ ‘mainline‘:

$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome

though if you’re going to do that you’re best off following the instructions in the HACKING guidelines.

AfC

Wed, 17 Mar 2010

java-gnome 4.0.15 released!

This blog post is an extract of the release note from the NEWS file which you can read online … or in the sources from Bazaar.

java-gnome 4.0.15 (16 Mar 2010)

Radio things

This has mostly been a bug fix cycle with numerous internal quality improvements being made. A few developer visible API additions have been made, summarized below.

Unified radio handling

There are a number of controls in GTK that exhibit the “radio” behaviour of being in a group of which only one can be selected: RadioButton, RadioMenuItem, RadioToolButton and RadioAction. We originally had a class called RadioButtonGroup which was used when constructing RadioButtons to indicate which group they were a member of. In introducing overage of the other radio types, Guillaume Mazoyer implemented a generic grouping class called RadioGroup which is now used for all the radio types.

XDG utility functions

A number of utility functions (aka static methods) were added to Glib allowing you to access the various user and systems directories as specified by the XDG specification. These are Glib.getUserConfigDir(), Glib.getUserDataDir() and friends.

Miscellaneous improvements

Better control of positioning when popping up context menus; you can specify co-ordinates when calling Menu’s popup().

The no-arg “convenience” packing methods we invented for HBox and VBox were causing more trouble than they were worth because people we not understanding the implications of the “default” packing values. So these are deprecated; the full four-argument packStart() and packEnd() have been present for a long time and are to be used in preference.

Serkan Kaba spent a bit of time working with the text version of the ComboBox API. Apparently no one had needed removeText() so he added that.

A number of improvements to the coverage of GDK’s event masks were merged. This is work originally by Vreixo Formoso necessary to support the Widget.MotionNotifyEvent signal, though it has use in other applications. Widget now has addEvents() and setEvents() to this end.

Finally, Guillaume needed to handle selections in IconViews. The API is similiar to that in TreeView, but doesn’t use the same TreeSelection helper class; the methods are directly on IconView. Boo for asymmetry. Anyway, we’ve exposed isSelected() on both TreeSelection and IconView so you can find out if a given TreePath is currently selected.

Better initialization checking

Logic checking that the library has been properly initialized has been refactored, making it harder to accidentally misuse java-gnome when getting started [or when starting a new program after you've been using the library for years and forgotten the basics :)].

Last but not least, a number of bug fixes; one in Enchant was developer-visible; Enchant.requestDictionary() now returns null like it claimed to if you request an unknown dictionary. Nice catch, Serkan.

All the source files have the full (ie traditional) GPL v2 header text now; the files comprising the library as used at run-time have GPL headers text + the Classpath Exception text. Needed to be done. Makes for a large diff this release, but makes the Ohloh‘s page for java-gnome happy too :).

You can download java-gnome’s sources from ftp.gnome.org_, or easily checkout a branch from_ ‘mainline‘:

$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome

though if you’re going to do that you’re best off following the instructions in the HACKING guidelines.

Enjoy!

AfC

Sat, 19 Dec 2009

Lovely Inconsolata

Federico writes that he’s recently discovered Raph Levien’s Inconsolata font and really liking it.

I likewise discovered Inconsolata not too long ago (it was packaged in Gentoo and I was really pleased to discover it also available in Debian), and have been using it as the constant-width font in Quill and Parchment for program listings in technical writing.

Parchment output showing Inconsolata font used for program code

We all tend to get obsessive about things we like, and so of course I tried it as a terminal console font. Interestingly, after a brief consideration, I decided not to use it for terminals and gedit and such. Deja Vu Sans Mono is still the king for that, especially if you’re using Deja Vu Sans and Deja Vu Serif for the rest of your UI; it means that the visual consistency across your desktop is really awesome.

gnome-apperance-properties Fonts tab, picking Deja Vu fonts

Inconsolata doesn’t have anything even remotely close to the kind of Unicode coverage you need in your full-time constant-width font, and when fontconfig does a fallback it looks awful because Inconsolata’s metrics are so different from others. That’s all ok; Inconsolata is meant for program listings, and looks incredible on paper.

Anyway, Federico noted that bold didn’t work when specified as a FontDescription, it doesn’t come up bold me either when I tried to do so via a bold PangoAttribute. But if you use Wouter’s Specimen, it shows up fine (on an Ubuntu box, anyway):

gnome-specimen showing Inconsolata font medium and bold

So there’s a bug in our stack somewhere.

AfC

Update

Or not. I just reread the JavaDoc for the FontDescription constructor, and lo and behold relearned what I wrote there in the first place. To get bold Inconsolata you just need to use a ',' in the right place:

    desc = new FontDescription("Inconsolata, Bold 8.0");
    ...

and my Cairo drawing code on screen in a XlibSurface shows bold. Great.

But nothing is ever simple. I ran the same drawing code out through to a PdfSurface, and no bold. What the hell? There’s a bug in our stack somewhere. {sigh}

In my original post, I misattributed Specimen… it’s written by our very excellent Wouter Bolsterlee, uws on IRC. Sorry!

Wed, 16 Dec 2009

java-gnome 4.0.14 released!

This blog post is an extract of the release note from the NEWS file which you can read online … or in the sources from Bazaar.

java-gnome 4.0.14 (16 Dec 2009)

You have to compose in order to enchant

Access to Enchant spell checking API

Coverage of the Enchant spell checking facade (which was already an implicit dependency arising from our GtkSpell coverage) is now included in java-gnome. It’s a lovely library with a simple to use API which in turn fronts for various back end spelling providers.

More detailed input handling

GTK’s handling of complex input methods is extraordinarily powerful, and of course present by default in the Entry and TextView text entry Widgets. If you’re doing your own text based work, however, you might need to capture the results of an input method being used to compose characters or words. InputMethod.Commit is where the result of a compose sequence is captured and delivered to the application.

We’ve also made numerous improvements down in GDK where events are processed; as a Java library we represent many naked low-level native entities with strongly-typed classes, and have improved our coverage here, notably with new Cursor constants representing the common use cases of changing the pointer.

Improved text rendering

Other minor improvements are present across the text rendering stack, notably with the ability to introspect where a Pango Layout has made its line breaks when wrapping via LayoutLine’s getStartIndex() and getLength() methods.

Guillaume Mazoyer finished up a work by Serkan Kaba resulting in us having coverage of the special LinkButton subclass of Button which can be used to present clickable URLs.

You can now create custom PaperSize objects, which is handy if you need to use Cairo to output PDF documents with a non-standard paper format.

Other changes

You can now use gdk-pixbuf to query an image on disk for its dimensions via Pixbuf getFileInfo() function calls.

There were of course miscellaneous improvements to various long established core classes, mostly fixing typos.

We now have the methods necessary to have ImageMenuItems actually show images (there’s a GNOME bug whereby suddenly icons are not showing in menus. So you need to either explicitly tell an ImageMenuItem that it should always show its image, or use the global Settings to say that Menus and Buttons should always have their icons showing).

The internal initialization sequence has been tweaked to ensure that GLib’s threads are initialized before anything else. This means java-gnome apps will work if glib 2.22.3 is installed; this is a workaround for bug 603774.

Headless testing

For a long time we’ve had to be careful in our test suite not to do anything that would cause a Window to appear or otherwise popup while the tests were running. But some for some test cases this is unavoidable, especially if the main loop needs to cycle. We now run the java-gnome test suite within a virtual X server (ie Xvfb), and as a result distros packaging the library can run the test suite on their headless build servers if they wish. There’s a new base class for java-gnome TestCases needing to run in this environment.

Looking ahead

What’s ahead for java-gnome? That’s always a good question. At this point java-gnome provides a comprehensive API for development of user interfaces suitable for the GNOME desktop, and it’s incredibly rewarding to see people using the library for their own programs.

Development of java-gnome has continued pretty steadily, driven by people finding they need additional features from some of the underlying GNOME and FreeDesktop libraries we already expose. As a community we also work to fine-tune the performance and quality of the library through continuous improvement of the code base and its algorithms. There are also people quietly working on experimental coverage of more unusual libraries such as GStreamer and Clutter which is pretty exciting to see.

Anyone using java-gnome are always welcome to join us in #java-gnome to ask questions or just hang out! So happy hacking, and see you soon.

You can download java-gnome’s sources from ftp.gnome.org_, or easily checkout a branch from_ ‘mainline‘:

$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome

though if you’re going to do that you’re best off following the instructions in the HACKING guidelines.

Enjoy!

AfC

Fri, 11 Dec 2009

Get your icons back

We recently upgraded a number of systems, and after a few days the (previously happy GNOME users) started to notice the dialog buttons were all lacking their icons. How did that break? At first I assumed it was a bug in Canonical’s then pending Linux release, “Karmic”. But the problem didn’t go away, and suddenly I noticed a fair bit of email and bug traffic about the issue.

It turns out that someone removed the icons on purpose!

It didn’t attract that much attention at the time, but this setting was changed by the small group who maintain GNOME Control Center. They claimed that text-only interfaces were better. Hm. That doesn’t seem right, but interesting choice on their part. Fine. So you start hunting around in System -> Preferences to find the place where you can return your GNOME desktop to normal.

There isn’t one.

The usability of icons

In the GNOME community, we’ve gone to immense effort over the years to get people to use the proper stock GTK icons in menus and buttons so that the user experience is consistent across applications. They’re a significant cue that aids navigation. Meanwhile non-GNOME applications poorly ported from other platforms often violate this consistency (Eclipse {cough}). So suddenly lacking icons the entire desktop looked ghetto.

The whole debate about what the user experience should be was an interesting one, but it seems a user experience change of this magnitude qualifies as just the sort of thing we don’t do to the huge communities of people using our Desktop during a stable release series. We have GTK 3.0 and “GNOME 3.0″ coming up, and surely those would have been the appropriate contexts to propose such change, and the right place to trial landing it.

The part that really puzzles me, though, is that after the people who made this change were (politely) asked if they could point to the usability research that makes them think that text only menus are better, they (politely) replied with reference to a respected source in HMI design, Jared Spool. Reading that page it indeed says that text only is better than icon only. But right before that, however, he indicates that the combination of icons-and-text is more usable than text-only, with the further emphasis being that consistent positioning (ordering in menus) of those illustrative aides being what really what matters. Which seems to make it strange that text-only was just rammed down users’ throats.

Find out what’s broken and fix it

That they changed something is NOT the issue; at the end of the day it’s the people who do the work and write the software who set the agenda. But something this widespread seems like it ought to have been discussed on the usability and accessibility lists. And that’s the problem; there’s no mechanism requiring that.

It’s not the GNOME Control Center hacker’s fault that this became such a sore point for the rest of us; they were in a position to change something they wanted to change and so they did so. That’s just another day in Open Source land. But in GNOME there’s nothing that enforces the GNOME Human Interface Guidelnes. If a change like this had been proposed as a change to the HIG and if following the HIG was mandatory then clearly people would have had a good focused discussion about user experience, we could have come to a consensus (or “Usability Team” could have made a decision), the HIG documents would have been patched as a part of that, and then we could all get with the program.

The GNOME “Release Team” puts new module proposals through hell to be accepted as a part of GNOME, with endless discussions about what the user experience will be. Libraries underneath the desktop work incredibly hard to maintain API and ABI compatibility across releases. We try to remember that corporate IT departments just want gentle improvement between their upgrade decisions, rather than having to deal with a wrecking ball every six months. So we all know the importance of not screwing the user around.

But unless we find a way to apply the same rigour to maintaining UI standards like we do to managing the internal technical aspects of our platform, it seems we’re doomed to keep breaking the consistency of our users’ experience (and more to the point, jerking the chain of all the people who work hard to install and support the systems that our users run). How to do that while still enabling people to innovate is the hard part, but surely requiring people to follow the HIG and making that document the heart of user experience debate would be a step in the right direction.

Meanwhile, lets fix your desktop:

Workaround: users

The Control Center hackers removed the “Interface” tab from gnome-appearance-properties which is a shame since it would have been a lovely place for the user to say whether or not they wish icons in their menus and buttons.

It was pointed out that this is all still controllable by the user… by changing GConf settings. I think most of us would agree that is the very definition of what normal users aren’t expected to be doing.

The GConf keys are:

/desktop/gnome/interface/buttons_have_icons

and

/desktop/gnome/interface/menus_have_icons

So to fix your desktop to be consistent with previous GNOME releases, you need to run:

$ gconftool-2 --type bool --set /desktop/gnome/interface/buttons_have_icons true
$ gconftool-2 --type bool --set /desktop/gnome/interface/menus_have_icons true

You’ll definitely need to repair your system like this if you’re working in applications such as Inkscape that have huge numbers of items in their menus; they become really difficult to tell apart if you don’t have the pictorial aides to help you identify the action you’re looking for.

Workaround: code

It turns out GtkImageMenuItem has a new property "always-show-image" for really important icons, ie where “the menu item would be useless or hard to use without it”. The idea is that application programmers using GTK manually need to call this for all the menu items where the icons is really important and you actually want the icon shown in the menu item (Given that you have to go some trouble to construct a GtkImageMenuItem rather than just a normal GtkMenuItem, I would have thought that that emphasis would have been a given. Alas). I just added a setter to java-gnome:

    quit = new ImageMenuItem(Stock.QUIT);
    quit.setAlwaysShowImage(true);

There are also GtkSettings "gtk-menu-images" and "gtk-button-images" which can be used to set the property globally in an application programatically or via .gtkrc:

    settings.setMenuImages(true);
    settings.setButtonImages(true);

Judging by the howls of protest, not too many people had noticed the importance of these properties, and so no one was setting it in their code. Assuming that the new default is likely to stand in the GNOME >= 2.28 era, then indeed we’ll all have to be doing this a lot.

Setting defaults

Thinking about this from the perspective of a bindings hacker and sometimes application developer, it all makes me realize the importance of exposing setters for properties, and calling setters even when the value you are setting is the default. It’s tempting to think “oh, I don’t need to call that method, it’s set by default”, but as episodes like this demonstrate, relying on defaults isn’t very reliable.

AfC