A: Here is the road map from start to finish:
A: Those tables hold the module data and therefore can only be erased by unloading the corresponding module. They are easily recognizable since they are the only ones with a window bar including the module name.
A: What the module does when loading is really dependent on the module implementation itself. It should be described in the module documentation (accessible through the Help menu). A message appears in the moodss main window message area when each module is loading. Note that this message can be fugitive even if the module initialization takes a while and the module does it in the background (as it should so that other modules get a chance to also initialize).
If there are any errors, they will be reported in the message area. I suggest opening the trace window or loading the trace module is you want to precisely keep track of those errors.
A: There are several ways:
A: Move it (as usual, using the internal window manager handles) into another page tab (wait until you see the drop black outline around the tab label to release the mouse button). The viewer can then be found in the upper left corner of the target page.
A: the internal implementation requires that reloading a module be done in 2 steps: unloading the existing module then loading it using the new options values. Those are not lost however (starting from moodss 17.6): they are reused when trying to load a new instance of the module from the File/Modules/Load dialog box.
A: If a dashboard file that is monitored by moomps (see files and directory parameters in the usage moomps documentation section), is:
A: Once the states are changed, the edit database dialog closed and the dashboard file saved using the File/Save menu, the moomps daemon sees that the file has been updated and reloads it, provided of course that the file is part of the files that the daemon is monitoring (see files and directory parameters in the usage section).
Thus such changes are taken into account quickly (depending of course on the monitoring poll time of the dashboard files, as described in the usage section).
A: I have successfully tested the following on a Red Hat Fedora Linux system:
# service canna start # (as root) $ export LC_ALL=ja_JP.eucJP XMODIFIERS=@im=kinput2 $ kinput2 -canna -xim & $ moodss
with the following software installed:
Then, for inputting Japanese text in say, a free text viewer, hit Shift-Space and type into the little window that appears near and below the insertion cursor.
A: Yes, as the following actual practicle example shows.
A webmaster faced the situation where its server became overloaded and started swapping after a while. Unable to log in, he could not determine the exact cause leading to that situation.
Building a dashboard including the cpustats, memstats, psbyname and psbyuser modules and using a simple SQLite file as a database storage mean helped find the problem. This dashboard was loaded by the moomps daemon on the web server and left running to capture data around the busiest periods. The SQLite file was then recovered from the web server and browsed from the moodss GUI on another computer.