QPrompt-Teleprompter
QPrompt-Teleprompter copied to clipboard
Cuperino
Random text copying
.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
- Occurs randomly in this release
Device information
- QPrompt Version: 1.1.4
- Operating System: Raspberry Pi Bullseye, latest updates
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... For dev reference, this is the commit where I made those changes: ba4ae3f133b29ef068643184dd8c325ecf0fb2f9
Noticed it occurred once when I attempted a click-hold then scroll up or down to select text...then the erroneous text appeared.
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. https://forums.raspberrypi.com/viewtopic.php?t=289146
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 ba4ae3f133b29ef068643184dd8c325ecf0fb2f9 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: Device: Raspberry Pi 3B+ OS: Debian 11 Bullseye RAM: 1 GB of RAM CPU: BCM2835 @ 4x 1.4GHz Resolution: 800x600 DE: LXDE WM: OpenBox
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.
Yesterday's project (~1.5 hour script) had this occur again. While performing minor edits on other parts of the script, (not this specific part as best as I can recall) the following manifiested:
Script from a .docx file, copied and ctrl>shift>v pasted into Qprompt.
The originals as pasted from docx file:
Where the the selected sentence in the second example above originally existed:
Where it was randomly pasted:
Source document docx file was only pasted once at beginning of the session, all edits were made in Qprompt.
Qprompt 1.2 rev 5 Ubuntu 22.04 ARM, latest updates Raspberry Pi 4b
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. ~6.6k words.
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.
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 diff command to compare the contents of two different html files. The command works like so:
diff file_1.html file_2.html
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 diff command, and what you get when comparing changes on GitHub.
On Linux you could use a terminal to run the
diffcommand to compare the contents of two different html files. The command works like so:diff file_1.html file_2.html
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 Kompare. I personally just use the diff command and a commercial git client called Sublime Merge, so I can't speak for the options listed there.
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.
After copying selected text, middle clicking without scrolling appears to result in multiple pastes occasionally.
That sounds like a faulty button emitting an intermittent signal.
Is there a way to disable middle mouse clicks either in QPrompt
Not in QPrompt, tho I need to look into this to see if it would be possible. I think it should be.
or the OS while retaining scrolling functionality?
The middle click is paste behavior is OS specific, but IDK if Qt or the window manager is responsible for it...
Found an option in Gnome-Tweaks to disable middle.click paste... will explore further.
That might work for GTK applications, but I don't think it'll have an effect on QPrompt...
Not working with RPi LXDE
LXDE and Gnome have GTK in common, but they use different window managers, so it was unlikely.
https://ubuntuforums.org/showthread.php?t=2363299
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.