#91 Primary selection affecting gnome terminal search

Hi, I've noticed that recent versions of parcellite (last checked svn 383) have been affecting gnome-terminal search in a very subtle way. Ok I'll just note from the off that this started between parcellite-1.0.2rc6 and parcellite-1.0.2rc7 (where you seem to have made a lot of changes/moved stuff around). So I've been using an older version of parcellite for a long time now without problems, and for the past couple of days have been testing/keeping an eye on the lastest svn build. So, (as an example) whilst using gnome-terminal to search through vlc configure options for the string 'libva' which appears three times, when I hit 'find' or 'enter' to cycle to the next search result, gnome-terminal 'sticks' or doestnt move to the next result cleanly as though it's been blocked in some way (for want of a better explanation). The way to to induce this 'stickiness' I've discovered is, In parcellite have 'use primary (selection)' enabled and grab some text (to fill the primary selection buffer) and then attempt to use find in gnome-terminal as previously described. If I clear parcellite history/quit parcellite/use older version of parcellite, the problem stops. I'm curious as to whether parcellite should be affecting other applications like this, and/or if whether this has the potential to have other (unwanted) affects on other applications? By the way I'm using Ubuntu Maverick 10.10. There is a possibility that this bug wont affect newer versions/flavours of linux. Maybe someone else could try this out?
Hope this info is useful, Regards.

[Anonymous]

Hi, further on this. This problem appears with commit 314. The lines are:

    }else {/**restore clipboard  */
        gchar *d;
        if(NULL ==*existing && NULL != history_list){
            struct history_item *c;
            c=(struct history_item *)(history_list->data);  
            d=c->text;
        }else d=*existing;
        if(NULL != d)
            last=_update_clipboard(clip,d,existing);

If I remove these lines and compile again, the afore mentioned problem doesn't appear.

That is up until commit 375 when removing the above lines (/**restore clipboard etc) still doesn't prevent the problem from occuring. The problem lines in commit 375 that seem to cause the (further) problem are:

• /* int count;
  GdkAtom targets;
• if(clipboard == clip) g_printf("-%s-",gtk_clipboard_wait_for_text(clip));
  gboolean contents = gtk_clipboard_wait_for_targets(clip, &targets, &count);
• if(clipboard == clip) g_printf("-%s-2nd-",gtk_clipboard_wait_for_text(clip));
  g_free(targets);
• return !contents;
• if(TRUE == contents || count >0)
• return 0;*/
• gchar *x=gtk_clipboard_wait_for_text(clip);
• if(NULL == x) return 1;
• g_free(x);
• return 0;

Reverting these so as to match commit 374 (together with removing the lines from commit 314) makes the problem go away. I've spent hours (close to a couple of days actually) tracking these down so It would be nice to know whats causing this over-heavy grabbing of the clipboard is (or whatever the problem really is, as it seems hard to describe properly), and perhaps prevent it from occuring in future. Just a thought anyway.

I'll quickly go over once again what to do to replicate the problem. Using a recent version of vlc (as an example), decompress tarball then open terminal and do ./configure --help. Then using gnome-terminal use find and look for (say) libva. The search shows about 4 finds of the string 'libva' and pressing enter (or find) over and over should cycle cleanly and smoothly through every example of the string found. With parcellite active and with some primary text selected cycling through the strings that gnome-terminal finds is, for want of a better word erratic (and seems to stick/not cycle properly).

[rickyrockrat]

I'll have a look. I still use 10.04 (Lucid) :) I really appreciate your debugging efforts, BTW.

[rickyrockrat]

katiem,
I just took a took (3 months later), but I'm stumped at 'use find'. The find command? Do you have special keyboard shortcuts in gnome-terminal?

Can you give me the exact command lines you are using in gnome-terminal? Also, is gpaste running?

[Anonymous]

Hi, that's 'search' (I should have mentioned it's along the top menu between 'view' and 'terminal'). That opens the find dialogue. I dont't have any keyboard shortcuts that I've set myself, and gpaste isn't installed.

Regards.

[Anonymous]

Just checked, I've got no keyboard shortcuts set in gnome-terminal...

[Anonymous]

Ok hi, I've just been playing around with latest svn and I can see an effect that is much easier to see/consistent (than recently described) and seems to affect all gnome applications (and i'm guessing is connected to what I was describing above). Say in gedit I have some text and 'use primary selection' is off' ~ I drag along a piece of text and it is highlighted, it remainins so as expected. If I then activate 'use primary selection' and then drag along a piece of text it highlights as expected, and then un-highlights again (not expected). This seems to happen everywhere in gnome applications (about boxes anywhere text is highlightable) but not in qt or kde apps. Firefox seems to be unaffected...

[Anonymous]

Ok, well the plot thickens! From rev svn 390 I can no longer reproduce what I was originally describing !but! from this revision onwards I have to select text twice for it to be highlighted (rev 389 and below = no problem selecting text). This problem only occurs with primary selection activated. With primary selection unactivated all is well...

[Anonymous]

In commit 390 lines @@ -338,9 +348,9 @@ you changed

        if(0 == p_strcmp(processed,changed)) set=0;
        else set=1;

to:

        /** if(0 == p_strcmp(processed,changed)) set=0;
        else set=1; Always set the text.*/
        set=1;

If I revert this change (I tried this with latest svn (391), then it's possible to select text normally again (even with primary selection active) and bug as originally described at the beginning of this report hasn't reappeared (gnome-terminal search/find works without glitches). Hope this helps.

[rickyrockrat]

Ooops. That was debug code, and not supposed to be there. So you are saying the bug is fixed? Please check out SVN 392, and let me know if I can close this bug. I'm trying to release 1.1.5. Thanks.

[Anonymous]

Hi, rebuilt svn 392. Well the initial bug I reported has gone away, but the erratic select problem which turned up with rev svn 390 is still there. To make it go away (in rev 392) I changed (main.c line 358) ~ if(0 == p_strcmp(processed,*existing)) set=0; to
if(0 == p_strcmp(processed,changed)) set=0;

To (possibly) reproduce the problem I'm seeing have 'use primary (selection)' enabled. Then open a file already containing some text in gedit. Try to select a line of text, which will highlight but then that line will immediately unhighlight. If you re-highlight (say) a word that you've already tried to highlight (for the second time) then it will then remain highlighted. If 'use primary (selection)' is disabled or the change to the line [if(0 == p_strcmp(processed,changed)) set=0;] is made then line selection works normally.

[rickyrockrat]

Are your preferences the same as when you posted? miscellaneous all off except confirm clear, both clip & primary but not synchronized? Your change will make it ignore the history entry. thanks for the help. I will get this fixed.

[Anonymous]

Indeed, nothing extra turned on in preferences (except use primary selection). Mouse under history is checked (which is on by default as I remember), although I've tried toggling that and various other settings anyway to no avail. The only setting which seems to make any difference to the effect I've described is 'use primary selection'.

Regards.

[rickyrockrat]

I'm an idiot. Your change was correct. This part-time developer stuff doesn't lend itself to clear thinking. Try 393. Thanks.

[Anonymous]

Hi, svn (rev 394) > tested and all is well! Thanks for your work on this.

Kind regards.

[rickyrockrat]

No problem. I'm going to leave this open until I do the next release. If you don't mind, I'd appreciate it if you will run this version in the mean time, then when I tag the release, I'd appreciate it if you would run that & verify.

[Anonymous]

Glad to help... just tried 395 & seems to be fine...

[Anonymous]

Sorry, that's 396 (is fine)...

[rickyrockrat]

[rickyrockrat]

fixed in 1.1.5