Bug 39242 - no easy way to wait until uim-xim is ready
Summary: no easy way to wait until uim-xim is ready
Status: RESOLVED INVALID
Alias: None
Product: UIM
Classification: Unclassified
Component: bridge: XIM (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: uim-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-14 18:26 UTC by d+bugzilla
Modified: 2012-10-23 11:36 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
patch to replace "unrealize" with "destroy" (846 bytes, patch)
2012-04-21 19:32 UTC, Muneyuki Noguchi
Details | Splinter Review
non-sleep version of /usr/share/im-config/data/24_uim.rc (1.69 KB, text/plain)
2012-04-21 19:34 UTC, Muneyuki Noguchi
Details
patch for /usr/share/im-config/data/24_uim.rc (613 bytes, patch)
2012-04-21 20:08 UTC, Muneyuki Noguchi
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description d+bugzilla 2011-07-14 18:26:37 UTC
[ this is forwarded from http://bugs.debian.org/300486 ]

When using loading uim-xim and another program that needs to use it one
right after the other (e.g. in an .xsession) programs started after
uim-xim but before uim-xim is ready to service them can't use uim.

This comes up for me if I try to make an .xsession that looks something
like this:

uim-xim &
xterm

The xterm loads up after uim-xim has been started, but before it's ready
to accept connections from XIM clients. I can fix this by doing:

uim-xim &
sleep N
xterm

Where N=1 on most machines (like this one, a new amd64), but N=2 or 3 on some
really slow machines (notably, a heavily loaded PII-450 I have, so we're not
just saying hypothetically!)

It would be nice if there were an option to/wrapper for uim-xim that
allowed it to daemonize itself and only return to the caller when it was
not only daemonized, but actually ready to accept XIM clients. Then the
proposed .xsession could be something like:

uim-xim --daemonize
xterm

And everything would work nicely. =)

--------------------------------------------------

I was facing problem of starting uim-toolbar-gtk just like this bug
report.

My workaround of not really waiting ...

Wait short --> uim-toolbar-gtk does not work
---
uim-xim &
sleep 1
uim-toolbar-gtk &
----

Waiting long --> uim-toolbar-gtk works
---
uim-xim &
sleep 10
uim-toolbar-gtk &
----

Waiting smart --> uim-toolbar-gtk works
---
uim-xim &
(sleep 10 ; uim-toolbar-gtk ) &
----

So if the original bug reporter wishes xterm to start a bit later, there
is a decent work around which does not really slow down X start up. 

--------------------------------------------------

Xlib provides the way to do this, which is XRegisterIMInstantiateCallback.
It is up to clients to decide what should be done when an IM server is not
available.

--------------------------------------------------
Comment 1 Muneyuki Noguchi 2012-04-21 19:32:09 UTC
Created attachment 60438 [details] [review]
patch to replace "unrealize" with "destroy"

I'm not sure what you want, but if you want to remove "sleep" from a rc file in im-config, this patch should work.
Comment 2 Muneyuki Noguchi 2012-04-21 19:34:42 UTC
Created attachment 60439 [details]
non-sleep version of /usr/share/im-config/data/24_uim.rc
Comment 3 Muneyuki Noguchi 2012-04-21 20:08:05 UTC
Created attachment 60440 [details] [review]
patch for /usr/share/im-config/data/24_uim.rc

This patch for /usr/share/im-config/data/24_uim.rc
 * removes the sleep command
 * replaces uim-toolbar-qt with uim-toolbar-qt4
 * adds a space just before `]' (2 places)
Comment 4 Muneyuki Noguchi 2012-04-24 08:53:31 UTC
I found that the uim helper applications (uim-toolbar-gtk-systray, uim-toolbar-gtk and uim-toolbar-qt4) aren't releated to the issue the original reporter mentioned in Debian BTS because the helper applications don't require uim-xim to launch (at least as for uim 1.8.0). Actually, when the 2 patches above are applied, even in my old box with 266MHz (not 2.66GHz) CPU, uim-toolbar-gtk-systray was successfully shown in a notification area without a sleep command. You can make sure that they don't require uim-xim by killing xim-uim and launch one of them:
    $ killall uim-xim
    $ uim-toolbar-gtk

In my environment, the patch for uim-toolbar-gtk-systray is needed because
without it, a uim-toolbar-gtk-systray process becomes a zombie (defunct) after
login because systray_unrealize_cb() is called during a login process.

FYI, for im-config, I filed 2 bug reports in Debian BTS.
Comment 5 d+bugzilla 2012-04-25 04:56:37 UTC
> I found that the uim helper applications (uim-toolbar-gtk-systray,
> uim-toolbar-gtk and uim-toolbar-qt4) aren't releated to the issue the original
> reporter mentioned in Debian BTS because the helper applications don't require
> uim-xim to launch (at least as for uim 1.8.0). Actually, when the 2 patches
> above are applied, even in my old box with 266MHz (not 2.66GHz) CPU,

Ah, I just understood.  I was confused what needed sleep command.

> uim-toolbar-gtk-systray was successfully shown in a notification area without a
> sleep command. You can make sure that they don't require uim-xim by killing
> xim-uim and launch one of them:
>     $ killall uim-xim
>     $ uim-toolbar-gtk

I tested in 1.5.7, 1.7.3 and 1.8.0, and confirmed.
So, I will ask we can get rid of sleep commands from Debian im-config.

> In my environment, the patch for uim-toolbar-gtk-systray is needed because
> without it, a uim-toolbar-gtk-systray process becomes a zombie (defunct) after
> login because systray_unrealize_cb() is called during a login process.
> 
> FYI, for im-config, I filed 2 bug reports in Debian BTS.

Thank you for your reporting.

BTW, below, original report in Debian BTS, is still reproducible in 1.8.0.

	$ killall uim-xim
	$ uim-xim & xterm # <-- cannot use uim-xim in this xterm.

	$ killall uim-xim
	$ uim-xim & sleep 5 ; xterm # <-- can use uim-xim in this xterm
--
Comment 6 d+bugzilla 2012-10-23 11:36:09 UTC
im-config 0.18 does not need sleep anymore.
So I cancel this bug report.
Thank you.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.