Unable to paste text to clipboard #617
Comments
qlrd
changed the title
|
This used to be broken but I submitted a patch to fix it long ago, are you using gossip-git from the AUR? Middle mouse may not work, but the copy button in gossip, and pasting into gossip with CTRL-V works for me. gossip-git .r1805.gfc7f13e3-1 |
|
You can single out the clipboard for debug with this log config: I can't help with debugging as I don't have any non-headless linux machine at the moment. |
|
Also make sure your version of 'Mutter' if applicable, has this fix: https://gitlab.gnome.org/GNOME/mutter/-/issues/1250 |
@jeremyd
No, i'm using from gossip-bin from AUR (by the way, I'm the author of the package, it extracts the binary from .deb package). My system: gossip-bin 0.9.0-1 @bu5hm4nn
Output when try to paste
Updated to and running
had the following output: |
Well, I tried downgrading to gossip-bin and that works for me too. The only difference I can see is that I use sway and don't have mutter installed.. |
So the bug isnt related to gossip itself, but in its interaction with the window compositor used and/or components of that window compositor (that can differ)? |
I'm not sure where the bug is, but i wasn't able to narrow it down (because I can't reproduce), it could be a bug in the rust library that handles clipboard. Maybe if you try compiling gossip via the gossip-git package and see if that helps? Maybe it's something to do with the .deb? But also, I tried the deb on my system and it seemed ok. Basically just have to track the bug down... The library being used is this one: |
One other thing to check is make sure it's running on wayland and not on xorg-xwayland or something like that.. |
|
I'm trying to build One note: maybe need to put When done i will try to report the usage of compiled gossip. EDIT: |
Checked with the following:
I will try with Some results with (1) first i cleaned my clipboard and runned 1891202.132] [email protected](6, "wl_data_device_manager", 3)
[1891215.602] [email protected](6, "wl_data_device_manager", 3)
[1891216.783] [email protected](6, "wl_data_device_manager", 3)
[1891308.263] [email protected](6, "wl_data_device_manager", 3)
[1891308.268] -> [email protected](6, "wl_data_device_manager", 3, new id [unknown]@49)
[1891308.465] -> [email protected]_data_device(new id wl_data_device@51, wl_seat@50)
[1891333.185] [email protected](6, "wl_data_device_manager", 3)
[1891333.195] -> [email protected](6, "wl_data_device_manager", 3, new id [unknown]@58)
[1891333.522] -> [email protected]_data_device(new id wl_data_device@60, wl_seat@59)
[1891431.050] [email protected](nil)Then yanked some random content to clipboard and pasted to gossip: [2629385.169] [email protected]_offer(new id zwp_primary_selection_offer_v1@4278190082)
[2629385.169] [email protected]_offer(new id zwp_primary_selection_offer_v1@4278190082)
[2629385.216] [email protected]_offer(new id wl_data_offer@4278190080)
[2629385.234] [email protected]("text/plain")
[2629385.241] [email protected]("text/plain;charset=utf-8")
[2629385.287] [email protected]("STRING")
[2629385.292] [email protected]("text/plain")
[2629385.296] [email protected]("TEXT")
[2629385.300] [email protected]("COMPOUND_TEXT")
[2629385.303] [email protected]("UTF8_STRING")
[2629385.307] [email protected]("text/plain;charset=utf-8")
[2629385.311] [email protected](wl_data_offer@4278190080)
[2629385.317] [email protected]_offer(new id zwp_primary_selection_offer_v1@4278190081)(3) With The |
The version of a |
Interesting. So I noticed that my gossip has the following warnings, does yours? It's failing to initialize the arboard clipboard, which I think is what it's supposed to do. I remember when I was reading the code there was some kind of clipboard management logic that was different depending on wayland vs. X11. I'm on wayland it initialized smithay instead (like it's supposed to). Also, when you say yank, you mean CTRL-C right? I know it still does not work with middle mouse / select. Only ctrl-c and ctrl-v.. |
|
Thanks @mikedilger, i thought that got the source through git tag.
Yes, but both arboard and smithay initialize. And smithay fail in receiving offer.
Yes, but i tried copy with mouse and do not work to. |
|
I wish I could help with this problem but it is outside of anything I am familiar with. I hope you guys can work it out. |
|
I installed gnome (for another purpose) and I can confirm that Paste from outside of gossip, into gossip fails, logging the following -> However, copying from gossip (using the copy button) and pasting outside of gossip works. Interesting. Maybe now that I have gnome installed and can reproduce the bug, I may go splunking around in cargo again for smithay problems :) Silly that it works in Sway, usually it's the opposite (stuff broken in sway and works in gnome) haha. |
|
Interesting. I'm on the case. I went back to commit 42c571f of gossip and confirmed that this old version, pasting *did work in gnome (i had to make sure because I thought I tested both sway and gnome at the time). So, something in-between then and now has regressed in egui-winit. |
|
So I tried to bisect the changes between the working version of the past, and today's version. The working version, was using a "gossip" branch of mikedilger/egui. The current version is pinned to a commit 50393e4f34ac6246b8c2424e42fbe5b95e4b4452 . However, there seems to be no difference in the egui-winit crate for these two versions. The only other differences I can see, would be changes to other libraries, and the split of the gossip-lib and gossip-bin into separate 'crates?'. egui_extras has been removed, and egui-video added. The version that gossip uses of the egui crate itself *is behind upstream. I diffed the difference in just the clipboard source and got the following diff (pasted below). This leads me to believe that some things are changing in egui-winit upstream that could possibly fix things with wayland.. So, I don't know how extensive the gossip modifications are to egui (it's behind by 255 commits and ahead by 5). But without being up to date with upstream I can't file any bugs against upstream, gossip is on it's own fork here.. |
|
I attempted a naive rebase of upstream.. Couldn't get it compiling due to lack of context about the changes.. @bu5hm4nn or @mikedilger what do you think about rebasing to the latest egui? I don't know if it will fix anything, I just was trying to see if clipboard would work and curious how different the gossip fork of egui is.. (see previous comment). |
|
@jeremyd I can tell you exactly what change broke the clipboard for you. We added a second instance of egui clipboard so that we could offer a "paste" button (and maybe soon a context menu that has "copy, "cut" and "paste". What that does in the linux implementation, is it creates a second datadevice for the same process. As I linked earlier, there was a bug in Mutter where only the first datadevice was sent the data offer: https://gitlab.gnome.org/GNOME/mutter/-/issues/1250 I am assuming the current bug you are experiencing is related to this. I was hoping that if you updated all your platform libraries eventually a fix would be included. What we can do to help you and people that use a similar linux version is to exclude the second clipboard instance from builds for your platform. However, I maintain that it is a bug in your platform and not the app. As far as I know it works fine on macOS, Windows and other Linux distros, like the one Mike is using. |
|
@bu5hm4nn oh, yes I see this bug, however the bug is closed 3 years ago and we're on the very latest mutter.. So something is not quite right still. The bug mentions "This is however not the case of DnD data offers, as the semantics I happened to notice the clipboard has been going through some changes in egui-winit and I wanted to try it out to see if it 'fixes' the problem, do you know of a way to try this out in a sample app or something? I want to file a bug upstream with egui-winit but I can't really use gossip to prove it since it's behind latest. It looks like they changed how they access clipboard in wayland with some raw handle changes.. |
|
@bu5hm4nn and also, that previous version of gossip I mentioned (from when I originally fixed this) does work properly for copy/paste so that led me to believe it's something in egui-winit and not in mutter.. |
|
specifically the new release of https://github.com/Smithay/smithay-clipboard/releases/tag/v0.7.0 and the included upgrade to Smithay Client Toolkit to 0.18, wayland* 0.30. This was released and included in egui-winit in October 2023. I think it's possible that because we're on archlinux, we run the very latest wayland, we may experience the bugs that older versions of linux haven't gotten to yet. |
|
Basically what we do is pull latest egui and then cherry-pick our changes on top. We tried contributing them back to egui but they have quite the backlog of PRs (78 last time I looked). I can attempt an egui upgrade now and give you a branch you can pull. |
|
@jeremyd It was a bit of a journey, but I now have a branch that runs on the bleeding edge (master as of yesterday) egui. Interested to hear if it solves your issues. The branch is on my fork: https://github.com/bu5hm4nn/gossip/tree/updated-egui-test |
|
Tried this branch, it's having compile errors with accesskit / atspi-common. I tried to find where this dependency is pulled in from, atspi, and checked all versions there... the only real difference from egui main branch cargo.lock is accesskit_unix is 0.6.1 in upstream egui, and 0.6.2 in your test branch.. Not sure if that matters or not.. seems to be an error with the types somehow. Here's a few of the errors from my error log.. |
|
@jeremyd I just pushed a commit that removed the zbus patch as Mike had to remove that on his linux machine as well. Also I'm going to set up a Linux VM so I can test this stuff myself. |
|
@bu5hm4nn Just compiled the new one and tried it out.. So, it's showing signs of wanting to work! I notice that any of the new "paste" buttons in the various fields, like when you're setting up metadata or passphrase, they work! However, just doing CTRL-V to paste, does not work and the log says: (also worth noting, that CTRL-C within gossip and pasting to the outside works). |
|
I tested in egui's hello world example, to see if paste/copy works there. It does.. I know you mentioned gossip is doing a second instance so maybe this is expected (but also means I can't really file a bug upstream as it appears to be working there). It's cool that the button for paste does work, so this bug could possibly be mitigated just by adding a paste button to the compose note text area (like it is in the other text areas).. |
That's the second clipboard instance, so that one is getting data, but not the first it seems. |
|
@jeremyd You could also try compiling without wayland support (remove it as an eframe feature at |
|
Hi @bu5hm4nn thanks for trying so hard to fix this.. I don't run Xorg, and I'm never going back to it, but I did go one step further and disable Xwayland support on gnome to see if that was confusing winit's clipboard (this is the xorg compatibility layer that apparently gnome launches by default). Even without the Xorg compatibility running, It still has the smithay error. The logs look the same as they do in Sway though now (which has always worked fine). There must be something that mutter is doing poorly, that Sway isn't doing.. I am close to running out of ideas to try, but perhaps I can figure out what flags to use in the compile to disable X11 completely? |
|
@bu5hm4nn for example, I see them discussing a lot in this PR about "no-default-features" ironically to support just X11.... I believe that doing cargo build with --no-default-features and specifying features = 'wayland' for egui-winit, that disabled completely arboard, so I guess, that worked, but the clipboard still is broken. (emilk/egui#1971 - I attempted to figure out what they're doing here and disable x11). Anyway, thanks again for trying, I will let you know if I think of anything else to try. Since Sway works, there must be some solution outside of gossip to discover.. |
|
@jeremyd The new tip of the 'updated-egui-test' branch I shared will now work (I'll explain below), however it will take a few days/weeks until we get those changes back into unstable as they do depend on updating egui which needs more testing and work from our side. In the meantime if you would like to use this branch and provide feedback on this thread if you find things that don't work then it would help us with testing for the new egui version. So I now have a Ubuntu VM which allows me to test Wayland integration (yay). I could not get to the bottom of where the bug is, but I suspect it is somewhere in the smithay code. The reason I believe this is that I was able to test the App against 'weston', the reference implementation of wayland, and it behaves the same way as under 'mutter'. I have debugged all the egui code and I cannot find a problem there. So I suspect smithay, unless nobody has tested two clipboard instances on the same windowhandle and it's a common bug across wayland implementations, but that seems unlikely to me. So the way I fixed it was to remove the second instance, and patch egui to allow us to initiate a paste from our code. My hope is I can get that patch into egui so we don't have to lug it around. |
|
@bu5hm4nn very cool! I appreciate the effort, copying and pasting in a nostr client is very important which is why I wanted to track this bug down for linux users.. I tried to compile the latest branch, it has some compile errors (mentions possibility of two eguis) |
|
Only if you compile with video support. I pushed an update for you @jeremyd . |
|
Confirmed!! Copy/Paste is working in both Gnome and Sway 🎉 🎉 🎉 👍 You rock @bu5hm4nn Right on. I will let you know if I notice any bugs, looking to be working great so far (and with video enabled too yep). |
|
Found the first possible bug. The slider buttons in the relay settings (for R/I/W/O) don't toggle (they toggle right back when clicked.) hehe. |
|
Also experiencing some freeze-ups when scrolling my main feed.. where the UI goes un-responsive and have to force-quit. Nothing abnormal in the logs that I can see.. |
|
I cannot reproduce the slider button problem nor the freezing. Here's the slider buttons on my Ubuntu VM |
|
I fixed a switch slider issue back in this commit: 258cdcc |
|
Ok, so I tried to see what might be different here on my setup vs yours @bu5hm4nn. First I moved my older (and larger gossip DB out of the way and started fresh but still with my pubkey. The sliders were still stuck. Then I compiled without --features=video-ffmpeg. This got the sliders working. It also seems like the freezing isn't happening now.. So, *then I put my old gossip DB back in place and started up. I noticed that in the first few minutes (say about 3-4 minutes), the sliders were stuck and the machine was working super hard.. Then, I kept trying after the machine calmed down and the sliders worked.. So it must have been working too hard on the feed or something like this, it was unable to set the sliders till some background task finished.. So, it could be an issue with some background processing and maybe nothing to do with video-ffmpeg other than using that feature makes gossip work harder and it never finishes doing what it needed to do for the sliders to start working, and ultimately froze the app.. Hard to say, my follow list is pretty large (1013) so there's a lot of processing going on. Hope this helps. 🤙 |
|
Same problem. Which makes Gossip pretty useless for the moment. No way I will write a pubkey of a person to add a contact by hand... |
|
@gustavklopp try the new testing branch if you want, it's working there now https://github.com/bu5hm4nn/gossip/tree/updated-egui-test |
Sounds like a serious performance problem. This issue is far too long for us to discuss that here, so open a new issue for it if you want. |
|
@jeremyd Mike has merged the egui update into |
|
Excellent! 💪 |
…o trigger Clipboard actions (#4035) ### Motivation We want to offer our users a context menu with `Cut`, `Copy` and `Paste` actions. `Paste` is not possible out of the box. ### Changes This PR adds `ViewportCommand::RequestCut`, `ViewportCommand::RequestCopy` and `ViewportCommand::RequestPaste`. They are routed and handled after the example of `ViewportCommand::Screenshot` and result in the same code being executed as when the user uses `CTRL+V` style keyboard commands. ### Reasoning In our last release we used an instance of `egui_winit::clipboard::Clipboard` in order to get the `Paste` functionality. However Linux users on Wayland complained about broken clipboard interaction (mikedilger/gossip#617). After a while of digging I could not find the issue although I have found references to problems with multiple clipboards per handle before (https://gitlab.gnome.org/GNOME/mutter/-/issues/1250) but I compared mutter with weston and the problem occured on both. So to solve this I set out to extend egui to access the clipboard instance already present in egui_winit. Since there was no trivial way to reach the instance of `egui_winit::State` I felt the best approach was to follow the logic of the new `ViewportCommand::Screenshot`. ### Variations It could make sense to make the introduced `enum ActionRequested` a part of crates/egui/src/viewport.rs and to then wrap them into one single `ViewportCommand::ActionRequest(ActionRequested)`. ### Example ```Rust let mut text = String::new(); let response = ui.text_edit_singleline(&mut text); if ui.button("Paste").clicked() { response.request_focus(); ui.ctx().send_viewport_cmd(ViewportCommand::RequestPaste); } ``` --------- Co-authored-by: Emil Ernerfeldt <[email protected]>
…o trigger Clipboard actions (emilk#4035) ### Motivation We want to offer our users a context menu with `Cut`, `Copy` and `Paste` actions. `Paste` is not possible out of the box. ### Changes This PR adds `ViewportCommand::RequestCut`, `ViewportCommand::RequestCopy` and `ViewportCommand::RequestPaste`. They are routed and handled after the example of `ViewportCommand::Screenshot` and result in the same code being executed as when the user uses `CTRL+V` style keyboard commands. ### Reasoning In our last release we used an instance of `egui_winit::clipboard::Clipboard` in order to get the `Paste` functionality. However Linux users on Wayland complained about broken clipboard interaction (mikedilger/gossip#617). After a while of digging I could not find the issue although I have found references to problems with multiple clipboards per handle before (https://gitlab.gnome.org/GNOME/mutter/-/issues/1250) but I compared mutter with weston and the problem occured on both. So to solve this I set out to extend egui to access the clipboard instance already present in egui_winit. Since there was no trivial way to reach the instance of `egui_winit::State` I felt the best approach was to follow the logic of the new `ViewportCommand::Screenshot`. ### Variations It could make sense to make the introduced `enum ActionRequested` a part of crates/egui/src/viewport.rs and to then wrap them into one single `ViewportCommand::ActionRequest(ActionRequested)`. ### Example ```Rust let mut text = String::new(); let response = ui.text_edit_singleline(&mut text); if ui.button("Paste").clicked() { response.request_focus(); ui.ctx().send_viewport_cmd(ViewportCommand::RequestPaste); } ``` --------- Co-authored-by: Emil Ernerfeldt <[email protected]>
Description
Like the title says, i'm unable to paste text (typing CTRL-V or clicking right's mouse) button to gossip. But there's 3 types of this behaviour:
OS Summary
Opengl summary
Catching the error
Reading this commented thread, i was able to catch the specific error using
RUST_LOG=debug(i removed timestamps to better readability):The last lines caught attention, which were the last action performing the 1st procedure described in the list above:
The text was updated successfully, but these errors were encountered: