GNOME Bugzilla – Bug 492794
Pasting external text at end of view yields wrong scrolling to mark
Last modified: 2009-01-23 21:04:59 UTC
Please describe the problem: First noticed in gedit, afterwards verified for GTK.TextView. If you copy text from an external source (such as browser) and paste it into a TextView which will require scrolling to the cursor position due to lines reaching window height, the paste operation completes however the insert cursor is hidden. Steps to reproduce: 1. Open some website in a browser window. 2. Copy some text with newlines. 3. Paste text into a TextView component (even gedit) until the number of lines exceed the height of the view. Repeat 1) but this time copy the same text from within the TextView and compare the scrolling behaviour after having pasted. Actual results: Cursor is hidden. Expected results: The same behaviour which occours when using text copied from within a TextView with the view scrolling to make the cursor be on the last line in the view. Does this happen every time? Yes. Other information: Related to BNC https://bugzilla.novell.com/show_bug.cgi?id=181588
Funny bug, caused by asynchronous paste - gtktextview scrolls immediately after gtk_text_buffer_paste_clipboard() call, but that gets clipboard contents asynchronously (two times since first it requests GtkTextBuffer, then text), so scrolling wins. Is there an objection to making paste synchronous (using gtk_clipboard_wait_for_everything)? I've never had problems with it, except kind-of-freezing ui during paste when X server is slow; but it didn't seem to be a problem to me (since the whole ui is slow like a dead turtle).
gtk_clipboard_wait_for_contents() runs the main loop ... so it a) won't block the UI b) doesn't fix any problems with asynchronicity except sometimes makes the code a little more convenient. However, it can also introduce problems because it runs the main loop. An app might be able to handle a menu item being selected, an incoming network call. So that means gtk_text_buffer_paste_clipboard() can't be changed to use it. It's not possible to take a public API that didn't run the main loop and make it run the main loop. So, I think a GtkTextBuffer API addition is needed. Possibilities: gtk_text_buffer_paste_clipboard_and_wait(): - easy to use - moderately easy to implement - applications users of gtk_text_buffer_paste_clipboard() would need adaption or they'd still have that bug - run-the-main-loop functions are never supposed to be the only way to do things. gtk_text_buffer_paste_clipboard_with_callback(, ..., callback, data) - A little harder to use - moderately easy to implement - application users need adaption - functions that take function pointers take manual language binding GtkTextBuffer::paste-received signal - easy to use for GtkTextView - easy to implement - no application adaption needed - maybe a little less flexible
Created attachment 99254 [details] [review] patch "paste-done" (you invent a nice name) signal. It seems to be the best (simplest and easiest) option.
Looks good to me. I'm fine with paste-done as the name. Two suggestions: - Would it be useful to pass the GtkClipboard as an argument, so so someone could do something different on middle-button-paste as compared to C-v paste? - I think you might as well use one of the padding slots on GtkTextBufferClass instead of using 0 for the default handler offset. If there were only 1-2 left, I'd say differently, but there's 6 at the moment.
Created attachment 126290 [details] [review] paste_done I suppose this is what you wanted.
sorry there was a bit of miscommunication between me and nacho about the above patch (he asked me to test since I could not do it and I said "it looks ok", but I just mean that by looking at the patch and I didn't test it). The patch needs a couple of fixes since it puts the new signal in the middle of the class struct and thus breaks abi. I'll attach a /tested/ patch in a bit
Created attachment 126292 [details] [review] tested patch This one seems to work fine here
Looks fine, please commit. It would be good to point out the intended use caes (i.e. scrolling) in the signal docs.
*** Bug 566450 has been marked as a duplicate of this bug. ***
I don't know if it's related to this current bug, but there's the same comportment with Snippets (Edit > Preferences > Plugins > Snippets). To reproduce the bug with Snippets: 1. Add a new Global Snippet with this content: /* Line 1: $1 Line 2: $2 Line 3: $3 Line 4: $4 Line 5: $5 */ $0 2. Create a new file in gedit and write enough text to make the right scrollbar appear. 3. Put the cursor to the end of the file and get expanded the previous Global Snippet. Actual result: we see only the first line of the added comment: /* Line 1: $1 The scrollbar didn't move to the bottom to allow us to see all the comment.
That's a snippets bug, please file a separate reports. Thanks!
(In reply to comment #11) > That's a snippets bug, please file a separate reports. Thanks! Done: bug 568916