Some other related point: I don't understand the HAVE_XIM check! If I
see the dependency in configure.ac:891, I just see it tests existence of
XRegisterIMInstantiateCallback in Xlib. But this function seems a normal
X11 function to me!
http://www.xfree86.org/current/XRegisterIMInstantiateCallback.3.html
If I look the man XRegisterIMInstantiateCallback, I don't see anything
special about it which seems to say it is separate from the rest of the
Xlib.
As I saw it was taken from the xterm code, I downloaded it, and the
Patch #176 of the release notes says about this:
"broaden ifdef for XRegisterIMInstantiateCallback() from patch #175
(XIM fix) to exclude non-XFree86 (report by Nelson Beebe indicates this
breaks for Solaris, IRIX and OSF/1)."
In xterm's code, it is explained this way:
/* limit this feature to recent XFree86 since X11R6.x core dumps */
So apparently I am not sure to understand everything, but it protects
something in recent XFree86. Yet it is not about all the IM functions!
Only about the specific XRegisterIMInstantiateCallback() function. In
the whole xterm code, this ifdef is used only 3 times, and only for very
small piece of codes around this function.
Moreover it is not defined as any kind of dependency (as we do in
mrxvt), but in the code itself, depending on the version of the XFree:
#if defined(XtSpecificationRelease) && XtSpecificationRelease >= 6 &&
defined(X_HAVE_UTF8_STRING)
#define USE_XIM_INSTANTIATE_CB
Hence I think the optional dependency "--enable-xim" in mrxvt's code
must be removed, and we should simply add a similar #define in our code
as there is in xterm's, but only around this function. Moreover I think
one of our user encountered this bug once, because mrxvt's code has this
(init.c:1616):
/* To avoid Segmentation Fault in C locale: Solaris only? */
if (STRCMP(r->h->locale, "C"))
XRegisterIMInstantiateCallback(r->Xdisplay, NULL, NULL,
NULL, rxvt_IM_init_callback, NULL);
As a conclusion --enable-xim is only a dummy option because it is
enabled in all Xlib, it is not an option there, and it prevents me from
efficacely use the X functions I need.
Hence I will try to remove it at least in the utf8 branch. Then if
someone tests this against Solaris or else in some future, probably he
will tell us if this causes any issue.
Jehan
P.S.: I have not look everything about --enable-cjk option and if it has
any specific function, but as far as I could see, and especially looking
at configure.ac:1065:
if test "x$support_cjk" = "xyes"; then
AC_DEFINE(MULTICHAR_SET, [], [set CJK multichar set support])
AC_DEFINE_UNQUOTED(MULTICHAR_ENCODING, "$encoding_option", [default
encoding])
fi
It really looks like a useless test with nothing specific at all. In the
implementation design I made for adding utf8, I don't do any difference
between MULTICHAR or NO MULTICHAR. I use a generic design for all
charmaps. Hence I will also remove MULTICHAR_SET and MULTICHAR_ENCODING,
thus --enable-cjk as well.
As a simple example of all this breaks the current working of mrxvt:
currently there is a locale test only when there is MULTICHAR_SET, so
only when there is --enable-cjk!!! So whatever you use as a locale, if
you did not enable this option for "chinese, japanese and korean", I
won't have any charmap detection and just fall back to
rxvt_decode_dummy. So there is no difference between all existent 8-bit
european charmap for mrxvt. Cf. xdefaults.c:1474 :
#ifdef MULTICHAR_SET
if (r->h->rs[Rs_multichar_encoding])
rxvt_set_multichar_encoding(r, r->h->rs[Rs_multichar_encoding]);
else
{
char* enc;
if (NOT_NULL(enc = rxvt_get_encoding_from_locale (r)))
rxvt_set_multichar_encoding (r, enc);
else
rxvt_set_multichar_encoding(r, MULTICHAR_ENCODING);
}
#endif
-> the only place where rxvt_get_encoding_from_locale is called is this
place for multichar encoding!
Jehan
Jehan a écrit :
> Hello,
>
>
>
> Gautam Iyer a écrit :
>> The HAVE_LIBX11 is a real dependency. See configure.ac:873 for the lines
>> that generate it. They die if the library is not found.
>>
>> Any references to HAVE_LIBX11 in the code can safely be removed, or
>> replaced with
>>
>> #ifdef HAVE_LIBX11
>> /* code here */
>> #else
>> # error "Mrxvt needs libX11 to compile (and run)"
>> #endif
>>
>
> Ok perfect for the X11 lib knowing it is mandatory! I was just getting
> tired of thinking there was some other way for mrxvt to run than X and
> having to look for alternate method for all these other ways! :p
>
> If you don't mind, rather than making your "complicated" #ifdef #else, I
> would rather remove all "HAVE_LIBX11" reference. As it is a real
> mandatory dependency, user must have it, and they won't be able to pass
> the configure state anyway (and even by somehow bypass it, it will fail
> at the include). So for readability, and avoiding developers (like me!)
> to wonder stupidely "is X optional for mrxvt?", I will just use all the
> X function directly (at least the one which must be in all X versions).
>
>> Feel free to use any function in libX11. I'm 99% sure you can also use
>> libXext. At any rate, if there's some library you want to use functions
>> from (for UTF8 support) feel free -- Just be sure you #ifdef the code,
>> so that people without the library are not forced into installing it.
>>
>
> Yes, of course, if I use an optional method. But I will try to avoid
> such as much as possible (making ten methods with ifdef for each step is
> really boring and hard to maintain code, at least I think).
> For the libXext, I did not know it, I will have a look.
>
> Jehan
>
>> GI
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Materm-devel mailing list
>> Materm-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/materm-devel
>> mrxvt home page: http://materm.sourceforge.net
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Materm-devel mailing list
> Materm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/materm-devel
> mrxvt home page: http://materm.sourceforge.net
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Materm-devel mailing list
Materm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/materm-devel
mrxvt home page: http://materm.sourceforge.net
