Hi, On Mon, Jun 27, 2011 at 09:49:21PM +0800, Aron Xu wrote: > On Mon, Jun 27, 2011 at 21:21, Osamu Aoki <os...@debian.org> wrote: > > HI, > > > > On Mon, Jun 27, 2011 at 11:10:24AM +0800, Aron Xu wrote: > >> Package: im-config > >> Severity: wishlist > >> > >> I am the maintainer of fcitx related packages, and planning to switch > >> to im-config from im-switch. > > > > Good. > > > >> The upcoming upstream release of fcitx > >> will have fbterm support, and fcitx itself will be highly modularized > >> hence itself won't depend on any X or gtk packages. But im-config > >> depends on zenity, which depends on X and libgtk, will force fcitx > >> pulling in those dependencies if I replace im-switch with it, this > >> would be unacceptable for those people who only use fcitx-fbterm. > > > > Actually, this was bug on my part. I meant to do: > > > > Depends: zenity | dialog, ${misc:Depends} > > > > If one of it exist, this program work as configuration tool. > > > > If it finds zenity, it uses zenity over dialog. > > > > This way is great, too.
Fixed in git. > >> There are two ideal ways to resolve the problem: > >> 1.downgrade zenity to Recommends, this is the easiest way > >> 2.provide two packages from im-config, one depends only on dialog, > >> another depends on zenity. > > > > But I do not understand "fcitx itself will be highly modularized > > hence itself won't depend on any X or gtk packages." > > > > You do not need to use "DEPENDS" for im-config. Just "Recommends" is > > good enough. People may configure any way they wish to start it. Thus > > this recommends should come from something like fcitx-x. So installing > > fcitx-fbterm only should not pull in even as recommend. > > > > I had a short conversation with the ibus maintainer this morning, > about whether uses Depends or Recommends. Personally I like the idea > of setting it in Recommends. > > Currently ibus sets im-config as Depends because the maintainer think > it would be best if users could have ibus out-of-box after > installation, but there are some feedbacks complaining the dependency > is too strong. > > fcitx is still using im-switch, in its Recommends field. But I'm still > not sure about how to split the packages now, because upstream has > done numerous changes to make it another input method framework. > > > Please note, script hook of im-config / im-switch is in X start up code. > > I see. > > > Since I do not know how stadard start up code should be for fbterm, I > > can not extend im-config to support fbterm. Any suggestion is welcome. > > > > I'll investigate and give feedback to you, as I am also the maintainer > of ucimf in Debian, I should be the person who desires this feature > the most, ;-) As I see fcitx, it is only supported via xim. --- # start fcitx # vim: set sts=4 expandtab: # start fcitx daemon /usr/bin/fcitx & # set variables for the plain XIM XMODIFIERS=@im=fcitx GTK_IM_MODULE=xim QT_IM_MODULE=xim --- If it can use other values for GTK_IM_MODULE QT_IM_MODULE like gcin, we can update im-config default script. (For im-switch you need to provide the equivalent inside fcitx package.) gcin.im is: --- # start gcin # vim: set sts=4 expandtab: # start gcin daemon /usr/bin/gcin & # set variables for the plain XIM XMODIFIERS=@im=gcin GTK_IM_MODULE=xim # use immodule when available for GTK for IM_CONFIG_MARKER in /usr/lib/gtk-2.0/*/immodules/gcin.so ; do if [ -e $IM_CONFIG_MARKER ]; then GTK_IM_MODULE=gcin fi done QT_IM_MODULE=xim # use immodule when available for QT for IM_CONFIG_MARKER in /usr/lib/qt3/plugins/inputmethods/libqgcin.so /usr/lib/qt4/plugins/inputmethods/im-gcin.so ; do if [ -e $IM_CONFIG_MARKER ]; then GTK_IM_MODULE=gcin fi done --- Basically, gcin use access via xim if there is no IM_MODULE. If there are IM_MODULE, it uses them. Once you finish your package, let's discuss what is the desired start up code for it. > > See code at: > > Vcs-Git: git://git.debian.org/git/collab-maint/im-config.git > > Vcs-browser: http://git.debian.org/?p=collab-maint/im-config.git > > > > Anyway, how soon I should fix this? > > > > No hurry, I think anytime before August is okay. OK. Maybe, we include updated start up code :-) > > -- > Regards, > Aron Xu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org