[Dillo-dev]Problems with the activation of the URL entry
Hi! The current CVS version is supposed to visit the URL in the selection, when the user clicks with the middle mouse button on the "clear URL" button. However, I got it once working (strangely), but currently it does not work. I use Gtk+ version 1.2.10. The function Interface_entry_paste_selected first copies the selection into the entry (as you see from the comment, I did not really understand the code), and then calls gtk_widget_activate, which emits the activation signal of the widget, which is "activate" for GtkEntry, and normally emitted when the user presses the enter key within the entry. This signal is connected to the function a_Interface_entry_open_url. 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?) I'm not very familiar neither with selection in general (i.e. the protocols provided by ICCCM), nor with the mechanisms Gtk+ provides. If someone knows a better solution, please describe it (or send a patch). If not, I'd clean up and commit solution 1. Sebastian
On Mon, 14 Jun 2004, Sebastian Geerken wrote:
Hi!
The current CVS version is supposed to visit the URL in the selection, when the user clicks with the middle mouse button on the "clear URL" button. However, I got it once working (strangely), but currently it does not work. I use Gtk+ version 1.2.10.
Oh, I thought is was meant to only copy the selection to the entry, and wondered why sometimes it went to the link automatically :-). Very funny! Now I think the automatic behaviour is better, so let's continue...
The function Interface_entry_paste_selected first copies the selection into the entry (as you see from the comment, I did not really understand the code), and then calls gtk_widget_activate, which emits the activation signal of the widget, which is "activate" for GtkEntry, and normally emitted when the user presses the enter key within the entry. This signal is connected to the function a_Interface_entry_open_url.
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).
I'm not very familiar neither with selection in general (i.e. the protocols provided by ICCCM), nor with the mechanisms Gtk+ provides. If someone knows a better solution, please describe it (or send a patch). If not, I'd clean up and commit solution 1.
Please try my suggestion. As for selection in general, our code is not clean and at best incomplete. Dillo doesn't react to external selection acquirement events yet (don't know if that's the technical name), but at least can set its own buffer and hand over the selection. I mean, selecting the URL text in the location (a GTK entry) highlights properly. Selecting from the viewport afterwards, highlights in the viewport and sets Dillo's selection buffer _and_ the location gives up the selection (unhighlights); this is GTK. But if you go and select again from the location, the location highlights but the viewport doesn't give up the visual clue. Dillo is not reacting to that event. Back when developing the code, no one was savvy enough to implement it cleanly... Cheers Jorge.-
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. Cheers Jorge.- 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!
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.-
participants (2)
-
Jorge Arellano Cid -
Sebastian Geerken