Index: doc/devlog/20171004_plan_mark.html =================================================================== --- doc/devlog/20171004_plan_mark.html (nonexistent) +++ doc/devlog/20171004_plan_mark.html (revision 11915) @@ -0,0 +1,96 @@ + +
++thanks for the answers, I have a better picture on how our users use the +mark. Here's my proposal for the cleanup/bugfixes: + +1. we should distinguish between user placed marks and automatic marks. +Whenever there's an user placed mark, only the mark related actions should +remove or move the mark. In other words, if the user explicitly placed the +mark, side effect of non-mark-actions shouldn't change the mark. + +2. drag&drop-like operations: for those mouse actions that start with a +click then move then release, if there is no explicit user mark, the code +should place the mark at click and remove it after the release. + +3. multi-click, non-drag&drop-like operations shouldn't ever change the +mark. (There are too many ways such an operation can end it would be very +hard to make it work like 2.) + +This means if you want to use the mark for your line length/orientation, +you would need to manually place it when starting to draw the line. + ++ +examples on how the current implementation is broken
+ ++The whole marker thing is a bug in itself.... Nobody understands what it is +intended for and the code uses it random ways - probably developers never +understood it either so each part of the code does something randomly. + +If anyone is using the mark, please let me know your use patterns. We should +probably clean this up a bit, as in the current state it looks like if it did +random wierd things. + +My experience of the bugs: + +The mark is sometimes placed as part of a random operation, for no appearant +reason. Some operations remove the mark at the end, some cancels/undos also +remove the mark. Others don't, and many operations don't place the mark. When +an operation is messing with the mark, the user set mark is moved, so the user +loses the original mark position. This has thaught users not to try to use the +mark as it randomly jumped away. + +Examples of inconsistencies: + +1. start drawing a line; mark is placed; press esc after a few line sections, +mark is removed; esc sounds like 'cancel', but it doesn't really cancel your +lines, merely finishes the mode: switching to the arrow mode with F11 or the +toolbar icon does the same, so it feels like the mark is only during the +drawing + +2. do the same, but instead of esc, undo a few of the last lines; you go on +drawing a new line from the original end of the trace where you undoed, but the +mark is not moved there; so the mark doesn't mark where you last started to +draw lines, but where you first started to draw lines + +3. draw a polygon: mark is placed on the start, but is _not_ removed when you +finish (while in line it got removed for esc, that simply finished drawing +mode); switching to arrow mode won't remove it. so it's not like in point1, +marking the start during draw, but it persist + +4. now draw a polygon using the rectangle tool: no mark at all, neither during +draw, nor persisting after the drawing + +5. grab a polygon point for move; while moving it, there'll be a mark at the +original position; it's gone after the move - except if the operation is +cancelled with esc. I'd expect exactly the opposite to happen: if it has to +mess with the mark, it's more useful to see where I succesfully moved a point +from than marking where I did _not_ do a change. We have undo anyway, so +marking the move start doesn't make much sense either. + +6. draw arc -> no mark; start drawing lines, switch to drawing arc in the +middle, the arc continues your track from the endpoint of the last line, but +the mark is not removed, as if you were still in the line drawing mode... but +if you started your track with arc then switched to line in the middle, the +mark is placed at the end if the first line segment, which sounds totally +broken + +7. placing an element won't put a mark there; moving an unselected element will +move the mark to the original position; moving a selected element won't do a +mark(!). This seems to be universal to all objects: moving by drag&drop marks +original location, unless the object is selected + +8. drag&drop moving a line endpoint does a mark during the move, and it is left +there after 'esc' but removed after a succesful move; same as in 5. + +9. ctrl+drag&drop leaves a mark at the original point for some reason, but only +if mark was off before the operation +