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

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

In article <"4rVZt3.0.xt1.NSfQq"@mail2.redhat.com>
owt1@cornell.edu writes:

[snip]

>> > 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.
>> 
>> I suppose it's not that complicated - if you know the terminology.
>> I can't find the documentation I had around for XIM, so I'm rather
>> fuzzy myself, but does it really make sense for the user to change
>> the style of preedit? If the application doesn't support preedit
>> callbacks, then the user can't make it do so by setting a command
>> line option.
[snip]

I suppose, people use the best style widget support in usual case.
But I don't know no-one want this option.
One example I can think is that IM may have a bug in some style.
But in that case, style should be specified by rc file rather than command
line option.
I've plan this, but I'm not familiar with gtkstyle enough to write it.


>> > 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.
>> 
>> I can't speak to tk or vim, but my (fairly recent) version of 
>> readline doesn't have these bindings by default. A survey of three
>> Motif applications showed one (Netscape) supporting C-h, and none
>> supporting M-h. M-Backspace seems to be pretty standard for
>> backwards-delete-word functionality. It's not a big deal, but
>> it might be nice to leave M-h free for help.
[snip]

I think C-h is standard. But I added M-h binding because of only analogy.
I'll remove M-h from next release.


>> 
>> I don't think the changes should be that major - I think the way
>> I suggested shouldn't be too much work. (I hacked kterm to work
>> in that way a while ago, and it seems to work fine.)
>>  
>> > >> 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?
>> 
>> To quote from the ICCCM:
>>
[snip]

I'd misunderstood.
Is this correncted by simply removing TEXT from gtk_entry_*_recieved ?


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