On Thu, 17 Jun 2004, Jorge Arellano Cid wrote:
Sebastian,
On Tue, 15 Jun 2004, Jorge Arellano Cid wrote:
When a_Interface_entry_open_url is called in this case, gtk_editable_get_chars returns an empty string, it seems that the "real" copying of the selection in Interface_entry_paste_selected is somehow delayed. As workarounds, I see two possible solutions:
1. Also queueing our code in an idle function. The attached patch demonstrates this successfully, although it has to be cleaned up (in some cases, the active idle function has to be removed again).
2. Calling a_Interface_entry_open_url directly with the contents of the selection. (But how do I get the latter?)
The safe way to get 2) is to call a_Nav_push from the callback, and not to worry about a_Interface_... functions. That way, the selection is handled as a link.
The only glitch is that the entry is not inmediately changed, but the stop button will serve as feedback (it shows activity).
Oh, later I realized that this is not enough to solve the problem, because there's a race condition if the selection is not retrieved by catching the "selection_received" signal.
Now I have some code that does this and will commit after some polishing.
Done.
PS: Is there anyone using a 2.6.x linux kernel? I tried it yesterday and viewing directory listings with dillo was painfully slow. So I developed a patch for this, but I'm surprised noone complained!
and Done. Now the copy&paste into the "clear URL" button works by catching the "selection_received" signal. It was very hard to find out how its done because the GTK+ docs are incomplete, the GDK ones recommend using Xlibs directly (or the GTK API), and the example code in the GTK+ has the wrong parameters. The GDK sources shed some light. With regard to 2.6.x linux, it was a matter of adding some buffering, a stream transfer instead of FD was enough. Cheers Jorge.-