[openi18n-im:01021] updated a bit and some patches

Hi,

I updated a patch to separate those clearly.

Here is the summary for new patches:
im-sdk-12.0.1-unix-domain-socket.patch
Although it depends on xmlconf patch, the socket file
shouldn't be created under /tmp, because of the security
reason. it should uses /var/run instead of.

im-sdk-12.0.1-iiimsf-disable-tcp.patch
Although it also depends on xmlconf patch, listening on tcp
should be disabled by default.

--
Akira TAGOH

diff -ruN im-sdk-r12_0_1-svn1891.orig/iiimsf/Makefile.am im-sdk-r12_0_1-svn1891/iiimsf/Makefile.am
--- im-sdk-r12_0_1-svn1891.orig/iiimsf/Makefile.am	2003-03-26 19:36:50.000000000 +0900
+++ im-sdk-r12_0_1-svn1891/iiimsf/Makefile.am	2004-09-01 15:04:29.258360982 +0900
 <at>  <at>  -1,4 +1,5  <at>  <at> 
 AUTOMAKE_OPTIONS = foreign
 SUBDIRS = lib src
-datadir = $(IMDIR)
-data_DATA = htt.conf
+
+confdir = $(XMLCONFDIR)
+conf_DATA = htt.xml.conf

[openi18n-im:01022] watchdog and daemonize

Hi,

I just wonder if htt is designed to run as a daemon. we have
a patch which calls daemon(3) to run it as a
daemon. although htt uses fork(2), it's to watch the process
of htt_server, but not to run it as a daemon.  We
encountered a problem which is related on this. on current
implementation of htt, the unknown options for htt is
nothing. instead, those is just passed through
htt_server. since htt is working as a deamon and/or watchdog
program, htt has no way to know if given options for
htt_server is the unknown or not. and people has no way to
know it from the terminal -- in our package, it's notified
to syslog, though

I don't know the details/history why htt is needed and why
we can't run htt_server directly. I suppose that majority of
daemonized program won't work without proper configuration
and/or something like that. so if something is wrong to get
working, exiting immediately is right behavior I
think. otherwise we should fix the unnecessary exit and keep
to stay there.

Regards,
--
Akira TAGOH

[openi18n-im:01023] Re: XML configuration

Sorry for the delayed response.

At Fri, 27 Aug 2004 14:14:17 +0900 (JST),
Akira TAGOH <tagoh <at> redhat.com> wrote:
> 
> >>>>> On 27 Aug 2004 09:09:25 +0800,
> >>>>> "JL" == Jacky Lau <jackylau <at> thizgroup.com> wrote:
> 
> JL> Should one LE (<module>) be appear more than once in different
> JL> <LanguageEngine> when LE can support different lang (like zh-cn, zh-tw)
> 
> Yes, in that case I have no changes in my proposal, which is
> based on openi18n-im:00884. for example, the Unit LE which
> supports a lot of locales will be:
>     <LanguageEngine lang="en">
>       <module path="/path/to/leif/unitle.so"/>
>     </LanguageEngine>
>     <LanguageEngine lang="he">
>       <module path="/path/to/leif/unitle.so"/>
>     </LanguageEngine>
>     <LanguageEngine lang="ar">
>       <module path="/path/to/leif/unitle.so"/>
>     </LanguageEngine>
>     ...
> 
> this configuration is used only the LE search order. so even
> if the same module in the differnt LanguageEngine appears,
> the number of the instances is same as before applying
> this change.

[openi18n-im:01024] Re: XML configuration

>>>>> On Sun, 05 Sep 2004 23:29:15 +0900,
>>>>> "MH" == MIYASHITA Hisashi <himi <at> meadowy.org> (宮下 尚:HIMI) wrote:

MH> Here is my proposal, which is described in Compact RELAX NG, DTD, and XSD format,
MH> attached to this mail.

MH> Major changes from Tagoh-san's proposal are as follows.

Well, I apologize that I forgot to notify the changes in the
implementations. please look at the sample xml file in the
patch for more details. the changes are:

- anything shouldn't be parsed like localhost:9010. it
  should be put into <hostname> and <port> -- perhaps
  IP address may be put in another directive like
  <address>. but I didn't do that. any comments?
- for consistencies, the filenames, like for the unix domain
  socket file should be put into <file>.
- described the directives for SSL.

MH> (1) First of all, we MUST define our own XML namespace for IIIMF configuration.
MH> (2) We should use uppercase for IIIMF if we use uppercases for other elements like "LanguageEngine".

It sounds reasonable.

MH> (3) IMO, we shouldn't treat document types for server configurations and language engine configurations
MH>     in a seprated way.  Of couser we can put configuration files themselves in different places but
MH>     also in this case, multiple document types will be confusing.  We can put them in the same document
MH>     element named "IIIMF".

[openi18n-im:01025] UnitLE - Indic Inscript keyboard layouts

Hi all

In the inscript keyboard layouts in UnitLE there are several mistakes 
where some of the characters are assigned to the wrong keys and some are 
missing altogether.
I am attaching a patch to correct this. Hope it can be committed to the src.
Please let me know if you need any clarifications

Thanks & regards,

Jatin

[openi18n-im:01026] Re: UnitLE - Indic Inscript keyboard layouts

Hi Jatin,

I've integrated your patch into trunk.

Thanks,
Sriram.

Jatin Nansi wrote:
> Hi all
> 
> In the inscript keyboard layouts in UnitLE there are several mistakes 
> where some of the characters are assigned to the wrong keys and some are 
> missing altogether.
> I am attaching a patch to correct this. Hope it can be committed to the 
> src.
> Please let me know if you need any clarifications
> 
> Thanks & regards,
> 
> Jatin
> 
> 
> ------------------------------------------------------------------------
> 
> diff -Naur im-sdk-r12_0_1-svn1891.org/leif/unit/dict/BENGALI/inscript.utf im-sdk-r12_0_1-svn1891/leif/unit/dict/BENGALI/inscript.utf
> --- im-sdk-r12_0_1-svn1891.org/leif/unit/dict/BENGALI/inscript.utf	2003-02-21
23:08:44.000000000 +1000
> +++ im-sdk-r12_0_1-svn1891/leif/unit/dict/BENGALI/inscript.utf	2004-09-06
17:32:32.947393944 +1000
>  <at>  <at>  -1,8 +1,8  <at>  <at> 

[openi18n-im:01027] Re: UnitLE - Indic Inscript keyboard layouts

Sriram Kallidaikurichi wrote:

> Hi Jatin,
>
> I've integrated your patch into trunk.
>
> Thanks,
> Sriram.
>
Hi Sriram,

Thanks for integrating the patch.
I wanted to ask about another patch which I had sent to the list 
sometime back (Subject of the mail: Phonetic module in UnitLE + patch 
for indic phonetic layouts). That patch provided phonetic keyboards 
using the ctim module. The languages and layouts were:  hindi - 
phonetic, gurmukhi - phonetic, bengali  - probhat (which is a phonetic 
layout) & gujarati - phonetic.
I know that there is a phonetic module which is probably going to 
provide similar functionality, but its disabled by default now. The 
phonetic layouts make it so much more convenient to type in Indic 
languages, so, can that patch also be committed to the trunk?

TIA
Jatin

> Jatin Nansi wrote:
>
>> Hi all
>>

Subject: [openi18n-im:01028] iiimgcf window status atom updating

[openi18n-im:01028] iiimgcf window status atom updating

Below is a patch to make the gtk im module update the
window status X atom also when status is attached-to-app.
This always programs watching windows to be imformed of
status events irrespective of status placement.

If this change is acceptable, shall I commit it to trunk?

Jens

2004-09-08  Jens Petersen  <petersen <at> redhat.com>

	* gtkimcontextiiim.c (status_callback): Update the status atom
	even when status is attached to application frame.

Index: iiimgcf/gtkimcontextiiim.c
===================================================================
--- iiimgcf/gtkimcontextiiim.c	(revision 1900)
+++ iiimgcf/gtkimcontextiiim.c	(working copy)
 <at>  <at>  -306,7 +306,10  <at>  <at> 
    else if ((current_setting_enabled &&
  	    current_setting.status_placement == ATTACH_TO_APP_FRAME) ||
  	   !current_setting_enabled)
-    status_window_set_text (context_iiim->status_window, utf8);
+    {
+      status_window_set_text (context_iiim->status_window, utf8);
+      im_context_switcher_set_status_text (context_iiim, utf8);
+    }
    else
      {
        status_window_set_text (context_iiim->status_window, "");

[openi18n-im:01029] Re: XML configuration

At Mon, 06 Sep 2004 18:52:50 +0900 (JST),
Akira TAGOH <tagoh <at> redhat.com> wrote:

> MH> Here is my proposal, which is described in Compact RELAX NG, DTD, and XSD format,
> MH> attached to this mail.
> 
> MH> Major changes from Tagoh-san's proposal are as follows.
> 
> Well, I apologize that I forgot to notify the changes in the
> implementations. please look at the sample xml file in the
> patch for more details. the changes are:
> 
> - anything shouldn't be parsed like localhost:9010. it
>   should be put into <hostname> and <port> -- perhaps
>   IP address may be put in another directive like
>   <address>. but I didn't do that. any comments?
> - for consistencies, the filenames, like for the unix domain
>   socket file should be put into <file>.
> - described the directives for SSL.

Although these changes are O.K. for me,
I doubt well-formalized and widely used convension like localhost:9010 should be
decomposed into unfamilier and redundunt XML form like
<hostname>localhost</hostname><port>9010</port>.
But, it might belong to some sort of taste.

> MH> (3) IMO, we shouldn't treat document types for server configurations and language engine configurations
> MH>     in a seprated way.  Of couser we can put configuration files themselves in different places but
> MH>     also in this case, multiple document types will be confusing.  We can put them in the same document
> MH>     element named "IIIMF".

[openi18n-im:01030] Re: XML configuration

>>>>> On Mon, 13 Sep 2004 01:17:19 +0900,
>>>>> "MH" == MIYASHITA Hisashi <himi <at> meadowy.org> (宮下 尚:HIMI) wrote:

MH> Although these changes are O.K. for me,
MH> I doubt well-formalized and widely used convension like localhost:9010 should be
MH> decomposed into unfamilier and redundunt XML form like
MH> <hostname>localhost</hostname><port>9010</port>.
MH> But, it might belong to some sort of taste.

Yes, but I just thought requiring any parser to separate the
hostname and the port number doesn't make sense.

MH> For now, I don't see any clear reason why we have to define other XML namespace
MH> for user configurations than that for server configurations.  If we have to
MH> independently update the document type for user and server configuration, certainly
MH> we should define XML namespaces for each of them.  Do you think it's really necessary?
MH> Is that going a little too far?

how about moving out the LE-specific configuration into the
XML configuration file, say?

MH> Yes, in my proposal, an ID is essigned to each LE configuration.

MH> IMHO, I don't think we should categorize Language Engines only by languages.  It's rather
MH> unnatural limitation.  Why do we have to impose users to sort out all LE configuration
MH> by language?  Besides it, it's also unnatural to define hotkey configurations for each
MH> LE module in <module> element.

Er, it's to determine the default LE per languages when
multiple LEs which supports same language was