Operations and other mysteries
A blog by Andrew Cowie
Wednesday, 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
Saturday, 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.
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.
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):
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!
Wednesday, 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
Friday, 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
Thursday, 26 Nov 2009
Getting a core dump
Sometimes things crash. This is the normal order of things, even if we like to pretend that Linux is so much better than its proprietary competitors. When a native library crashes underneath a java-gnome program, however, this isn’t so much fun, because the actual process which crashed is a Java Virtual Machine.
Usually I see with crashes because of something I’ve done wrong in binding an underlying GNOME library from java-gnome. So I bisect & printf() my way down until I can find the thing that causes it, read the docs, and hopefully figure it out.
Recently, however, I’ve been getting crashes somewhere deep in libpangoft when my the app is first loading or worse just sitting there and I’m not doing anything more onerous than moving the cursor around a TextView. This is still likely due to something I’ve done wrong in my code or in the bindings layer, but when it’s not happening deterministically or on demand it’s hard to even begin to analyze the problem.
The OpenJDK HotSpot VM (formerly the Sun HotSpot VM) has a pretty good SIGSEGV handler; it does its best to show you what the C library call was that died, and what the Java and C call stacks were leading up to the crash. You may have seen them around as hs_err_pid10733.log and such [I wish it would just spew that out to stderr instead of troubling to write a file, but anyway].
Strangely, the only line I’m getting when reading the crash report is:
C [libpangoft2-1.0.so.0+0x17687]
no other stack frames. Which is a bit strange, and decidedly unhelpful. So I’m going to need to try a bit harder to get a backtrace, it seems.
Getting a native C stack trace of a Java program with GDB
Much as I otherwise feel GDB is the most horrendous user interface in the history of civilization (ok, maybe second only to GPG’s command line interface), it does do one thing extraordinarily well and that’s stack backtraces of crashed programs. These days one normally runs one’s program in gdb, induces it to crash, and then runs bt:
$ gdb ./program (gdb) run SIGSEGV caught (gdb) bt
And you get your stack trace.
That’s a bit of a pain with a Java “program” because as mentioned the process running is a Java Virtual Machine (and because invoking java is … almost as bad as GPG’s command line interface):
$ java ... gobbledygook ... package.Class arguments
Usually people put their invocation line in a shell script along with various environment setup and so on:¹
$ ./script arguments
and off they go. The complication is that’s not really easy to use with GDB, since you need to invoke gdb on the binary executable (the JVM) and then, once GDB is finally up, tell it to “run” that executable with a bunch of arguments. Which means you’re back to the gory mess:
$ gdb java (gdb) run ... gobbledygook ... package.Class arguments SIGSEGV caught (gdb) thread apply all bt
which is incredibly tedious for casual use.
But the old fashioned 1980s way of using a debugger is to get a “core dump” of memory into a file called core and to run GDB on that. Just set your shell to core dump, then go back to running your program as normal:
$ ulimit -c unlimted $ ./script arguments Aborted (core dumped) $ gdb java core (gdb) thread apply all bt
and our stack traces will spill out in great gory detail. Hooray!
Incidentally, if you want to play with GDB and see what a HotSpot JVM is up to, then you need to induce it to crash; one way to do this is to send it a signal, say SIGSEGV or SIGBUS:²
$ kill -11 10733
Yeay, Open
The real point here is that with Sun having open sourced Java and it’s HotSpot VM implementation, we can now build Java ourselves and include debugging symbols [on Debian Linux, for example, install package openjdk-6-dbg along with the symbols for the various libraries in the GNOME stack, libgtk2.0-0-dbg and so on]. This means, at long last, we can actually run Java under GDB — something we weren’t able to do when Java was proprietary — and get lovely backtraces when it thunders in.
Yeay for crashes.
AfC
¹ Which is why people put this invocation into a shell script, which makes it even harder to debug because you’ve got to run ps axww or whatever to try and get the full command line used to run the program. {sigh}, but fixing this will have to wait for another day.
² Bernd Eckenfels suggests avoiding SIGSEGV as apparently he believes this is caught in some places and rethrown as NullPointerException. I’ve never observed that, but I thought I’d mention his advice to use SIGBUS instead.
Comments
Josh Triplett wrote mentioning that he likes to use
SIGQUITto get his C applications to core dump, since you can trivially generate that signal from the console withCtrl+\. What he didn’t know was that Sun’s Java VM has always had a handler forSIGQUITwhich prints a stack trace for each currently running Java thread (which is useful when trying to debug deadlock issues, but it’s the Java-side call stack only, not the native frames).Mark Wielaard mentioned a nice trick to attach to a crashing hotspot JVM to work around any core file limitations:
java -XX:OnError="gdb - %p" <arguments>He and James Henstridge also note that having the “live, but almost dead program” around sometimes makes things a little easier on the debugger (as opposed to relying on a core dump). James suggests computers are fast, and just running all your [problem child] programs in
gdball the time. Fair enough, although in my case with such a hard to reproduce crash, I think I’ll wait on a core dump.Mark let me know that on Fedora you can get debug symbols for any package you are trying to inspect. If you do
debuginfo-install java-1.6.0-openjdk(in this case) it will pull in every dependent debuginfo package also! He also notes that this crash in question might actually be a Pango problem, and cites this Fedora bug.
Monday, 31 Aug 2009
java-gnome 4.0.13 released!
This blog post is an extract of the release note from the NEWS file which you can read online … or in the
sources,
of course!
java-gnome 4.0.13 (27 Aug 2009)
Unicode. It’s bigger than you think.
This is a bug fix release to address a serious weakness in Java’s handling of Unicode characters.
Unicode handling
It turns out that Java’s chars are not pure Unicode codepoints. Most
people know that Java String objects are arrays of Java chars, but in
aggregate they are encoded in UTF-16 in order to deal with the fact that there
are Unicode characters whose index is higher than 0xFFFF and which need more
than two bytes to identify them. It’s a problem that an application developer
has to deal with if they’re using high-range “supplementary” Unicode
characters, but wasn’t something that would break java-gnome…
Except it turns out that the Java VM does not do UTF-8 translation properly. It has a hard wired limitation preventing it from writing out UTF-8 sequences longer than 3 bytes. Who knows what crack they were smoking when they decided that one. But things like TextView / TextBuffer work in characters, so we need characters. (actually, they work in UTF-8 bytes, but the offsets in our public API are the characters variants).
Luckily, we can get at the raw UTF-16 arrays backing Strings, and so in combination with GLib’s character set conversion functions, we’ve been able to redo our string handling internally so as to have correct treatment of Unicode codepoints. Lots of testing.
This surgery was almost entirely internal; Strings returned by java-gnome methods are of course still Java String objects.
New coverage
This release also features the work
of Guillaume Mazoyer exposing some of the new features available in Entry
Widgets, including displaying icons and showing progress bars in the
background. This compliments other minor enhancements to various miscellaneous
classes.
With this release, java-gnome now requires GTK 2.16 or newer.
This release is already packaged for Gentoo and Ubuntu, which is sweet.
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
Monday, 03 Aug 2009
One year and more
One of the things that saddens me is just how long it takes to write good code.
Havoc Pennington wrote a classic essay almost a decade ago about working on open source software. A lot has changed in 10 years, but his advice has surprising endurance:
Don’t start by launching your own project… it’s more educational to read and learn from other people’s code.
If you haven’t lurked and participated in a free software project, you won’t know how things are done and you’ll have an awful time trying to run your own…
If you do start a project, the all-important thing is to write code. You have to code enough to make the app useful pretty much by yourself; this can be months or years of lonely work…
When it comes down to it, writing a free application is a huge amount of work. If you’re writing your own, schedule 10-20 hours per week, at least… And schedule those 10-20 hours every week, for the foreseeable future. If you can’t commit this much time — don’t even bother starting the project. If you can’t write code, ditto.
It takes about a year
It takes about a year to write a serious application. A year! Sure, it’s easy to knock off a proof-of-concept or a mockup, but once you get down to the business of making all the internals actually work, ensuring it is well tested, and making it build for other people it all just becomes a long grind.
And frankly, that year is just to get far enough to know whether the thing is going to fly or not. It takes somewhere between two and three years to get a serious application to the point where it’s polished and well-rounded enough where other people are able to use it.
And as Havoc points out, then if your app becomes widely adopted you’re in for years and years of continued involvement.
Why on earth do we do it?
Writing software, writing poetry
This week a friend introduced me to Jacket Magazine, a poetry and literature periodical. Tons of cool & eclectic stuff. It’s published entirely online, and is clearly a labour of love. Early on the founder & editor, John Tranter, wrote an essay for the about page. The piece mostly focuses on the economics of periodical production and how the internet has opened revolutionary possibilities for the distribution of literature. Hot topics today, right? Not bad for a piece written in 1999.
The best part, though, was when he tried to describe his motivation:
The main cost is my time; which means I don’t get much poetry written these days. … it takes up most of my waking life. Why do I do it? Jacket is hard work, and I like hard work. I enjoy editing the poems and articles and taking photos of people and designing the pages, and I even enjoy writing the HTML that underlies the pages. Jacket exercises all my various talents - and it’s fun.
It has also enlarged my circle of friends by a factor of about ten. And I feel I’ve enabled a lot of writers to find a wider international audience for their work, especially younger poets. I received a lot of generous support and assistance when I was a young writer, and it’s good to be able to give something back.
10 years later, he and his contributors are still at it. Beautiful.
I’m not a poet, but the compulsive dedication that he talks about resonates.
I am ashamed to admit that of the five or so major software projects I have initiated since I returned to writing open source in 2002, only two of them have made it past the “1 year” proof-of-concept point, and only one of them has reached the “usable by real people” stage — indeed it has taken over 3 years, and that project is a library, not even an end-user application!
This emphasizes a point that the agile development community have been making for a while now — you have to get to the point of your app being usable by {you, your customer, whoever} as unbelievably fast as you can. If you’re not able to enjoy the fruits of your hard work, then you’ll likely reach the point where you’ve put tons of effort in and it’s still a demo harness that you can’t actually use for what you wanted to use it for. Live and learn.
Or maybe not :)
I’m at it again; I’ve got another one brewing, and it’s passed the 1 year mark. The competing pressures are almost overwhelming. One the one hand is the excitement that it’s starting to come together, and that drives me forward. But at other times there is intense frustration when I discover yet another bug and when it feels that the thing is no closer to being usable (by me, let alone anyone else) than it was months and months ago. Sometimes you just want to let it all go.
And I have no doubt that it will be at least two more years before it reaches the level of polish and general usefulness that is merely the starting point for other people to consider using this program.
What in God’s name am I doing spending time on this?
The demon that drives us
I was trying to explain all this to someone in a bar a few weeks back, and she asked that very same question.
Are you doing it to make money?
Well, no.
Then why are you doing it?
Well, the coding I do has paid off, at least sort of. Most of my software architecture work is consulting to large companies, but all the experimentation and new ideas that drive those engagements comes from my open source work. And some of my clients have found me through my public hacking.
Oh, so, it’s a promotional activity?
Well, I suppose it ends up that way, but that’s not why I’m doing it. It takes too much time to justify that way. Perhaps in the long term people will use my software and think well of me for having written it. Probably not, though; likely they’ll just bitch about how it doesn’t do this or that that they think it should. Doesn’t matter, I’m not really doing it for them.
Who are you doing it for?
Me.
For three years!
Hm, yeah, probably longer.
So you’re not going to make any money out of this, you aren’t building your reputation with people who hire you, and you may not ever finish it. Why are you doing it?
and I finally found an answer that made sense. The right answer:
Because it needs doing.
Needless to say that was pretty much the end of that flirtation. Apparently non-materialism isn’t sexy. :)
Doesn’t change the fact that it really is the reason we do it. It needs doing.
As for the thing I’m working on? The feeling of accomplishment that comes when I show people screenshots of my work is undeniable. The code inside’s not bad, not bad at all. And I’m actually dogfooding with it now (ok, ok, almost). I think this one is going to fly.
At last.
AfC
Tuesday, 28 Jul 2009
java-gnome 4.0.12 released!
This blog post is an extract of the release note from the NEWS file which you can read online … or in the
sources,
of course!
java-gnome 4.0.12 (24 Jul 2009)
Being Uniquely Notified while Spelling the Sources you are Viewing is good for the soul.
In addition to ongoing improvement in our coverage of the GTK widget toolkit, the next release of java-gnome begins to realize our vision to offer coverage of the broad suite of libraries making up the GNOME desktop.
New Coverage
The TextView text editing Widget has received two significant capability boosts. With the work of Stefan Schweizer, we now have coverage of the powerful GtkSourceView library with its impressive built-in multi [programming] language source highlighting features.
And with the contribution of GtkSpell coverage by Serkan Kaba, we can now offer spell checking in TextViews as well.
Two other GNOME libraries feature in this release. Serkan also contributed excellent coverage of LibNotify, enabling an application to create and send popups to be displayed by the desktop notification mechanism.
And, we expose LibUnique, which offers DBus-powered machinery enabling a developer to ensure only one instance of their application is running.
Continuing improvement
Lots of minor changes and enhancements throughout the core GTK libraries. Highlights include improved mouse button handling, filtering when choosing files, and further refinement to Pixbuf. Thanks to Peter Mossveld, Kenneth Prugh, Vreixo Formoso, Serkan Kaba.
Finally, thanks to Guillaume Mazoyer we now have coverage of EntryCompletion, the feature of Entry Widgets whereby available possible completions are offered to the based on characters the user has typed so far.
Looking ahead
There are a number of people working on various branches — some small feature extensions, and some major coverage additions that add signifant capabilies — but which haven’t quite made it to the point where they can be merged into java-gnome. We’ll see how these pieces of work fare in the coming months, but nevertheless the Java bindings for GNOME have reached a significant level of maturity and we are pleased to see people starting to use them for serious application work.
This release is already packaged for Gentoo and Ubuntu, which is sweet.
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
Tuesday, 12 May 2009
Roman Numerals
Some things about Unicode are really impressive. And some things just make you wonder.
Why are there unicode characters for roman numerals? ie, Why is U+2167 'Ⅷ' better than VIII? And, whoa, thank God that there’s U+216F 'Ⅿ' there, because otherwise I’d have to use the letter 'M' to write ©MMIX.
As we were chatting about this in #gnome-hackers, Xan Lopez found a wikipedia entry about it which seems to say “Only for compatibility” & “do not use”. I can handle that.
AfC
Sunday, 03 May 2009
java-gnome 4.0.11 released!
This blog post is an extract of the release note from the NEWS file which you can read online … or in the
sources,
of course!
java-gnome 4.0.11 (1 May 2009)
This is a bug fix release.
We made a few mistakes in our handling of the PangoAttribute structures’
memory which resulted in VM crashes [unfortunately, the normal GNOME way of
debugging things is to SIGSEGV. That’s fine for a C program but Bad™ for
your average Java Virtual Machine as it takes out the entire process. We
therefore work rather hard to avoid — or at least trap — this sort of
thing]. Releasing corrections for these bugs was a priority.
Concurrently a significant internal improvement in our handling of
accumulating Attributes into AttributeLists was made. While this is not user
visible per se, we were able to drop the requirement that the text you were
formatting already be in the Pango Layout before assigning the range that the
Attribute would cover. You also no longer need to pass that Layout to
setIndices() when building up Attributes. This makes things a great deal
easier if you are simultaneously aggregating the text and assigning markup.
Martin Garton contributed some documentation quality improvements and new coverage. Serkan Kaba made some minor fixes to ensure the unit tests run in a Turkish locale. And as ever there are small incremental improvements to various classes, including a number of additional properties exposed care of the work of new contributor Thijs Leibbrand.
Looking ahead
This was a brief cycle; as noted we’re mostly pushing some bug fixes. Meanwhile there are a number of significant branches underway by various hackers; which, hopefully, will feature prominently in the next release.
You can download java-gnome from ftp.gnome.org or easily checkout a branch from ‘mainline‘ using Bazaar:
$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome
though if you’re going to do that you’d best follow the HACKING guidelines.
AfC
Saturday, 07 Mar 2009
3 mobile broadband on Linux
I had to get a mobile broadband gizmo this week. It’s something I’ve been avoiding (not having internet access while sitting at a cafe by the beach is a feature, not a bug), but I need it for a current client. After advice from one of my colleagues that “3” (one of the carriers here and the first that did 3G digital phones in Australia) was reliable and, more importantly, that their device worked with Linux, I went and picked one up along with a prepay SIM.
3’s offering has two devices at the same price right now; the Huawei E160G and the ZTE MF627. I thought my friend had the latter and so bought that one. Big mistake.
| E160G Bit older works great |
MF627 Brand new doesn’t work |
 |
 |
Do not get the ZTE MF627 device if running Linux. Stay away from it. Even after trying the usb_modeswitch hassles, it still does not present as the device as a GSM modem like it is supposed to. Tried it on two separate laptops; one running Gentoo, the other with Ubuntu’s “J” version on it. Spent the better part of a day researching and debugging the issue, but no joy on either. One person in London claims to have a similar device working, but comparing their lsusb and dmesg output, I’m not convinced the electronics in the one available here were the same; after doing a mode switch the miniSD adapter presents, but not the modem. Anyway, sure, maybe someday someone will figure out how to make it work here, but that’s not right now.
Even worse, people writing in places like Whirlpool cite chronic quality problems with ZTE devices. Clearly this is something to avoid.
I took the thing back to the store the next day and finally managed to get a refund which I promptly used to buy their other device (why they couldn’t just do an exchange was as puzzling to the poor guy in the store as it was to me. Whatever; they kept him on the phone for almost an hour while the corporate drones he had to call for permission made up their minds that it was ok to give me my money back).
So home I went with a Huawei E160G (which is what Peter had) and it worked perfectly, right out of the box, literally. Plugged it in, device properly recognized by USB subsystem and, after adding a “mobile broadband” connection with NetworkManager 0.7, it immediately started working. Pretty amazing.
You need to have the PPP stack built into your kernel and pppd installed (once upon a time we all had that, but most of us haven’t needed to do point-to-point over a dialup modem for years, so if you’re running a modern system with a custom Linux kernel you might not have it). The relevant kernel modules are “ppp_async“, “usbserial“, and “option“.
So a big hooray to the NetworkManager team and all the people working on the drivers that made this magic work. That NetworkManager seamlessly handles all the PPP configuration and dialing is brilliant.
Neat connection active icon.
And as for the lovely staff in the store, don’t let them tell you that their service doesn’t work on Linux — but do get a device that does.
AfC
java-gnome 4.0.10 released!
This blog post is an extract of the release note from the NEWS file which you can read online … or in the
sources,
of course!
java-gnome 4.0.10 (5 Mar 2009)
Sculptures made of letters
This release is a landmark, because it features coverage of the Pango text rendering library and so, along with our coverage of Cairo, brings us to a complete solution for drawing graphics with text — be they custom Widgets, PDF documents, or beautiful vector illustrations.
In addition to merging Pango work from numerous contributors, we have made massive improvements to our Cairo coverage, support for writing PDFs, and better access to the system Clipboard.
Drawing API improvements
We’ve done a huge amount of refinement to our APIs for the ever fabulous Cairo
Graphics drawing library, including full coverage of matrix translations,
rotations, and scaling and more integrated ways of setting the source pattern
to be used in stroke, paint, and fill operations. 
Thanks to Kenneth Prugh for
having seen this through and having done the lion’s share of the testing. 
We’ve also had a number of improvements in the lower levels of GTK relating to image rendering. The gdk-pixbuf library contains a capable image parser and we can now feed it directly from a Pixbuf constructor. Thanks to new contributor Martin Garton for his hard work getting that tested and accepted.
Drawing graphics often also requires drawing text. This release features coverage of Pango, GNOME’s powerful text rendering library. Pango is not just about drawing mere glyphs; it also includes a sophisticated paragraph layout engine which gives us a capable solution for drawing text onto Cairo Surfaces.
Thanks are due to Serkan Kaba and Kenneth Prugh have both been really helpful testing; it was Vreixo Formoso who did the original leg work in April that identified Layout as the key class that we needed to concentrate on and cleaned up much of the underlying infrastructure.
As we were working on this we had occasion to continue the polish in and around the TextView / TextBuffer APIs, including a number of convenience methods for inserting text while simultaneously applying multiple TextTags, and supporting changing default fonts.
We’ve also modelled “notify signals” for when a property changes; see the
TextBuffer.NotifyCursorPosition signal for this in action.
Finally, thanks to contributions from Zak Fenton and Kamil Szymala we have
support for applications running in composited window managers to have
transparent backgrounds — which is an exceptionally cool effect, even if it
doesn’t have much to do with creating HIG compliant usable applications :).
Handling cut & paste
The GTK clipboard APIs are fairly complex, in no small part because the underlying implementations in X are really rather complex. Our coverage here in java-gnome is still fairly basic relative to that, but it’s been enough for people working on applications like text editors to write text to the system clipboard, get notification when the clipboard changes, and read text back out again.
Printed document support
The work on Pango noted above represented the essential machinery necessary to
make effective use of Cairo’s PDF backend, and this has started us down the
road of covering the GNOME printing APIs. You can now generate .pdf
documents with java-gnome, and we’ve included an fun
example showing this in action.
Thanks to Nathan Strum for permission to use one of his sketches in the example (you might find reading the blog where we found this interesting — it’s a fascinating exposé of a graphic artist in action).
Continuing improvement
Thanks to new contributor Stefan Schweizer we now have better coverage of signals relating to Notebook style Containers, and to new contributors Miloud Bel and Bruno Dusausoy for numerous small improvements in and around ProgressBar.
Miscellaneous documentation improvements and minor feature improvements always feature in our releases, with minor changes having accrued in many classes.
Just as important as new coverage is getting rid of cruft that we don’t need.
Libraries like GTK and GDK are, like any other mature project, full of
deprecated, obsolete, and unnecessary code — not to mention things that we
just plain don’t need in a Java binding of these underlying native libraries.
We’re already pretty good about not generating translation Java or JNI C code
for such things; this release continues our refinements in this area with a
considerable refinement of the .jar and .so which is ultimately what we
ship.
Finally, it’s worth noting that java-gnome’s test suite is now 40 unit test classes with 186 individual test fixtures. Combined with over 30 screenshot generating programs and 17 example programs, we actually have surprisingly good test coverage of our library. It’s high time they — and more to the point the people who work hard to create such tests — got as much credit as the visible public APIs do.
Anyone can run the tests (and anyone wanting to submit a patch had better run the tests!); they’ve been accumulating since java-gnome 4.0.0; it’s just:
$ make test
and
$ make doc
If you’re working in Eclipse launch class UnitTests as a JUnit test suite.
Build improvements
We have some fixes from new contributor Przemysław Grzegorczyk ensuring we include the correct headers in a few corner cases. This came to us via work on a GNOME Love bug, which is a first for us. Thanks!
Meanwhile, the ever industrious Serkan Kaba has added some changes to ensure that our magically locating the native shared library component of java-gnome works properly even under strange and unusual conditions.
Configuration and prerequisite detection on Open Solaris is improved thanks to reports from new contributor Kamil Szymala.
Instructions for how to optimally lay out your branches when working with
java-gnome have been moved to the HACKING file. People
intending to hack on the bindings from Eclipse are really urged to set
things up this way as it will make their lives much easier. Also, using the
latest release of Bazaar (ie bzr >= 1.12) is definitely recommended — it’s
getting really fast. We’ve upgraded our public branches, so you will need
1.9 at a minimum.
Note to those creating packages for distributions: java-gnome now depends on
the current stable GTK (ie gtk+ >= 2.14).
Looking ahead
Coverage of Poppler, GNOME’s PDF rendering library is well along, but didn’t quite make it in time for this release. It could very likely feature in the next version of java-gnome, as might coverage of GConf, GNOME’s simple store for application configuration options. People are also known to be working on coverage of GtkSourceView, libwnck, and librsvg. We’ll see what gets contributed!
The most exciting part about java-gnome at the moment, though, is the number of people working hard on applications using it. It takes a long time to write a mature, well rounded, robust end-user program, but there are some pretty cool projects ticking away out there, and it has been terrific to see the authors of these projects joining our community.
Happy developing,
You can download java-gnome from ftp.gnome.org or easily checkout a branch from ‘mainline‘ using Bazaar:
$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome
though if you’re going to do that you’d best follow the HACKING guidelines.
AfC
Tuesday, 03 Feb 2009
Miraculous
While at linux.conf.au a few weeks ago, my laptop decided to blow. It had been twitchy with suspend and resume for about a day, and then Tuesday, not 48 hours until I was scheduled to give the GTK & GNOME tutorial, the thing quite petulantly decided to stop booting. No POST. Nothing. Zap.
Eeek!
Now, laptops breaking are nothing special, and I do keep fairly regular backups. So I wasn’t that concerned about data loss. But in so far as the live-action style tutorials I give are less about formal presentation slides (though I do have lots of those as backdrop) and instead more “everyone gather around and watch Andrew play in his happy place”, suddenly losing my development meant that actually coding live in front of people was looking to be a bit of a problem.
My current laptop is from ASUS, and I’ve been very happy with it. That it fried, ok, fine whatever. But as we were now in Hobart, Tasmania I had a real problem. I needed a mainboard replacement. Fast. ASUS has service centres in Perth, Brisbane, Sydney, and Melbourne. But not Hobart.
Several people offered to lend me a laptop “for the presentation” which was lovely of them, but given that it wasn’t just me playing a slide deck but rather me needing my full development stack on board such a machine — and more to the point, me needing my system so I could get back to real work during and after the conference — my option space was very limited. Indeed, it took me all of about 3 seconds to realize that I was going to be on a flight (to Melbourne, probably) in about 90 minutes. Sure I could have couriered it and had it back in a “few days” but I patently did not have that kind of time.
Steve to the rescue
I was in the process of booking my flight out when Steve Walsh suggested that he might have a system I could use. At first it was borrowing one of the desktop machines they had around (yup, would have worked), but then he realized he might be able to lend me “the conference laptop”, which was a computer that Hewlett-Packard had donated to linux.conf.au a year or so ago. Josh wasn’t using it anymore, and Ben agreed I could use it. You guys are awesome.
As I was thinking about what I’d have to do to bootstrap and restore off of my closest available backup (on an SD card, but that’s a story for another day), I saw one of these lying on the table
and we suddenly had a very bright idea. Why not pop the hard drive out of my laptop and put it in that thing?
I had already considered putting my hard drive into the new laptop, but only for a brief moment. Even assuming it fit, I happen to have a very tightly tuned kernel and I knew was unlikely to have enough drivers to get booted on foreign hardware. Besides, the Linux installation on the new laptop was already running great.
But why not try putting my drive into Steve’s external USB enclosure? Would that even be possible?
Steve cracked his enclosure open and carefully extracted his drive. Then we started removing endless screws from my system and found our way down to the harddisk compartment and pulled my drive out:
To be honest, I would never have attempted such a thing, but Steve knew what he was doing (and more importantly, had all his tools handy). So, having taken the cradle off of my drive, we even more delecately then attached the enclosure’s logic board to my drive.
- Miracle #1: the connector from my drive fit the one in the enclosure.
(I gather that these things are “standardized” but still. The hardware you find in your average laptop is always wacky and weird. So I was pretty excited) With that done, we plugged it into the new system:
and to my supreme happiness,
- Miracle #2: the drive’s filesystems mounted to
/media/disk
Hooray for the Linux kernel, HAL, the GNOME automounter, Nautilus, and everything else that made that work.
And then, even better,
- Miracle #3: whatever it was that took out my laptop’s mainboard did not zorch my hard drive.
Hooray! My data was all ok!
A little fiddling about to make sure there was now a user andrew with a matching UID on the Ubuntu system, and then, very simply:
$ rsync -av... /media/disk /home/andrew
Outstanding.
So thanks to the help of Steve and the others, I had my /home on this new system. And one of the magic things about the GNOME Desktop for the last few years has been them safely writing down everything you need to run, so pretty much instantly I had my happy place back.
The data, at least.
Comparing distros; comparing laptops
The one problem I still faced was that the system in hand was not configured as a development machine. I had to work out what the appropriate packages were for all the different bits and pieces I was accustomed to having.
One thing I really like about Gentoo is that they clued in long ago that disk space is cheap and that things like .h files don’t take up that much room. So when you install a package on Gentoo you get development tools, header files, debug symbols [if so configured], compilers, documentation, the works. I had forgotten that Debian and Debian derived systems like Ubuntu do not install all the development libraries and tools. So I proceeded to tear my hair out for over a day wading through endless package lists trying to find what I would need to get development headers and the various tools necessary to build software (the morning of the tutorial I discovered the laptop didn’t have any man pages. What the hell?)
Granted, such things are essentially trivialities, and I accept that they were the sort of thing that one runs into when working on a new system. No big deal. Sure I could easily have built a Gentoo system in less time, but it’s not my machine and in any case I was enjoying the learning experience.
Far more interesting was living on a new distro for a few weeks. It was nice to experience all this “polish” that I’ve heard people going on about, and I was indeed duly impressed. After a while, though, I started to notice all kinds of little changes that Canonical has made to the Desktop that are really cool, but which have not been contributed back upstream to GNOME. That bothers me a little bit, but I’m hopeful that in time this sort of practise will fade in favour of them working more closely with the upstream projects they are using.
Meanwhile I also got to trial a new laptop brand. I gotta say I was really impressed with the build quality, robustness, and power efficiency of the HP corporate laptop line. This one is a couple model-years old, but I was able to have a few good chats with Bdale Garbee about it and he walked me through their current line up. After this experience I can definitely say that we will be getting HP laptops in the future.
Drove me nuts having a different keyboard layout to deal with for a few weeks. And having just about spent enough time on it to get it in my fingers, now my laptop is repaired and I’m once again mistyping everything… :)
Again, thanks to Steve who totally saved the day. And thanks to everyone anywhere who ever contributed to all the wonderful software that made the transfer from one system to another miraculous — and easy.
What about next time?
So what I have I learned?
I travel a huge amount, and having my laptop blow up is clearly something I need to be more prepared for. Remote backups are still necessary, of course, and the SD card I carry around with more or less continues snapshots of my critical files is also clearly going to continue.
But it’s kinda obvious to me now that it would be a good idea to carry around an external USB enclosure with a hard drive big enough to back up my entire system — nice encrypted partition and all set, just rsync the whole damn thing. Disk space is cheap. Along with a boot partition holding a nice generic runs-everywhere kernel, that would be enough to not only recover from, but also boot from live the next time my computer fries.
AfC
Monday, 22 Dec 2008
Positive Y
The excellent Cairo graphics library has a simple function to draw arcs; in C it’s cairo_arc(); from java-gnome it’s Context’s arc() method, etc.
Quite unsurprisingly they define increasing angles as going from the positive x axis on toward the positive y axis. Nothing unusual about that. The only thing that was surprising is that they even mention this in their documentation.
I should know better.
What I totally missed was the implication of this. I didn’t quite clue in that the positive y direction in screen positioning and page drawing is down, and so increasing angles go clockwise. Using cr.arc() to go from 0 to say π/3 radians does not give a rise of 60° like I expected; it gives this:
Whoa. This is not the counter-clockwise increasing θ like we’re all used to seeing in normal Cartesian or Polar co-ordinates. But it is indeed increasing toward the positive y axis. Oops. Oh well :)
So I made this illustration and added it to the documentation for Context’s arc() method. Really it’s mostly about pointing out which direction positive y is, but when I’ve learned something like this the hard way, I do my best to try and incorporate that knowledge into our public API. With any luck others can be spared my folly.
Drawn with Cairo, of course!
AfC
Update: Some people have pointed out that you can use a transformation matrix, and if you happen to (say) mirror across the horizontal axis then the clockwise notion would no longer apply. Fair enough; but if you have forgotten that +y starts out going down, then you’re not going to think to do such a flip in the first place.
Wednesday, 03 Dec 2008
Subversion revision number?
If you’re using the bzr-svn plugin to allow you to easily to interact with upstream projects using Bazaar, how do you find out the Subversion revision number that you happen to be at? (The bzr revno is, in general, going to be something different)
Seems to be a common question; I found myself asking it today. Turns out that the bzr-svn plugin adds a line to the bzr log output telling you the answer:
$ cd ~/vcs/gnome-util/trunk
$ bzr pull
$ bzr log | less
------------------------------------------------------------
revno: 6852
svn revno: 8199 (on /trunk)
committer: gforcada
timestamp: Tue 2008-11-25 12:52:19 +0000
message:
Updated Catalan translation
------------------------------------------------------------
revno: 6851
svn revno: 8197 (on /trunk)
committer: gforcada
timestamp: Tue 2008-11-25 12:37:53 +0000
message:
Updated Catalan documentation
------------------------------------------------------------
revno: 6850
svn revno: 8194 (on /trunk)
committer: ebassi
timestamp: Mon 2008-11-24 22:45:28 +0000
message:
2008-11-24 Emmanuele Bassi <ebassi@gnome.org>
* gnome-screenshot.c: (save_options): Save the include-pointer
setting to GConf.
------------------------------------------------------------
...
8199, apparently. :)
Nice feature!
Thanks to Matt Nordhoff for pointing this out to me in #bzr.
AfC
Wednesday, 26 Nov 2008
Slashtime goes gooey
A long time ago I wrote a tiny perl script that told you the time in various places. It was a somewhat unusual take on the usual approach to the timezone problem in that it displays offsets from where you are, not offsets from UTC (which, unless you’re in the UK in the winter time, are really kinda useless). A number of people liked using it, which was nice. It was called “slashtime” since /time is a shortcut on my company’s website to get to an HTML version of it.
For a while, though, I’d wanted to make a version that would be graphical; in addition to being more compact, I wanted it to be live and to help me with arranging meetings. So I did!
Here’s a screenshot of Slashtime running.
The new Slashtime inherited the original’s premise of showing offsets, of course, and adds some other nicities. When the sun is up is irrelevant in this day and age; but business hours aren’t (white background), as is knowing when it’s not a good time to call someone (the dark shading).
Knowing where you are is important too; that’s the blue line. There are a number of heuristics to try and figure that out, but if your Linux box’s /etc/localtime is a symlink to a file in /usr/share/zoneinfo like it’s supposed to be, you’re golden; it degrades gracefully from there, looking at what /etc/timezone says, then the TZ environment variable, etc, and doing all this in a hopefully OS aware way (there’s code in there that made it work Solaris, for example).
Oh, and yes, 01:30 is the fold point, quite deliberately. Hackers don’t go to bed at midnight. Perish the thought. So if the person you’re looking for is in the dark portion but at the bottom of the display, there’s every chance they’re still up :).
The list of places shown is specified in from a simple text file at ~/.tzlist (a default list will come up if you don’t have one). Instructions of how to set this file up properly to your own preferences is shipped with the program in the PLACES file. As you can see, I have quite a number of places in my .tzlist file, but there’s nothing wrong with just having two or three if those are the only places you want to know about.
The discussion in the PLACES example makes a point that might night be obvious at first glance: you control the names of the places shown. So if you live in Marseilles, and are tired of every other gizmo out there showing the time in “Paris”, you just go right ahead and put “Marseille” in your .tzlist file as:
"Europe/Paris" "Marseille" "France"
There’s also a meeting planner. Right-click the list and select “Meeting…” from the context menu:
and you can set the program to display a specific time and date somewhere in the world. More typically, you ned to hunt for a good time to have a phone meeting with someone; just move the sliders back and forth until you find a nice alignment for you and the other people on the call.
This example shows me working out that assuming I’m in Sydney that week, if I want to call my Mum to wish her a Happy Christmas, so long as I call just before I go to bed on 25 December it won’t be too early there (the red border is a warning that you’re not seeing current time displayed).
The GUI version of Slashtime has actually been around a long while; It’s written in Java and served as an early test bed for the java-gnome bindings of GTK and GNOME. Thanks to recent work by Serkan Kaba, however, the program is now properly internationalized. Not that there’s much to translate, but it’s important to at least set the foundation. Serkan did Turkish; I’ve done French Canadian (ahem, that’ll just go to show how rusty my Quebecois is). I must admit that I’m still pretty new to internationalization and localization, so I’m sure there’s room for improvement here.
Slashtime 0.5.9 was released this week with that branch merged. It’s packaged on Gentoo Linux as app-misc/slashtime. Building it yourself shouldn’t be hard; Thanks to people like Carl Worth and Rob Taylor it works out of the box on a number of other distros. You’ll need java-gnome >= 4.0.9. Just follow the instructions in the README file; once you’ve make installed it to the right place it’ll be in your system menus and whatnot. I personally also have a keybinding set up so I can easily run it on demand, but:
$ slashtime
will certainly do the trick :)
If you want to hack on Slashtime, just use Bazaar to grab the sources. The 'mainline' branch is at bzr://research.operationaldynamics.com/bzr/slashtime/mainline/ and you can find me in #java-gnome if you want to chat about it.
Incidentally, no, this isn’t a GNOME clock applet replacement — although I’m very pleased that Bryan Clark picked up on some of the UI ideas when I showed Slashtime to him last year in Boston; sharing ideas and learning from each other is what Software Freedom is all about — but it is a fantastically useful program to have around when you’re dealing with people around the world, as so many of us do. Enjoy!
AfC
Fixed
One of the less pleasant things about upgrading is the risk that new versions will break existing capabilities that you’re used to. Sometimes these are for-real regressions; others its just a case of codebases having moved on and unfortunately things not gelling together properly.
Upgrading my Linux kernel to >= 2.6.26 from 2.6.24 or so caused me two problems; the brightness controls for my screen were inverted, and the wireless networking applet suddenly stopped working!
Both of these bugs were resolved in the last two days! I’ve been very fortunate to have the help of some wonderful people. In one case it involved backporting an as-yet-unreleased bug fix in HAL, and in the other it was my kernel config lacking a necessary setting.
The details aren’t really important. The mutual support that is so often evident in Open Source communities like Gentoo Linux is. So to the inestimable Daniel Drake, “Sergey”, Ricardo Salveti, and all the others who helped me isolate and troubleshoot these problems, thank you very much!
AfC
Tuesday, 18 Nov 2008
A nice way to wake up
I’m the lead author and maintainer of java-gnome, an Open Source project that enables Java developers to write native GNOME applications using the GTK user interface toolkit. Like any such effort, it’s a huge amount of work, much of which goes on unseen. So there are few better ways of starting off your morning than finding a message like this in your Inbox:
I just want to thank you for this great API to GTK.
It feels entirely natural in Java, is very comfortable and very approachable. The names and APIs are as you’d think them up when you’d draw a widget set API in your mind, thus they are easy to find, too. They also work as expected (as least so far, I am still new).¹ The API documentation for each class has a nice prose introduction text, which is very helpful and saves most “tutorials”. I also appreciate that it points out just the right level of footangles to be aware of.
All in all a really great piece of work. When you talked about “quality” on your website, I was suspect, as that’s most of the time just words, but you really deliver quality. You show an good example of what quality means in the context of an API.
Sun should take a good example from you and many in the open-source world, too. Such brightness and care is rare.
Hey, thanks!
Quality versus Barrier to Entry
Regardless of the underlying economic circumstances, most Open Source projects are labours of love. But they can go one of two ways.
One tendency is to just accept anything, and hope that “someone” will fix it later. This approach has the beneift of a low barrier to entry, making it easy for people to contribute. But it can result in a muddle; code that is not yet up to scratch but whose authors have moved on to other things. The only time that Open Source fails to live up to its promise (as a software development methodology) is when someone starts something and doesn’t finish it. A situation nobody wants, but it is easy to have this inflicted upon your project if you accept incomplete contributions from other people — it can be hard to incent them to come back and finish the job.
The other way is to maintain a high standard, putting emphasis on internal consistency and clarity and asking people to rise to that level. While setting a high bar does put some people off, the contributions from those who invest the effort to rise to the occasion tend to be really good.
I tend to favour the second way. If your initiative is worth working on at all, then it is the kind of thing you work hard at making perfect because it deserves nothing less. You’re not going to let it down, and you don’t want anyone else to either.
Anyway, it’s all a lot of work. Sometimes I hate it. But when you receive a note like this from someone who appreciates the effort you’ve put in, it really does make your day — and makes you feel that result of staying clearly focused has been worth it.
AfC
¹ I pointed out to him in my reply that there was still plenty of time for him to trip over something :)
Monday, 13 Oct 2008
java-gnome 4.0.9 released!
This blog post is an extract of the release note from the NEWS file which you can read online … or in the
sources,
of course!
java-gnome 4.0.9 (13 Oct 2008)
The pen is mightier than the sword
New coverage
This is the first release with coverage of GTK’s powerful TextView/TextBuffer
multi-line text display and editing Widget. This has been the result of
several months of careful effort to present a clean and self-consistent API
while remaining faithful to the underlying implementation. This bulk of this
work was done by Stefan Prelle and Andrew Cowie, with contributions from
Kenneth Prugh and testing by many people in the #java-gnome community.
The snapshot at right is from
ExampleInstantMessenger,
included with the sources. It is a somewhat detailed example showing the use
of TextView, TextBuffer, and related classes.
Other improvements
Continuous improvement to various classes, especially in our documentation. Incremental changes have occurred in a number of places. In the TreeView/TreeModel APIs, some useful methods for translating TreeIters from one model to another have been added.
Also thanks to the persistent work of Stefan Prelle, we now have nice coverage of GTK’s Assistant (aka druid, wizard, etc), along with better support for doing popup context menus, including some bug fixes. Thanks to Srichand Pendyala for taking care of this and to Owen Taylor for having explained out some of the underlying implementation details.
As usual, incremental improvements to core classes continue. Virtually every class has been touched in one way or another; many changes are cosmetic but they add up to a nice delta overall.
Reducing memory pressure
Internally, java-gnome maintains a lookup table so that pointers coming from the C side can be converted into proxy objects for the case where a proxy has already been created. In any library there a great number of transient and temporary objects and structures allocated, and in wrapping native GNOME libraries we are no different. It turned out that registering these temporary objects was putting pressure on the lookup table. While these objects were properly weak referenced and being garbage collected (and thence freed), there were nevertheless an enormous number of temporary objects being inserted and removed from the lookup table — and that sort of thing causes hash tables to grow overly large.
To do something about this we have split the former hierarchy root into two classes. Only structures which have a persistent identity (which, in practise, means only GObjects and certain Cairo entities) are registered so they can be looked up by address later as necessary. The rest of the Java side proxies aren’t registered, essentially eliminating the transient pressure on the lookup table.
Thanks to Vreixo Formoso for doing the bulk of the leg-work on this one.
Making it easier to run java-gnome programs
Because java-gnome is directly binds to underlying system libraries, it has a
native shared library component. This led to the usual development hassle of
having to specify where this library is to be found if it were anywhere other
than /usr and of course the nightmare of ensuring a VM used the right
library in the event you were developing against or hacking on a newer version
of java-gnome; in Java this meant:
$ java -classpath /opt/local/share/java/gtk-4.0.jar:. -Djava.library.path=/opt/local/lib com.example.Program
No longer!
The native shared library part of java-gnome is now located deterministically
and loaded automatically. You don’t need to faff about with
java.library.path on the command line or in your IDE any more!
$ java -classpath /opt/local/share/java/gtk-4.0.jar:. com.example.Program
Our native component is completely coupled to the specific release you are
using, so sufficient version information is embedded in the .so name to
ensure that the right library (and only the right library) is loaded.
There are no changes if you are simply working against an “in-place”
development build of java-gnome, be it from command line, or in an IDE like
Eclipse. Things will Just Work™. Again, no -Djava.library.path.
This whole issue turned out to be a real stumbling block for new developers attempting to use the bindings; it’s not something that many Java programmers have had to deal with, so engineering around this problem to make the native library loading transparent is a big win for us.
Build system improvements
Serkan Kaba has contributed a number of internal improvements allowing the top
level ./configure script to be precise about the versions of various GNOME
dependencies we require.
Thanks to some hard work from Serkan Kaba and new contributor George McLachlan, java-gnome correctly builds against GTK 2.14 without any problems due to deprecations.
Note that java-gnome releases do not set GTK_DISABLE_DEPRECATED (this is a
change from 4.0.8); thanks to Mart Raudsepp of the Gentoo Linux desktop team
for pointing out why this would be better. These macros are still enabled
for builds checked out from version control so hackers working on the bindings
so will be able to keep up with ensuring we react to future deprecations (it’s
always awesome when downstream is a part of the upstream community; Serkan and
Kenneth are also Gentoo packagers, and take care of the java-gnome .ebuild
for us).
Looking ahead
We’re pretty happy with the state of the java-gnome right now. Coverage of the most important parts of GTK are in place. Our treatment of the underlying drawing library, Cairo, still has a bit to go, but the basics are there and a firm foundation to build from. More interesting are the remaining areas; the more general GNOME utility libraries and other parts of the Free Desktop stack that might be needed by an end-user application. It’ll be interesting to see how these areas evolve in the coming months.
You can download java-gnome from ftp.gnome.org or easily checkout a branch from ‘mainline‘ using Bazaar:
$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome
AfC
HTTP response code nuttiness
The technique of using a 404 error handler to actually render a web page from some underlying source or data is widely used. We use it on the java-gnome website to render prettily marked-up versions of our text meta documents (NEWS, README, HACKING, etc). The document you’re asking for (“README.html“) doesn’t exist, but a text source (“README“) does and so it reads that file in, runs the markup processor, and then serves the result. Yawn.
If you’re already in an error handler, then the default status code as far as the web server is concerned is, of course, HTTP 404. So you need to change that. In PHP, that’s as simple as:
which is actually treated a bit magically to tweak the response code. Too easy. This worked fine on our test site and on the production site for, well, years.
We ran into a weird problem that at some point over the last few weeks that suddenly I was seeing garbage appearing at the beginning and end of documents being so rendered on our SourceForge website. Huh?
I still have no idea what is wrong, and won’t detail all the diagnostics it took to track down the problem, but I ended up isolating it to the header() call. If I skipped that, then the document would render and serve correctly. But that’s no good, because then you are serving documents with an HTTP 404 error code, which will inhibit search indexing and caching even if it doesn’t screw with your browser.
The workaround ended up being this:
I have no idea why, but with whatever SourceForge has done to their webservers lately, this made it work fine. Go figure.
The real inanity, though, is that using wget to fetch the document while showing HTTP headers the result is this:
$ wget -x -S http://java-gnome.sourceforge.net/4.0/README.html
--2008-10-13 14:11:28-- http://java-gnome.sourceforge.net/4.0/README.html
Resolving java-gnome.sourceforge.net... 216.34.181.96
Connecting to java-gnome.sourceforge.net|216.34.181.96|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: nginx/0.6.31
Date: Mon, 13 Oct 2008 03:11:29 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
X-Powered-By: PHP/5.2.6
Last-Modified: Sun, 12 Oct 2008 14:02:37 GMT
Length: unspecified [text/html]
Saving to: `java-gnome.sourceforge.net/4.0/README.html'
[ <=> ] 16,052 22.3K/s in 0.7s
2008-10-13 14:11:30 (22.3 KB/s) - `java-gnome.sourceforge.net/4.0/README.html' saved [16052]
$
Their web server sent an HTTP/1.1 response anyway! Talk about adding insult to injury. What a waste of time.
I’m sure this is just one of those transient conditions that’ll be gone by this time next week, but it sure as hell frustrated me. If you’re seeing something weird going on with PHP pages on one of your SourceForge sites, perhaps have a look and see if this workaround helps.
{shrug}
AfC
Material on this site copyright © 2002-2010 Operational Dynamics Consulting Pty Ltd, unless otherwise noted. All rights reserved. Not for redistribution or attribution without permission in writing.
We make this service available to our staff in order to promote the discourse of ideas especially as relates to the development of Open Source worldwide. Blog entries on this site, however, are the musings of the authors as individuals and do not represent the views of Operational Dynamics. All times UTC.