In order to simplify the transition away from IIIMF for existing user profiles, gimlet should exit and remove itself from the GNOME panel if it runs with environment variables where IIIMF would not work anyway. Perhaps both GTK_IM_MODULE and XMODIFIERS should be examined in order to avoid disabling gimlet in corner-case situations like GTK_IM_MODULE=xim but utilizing IIIMF IM. Please examine the following two use cases and provide another demonstrative use case if this implementation suggestion fails in another corner case. Use Scenario #1 =============== 1. User upgrades to FC5 or RHEL5. 2. Login, GNOME panel still has gimlet. 3. gimlet runs, but exits because env vars contain SCIM instead of IIIMF. Use Scenario #2 =============== 1. User upgrades to FC5 or RHEL5. 2. Login, GNOME panel still has gimlet, but user profile explicitly points at iiimf in ~/xinput.d/ so IIIMF is still active. 3. Auto-profile migration wizard or explicit setting to SCIM. 4. Logout 5. Login, GNOME panel still has gimlet. 3. gimlet runs, but exits because env vars contain SCIM instead of IIIMF.
Tagoh and Jens came up with a use case where this fails: Run gimlet, and manually enable IIIMF input for a specific GTK+ application. Jens suggested a simple addition to this plan: If gimlet exits due to the env vars, create a file somewhere. If that file exists, then future runs of gimlet ignore the env vars and do not exit.