getUserSpecialDir

Get the XDG user specific special directory. Directory constants are
defined in UserDirectory. System wide defaults are defined in
/etc/xdg/user-dirs.defaults and can be overridden in
~/.config/user-dir.dirs.

If you've already queried the "special" directories then those values
are cached; they certainly don't change often. If you're writing a
program that absolutely needs to be aware if those settings have
changed after you're already used this, then you can force up to date
information by calling Glib.reloadUserSpecialDirsCache().

where b is a Button you'd previously initialzed and added
to your UI. More generally, you'd just call some doStuff()
method and do your updates there.

The return value in the handler indicates whether or not the idle
function has done it's work; return true to indicate you
want the handler to be re-invoked. Note that you are blocking the main
loop when your idle handler is running, so if you're doing serious
computation you're best doing that in a worker thread and not in the
idle handler callback.

Since:

4.1.2

markupEscapeText

public static String markupEscapeText(String str)

Perform basic escaping on a String so that it can be safely passed to
XML.

This will escape &, >,
<, etc which is necessary when passing arbitrary input
to methods which use Pango Markup such as Labels with markup enabled
via setUseMarkup()
and directly with CellRendererText's
setMarkup() or Layout's
setMarkup()

reloadUserSpecialDirsCache

WARNING:
This may cause memory leaks if the return values change between calls.

Since:

4.0.15

setProgramName

public static void setProgramName(String name)

Change the internal program name used by GLib and GTK for internal
error messages. Occasionally (especially as we develop new
functionality) you or we will do something wrong, and GLib will
complain loudly about it to the console, for example:

where "gnome-panel" was the name set by that program with
this method call, and 5581 was the process id originating
the message. As you can see, the whole thing is pretty ugly (not to
mention having no context), which is why one of the design goals of
java-gnome is to fully proxy the entire underlying library and have
none of the internals from GLib or GTK be exposed to the Java
developer. If we do our job right, your users should never see a
message like that; at worst it would be reported as a Java stack
trace.

You don't really need to call this, but it's here if you want to make
it clearer in the .xsession-errors log what the culprit
application is.

Warning
If you wish to use this, it must be called before anything else.
This is the only method in java-gnome that can be called before
Gtk.init().