Initialisation

This function initializes the GUI toolkit and parses all Gtk
specific arguments. The remaining arguments are returned. If the
initialization of the toolkit fails for whatever reason, an exception
is thrown.

Throws: error "Cannot initialize GUI."

If you want to use Gtk2Hs and in a multi-threaded application then it is your obligation
to ensure that all calls to Gtk+ happen in a single OS thread.
If you want to make calls to Gtk2Hs functions from a Haskell thread other
than the one that calls this functions and mainGUI then you will have to
'post' your GUI actions to the main GUI thread. You can do this using
postGUISync or postGUIAsync. See also threadsEnter.

During normal operation, this lock is held by the thread from which all
interaction with Gtk is performed. When calling mainGUI, the thread will
release this global lock before it waits for user interaction. During this
time it is, in principle, possible to use a different OS thread (any other
Haskell thread that is bound to the Gtk OS thread will be blocked anyway)
to interact with Gtk by explicitly acquiring the lock, calling Gtk functions
and releasing the lock. However, the Gtk functions that are called from this
different thread may not trigger any calls to the OS since this will
lead to a crash on Windows (the Win32 API can only be used from a single
thread). Since it is very hard to tell which function only interacts on
Gtk data structures and which function call actual OS functions, it
is best not to use this feature at all. A better way to perform updates
in the background is to spawn a Haskell thread and to perform the update
to Gtk widgets using postGUIAsync or postGUISync. These will execute
their arguments from the main loop, that is, from the OS thread of Gtk,
thereby ensuring that any Gtk and OS function can be called.

Less commonly used event loop functions

Callbacks that take more time to process can call mainIteration to keep
the GUI responsive. Each time the main loop is restarted this way, the main
loop counter is increased. This function returns this counter.

Processes a single GDK event. This is public only to allow filtering of events between GDK and
GTK+. You will not usually need to call this function directly.

While you should not call this function directly, you might want to know how exactly events are
handled. So here is what this function does with the event:

Compress enter/leave notify events. If the event passed build an enter/leave pair together with
the next event (peeked from GDK) both events are thrown away. This is to avoid a backlog of
(de-)highlighting widgets crossed by the pointer.

Find the widget which got the event. If the widget can't be determined the event is thrown away
unless it belongs to a INCR transaction. In that case it is passed to
selectionIncrEvent.

Then the event is passed on a stack so you can query the currently handled event with
getCurrentEvent.

The event is sent to a widget. If a grab is active all events for widgets that are not in the
contained in the grab widget are sent to the latter with a few exceptions:

Deletion and destruction events are still sent to the event widget for obvious reasons.

Events which directly relate to the visual representation of the event widget.

Leave events are delivered to the event widget if there was an enter event delivered to it
before without the paired leave event.

Drag events are not redirected because it is unclear what the semantics of that would be.

Another point of interest might be that all key events are first passed through the key snooper
functions if there are any. Read the description of keySnooperInstall if you need this
feature.

After finishing the delivery the event is popped from the event stack.

Sets a function to be called at regular intervals, with the default
priority priorityDefault. The function is called repeatedly until it
returns False, after which point the timeout function will not be called
again. The first call to the function will be at the end of the first interval.

Note that timeout functions may be delayed, due to the processing of other
event sources. Thus they should not be relied on for precise timing. After
each call to the timeout function, the time of the next timeout is
recalculated based on the current time and the given interval (it does not
try to 'catch up' time lost in delays).

This function differs from timeoutAdd in that the action will
be executed within the global Gtk+ lock. It is therefore possible to
call Gtk+ functions from the action.

Sets a function to be called at regular intervals, with the given
priority. The function is called repeatedly until it returns False, after
which point the timeout function will not be called again. The first call
to the function will be at the end of the first interval.

Note that timeout functions may be delayed, due to the processing of other
event sources. Thus they should not be relied on for precise timing. After
each call to the timeout function, the time of the next timeout is
recalculated based on the current time and the given interval (it does not
try to 'catch up' time lost in delays).

This function differs from timeoutAddFull in that the action will
be executed within the global Gtk+ lock. It is therefore possible to
call Gtk+ functions from the action.