Description of problem: SCIM won't save the trigger hotkey. Version-Release number of selected component (if applicable): scim-1.4.4-9.7.fc5.i386
It does for me: can you explain the exact steps you take so that I can to reproduce?
Sure: click System->Preferences->More Preferences->SCIM Input Method Setup click Global Setup click the '...' button next to Trigger click the '...' button next to Key Code press and release Ctrl-Alt-s click Add click OK click OK click OK click System->Preferences->More Preferences->SCIM Input Method Setup click Global Setup notice that the input field next to Trigger is empty again, and that Ctrl-Alt-s does nothing
I can't reproduce this. Do you have scim running when you're doing this? Note if scim is running you can run setup from scim command menu by pressing the Right button on the scim icon in the systray or on the toolbar.
I can reproduce this but in a different way. I got FC5 scim and tried to use shared input mode. After SCIM restart, all of the hotkeys configuration are emptied and I couldn't customize any keys (the fields keep in empty). I cannot reproduce it again nor I can reset the default setting. Not sure if this is if it is the same problem but it is pretty serious.
BTW the saved config setting can be checked with: grep /Hotkeys/FrontEnd/Trigger ~/.scim/config
I can produce this partly. The "Trigger" item is empty in the setup panal after I setup trigger key "Ctrl+Alt+s" by the way above. But I can active or deactive scim by "Ctrl+Alt+s" after I setup and there is /Hotkeys/FrontEnd/Trigger = Control+Alt+s" in ~/.scim/config file. Seems it is a bug here.
I can produce this partly. The "Trigger" item is empty in the setup panal after I setup trigger key "Ctrl+Alt+s" by the way above. But I can active or deactive scim by "Ctrl+Alt+s" after I setup and there is /Hotkeys/FrontEnd/Trigger = Control+Alt+s" in ~/.scim/config file. Seems it is a bug here. I will research it in more detail soon.
Yup, reproduced on FC5. (Comment 4 was for rawhide.)
I find if I use "make" and "make install" install scim from source code, this problem is gone. Yet if I use rpm(whatever locale build or brew build), this problem will show up. I wonder if this is the problem of spec file of rpm.
To clarify much more, when you've tried "make" and "make install", have you applied all the patches are available on srpm? or just from an original tarball without any patches?
I think I applied all the patches on srpm. Because I downloaded scim-1.4.4-9.7.fc5.src.rpm and run "rpm -ivh". And then I enter SPECS directory run "rpmbuild -ba scim.spec", enter "BUILD" directory and scim source code directory runing "./configure","make" and "make install".
I tried building without libstdc++so7 and that seemed to fix the problem, which would agree with comment 12 also.
Also rebuilding the current scim package against libstdc++so7-4.2.0-0.3.20060203.2 makes the problem go away for me. I'm wondering if this problem may already have been fixed upstream in current 4.2. Benjamin?
Here is some gdb output from the setup config module (scim/modules/SetupUI/scim_frontend_setup.cpp (load_config)) which may shed some more light on the problem. [ __config_keyboards [0] is the data for the main scim trigger key] With the older snapshot: (gdb) p __config_keyboards [0].data $1 = {<__gnu_cxx::_7_20060203::__rc_string<char,std::_7_20060203::char_traits<char>,std::_7_20060203::allocator<char> >> = {<__gnu_cxx::_7_20060203::__string_utility<char,std::_7_20060203::char_traits<char>,std::_7_20060203::allocator<char> >> = {<No data fields>}, static _S_empty_rep = {<__gnu_cxx::_7_20060203::__rc_string<char,std::_7_20060203::char_traits<char>,std::_7_20060203::allocator<char> >::_Rep> = {{ _M_info = {_M_length = 0, _M_capacity = 0, _M_refcount = 8}, _M_align = 0 '\0'}}, _M_terminal = 0 '\0'}, _M_dataplus = {<std::_7_20060203::allocator<char>> = {<__gnu_cxx::_7_20060203::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x850e16c "Control+space,Zenkaku_Hankaku,Alt+s"}}, static npos = 4294967295} And the current one: (gdb) p __config_keyboards [0].data $3 = {<__gnu_cxx::_7_20060428::__sso_string<char,std::_7_20060428::char_traits<char>,std::_7_20060428::allocator<char> >> = {<__gnu_cxx::_7_20060428::__string_utility<char,std::_7_20060428::char_traits<char>,std::_7_20060428::allocator<char> >> = {<No data fields>}, _M_dataplus = {<std::_7_20060428::allocator<char>> = {<__gnu_cxx::_7_20060428::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x93cf6e8 ""}, _M_string_length = 0, { _M_local_data = "#\000\000\000rol+space\000\000", _M_allocated_capacity = 35}}, static npos = 4294967295} I don't know enough about the string implementation but naively it looks like the string with the newer snapshot isn't right.
Yes. Some of the string configuration did change with this release of libstdc++-so7. Specifically, I changed from rc string to sso string in GLIBCXX_ENABLE_STRING. I've attached a patch to revert this change. You'll need to apply it, and then re-generate the auto* files in the libstdc++ directory. You do this by typing "autoreconf" in the base libstdc++-v3 directory. If you have done it correctly, then during configure you should see: ... checking for std::basic_string base class to use... rc .... -benjamin
Created attachment 133090 [details] change default std::string to rc
Okay thanks, it seems easier for me to pass "--enable-libstdcxx-string=rc" to configure.
Ok that works. However scim needs to be rebuilt against the fixed libstdc++so7... Since the update breaks ABI I guess it makes sense to change the library version. How about s/20060428/20060428_1/?
Created attachment 133126 [details] package changes Here is a patch that implements the changes. Does it look all right?
Hey Jens. Yes, you can get where you need to go with the configure option too, and that's definitely easier. For the library version, just stick to the date thing. Ie: s/20060428/20060728/
Ok - one last question: should the date in libstdc++-v3-so7-version.patch be changed to 20060728 too or left at 20060428?
Yes please.
4.2.0-0.3.20060428.fc5.3 has been built for this.
scim-1.4.4-1.4.4-9.8.fc5 built
All the fc5 scim IMEs have been rebuilt.
libstdc++so7-4.2.0-0.3.20060428.fc5.3 scim-1.4.4-9.8.fc5 scim-anthy-1.2.0-1.fc5.1 scim-chewing-0.2.1-5.3.fc5 scim-hangul-0.2.2-2.fc5.1 scim-m17n-0.2.0-2.2.fc5 scim-pinyin-0.5.91-4.5.fc5 scim-tables-0.5.6-3.2.fc5 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
(In reply to comment #15) > I don't know enough about the string implementation but naively it looks > like the string with the newer snapshot isn't right. Naively, I don't think you can say much from this tiny bit of info: in *both* cases the length is zero (called, either _M_length or _M_string_length). In my opinion, using v7 with rc-string is pointless (besides special benchmarking purposes): if really there are problems, should be pinpointed, a reduced testcase prepared, and fixed.
(In reply to comment #28) > Naively, I don't think you can say much from this tiny bit of info: in *both* > cases the length is zero (called, either _M_length or _M_string_length). I don't know about _M_length means, but the problem was in the actual string data in _M_p I think). > In my opinion, using v7 with rc-string is pointless Ok, I'm just the scim package maintainer and needed a working libstdc++so7 for it and so reverted to the previous working default string implementation. Perhaps another bug should be filed for the sso issue. > if really there are problems, should be pinpointed, > a reduced testcase prepared, and fixed. Perhaps it is already fixed in cvs? Probably it is worth trying. Benjamin how about a newer snapshot for fc6, if it is going to be included?
(In reply to comment #29) > (In reply to comment #28) > > Naively, I don't think you can say much from this tiny bit of info: in *both* > > cases the length is zero (called, either _M_length or _M_string_length). > > I don't know about _M_length means, but the problem was in the actual > string data in _M_p I think). If length is zero, the data you find is not meaningful, just random character that happen to be there, you cannot access past position 0! > > In my opinion, using v7 with rc-string is pointless > > Ok, I'm just the scim package maintainer and needed a working libstdc++so7 > for it and so reverted to the previous working default string implementation. > Perhaps another bug should be filed for the sso issue. A few punctualizations: 1- The *default* string in v7-branch is sso-string; 2- If that string really doesn't work, for some reason, v7 should not be used at all, in my opinion. It's something you have to check at the outset. rc-string isn't really meant for normal use, just for benchmarking purposes! > > if really there are problems, should be pinpointed, > > a reduced testcase prepared, and fixed. > > Perhaps it is already fixed in cvs? Probably it is worth trying. Who knows? Frankly, being the author of sso-string, I'm skeptical, but, really, who knows? We ***badly*** need a reduced testcase and/or meaningful debugging info. Note that in v7 there is at least another new thing, simulated move semantics, which interacts in delicate ways with the new sso-string, in particular when containers are involved (containers of strings), otherwise, sso-string per-se is already well tested and well performing together with the rest of the v6 library and mainline compiler (power users tell me that ;) To repeat, I find simplistic just switching to rc-string in this way: v7 is a complex beast, which should be used in experimental environments, carefully tested, possibly *fixed* for real, and only eventually deployed.
(In reply to comment #30) > If length is zero, the data you find is not meaningful, just random character > that happen to be there, you cannot access past position 0! Ok :) I'm just a user and the string length in the case above should be non-zero in the app anyway. > A few punctualizations: 1- The *default* string in v7-branch is sso-string Okay - for the earlier snapshot we used this was not the case afaik. > 2- If that string really doesn't work, for some reason, v7 should not be used at > all, in my opinion. It's something you have to check at the outset. rc-string > isn't really meant for normal use, just for benchmarking purposes! The decision to use v7 for scim was not taken lightly, but pragmatically to help work around weak symbol conflicts when used with 3rd party gtk apps built with v5. > > > if really there are problems, should be pinpointed, > > > a reduced testcase prepared, and fixed. > We ***badly*** need a reduced testcase and/or meaningful debugging > info. Okay, I would like to help with that but have little time right now. If you install the previous scim packages on fc5 and it is rather easy to reproduce fwiw. > Note that in v7 there is at least another new thing, simulated move > semantics, which interacts in delicate ways with the new sso-string, in > particular when containers are involved (containers of strings), otherwise, > sso-string per-se is already well tested and well performing together with the > rest of the v6 library and mainline compiler (power users tell me that ;) To > repeat, I find simplistic just switching to rc-string in this way: v7 is a > complex beast, which should be used in experimental environments, carefully > tested, possibly *fixed* for real, and only eventually deployed. Okay, I see. Could you please open another bug against fc devel about this and we should fix that.
Hmm, so perhaps it may also be a scim bug... Anyway I'm building libstdc++so7-4.2.0-0.10.20060428.fc6 now which reverts to the default sso string implementation. But I really don't want to do that for fc5 until I know how to fix any problem with scim though. Apologies for the trouble.
An additional remark on my part: modulo gdb weirdness, as usual, the *rc-string* data seems actually inconsistent: the length is zero, still a string is printed, meaning there isn't a terminal '\0' in position zero, which should be always there. there. Thus, a possibility would be that scim is working fine "by chance" together with rc-string. It's even possible that some kind of memory corruption is taking place. Really, we need a lot more debug info in order to properly understand what the heck is going on...