#133 Selecting text de-selects text in terminals and other programs

[Tom Dexter]

This may not be a bug and could possibly be a side affect of fixes you've made since 1.1.7, but this behavior can quite bad in some cases: In GUI terminal programs (all that I've tried) when I highlight text and parcellite takes that selection, it unhighlights that selection in the terminal. The only time this doesn't occur seems to be when the selected text is the same as the current parcellite selection.

Another similar case that's much worse is this example: In the firefox save-as file dialog, say I want to highlight the first half of a very long default file name and clear that text with the delete key. It can't be done. As soon as you highlight the text, parcellite causes that selection to clear. At that point I almost end up having to close parcellite.

Before I forget: Thanks for maintaining an awesome project that I almost couldn't live without!

[Tom Dexter]

I noticed today that this was very similar to behavior described in bug #91. I'm a little confused as to the code changes that took place around that one, but I discovered that if I patch the existing SVN version with a change like the one described here:

https://sourceforge.net/p/parcellite/bugs/91/#7498

...that is:

@@ -424,7 +424,7 @@
            /**only check processed/changed. No need to update this clip, since the text is already there.  
               If we have identical lines except for whitespace, we also have to set the clipboard.
            */
-           if(0 == p_strcmp(processed,*existing) && 0 == mod) set=0;
+           if(0 == p_strcmp(processed,changed) && 0 == mod) set=0;
            else {
                set=1; 
                DTRACE(g_fprintf(stderr,"set=%d. p='%s'\n",set,processed));

The unwanted deselecting of text doesn't occur. I haven't used that change for very long, but I've already noticed one unwanted side affect (that I believe was fixed between 1.1.7 and 1.1.8), and that's that the function of Shift-Insert in some apps doesn't seem to behave the same as middle-click with the primary selection. That is, Shift-Insert may paste an older entry than middle-click.

For now I'm using it that way in spite of that. The more I used it the way it was with the text deselecting, the more I realized that it was just about unusable for me that way. Text editing in several (especially GTK) applications by highlighting text became essentially impossible.

Thanks again!
Tom

[Tom Dexter]

Now I understand the behavior when running with that patch mentioned above. What's happening there is due to the fact that firefox and other gtk apps behavior for shift-insert is to paste the gtk+ clipboard and not the X11 clipboard. The unpatched code as-is essentially fixes this behavior by setting the gtk+ clipboard to the PRIMARY.

Given that, I can see where this becomes a bit of a can of worms. It seems to me that the objectionable text deselection I'm seeing is arguably due to questionable behavior on the part of several applications. The clipboard standards (as listed in main.c) mention that a selection becoming unselected should never unset PRIMARY, however what's occurring in some of these apps is essentially the inverse. When/if parcellite takes ownership of the selection, the text in the app from which it was selected becomes functinally deselected. Very annoying. I've noticed that in some apps (that have a clue apparently) like gvim, this action by parcellite causes the highlighted text to be change to underlined, but it retains ALL of its functionality in gvim as selected text.

Very annoying.

[Vladimir Elisseev]

I have all different kind of annoyances, including the one you mentioned, with parcellite > 1.1.6, so at the moment I stick with this old-and-good one.

[rickyrockrat]

Tom,
Try SVN 533. your patch was not complete, there's another section of code that has similar issues. I need to write a single function that handles this to removed duplicate code...

[Tom Dexter]

Thanks! Just installed with that. Yes, that seems to function the same way as the patch I had. I don't get that text de-selection behavior.

It really is a shame that gtk+ apps want to use the gtk+ clipboard for shift-insert rather than the x11 clipboard as does the rest of the world. There's nothing that parcellite can do about that, unless it auto-selects in that case, which causes this unwanted text de-selection in those apps. I guess the only feasible way to get selected text to work in gtk+ apps with shift-insert is for the user to pro-actively select that text in the parcellite menu.

I can't imagine what they were thinking with that one.

Thanks again!

[rickyrockrat]

Actually, AFIK, GTK uses X11's clipboards, it just provides wrappers to do so. Parcellite uses GTK's clipboard functions. Almost positive GTK does not have any internal clipboards.

I've looked into X11 clipboard programming, but the first iteration was/is a bit involved - and I think I dug into Gtk's code, then decided to just use what was already written.

Try a read through these and see if it helps any:
http://askubuntu.com/questions/397972/use-shiftinsert-to-paste-from-clipboard-in-gnome-terminal
http://linux.seindal.dk/2005/06/16/xterm-and-the-clipboard/
http://mutelight.org/subtleties-of-the-x-clipboard

As to shift-insert, it is not a GTK issue, but a programmer's issue where they chose how to use that particular keystroke. All of Parcellite's keys are driven by events from Gtk, but I chose what actions each keypress takes. You can look around in the function 'key_release_cb' in main.c to see what I mean.

[Tom Dexter]

Oh man...I'd totally forgotten that along the way in testing some of this I'd disabled the option to synchronize clipboards. With that re-enabled and you're existing code it looks as though everything is behaving exactly as I want. That said, it appears that in firefox for example, shift-insert pastes the Copy (Ctrl-c) data and not the primary selection. Which I guess you're saying is the choice of the developers. With the synchronize enabled, that becomes moot. Sorry for the extra noise.

That aside, this most recent change does in fact correct that text de-selecting behavior, which was the real issue here.

Thanks again, and thanks for maintaining this thing...it's one of my most important must-haves!

Tom

[rickyrockrat]

It's one of my most important must haves as well, so when it got abandoned, I took it up so it would still live... I'll mark this fixed.

[rickyrockrat]

Fix will appear in 1.1.9