Bug Location input keeps overwriting clipboard
- Thread starter Voker57
- Start date
I'm not sure I understand what you are saying or how to reproduce it. I can tell you that using the word "annoying" has side effects that you might not want. But until you tell me how to reproduce it and I (or someone else interested) can either reproduce it or isolate it to being Linux specific I doubt anything is going to be done.
But I'm still not 100% certain what I should do to reproduce it and understanding that is a prerequisite to making the effort to set up a Linux VM and see if it can be addressed. Alternatively we could just mark this as Not Going To Fix.
If any selected JList item is being copied into your clipboad then it sounds like something potentially strange is configured in your X server or possibly with your JVM. Make sure they're up to date.
Does it happen with other frames? eg. open the inventory frame, click " - Fine Tuning" and paste. Does it paste the value of the list item?
Does it happen with other frames? eg. open the inventory frame, click " - Fine Tuning" and paste. Does it paste the value of the list item?
nworbetan
Member
I can reproduce this, or something pretty similar at least, in 3 easy steps:
1. start mafia
2. log in
3. middle clicking now pastes this:
Pasting the currently selected text with a middle click is pretty normal behavior in Linux. I've used that functionality in a Linux system that didn't even have an X server, and I'm sure there are extra-fancy clipboard programs that change that behavior in more or less subtle ways too. But the one thing I'm really not sure about is why this wall of text is "selected" when I log in with mafia.
1. start mafia
2. log in
3. middle clicking now pastes this:
Pasting the currently selected text with a middle click is pretty normal behavior in Linux. I've used that functionality in a Linux system that didn't even have an X server, and I'm sure there are extra-fancy clipboard programs that change that behavior in more or less subtle ways too. But the one thing I'm really not sure about is why this wall of text is "selected" when I log in with mafia.
Last edited:
roippi
Developer
That's just a random instance of JTextComponent.setText, presumably the last such that occurs during initialization. The little combobox that the OP is referring to is another JTextComponent.
I don't know what the Best Practice is here. Calling setText apparently causes this behavior even when the component is not enabled ('grayed out' for the laymen). Maybe there's a system property we can set on startup or something.
I don't know what the Best Practice is here. Calling setText apparently causes this behavior even when the component is not enabled ('grayed out' for the laymen). Maybe there's a system property we can set on startup or something.
The JTextComponents being referred to here are enabled, or else you wouldn't be able to interact with them. What you might be thinking of is that they are not editable. They are certainly handled differently, a component that is not enabled won't fire certain events.
The problem is related to the implementation of the DefaultCaret class that is assigned to each JTextComponent. There's a few ways we could handle it.
1. Create our own implementation of Caret that behaves how one would expect it to behave in Linux. This solution is probably way out of scope for KoLmafia.
2. Perform document changes that we don't want caret events to fire for on something other than the Event Dispatching Thread.
3. Set the NEVER_UPDATE property of the DefaultCaret for JTextComponents where we don't want the caret to move the dot around the document (thus causing unwanted events to fire). This is probably the easiest solution, but it may not be the best solution for every JTextComponent.
Interestingly, option 3 is what probably should've been done for the example nworbetan posted as someone has already implemented a hack to move the dot back to the start of the document for that component:
If you tell the DefaultCaret to NEVER_UPDATE, you wouldn't need this hack.
Sorry, I don't have time to tinker at the moment. Hope the information is useful.
The problem is related to the implementation of the DefaultCaret class that is assigned to each JTextComponent. There's a few ways we could handle it.
1. Create our own implementation of Caret that behaves how one would expect it to behave in Linux. This solution is probably way out of scope for KoLmafia.
2. Perform document changes that we don't want caret events to fire for on something other than the Event Dispatching Thread.
3. Set the NEVER_UPDATE property of the DefaultCaret for JTextComponents where we don't want the caret to move the dot around the document (thus causing unwanted events to fire). This is probably the easiest solution, but it may not be the best solution for every JTextComponent.
Interestingly, option 3 is what probably should've been done for the example nworbetan posted as someone has already implemented a hack to move the dot back to the start of the document for that component:
PHP:
textPane.setSelectionStart( 0 );
textPane.setSelectionEnd( 0 ); // don't have scrollPane scrolled to the bottom when you open itIf you tell the DefaultCaret to NEVER_UPDATE, you wouldn't need this hack.
Sorry, I don't have time to tinker at the moment. Hope the information is useful.
roippi
Developer
Well, I wasn't thinking of either. I thought that the location component was not enabled when mafia was in a pending state, but looks like it's always enabled.
You're right on the rest; I was unfamiliar with DefaultCaret but that is the proper way to implement a JTextComponent with that behavior. In that instance. I don't know if NEVER_UPDATE is the right behavior for the location combobox, I haven't looked at it.
Last edited:
Voker57
New member
Steps to reproduce (on linux):
1. Switch to Graphical GUI frame
2. Issue command to adventure somewhere
3. Go to terminal emulator and paste clipboard contents (Shift-Ins) or middle click in any text field.
Pasted text will be part of adventure location (like "Friars") despite the frame with this text field was not active.
Yes.
1. Switch to Graphical GUI frame
2. Issue command to adventure somewhere
3. Go to terminal emulator and paste clipboard contents (Shift-Ins) or middle click in any text field.
Pasted text will be part of adventure location (like "Friars") despite the frame with this text field was not active.
Yes.
This is partially normal behaviour, but it shouldn't be happening when the window isn't active, so there will probably be a fix for that when somebody has the time.