Dynamic xffm issues.
In order to keep the application quick, we must avoid loading any code until it is absolutely required (this is called “just-in-time” inventory, borrowing the concept from the automotive industry). This is one of the things that dynamic libraries are supposed to do, without any concern for the programmer. Notwithstanding, in elaborate applications it is very difficult to sort out the library dependencies amongst each other since all symbols are resolved at link time. To get around this hurdle, we use g_modules. Any library that can be dynamically linked to a program can also be loaded as a g_module. In this case, none of the library symbols are dynamically linked. With the use of some simple macros, we load the library and access the required symbol when it is required. In this fashion we can tell exactly when the library is needed and keep a very tight ship with regard to the exported symbols from the library. This is all very neat, but there is one big “but”. Whilst debugging a program, you cannot access any symbols in the library that has been loaded as a g_module. This makes debugging difficult, especially when the bug is located in the library. To get around this, when –debug=yes is specified during execution of the configure script, the g_modules are dynamically linked as .so libraries, allowing for full debug.
Currently the libraries generated from the code in the “modules” subdirectory behave in this fashion. A good deal of other code from the “libs” subdirectory will be relocated here as well as release 4.4 approaches. The dynamic libraries which pertain to the GUI interfase (treeview, gridview, deskview) will also be configured in this fashion. We don’t want any symbols from the wrong gui lying around in memory by mistake (BTW, gridview==navigational, deskview==root-window).