GTK -- UI toolkit and framework
===============================

//Menu: label GTK


Within this subsection we collect some random bits of information related to our
use of the GTK windowing toolkit for building Lumiera's user interface.

Concepts
--------

A facility like GTK can be seen to serve various needs. It can be used to simplify
the arduous task of building a graphical user interface, but it can also be seen as
a one-stop solution for just creating a (``damn modern cool'') application, which
all ``reasonable'' people today expect to have a shiny GUI. In fact, we can identify
these two different levels of support, which inevitably create conflicting goals.

- GTK-the-framework shall be easy to use and cover everything I never wanted to know
  about user interfaces. Ideally, I just inherit from a base class, implement two or
  three abstract methods and fill in my actual working logic.
- GTK-the-toolkit is a collection of prefabricated building blocks, ready to be used
  and put into action, by people with a clear conception about what is required for
  a productive UI and how to achieve that in detail.

Needless to say that Lumiera's use of GTK falls into the second category. Even more so,
as the GTK UI is just a plug-in, loaded optionally, and not identical with the application
as such. Which often places us into a tricky situation -- obviously GTK-the-framework is
what attracts most attention, both from the users and the developers.

The Gtk::Application
~~~~~~~~~~~~~~~~~~~~
*In short*: we do not use it, we do not want it, we do not need it, it's just obnoxious.

In the _good old days(TM)_ there used to be a singleton class `GTK::Main`. You'd activate
your application by invoking the blocking function `Main::run()`. This design was sweet
and simple, but turned out to be too rigid once people started to expect lots of things
to ``just work''. Consequently, `Gtk::Main` was deprecated by the GTK-developers and
``replaced'' by `Gtk::Application`. Unfortunately, this move reflects a paradigm shift
from _toolkit_ towards an _application building framework._ This framework includes

- a well defined global application lifecycle
- command line parsing with extension points for custom argument handling
- a ready-made framework of _actions_, to be arranged into menus and toolbars
- management of ``the application instance'', with inter process communication
  in case the deaf user double clicks the application icon a second time
- the notion of a ``associated document type'' and ``desktop actions''
  to be forwarded to the implementing application, which thus needs to
  be invocable in service-style.
- registration with the desktop, interconnection with the D-Bus

None of the above is _evil_ in any sense, much is even useful. However, there is a notion
of a working style, underlying the vision for Lumiera: work is considered a long-term
undertaking, organised into a project and carried out in a fixed and controlled environment
over the course of an extended time period. Basically we envision the user to make some
_footage_ available to an _editing workstation_, and then to return to this very setup over
the course of weeks, or months, or years, expecting everything to remain reliably the same,
just as configured initially.

Based on this model, we basically want to shape all application global concerns in a
very specific way -- and almost all the standard solutions offered by GTK-the-framework
tend to get into our way of working. For this reason

- we have our own framework of subsystems
- we build our own approach towards command line handling
- we rely on the notion of a project to define a specific work environment
- we want menus and toolbars to be configurable based on both the project and user preference,
  goverened by rules and with persistent interface state
- we deliberately allow for various ways to launch the application, even without UI
- we build our own system to navigate within the UI, spanning several top-level windows and desktops.

Consequently, none of the services offered by `Gtk::Application` is of much use for us. After reading
the source code, we came to the conclusion that it is perfectly valid to sidestep all those aspects
of GTK, and just perform those small number of toolkit initialisation steps -- previously invoked
by `Gtk::Main` -- directly from our application code. Basically Lumiera's `stage::ctrl::UiManager`
replaces `Gtk::Main`, invokes `gtk_init` and enters the blocking event loop by calling `gtk_main`.


