
        /**
         * <p>
         * If we want table1 and table2 to be able do DYNAMICALLY update
         * the GUK IM that we are editing - as handed over to EditIM() !
         * - then we must be able to:
         * remove an assignment of typeeventS to glyphS (KeystrokeParser!)
         * add an assignment of typeeventS to glyphS
         * ... which is troublesome as we have two arrays, and both do
         * contain stuff that cannot be easily represented by strings.
         * </p><p>
         * SOLUTION: give tables some handler through which it can call
         * removeAddKeymap(oldglyphs, oldevents, newglyphs, newevents)
         * where either old or new can be null and events are arrays or
         * Vectors of something machine-readable (KeyStroke or otherwise
         * prepared for GUK IM processing).
         * removeAddKeymap would be added directly to the GUK IM system,
         * as will be support for choice lists (if we add a glyph string
         * to an already defined (finite state machine) key sequence, GUK
         * IMs must be able to have a LIST, not a SINGLE output glyph
         * string, and have a USER INTERFACE that selects from the list).
         * </p><p>
         * TROUBLE: If adding all this to GUK is too much work, revert
         * to being able to read and write at least FILES of GUK IM and
         * MPI IM formats, plus possibly YUDIT and EMACS and others. This
         * could also mean that we do NOT extract table data from locales
         * that GUK has only in RAM - to keep things simple. We would use
         * IM that GUK (and MPI?) have in RAM in almost passive manner,
         * allowing the user to use them while editing (the tables),
         * selecting them through the hotkeys[] locale hotkeys. Client-
         * wise, we ARE a passive IM client in ALL cases. We only have
         * the GUK IM object open as a FSM coprocessor (*** rename the
         * THIS locale button if it turns out to be a problem to use the
         * dynamically changed IM for ourself, and just treat it as a
         * NORMAL locale button that holds the default locale, OR just
         * change the way the DOCUMENTATION refers to that button ***).
         * </p>
         */
        /**
         *  More GUK IM related: Have control for virtual keyboards,
         *  by the commands
         *  vkeyboard tracking (uses checked)
         *  vkeyboard [ctrl[- ]]?[shift[- ]]?[alt[- ]?]? (uses checked)
         *  ... which only make sense if we had some test text field
         *  or target (hint: the table editors!) that are active IM
         *  clients!? Well... IF we are a passive client AND can get a
         *  GUK control object, we could... BUT then, it would be best
         *  if GUK ITSELF had those menu items sticking to the first
         *  virtual keyboard, probably? Is it useful at all to spend so
         *  much room in showing several virtual keyboards apart from
         *  the currently active one for the normal GUK IM GUI? And for
         *  this editor? Okay, probably WE want to have the menu items,
         *  not GUK. Take care then, have the RIGHT control object for the
         *  GUK IM to which we ourselves are actually the passive client!!
         */
