Re: [gtk-list] Re: [patch] support XIM

[matsu arch comp kyutech ac jp (Takashi Matsuda)]

In article <lzpvo5xzs6.fsf@cu-dialup-0302.cit.cornell.edu>
owt1@cornell.edu writes:

>> 
>> matsu@arch.comp.kyutech.ac.jp (Takashi Matsuda) writes:
>> 
>> > Feature:
>> >   Followings are the main feature of this patch.
>> > 	* support XIM protocol.
>> > 	* GtkEntry widget support Over-The-Spot and Root style input.
>> > 	* input style is configurable by command-line option.
>> 
>> Very nice! I thought about writing such support but I didn't
>> really know enough about it (and it seemed pretty complex.)
>> 
>> I've tried it out a bit, and I can input Japanese text using kinput2,
>> but I closing the window afterwards causes the program to hang. (It
>> might possibly be a problem with my mainloop patch.)  I'll try to
>> figure out what is going on when I get the time.  (maybe over the
>> weekend). Displaying characters stills seems a bit rough as well.

I'm sorry I've forgotten to mention this problem. This is bug of kinput2.
Please use newer one. I found it at
	http://tateyama.comp.toyama-u.ac.jp/~miyake/
and I'm using kinput2-v2-fix3-UOP1.tar.gz though there is more newer.

>> 
>> Just a few comments about your patch - it mostly looks very good:
>> 
>> * You've made all your changes as
>> 
>> #if 1
>> [ new stuff ]
>> #else
>> [ old stuff ]
>> #endif
>>
[snip]

I see.


>> * The --xim-preedit and --xim-status arguments are very complicated.
>>   I don't really understand XIM very well, but are all these options
>>   really useful for the user?

For me, this option is not so complicated. But I think it is good to add
more abstruct and easy-to-understand option like Xaw and Motif.


>> 
>> * You've added the bindings
>>   C-h and M-h as delete-backward-character and delete-backward-word
>>   to the entry widget. Are these standard bindings? (The functionality
>>   is already there as Backspace and C-w.) There's a good reason not to 
>>   add every possible key binding - unrecognized keys should be let 
>>   propagate to the toplevel window so they can act as shortcuts.
[snip]

In general, I agree that it is not good to add binding every time someone want.
But, readline (tcsh, bash), motif, tk, and vim has these bindings.
I think these bindings are de facto standard.


>> > 	* copy and paste with other clients by compound text.
>> 
>> (In gtkentry.c)
>> +	  gtk_selection_convert (widget, GDK_SELECTION_PRIMARY,
>> +				 ctext_atom, event->time);
>> 
>> This breaks pasting selections from other clients that don't support
>> the COMPOUND_TEXT target. Of course, some programs, like rxvt,
[snip]

I apporogize. I've known this, but to deal with this problem,
I think I must change code radically.


>> Returning the type as TEXT is illegal. I don't see why we should
>> assume that the selection owner meant STRING. I think this
>> response should be ignored, as if the selection owner had responded
>> with some other inappropriate type. (On the other hand, if there
>> are actually programs out there that behave in this broken manner,
>> than it might make sense to support such behavior).
[snip]

In my first patch, only COMPOUND_TEXT is required. But if selection_recieved
is fixed as you mentioned before, TEXT becomes legal, doesn't it?


>> > 	* gtk_selection_owner_set calls gdk_selection_owner_set as well
>> > 	  new owner and old owner is same (but does not send selection_clear
>> > 	  event).
>> 
>> I'm not quite sure I understand. Why do you want
>> gdk_selection_owner_set to be called when the widget isn't changed?  I
>> suppose it does change the timestamp, but is this needed?
>> (I'm not saying that this change isn't right, I just would
>> like to understand why.)
>>

Please run two testgtk and open one entry window respectively, then
copy and paste diverse strings between two entries.
Without patching, re-selection does not change the string to copy.


                                  -Takashi Matsuda
                                   matsu@arch.comp.kyutech.ac.jp