UI glitch: entering float numerical data
In the Inspector and in the edit mode bar (the bar which appears at the bottom of the screen when an object is being edited), entering numeric data with floating point is cumbersome, because the edit box keeps supplying 0's to "fill the pattern". For instance, to enter the value -1.75 in one of those fields:
0) select the whole current value (to start from scratch)
1) key '-': "-" is displayed
2) key '1': "-1.00" is displayed
3) no more digits can be entered after the point directly; so:
4) press [Right] to skip the decimal point
5) press [Del] to delete the first 0: "-1.0" is displayed
6) key '7': "-1.70" is displayed
7) press [Del] to delete the other '0': "-1.7" is displayed
8) key '5': "-1.75" is finally displayed
Note: if both 0's are deleted together ("-1.00" => "-1.") the second '0' reappears after entering the '7'.
I think there should be an easier way to enter those data.
This does NOT happen for ALL float numbers; for instance entering floats in dialogues (for instance, the "Style | General..." dlg box) is straightforward. Inspector and edit tool bar are special in that the element worked on changes dynamically for each change to the value (which sometime is useful and sometime is not): are two things -- auto 0-ing and dynamic change -- connected?
Does this bother anybody else or am I particularly picky?
Thanks,
M.
Comments
Never too picky. I agree that there is no reason for these controls to act differently than the ones in Style. I'm taking a look on this one.
In reply to Never too picky. I agree that by [DELETED] 5
Ok, if you look into this one, I'll look into the other.
I suggest you start by looking at what happens in the Inspector and Edit tool dlg box apply() function: perhaps the value is read, acted upon and then set again into the control, which would re-format the textual representation of the value.
Thanks,
M.
In reply to Ok, if you look into this by Miwarre
It's exactly this. At least in the edittools, when the user enters a value, the signal is triggered, and the value is set again. An easy way to fix it is to compare the two values before settings them again but it looks ugly. I will try to look further and make a distinction between an edit in the score and an edit in the spinbox.
In reply to It's exactly this. At least by [DELETED] 5
Is an edit in the score possible at all, when the edit tool panel is open? I thought that by clicking on the score, one leaves the edit mode.
Of course the Inspector is different. But I think that the signal triggered by an edit in the score and an edit in the Inspector should be different; by connecting them to different slots (possibly sharing some underlying code) the distinction should be kept.
But I admit I could not understand the Inspector work flow 100%...
Thanks,
M.
In reply to Possibly a stupid remark but... by Miwarre
When the edittools panel is open, user can still move a note with left / right arrows.
It think the workflow originating this issue to be as follows:
1) A change in an inspector value triggers the apply() method of the relevant widget
2) Most, if not all, the apply() methods end with a call to MuseScore::endCmd();
3) MuseScore::endCmd() resets the selection to the current element
4) Resetting the selection triggers a call to Inspector::setElement() which re-format the display text of all inspector values
I am working on a fix; rather than altering the current behaviour of MuseScore::endCmd(), which is probably required by the 'big picture':
1) I added a bool flag, _inspectorEdit, which is set by each inspector (or inspector sub-widgets) apply() method.
2) Inspector::setElement resets the flag to false and returns without doing anything if the flag is true and the element being set is the same already set into the inspector.
Preliminary tests seem fine; I'll post a pull request if no obvious problem arises.
Thanks,
M.
I know the Inspector is being worked on, but this issue is back again in the Inspector (not in the EditTools widget).
M.
In reply to Regression! by Miwarre
Should work again...
In reply to Should work again... by [DELETED] 3
Indeed! Thank you!
I noticed your way of managing the _InspectorEdit flag: definitely more elegant than my previous solution.
I also noticed that you started replacing Qt containers (QList and similar) with STD containers: is this a guide line / requirement from now on?
Thanks,
M:
In reply to Indeed! Thank you! I noticed by Miwarre
Qt container are nice to use but have some code and runtime overhead.
With the use of c++11 features we enabled recently STL container classes are nearly as
easy to use as the Qt ones. Especially of help are the keywords "auto" and the new
range based for ("for (int i : container)") which can replace the qt foreach macro.
So as you noticed the new policy is to use STL container instead of the Qt variant.