java-gnome 4.1.2 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.1.2 (30 Aug 2012)

Applications don’t stand idly by.

After a bit of a break, we’re back with a second release in the 4.1 series covering GNOME 3 and its libraries.

Application for Unique

The significant change in this release is the introduction of GtkApplication, the new mechanism providing for unique instances of applications. This replaces the use of libunique for this purpose, which GNOME has deprecated and asked us to remove.

Thanks to Guillaume Mazoyer for having done the grunt work figuring out how the underlying GApplication mechanism worked. Our coverage begins in the Application class.

Idle time

The new Application coverage doesn’t work with java-gnome’s multi-thread safety because GTK itself is not going to be thread safe anymore. This is a huge step backward, but has been coming for a while, and despite our intense disappointment about it all, java-gnome will now be like every other GUI toolkit out there: not thread safe.

If you’re working from another thread and need to update your GTK widgets, you must do so from within the main loop. To get there, you add an idle handler which will get a callback from the main thread at some future point. We’ve exposed that as Glib.idleAdd(); you put your call back in an instance of the Handler interface.

As with signal handlers, you have to be careful to return from your callback as soon as possible; you’re blocking the main loop while that code is running.

Miscellaneous improvements

Other than this, we’ve accumulated a number of fixes and improvements over the past months. Improvements to radio buttons, coverage of GtkSwitch, fixes to Assistant, preliminary treatment of StyleContext, and improvements to SourceView, FileChooser, and more. Compliments to Guillaume Mazoyer, Georgios Migdos, and Alexander Boström for their contributions.

java-gnome builds correctly when using Java 7. The minimum supported version of the runtime is Java 6. This release depends on GTK 3.4.

AfC


You can download java-gnome’s sources from ftp.gnome.org, or easily checkout a branch frommainline:

$ 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

java-gnome 4.1.1 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.1.1 (11 Jul 2011)

To bump or not to bump; that is the question

This is the first release in the 4.1 series. This introduces coverage of the GNOME 3 series of libraries, notably GTK 3.0. There was a fairly significant API change from GTK 2.x to 3.x, and we’ve done our best to accommodate it.

Drawing with Cairo, which you were already doing

The biggest change has to do with drawing; if you have a custom widget (ie, a DrawingArea) then you have to put your Cairo drawing code in a handler for the Widget.Draw signal rather than what used to be Widget.ExposeEvent. Since java-gnome has ever only exposed drawing via Cairo, this change will be transparent to most developers using the library.

Other significant changes include colours: instead of the former Color class there’s now RGBA; you use this in calls in the override...() family instead of modify...() family; for example see Widget’s overrideColor().

Orientation is allowed now

Widgets that had abstract base classes and then concrete horizontal and vertical subclasses can now all be instantiated directly with an Orientable parameter. The most notable example is Box’s <init>() (the idea is to replace VBox and HBox, which upstream is going to do away with). Others are Paned, various Range subclasses such as Scrollbar. Separator, Toolbar, and ProgressBar now implement Orientable as well.

There’s actually a new layout Container, however. Replacing Box and Table is Grid. Grid is optimized for GTK’s new height-for-width geometry management and should be used in preference to other Containers.

The ComboBox API was rearranged somewhat. The text-only type is now ComboBoxText; the former ComboBoxEntry is gone and replaced by a ComboBox property. This is somewhat counter-intuitive since the behaviour of the Widget is so dramatically different when in this mode (ie, it looks like a ComboBoxEntry; funny, that).

Other improvements

It’s been some months since our last release, and although most of the work has focused on refactoring to present GTK 3.0, there have been numerous other improvements. Cairo in particular has seen some refinement in the area of Pattern and Filter handling thanks to Will Temperley, and coverage of additional TextView and TextTag properties, notably relating to paragraph spacing and padding.

Thanks to Kenneth Prugh, Serkan Kaba, and Guillaume Mazoyer for their help porting java-gnome to GNOME 3.


You can download java-gnome’s sources from ftp.gnome.org, or easily checkout a branch frommainline:

$ 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

java-gnome 4.0.20 released

This post is an extract of the release note from the NEWS file which you can read online.


java-gnome 4.0.20 (11 Jul 2011)

This will be the last release in the 4.0 series. It is meant only as an aide to porting over the API bump between 4.0 and 4.1; if your code builds against 4.0.20 without reference to any deprecated classes or methods then you can be fairly certain it will build against 4.1.1 when you finally get a system that has GTK 3.0 and the other GNOME 3 libraries on it.


AfC

java-gnome 4.0.19 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.19 (14 Feb 2011)

What do you mean that’s not the font I asked for?

This release includes some minor feature enhancements.

Preliminary coverage of Pango’s Font object. Font is Pango’s abstraction describing a typeface, and is what is actually loaded. We’ve exposed the methods that allow you to find out what was actually loaded for a given FontDescription request. You do this with Context’s loadFont() and then Font’s describe(). Thanks to Behdad Esfahbod for explaining how all this works.

Exposed a few utility functions, including one to find out if your program is running in a terminal or from the Desktop directly.

GTK improvements

Further improved some corner cases involved in using Actions, and now you can make them with named Icons.

There are some odd corner cases, especially with TextView, where idle handlers need to run before you have the calculations you need ready to query. One workaround appears to be letting the main loop cycle, so we’ve exposed Gtk.mainIterationDo() and the Gtk.eventsPending() which wraps it.

Build improvements

Building java-gnome on Mandriva now works! Thanks to Liam Quin for helping QA the top level configure script.


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

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

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

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

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

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

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