Re: back/x11 XIM fix [was: Re: Gworkspace with non-fragile abi, etc?]

2013-08-23 Thread David Chisnall
On 22 Aug 2013, at 22:12, Ivan Vučica  wrote:

> On 22. 8. 2013., at 05:03, "Lee, Seong-Gu"  wrote:
>> 
>> PS) Additonally in my opinion as non-developer about FIXME, it had
>> better leave with X system because resetting locale might affect other
>> applications.
> 
> setlocale() will affect only the current process, afaik.

The setlocale() call with "" as the argument will set the locale for the 
current process to the locale of the environment.

This is a really messy bit of POSIX where locale awareness had to be 
retrofitted without breaking code that required the C locale.  Ideally, it 
would have been implemented with symbol versioning and some tricks to say that 
if your code is locale-aware then it uses the locale-aware versions of 
functions and defaults to the one specified in the environment, otherwise it 
would use different versions of the functions without locale support.  Solaris 
libc works like this (and has some really crazy code to support it).  If you're 
writing a locale-aware library, there is no sensible place for the call to go.  
Ideally, I think we should put it in the start of NSApplicationMain(), and 
require anything that uses -gui / -back to make the call explicitly if it isn't 
using NSApplicationMain().

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: back/x11 XIM fix [was: Re: Gworkspace with non-fragile abi, etc?]

2013-08-22 Thread Ivan Vučica
On 22. 8. 2013., at 05:03, "Lee, Seong-Gu"  wrote:
> 
> PS) Additonally in my opinion as non-developer about FIXME, it had
> better leave with X system because resetting locale might affect other
> applications.

setlocale() will affect only the current process, afaik.

Regards,

Ivan Vučica
via phone
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: back/x11 XIM fix [was: Re: Gworkspace with non-fragile abi, etc?]

2013-08-22 Thread Lee, Seong-Gu
On 08/22/2013 07:39 AM, Eric Wasylishen wrote:
> Hi,
> Thanks for the feedback. I'll just address this one question:
> 
>> 3) XIM at X11 backends
>> To input non-latin character at text box of gnustep applicaton, I tried
>> all XIM such as ibus, scim, uim, fcitx, but failed. After then, this
>> document was found:
>> 
>> Input ( http://wiki.gnustep.org/index.php/I18n )
>>NSTextInput protocol
>>NSInputManager
>> Current Status
>>Currently we use XIM. It is only available on systems that use the
>> X11 backends.
>> 
>> Default backend at linux seems to be cairo. Does not cairo backend
>> support XIM? When backend was changed into xlib, applications were not
>> excuted as failed to load true-type fonts.
>> Because direct keyboard input is not allowed, indirect and incomplete
>> copy-paste input is only available.
> 
> Yes, XIM should work with cairo (or any of the graphics backends, as long as 
> the window server backend is x11). However, it looks like I broke XIM support 
> over a year ago. :-( I just committed a fix for now: 
> 
>   * Source/x11/XIMInputServer.m: Add the setlocale(LC_CTYPE, "") call
>   back that I removed last year (r35152).
> 
>   I tested the fcitx input method, and without the setlocale call,
>   XOpenIM would fail. I'm not sure what the best plan is in the long
>   term, I wanted to avoid calling setlocale from the core frameworks
>   but in this case xlib seems to require it.
> 
> To test gnustep with fcitx, I ran:
> 
> export XMODIFIERS=@im=fcitx
> 
> in my shell before launching Ink, and then was able to press ctrl+space to 
> enter Chinese characters.
> 
> Could you try doing an svn update on core/back and see if the fix works for 
> you?
> 
> Cheers,
> Eric
> 
 Dear Eric,

 Thank you for your work.
 Sorry to late reply as testing took some time.
 Previously referred XIMs (ibus, scim, uim, fcitx) worked well after
gnustep-back update.
 Not all applications were not tested but applications of which main
work is text-input such as Ink, Typewriter, ProjectCenter, Gorm, GNUMail
AddressManager were tested. Especially Gorm for resources localizing
tool was so necessary that it is good to work.
 Thanks again.

 Lee, Seong-Gu ( gmail dot com )

PS) Additonally in my opinion as non-developer about FIXME, it had
better leave with X system because resetting locale might affect other
applications.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


back/x11 XIM fix [was: Re: Gworkspace with non-fragile abi, etc?]

2013-08-21 Thread Eric Wasylishen
Hi,
Thanks for the feedback. I'll just address this one question:

> 3) XIM at X11 backends
> To input non-latin character at text box of gnustep applicaton, I tried
> all XIM such as ibus, scim, uim, fcitx, but failed. After then, this
> document was found:
> 
> Input ( http://wiki.gnustep.org/index.php/I18n )
>NSTextInput protocol
>NSInputManager
> Current Status
>Currently we use XIM. It is only available on systems that use the
> X11 backends.
> 
> Default backend at linux seems to be cairo. Does not cairo backend
> support XIM? When backend was changed into xlib, applications were not
> excuted as failed to load true-type fonts.
> Because direct keyboard input is not allowed, indirect and incomplete
> copy-paste input is only available.

Yes, XIM should work with cairo (or any of the graphics backends, as long as 
the window server backend is x11). However, it looks like I broke XIM support 
over a year ago. :-( I just committed a fix for now: 

* Source/x11/XIMInputServer.m: Add the setlocale(LC_CTYPE, "") call
back that I removed last year (r35152).

I tested the fcitx input method, and without the setlocale call,
XOpenIM would fail. I'm not sure what the best plan is in the long
term, I wanted to avoid calling setlocale from the core frameworks
but in this case xlib seems to require it.

To test gnustep with fcitx, I ran:

export XMODIFIERS=@im=fcitx

in my shell before launching Ink, and then was able to press ctrl+space to 
enter Chinese characters.

Could you try doing an svn update on core/back and see if the fix works for you?

Cheers,
Eric
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev