We think it does not make much sense in the 'Accessories' menu, and now that ibus has support launching iok, that is a much better solution.
I will need feedback from few more peoples before removing iok desktop file from iok package. iok is not only supporting for inscript standard based map parsing but few other Indic keymaps which have 1:1 keymappings defined in .mim files. So, if iok run as "iok -a" one can get other functionalities also. We developed iok keeping in mind those functionalities are needed for end user to create their own custom keymap. But for now IMHO, I will like to see iok appearing in "Accessories". Is anyone looking into this bug can also provide their feedback?
I don't think removing the desktop file is really right. We still want to have it around for iok to show up in menu editors, e.g. Adding a NotShowIn=GNOME; would be good. > iok is not only supporting for inscript standard based map parsing but few > other Indic keymaps which have 1:1 keymappings defined in .mim files. > > So, if iok run as "iok -a" one can get other functionalities also. We developed > iok keeping in mind those functionalities are needed for end user to create > their own custom keymap. All this does not really change the fact that it is a very special-purpose tool and not at all an 'accessory'. It is really an input method tool, so it should be available through the input method ui.
(In reply to comment #2) > I don't think removing the desktop file is really right. We still want to have > it around for iok to show up in menu editors, e.g. Adding a NotShowIn=GNOME; > would be good. > > Sorry but I am confused now. So does this mean let the desktop file be installed but don't show it in menus for GNOME? > > iok is not only supporting for inscript standard based map parsing but few > > other Indic keymaps which have 1:1 keymappings defined in .mim files. > > > > So, if iok run as "iok -a" one can get other functionalities also. We developed > > iok keeping in mind those functionalities are needed for end user to create > > their own custom keymap. > > All this does not really change the fact that it is a very special-purpose tool > and not at all an 'accessory'. It is really an input method tool, so it should > be available through the input method ui. May I know finally what change should I do in iok package to fix this bug?
Sorry for being confusing. Here is what I proposed, in patch form: diff -up iok-1.3.7/iok.desktop.in.in.menus iok-1.3.7/iok.desktop.in.in --- iok-1.3.7/iok.desktop.in.in.menus 2009-10-15 13:39:52.977402262 -0400 +++ iok-1.3.7/iok.desktop.in.in 2009-10-15 13:40:05.226424957 -0400 @@ -8,3 +8,4 @@ StartupNotify=true Terminal=false Type=Application Categories=GNOME;GTK;Utility;Accessibility; +NotShowIn=GNOME;
Yes, agree - hiding makes sense and had been thinking the same.
Fixed in new build iok-1.3.8-1.fc12
it is available in rawhide and fixed