I click the clear button next to 'Switch to close-up or distant view' in 'Mouse interaction' in the configuration window (so that I can use middle-button for 'move viewport by dragging' as it should be ...). I click Apply, and happily proceed to middle-button drag my viewport around. When I close and restart Palapeli the middle-button setting for 'move viewport by dragging' is remembered, but the none setting for 'switch to close-up or distant view' is not remembered. I tried to manually set this in the palapelirc, but couldn't figure out how to record 'None'. Reproducible: Always Steps to Reproduce: 1. Click clear button next to a trigger for an interactor in the Mouse interaction settings. 2. Close Palapeli and restart it. 3. Original trigger for the interactor is remembered.
If I change my palapelirc to have a line "ToggleCloseUp=NoButton;NoModifier" under [Mouse Interaction] I can get Palapeli to start with ToggleCloseUp set to NoButton which almost works. It's probably a separate bug, but when ToggleCloseUp is set to NoButton;NoModifier ToggleCloseUp is called whenever I press Alt, and my mouse jumps. I notice in the source of engine/trigger.cpp that NoButton has a value of 0, while MouseInputButton::clearTrigger() results in a Trigger::m_button value of -1 (which displays as 'None'). Palapeli's behaviour is as I expect it should be when the m_button value is -1. My interpretation is that Interactors are never expected to be disabled, and are expected to have a valid trigger. Using the clear button is breaking the trigger in such a way that the code happens to fail cleanly. The NoButton trigger mode is baffling to me - I'm not sure where this kind of behaviour could be expected, but it seems to be deliberate, and I'm not going to condemn it simply because I haven't thought of its use. I was hoping to write a simple patch to accept a value from the config file that would produce the same result as the clear button, but I'm now unsure that that would be the right approach.
(In reply to comment #0) > I click the clear button next to 'Switch to close-up or distant view' in > 'Mouse interaction' in the configuration window (so that I can use > middle-button for 'move viewport by dragging' as it should be ...). The default for 'move viewport' is right mouse-button. It has been for 4 years or more. Of course, you are at liberty to change it to middle button, but you will need 'Switch to close-up or distant view' if you wish to try a large puzzle (>= 300 pieces) and especially if you go above 1000 pieces. So it is best to set that option to some other button combination. > I click Apply, and happily proceed to middle-button drag my viewport around. When I > close and restart Palapeli the middle-button setting for 'move viewport by > dragging' is remembered, but the none setting for 'switch to close-up or > distant view' is not remembered. I tried to manually set this in the > palapelirc, but couldn't figure out how to record 'None'. It looks as though saving the None state is not supported. Nothing goes into the config file, so when you restart Palapeli it resets the default for 'Switch to close-up etc.'.
(In reply to comment #1) > If I change my palapelirc to have a line "ToggleCloseUp=NoButton;NoModifier" > under [Mouse Interaction] I can get Palapeli to start with ToggleCloseUp set > to NoButton which almost works. It's probably a separate bug, but when > ToggleCloseUp is set to NoButton;NoModifier ToggleCloseUp is called whenever > I press Alt, and my mouse jumps. Editing config files is at your own risk and is not supported... :-) FWICT, looking at the source code, NoButton;NoModifier is used as an "invalid" value. > My interpretation is that Interactors are never expected to be disabled, and > are expected to have a valid trigger. Using the clear button is breaking the > trigger in such a way that the code happens to fail cleanly. I think you might be right. I am not sure what the original author's intention was. If you like, you can set 'Switch to close-up etc.' to right mouse-button or some other combination of buttons and modifier keys and that setting should be saved and restored between runs. Any patch you write would need to thread its way through various signals until TriggerMapper::setAssociations() is reached and stores -1 and TriggerMapper::readSettings() would need to interprete and act on that correctly.
This seems to work with current KF5 version