mousepad 0.4.2 (or compiled from master) on arch linux / xfce If I select some text in mousepad, and middle-click elsewhere, the selected text is pasted as expected. But if I left-click before somewhere in mousepad window, thus deselecting text, I can't paste the previously selected text anymore, neither in mousepad nor in another application: X clipboard seems to have been emptied. This is quite a strange (and annoying) behavior: usually, selection is "persistent", in the sense that only a new (non empty) selection replace the previous one. So that one can freely move in a document by left-clicking somewhere, and paste by middle-clicking.
The behavior is the same in gedit and Geany, so it is not specific to Mousepad. https://github.com/geany/geany/issues/2323
Well, it's weird, many of the applications I use daily don't have this behavior : firefox, thunderbird, lyx, xfce4-terminal, atom (as said in your link)… But it's true that, for instance, thunar has this behavior (at least in address bar), now that I look at it. Too bad if it cannot be changed…
I'm closing this (with "RESOLVED: INVALID" for lack of a better status) since Mousepad just inherits this behaviour from GTK+, which I believe does it the "normal" X11 way and presumably how other Xfce apps work (except for xfce4-terminal which uses the special VTE widget, not a typical GtkEntry/GtkTextView). If it's not too complicated to make the alternate behaviour into a setting and somebody wants to work on it, we could re-open this bug.
Created attachment 9858 0001-Persistent-X-clipboard.patch Here is a possible approach. Should I continue by adding a new setting "persistent X clipboard"? Should I ask for permissions to fork and propose a merge request on Gitlab?
I'm not personally interested in this feature/behaviour (but neither strongly opposed to it, if it's optional and off by default), so I won't personally review or merge it (but neither block it). > Should I continue by adding a new setting "persistent X clipboard"? Ideally if this behaviour does get added, it won't be added to the preferences GUI (it's way too esoteric), but rather just be a default-off GSetting preference. > Should I ask for permissions to fork and propose a merge request on Gitlab? I don't think you need to ask for permission, do you? Of course it will require someone who's thinks it's a good enough idea to review/test/merge it, so it may not be a good use of your time, if nobody with commit rights wants it. I guess that's what you're asking?
> Ideally if this behaviour does get added, it won't be added to the > preferences GUI (it's way too esoteric), but rather just be a default-off > GSetting preference. Ok, I will do that. > I don't think you need to ask for permission, do you? Yes, I do. I read in this official blog post https://simon.shimmerproject.org/2020/04/30/xfce-switches-to-gitlab/ : "By default new users cannot fork before being manually approved. Yes. We are afraid of the spambots." And on the login page https://gitlab.xfce.org/users/sign_in : "Please note that if you sign up, you will initially have readonly permissions and an admin will have to approve you for being able to fork projects or propose merge requests." So my question is: should I continue to propose new features and / or bug fixes via this bugzilla, or ask for write permissions on Gitlab?
Created attachment 9868 0001-Persistent-X-clipboard.patch I feel like it's not very useful that I make merge requests on Gitlab actually. So I will continue to use this bugzilla with my Gitlab identity, at least for the moment. I added the default-off GSetting preference.
*** Bug 16871 has been marked as a duplicate of this bug. ***