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

[Owen Taylor <owt1 cornell edu>]

> 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.

Ah. Makes sense.

> >> * 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.

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. 

> >> * 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.

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.

> >> > 	* 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.

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:

"The atom TEXT is a polymorphic target. Requesting conversion into
TEXT will convert into whatever encoding is convenient for the
owner. The encoding chosen will be indicated by the type of the
property returned. TEXT is not defined as a type, it will never by
the returned type from a selection conversion request"

The possibilites for return type are STRING, COMPOUND_TEXT, or
C_STRING (C_STRING is just a sequence of bytes, as opposed to
STRING which is defined to be ISO_LATIN_1)

> >> > 	* 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.

Hmmm, I see the problem. I think what is really going wrong here
is that, since the entry widget defines its own selection_clear 
handler, the default one is not being called. I suppose 
gtk_entry_selection_clear should call gtk_selection_clear. I'll have to
look closer at that later.

Regards,
                                        Owen