ID: | 896 |
From: | ge...@igor2.repo.hu |
Date: | Sun, 17 Sep 2017 10:55:19 +0200 (CEST) |
Subject: | [pcb-rnd] does anyone use the mark (ctrm+m)? (was Re: marker still showing |
replies: | 897 from miloh <fr...@gmail.com> , 898 from John Griessen <jo...@cibolo.com> , 899 from Dave McGuire <mc...@neurotica.com> , 900 from ge...@igor2.repo.hu |
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1042080767-1505638343=:27212 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <alpine.DEB.2.00.1709171054442.27212@igor2priv> On Sun, 17 Sep 2017, Alain Vigne wrote: > Me again... >=20 > I don't know if it is intended or not, but: > 1. Open the 7805 tutorial >> ./pcb-rnd ../doc/tutorials/7805/7805.pcb > 2. Left-click the capacitor, keep the mouse clicked, move your mouse > =C2=A0 -> A red X marks the location of your button click. > =C2=A0 -> A ghost of cap. follows your mouse, saying you are moving the > component. > =C2=A03. Hit ESCape key before releasing the mouse key > =C2=A0 -> You corrected the bug, now, the move is canceled. Fine >=20 >=20 > But, the red X (marker) is still there... ! > (I think it should disappear, no ?) Moving this to the mailing list The whole marker thing is a bug in itself.... Nobody understands what it is= =20 intended for and the code uses it random ways - probably developers never= =20 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 shoul= d=20 probably clean this up a bit, as in the current state it looks like if it d= id=20 random wierd things. My experience of the bugs: The mark is sometimes placed as part of a random operation, for no appearan= t=20 reason. Some operations remove the mark at the end, some cancels/undos also= =20 remove the mark. Others don't, and many operations don't place the mark. Wh= en=20 an operation is messing with the mark, the user set mark is moved, so the u= ser=20 loses the original mark position. This has thaught users not to try to use = the=20 mark as it randomly jumped away. Examples of inconsistencies: 1. start drawing a line; mark is placed; press esc after a few line section= s,=20 mark is removed; esc sounds like 'cancel', but it doesn't really cancel you= r=20 lines, merely finishes the mode: switching to the arrow mode with F11 or th= e=20 toolbar icon does the same, so it feels like the mark is only during the=20 drawing 2. do the same, but instead of esc, undo a few of the last lines; you go on= =20 drawing a new line from the original end of the trace where you undoed, but= the=20 mark is not moved there; so the mark doesn't mark where you last started to= =20 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 y= ou=20 finish (while in line it got removed for esc, that simply finished drawing= =20 mode); switching to arrow mode won't remove it. so it's not like in point1,= =20 marking the start during draw, but it persist 4. now draw a polygon using the rectangle tool: no mark at all, neither dur= ing=20 draw, nor persisting after the drawing 5. grab a polygon point for move; while moving it, there'll be a mark at th= e=20 original position; it's gone after the move - except if the operation is=20 cancelled with esc. I'd expect exactly the opposite to happen: if it has to= =20 mess with the mark, it's more useful to see where I succesfully moved a poi= nt=20 from than marking where I did _not_ do a change. We have undo anyway, so=20 marking the move start doesn't make much sense either. 6. draw arc -> no mark; start drawing lines, switch to drawing arc in the= =20 middle, the arc continues your track from the endpoint of the last line, bu= t=20 the mark is not removed, as if you were still in the line drawing mode... b= ut=20 if you started your track with arc then switched to line in the middle, the= =20 mark is placed at the end if the first line segment, which sounds totally= =20 broken 7. placing an element won't put a mark there; moving an unselected element = will=20 move the mark to the original position; moving a selected element won't do = a=20 mark(!). This seems to be universal to all objects: moving by drag&drop mar= ks=20 original location, unless the object is selected 8. drag&drop moving a line endpoint does a mark during the move, and it is = left=20 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=20 if mark was off before the operation Regards, Igor2 --0-1042080767-1505638343=:27212--
Reply subtree:
896 [pcb-rnd] does anyone use the mark (ctrm+m)? (was Re: marker still showing from ge...@igor2.repo.hu
897 Re: [pcb-rnd] does anyone use the mark (ctrm+m)? (was Re: marker from miloh <fr...@gmail.com>
898 Re: [pcb-rnd] does anyone use the mark (ctrm+m)? (was Re: marker from John Griessen <jo...@cibolo.com>
899 Re: [pcb-rnd] does anyone use the mark (ctrm+m)? (was Re: marker from Dave McGuire <mc...@neurotica.com>
900 [pcb-rnd] mark: cleanup proposal from ge...@igor2.repo.hu
901 Re: [pcb-rnd] mark: cleanup proposal from John Griessen <jo...@cibolo.com>
902 Re: [pcb-rnd] mark: cleanup proposal from Dave McGuire <mc...@neurotica.com>