After shutting down parcellite I noticed that something is wrong with middle mouse button pasting. It turned out that this is what someone described as the Left-click clears PRIMARY buffer bug. I checked with the newest tahrpup. The bug is still there. Most users will not notice as the presence of a clipboard manager like parcellite or clipit miraculously "fixes" the bug. Anyway, it's a bug I can live with.
Variable bug
This is more serious and haven't found a cure or work around. I would be grateful for any help.
The problem arises when assigning a selection to a variable or directly to a widget. Something like
SELECTION=$(xclip -o) will assign the contents of the X selection (PRIMARY) buffer to the variable SELECTION. Used in a Gtkdialog code this works as expected after the user made a selection in a different window. Gtkdialog will then put the selection content into the variable SELECTION. However this does not work and causes Gtkdialog to freeze when the selection was made in the Gtkdialog window itself. Apparently this is not a xclip bug because it also happens with similar selection tools like xsel.
To confirm, that this is a GTK bug and not a Gtkdialog bug I checked with my recent YAD form demo code. When a user selects files in ROX-Filer and then pushes the "Refresh file list" button", the file names will appear in the form. When the user selects something else , e.g. text in a Geany window and then pushes the button,YAD will show an info text. However when the user selects something in the YAD form and then pushes the button, YAD will freeze (to test this, run the code from a console because it will not be possible anymore to close the YAD window. Close the console instead).
The same thing happens in Gtkdialog. Below a small example, this time using the clipboard (and for obvious reasons executed in a console window
). Copy some text in a different window and then push the "Paste" button. Should work without problems. Copying something from the dialog and pasting it to a different window will also work, but pushing the "Paste" button will make the dialog unresponsive. Any idea how I can prevent this?Edit1: I was hoping that writing the selection/clipboard content to a file and then reading the file would prevent the bug, but this doesn't work. Already the attempt to write the X selection to a file (command: xclip -o > file) will trigger the bug.
Edit2: Writing the selection/clipboard content to a file and then reading the file can indeed be used as a work around if the xclip command is executed in a separate console window. This window may still freeze, but killing the window can be automated and at least the main dialog stays alive. Not a great solution, but it works.
Code: Select all
#!/bin/bash
echo -n '' | xclip -selection clipboard # clear clipboard
urxvt -e bash -c "echo -n '<window>
<vbox>
<text label=\"Content of clipboard:\" selectable=\"true\"></text>
<entry>
<input>xclip -o -selection clipboard</input>
<variable>vENTRY</variable>
</entry>
<button has-focus=\"true\" label=\"Paste from clipboard\">
<action>refresh:vENTRY</action>
</button>
<button cancel></button>
</vbox>
</window>'|gtkdialog -s"
but it is in subsequent beta releases (running slacko64-6.3.0.3 right now). Nevertheless, the bug shows its face. I'm still wondering if it's an xlib bug.
