[Lumiera] starting up the GUI

[Ichthyostega]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi all,

after being still somewhat "disabled" by the flu,
I've now managed to finish my recent work and merge it to master.
Thus the lumiera executable not only loads the GTK GUI code as shared module,
but now actually starts the main event loop in a separate thread and opens
the GuiNotification facade interface (as proof-of-concept). When the GUI
terminates, GuiNotification facade is closed and the application will shut down.

I didn't touch the lumigui executable (which just runs the GUI without the lower
layers) -- rather, I just invoked gui::application().main(argc, argv) from the
gui/guistart.cpp (which in turn gets loaded as plugin and is linked against the
gui shared library)

In order to successfully run the lumiera executable from the build tree,
* you probably need to set LD_LIBRARY_PATH to point at the .libs subdirectory
  (or use the wrapper/libtool), so the linker is able to find the shared libs
* you need to set LUMIERA_PLUGIN_PATH to point to the dir containing gtk_gui.lum
  (which happens also to be the .libs subdirectory)
* you need to change to the directory containing the GUI resources (stylesheet,
  icons). This is the bin directory when building with SCons and it is the
  tree root dir when building with Autotools.

Of course, I would be interested to hear if this works four you!

Christian: I've moved the threads.h/c into the lib directory, because otherwise
the lib would depend on the backend. It seemed to me that it's more natural to
put the threads runner into lib, as the mutex and condition support currently is
also contained in the support lib.

Joel: maybe a next step to try out the integration would be to implement an
(asynchronous) message display within the GUI? Of course, all of this is merely
experimental. Currently, I've put the two following functions into the
GuiNotification facade (src/include/guinotificationfacade.h):
      virtual void displayInfo (string const& text)
      virtual void triggerGuiShutdown (string const& cause)

The idea was that this interface will become the official interface which can
be used by the lower layers when they want to push informations into the GUI
or want to trigger some behaviour within the GUI. Of course, this is rather
the exception, because normally it's the GUI which triggers operations. But
at least there is always the possibility that something asynchronous happens
"down in the core", which should cause some alert to appear in the GUI.

Of course, the problem with implementing such a mechanism is that the call can
happen at any time and thus should place the new informations in some buffer
or queue, and later on the main event loop (GUI thread) needs to pick up the
new informations from there. I am not familiar enough with GTK to know what
would be the best technique to achieve such a behaviour.

Basically, I've just used the GuiNotification as an example to work out how
to open/close and address any facade interface. Especially for the Proc-Layer,
there are other facade interfaces which I thought I should start drafting next,
using a similar implementation technique. Probably there will be one interface
which the GUI uses to access/modify session data, and maybe a separate interface
for general session management (load/save/close session). And yet another
interface will be used to issue pull() calls for specific frames.

A note regarding the threads: Currently, I've the main thread, which, after
starting the various subsystems, enters a wait state, until application shutdown
is detected. Then, there is the GUI thread, which executes the GTK main.
Besides, my intention was to run the builder in a separate thread; and similarly
a renderfarm node server will probably listen in a separate thread.

But, on the contrary, if I recall our discussions this summer right, the plan
was *not* to use a separate thread for the session, but to perform mutations
within the session synchronously from the GUI thread, responding immediately.
Of course, as any mutation may require parts of the low-level model to be
re-built by the builder, there may be an additional asynchronous response
in case any error is detected in the build process.

	Hermann





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJaSv5ZbZrB6HelLIRAmioAJ9lOGy6dHId2qBeTvW/fsnzQK1hEwCfUbUf
SFroyCj1XH4mMdiYO7lz4Es=
=MR3T
-----END PGP SIGNATURE-----