-
-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Random text copying #155
Comments
I did modify code related to the pre-processing that happens when opening files and pasting contents to make the process more efficient. Maybe the new code isn't an exact replacement to the original code as I'd thought... |
Noticed it occurred once when I attempted a click-hold then scroll up or down to select text...then the erroneous text appeared. |
What desktop environment are you using in that computer?
|
I think the click and drag may somehow be resulting in a middle click. Some desktop environments, including Raspberry Pi's it seems, allow using middle click to paste contents. |
LXDE
|
I tested clicking and dragging all sorts of things rapidly and constantly for several minutes on a Raspberry Pi 3B+ and wasn't able to replicate the issue. The only way of getting it to paste with the mouse was by middle clicking, which follows LXDE's default behavior. I also closely looked at the changes done in ba4ae3f and couldn't find anything that could cause an issue like this one. I did find a way to make it the code more space and RAM efficient, but will be leaving it as it is for now, to favor low CPU usage. The system had the following specs: |
Has any changes been made in reference to 1.2? While doing a search operation on ~6 instances of an incorrect word and pasting in the correction, I noticed the paste was incorrect upon file save/reload. |
No changes with regards to pastes. |
Happened twice on a job last night... first time since my last message in this issue. Had to copy/paste the Word document with formatting intact into QPrompt due to excessive font attributes/decorations I would have to redo manually with unformatted text. Most of my scripts are shorter so uncertain if script length is a contributing factor. Workflow: I was deleting all the errant carriage returns from the paste then adding a space between the words, no mouse interaction except to left-click to place the cursor in the correct spot and scroll in edit mode with the mouse wheel, all else was keyboard input. I noticed as I scrolled random text was placed twice, not copied but cut from its original location then pasted near my current position in the script (Text I highlighted in red). The example shows text removed from the end of the show and pasted up towards the front. No copy/paste operations were performed, occasional saves were implemented as I edited though. Only change in specs is currently using QPrompt 1.2 r6 |
This is really strange and I can't think of much that could cause this... This latest description completely discards my original theory of this having to do with the middle click pasting feature some Linux system have. It sounds more like an issue with memory management or an incorrectly implemented model. Using special tools I recently found an issue with the FileSystemWatcher (the thing used to auto reload changes done by other programs) that could cause QPrompt to crash or perform erratic behavior. Of the two, a crash is more likely. But I figured the chances of this bug ever manifesting were practically nonexistent. I'll try fix that issue for the next build, see if it prevents this. If you can think of any other steps to replicate the issue, please let me know. |
I've fixed the problem with the FileSystemWatcher, and added an option to disable local file auto reloading. That will allow us to rule out the two strongest contenders as to what could be causing this issue. If problems persisted with auto reloading disabled, then what's left is to use QPrompt in a desktop environment that doesn't past text when middle click is pressed, in case there's something about your hardware that will cause the middle click signal to unexpectedly emit in rare occasions. If that doesn't solve the issue either, then we will need to keep thinking of possible causes for the problem and take note whenever the issue occurs; maybe consider adding telemetry, tho right now I can't think of a way to collect enough data to dissect this bug, that's not simultaneously intrusive to the users. |
Thank you for all your hard work!
|
Random thought. Is there a way to 'write protect' a block or blocks of text to prevent any editing of those segments? Like some kind of 'read only' html flag <read only 'text block' /> type of construct? |
To answer your question, this should be possible, but it would not be straight forward thing to do, as it would require extending the document API to support HTML tags beyond the standards of HTML 4.1 that Qt supports. Having said that, this would be more of a patch than an actual solution, and those should be avoided as they tend to accumulate technical debt over time, which increases maintenance costs. There are already a few workarounds like this around upstream Kirigami bugs... I wouldn't want to add more. |
Understood. If I were to open two instances of QPrompt, then edit one of them, is there a workflow that could allow me to find/compare the two documents and highlight any differences to determine quickly if any errant pastes took place in the one i am editing? |
On Linux you could use a terminal to run the
|
In the future, could this be possible between QPrompt instances? |
QPrompt instances have no way of being aware of what other instances are doing unless those instances are spawned be QPrompt itself. But this would be impossible to do on MacOS because Mac does not support running more than one instance of any graphical program at once. If multiple windows are needed, the program itself must offer means for instantiating them. Because of this, I cannot add the feature in the way you describe, as it would become platform specific. The only instances in which I allow for platform specific behaviors are to follow platform conventions and to prevent crashes. What I could do is keep a copy of the original document, or an earlier state of the document, in memory, and provide an interface that highlights the differences, similar to what you saw from the |
That may be very helpful to verify all changes, thank you. |
Are there any gui apps like Nautilus that have the diff function? |
There are a few out there: https://www.tecmint.com/best-linux-file-diff-tools-comparison/ KDE has one called |
Tried both, appears to only list html code, not the contained text |
Right, for that the HTML code would have to be parsed and modified with additional classes to highlight the differences. I doubt any general purpose difference detection software would go through the trouble of doing that, considering often differences can't be identified from a document's parsed form. |
May be in fact related to middle mouse/scroll wheel click. It's possible my RPi mouse is inadvertently sending clicks when I scroll, have not been able to duplicate with my Logitech mouse. After copying selected text, middle clicking without scrolling appears to result in multiple pastes occasionally. Is there a way to disable middle mouse clicks either in QPrompt or the OS while retaining scrolling functionality? |
Found an option in Gnome-Tweaks to disable middle.click paste... will explore further. |
Not working with RPi LXDE |
Found this link: |
That sounds like a faulty button emitting an intermittent signal.
Not in QPrompt, tho I need to look into this to see if it would be possible. I think it should be.
The
That might work for GTK applications, but I don't think it'll have an effect on QPrompt...
LXDE and Gnome have GTK in common, but they use different window managers, so it was unlikely. That sounds very much like your issue. Judging by the comments, it seems apps are able to disable middle click pasting, so it should be no different with QPrompt. I'll see how I can add this. |
Closing as not a bug in QPrompt but something external. |
.Bug Description
Not certain I'm describing this accurately, however i have multiple paste-like fragments of text in random points in the script that I never selected for copy to my knowledge.
Steps to Reproduce
Device information
The text was updated successfully, but these errors were encountered: