Re: [Kicad-developers] Immediate mode actions
Jeff, I just finished testing this and it looks good. It wasn't an exhaustive test so if I find any issues I will file a bug report. Go ahead and push the board and footprint editor changes. Thanks, Wayne On 6/23/19 6:35 PM, Jeff Young wrote: > There haven’t been any additional comments on this. Is everyone happy with > it? Should I push the changes to Pcbnew? > > Cheers, > Jeff. > > >> On 19 Jun 2019, at 18:36, Jeff Young wrote: >> >> New bits are in…. >> >>> On 19 Jun 2019, at 18:04, Wayne Stambaugh wrote: >>> >>> For new features like bus unfolding, we have some leeway to decide how >>> we want to handle things. I think in the case of bus unfolding, >>> selecting the wire tool makes sense. Whether or not drawing a wire >>> should immediately happen after unfolding a bus is debatable. I'm open >>> to ideas on this. >>> >>> On 6/19/19 10:27 AM, Jeff Young wrote: I take the question back. It will be *far* easier to implement it like “start wire”, so unless anyone objects I’ll go that way. Cheers, Jeff. > On 19 Jun 2019, at 15:18, Jeff Young wrote: > > What about “unfold bus”? Leaves you in the wire tool (like “start > wire”), or in the previous tool (like “move”)? > >> On 19 Jun 2019, at 15:08, Jeff Young wrote: >> >> Ahh, I misunderstood your earlier comments. When you said they should >> act the same I thought you meant both like the old immediate action >> behaviour, not both like the old toolbar behaviour. >> >>> On 19 Jun 2019, at 13:46, Wayne Stambaugh wrote: >>> >>> The immediate actions are back to the same behavior as the initial >>> commit (one shot) and using the toolbar or menu to select a tool now >>> stacks tools so each escape to exit the current tool brings up the >>> previous tool until you finally end up back at the selection tool. I >>> think users are going to expect exiting a tool to always end up back at >>> the selection tool not the previously selected tool. Here is a synopsis >>> of the behavior I think we should aim for: >>> >>> Immediate actions: >>> >>> 1. The appropriate tool should be enabled and begin drawing at the >>> current cursor location (works). >>> 2. When the tool is busy drawing, the escape key should cancel the >>> current edit and the selected tool should remain enabled. Immediate >>> actions like move, rotate, mirror, etc. should be blocked until the tool >>> is idle but I'm open to suggestion on this. I can see the utility in >>> canceling the edit and performing the requested action. >>> 3. When the tool is idle, the escape key should exit the tool and return >>> to the selection tool. Immediate actions like move, rotate, mirror, >>> etc. should perform the expected operation and return to the selected >>> tool. >>> >>> Using the toolbar and menu to select a tool should behave the same as >>> above except that no drawing begins at the current cursor position >>> because the cursor position is meaningless while it's over a toolbar >>> button or menu entry. >>> >>> I hope I am explaining this well enough. >>> >>> On 6/18/19 5:35 PM, Jeff Young wrote: OK, next attempt is in. ;) > On 18 Jun 2019, at 21:07, Wayne Stambaugh > wrote: > > Better but now the second (third, fourth, fifth, ...) escape key does > not exit after the first escape key cancels the immediate action. > Using > the toolbar or menu to select the tool does work correctly. One other > new oddity is that selecting a second tool using the toolbar or menu > will result in the previous tool being selected rather than the > selection tool after escape is pressed when the tool is idle. I think > you may have gone too far the other way. > > On 6/18/19 3:52 PM, Jeff Young wrote: >> Hi Wayne, >> >> I checked in some new code. Give it a go when you get a chance. >> >> Cheers, >> Jeff. >> >> >>> On 18 Jun 2019, at 13:01, Wayne Stambaugh >>> wrote: >>> >>> Wire, bus, graphic line, and sheet but only when enabled with an >>> immediate hotkey. When I enable the tool via a toolbar button or >>> selecting a menu entry, then the behavior is the same as the legacy >>> tool >>> framework. It really should not matter how a tool is enabled, only >>> the >>> initial behavior. >>> >>> On 6/18/2019 7:53 AM, Jeff Young wrote: Hi Wayne, I wrote the whole PushTool/PopTool stuff exactly for that case. Which action in particular is going back to the SelectionTool? (Note that some are “supposed” to. If you click on a tool in the
Re: [Kicad-developers] Immediate mode actions
I still have some more testing to do. I have a bug fix I need to merge first thing in the morning. I should have time to test it tomorrow. Wayne On 6/23/19 6:35 PM, Jeff Young wrote: > There haven’t been any additional comments on this. Is everyone happy with > it? Should I push the changes to Pcbnew? > > Cheers, > Jeff. > > >> On 19 Jun 2019, at 18:36, Jeff Young wrote: >> >> New bits are in…. >> >>> On 19 Jun 2019, at 18:04, Wayne Stambaugh wrote: >>> >>> For new features like bus unfolding, we have some leeway to decide how >>> we want to handle things. I think in the case of bus unfolding, >>> selecting the wire tool makes sense. Whether or not drawing a wire >>> should immediately happen after unfolding a bus is debatable. I'm open >>> to ideas on this. >>> >>> On 6/19/19 10:27 AM, Jeff Young wrote: I take the question back. It will be *far* easier to implement it like “start wire”, so unless anyone objects I’ll go that way. Cheers, Jeff. > On 19 Jun 2019, at 15:18, Jeff Young wrote: > > What about “unfold bus”? Leaves you in the wire tool (like “start > wire”), or in the previous tool (like “move”)? > >> On 19 Jun 2019, at 15:08, Jeff Young wrote: >> >> Ahh, I misunderstood your earlier comments. When you said they should >> act the same I thought you meant both like the old immediate action >> behaviour, not both like the old toolbar behaviour. >> >>> On 19 Jun 2019, at 13:46, Wayne Stambaugh wrote: >>> >>> The immediate actions are back to the same behavior as the initial >>> commit (one shot) and using the toolbar or menu to select a tool now >>> stacks tools so each escape to exit the current tool brings up the >>> previous tool until you finally end up back at the selection tool. I >>> think users are going to expect exiting a tool to always end up back at >>> the selection tool not the previously selected tool. Here is a synopsis >>> of the behavior I think we should aim for: >>> >>> Immediate actions: >>> >>> 1. The appropriate tool should be enabled and begin drawing at the >>> current cursor location (works). >>> 2. When the tool is busy drawing, the escape key should cancel the >>> current edit and the selected tool should remain enabled. Immediate >>> actions like move, rotate, mirror, etc. should be blocked until the tool >>> is idle but I'm open to suggestion on this. I can see the utility in >>> canceling the edit and performing the requested action. >>> 3. When the tool is idle, the escape key should exit the tool and return >>> to the selection tool. Immediate actions like move, rotate, mirror, >>> etc. should perform the expected operation and return to the selected >>> tool. >>> >>> Using the toolbar and menu to select a tool should behave the same as >>> above except that no drawing begins at the current cursor position >>> because the cursor position is meaningless while it's over a toolbar >>> button or menu entry. >>> >>> I hope I am explaining this well enough. >>> >>> On 6/18/19 5:35 PM, Jeff Young wrote: OK, next attempt is in. ;) > On 18 Jun 2019, at 21:07, Wayne Stambaugh > wrote: > > Better but now the second (third, fourth, fifth, ...) escape key does > not exit after the first escape key cancels the immediate action. > Using > the toolbar or menu to select the tool does work correctly. One other > new oddity is that selecting a second tool using the toolbar or menu > will result in the previous tool being selected rather than the > selection tool after escape is pressed when the tool is idle. I think > you may have gone too far the other way. > > On 6/18/19 3:52 PM, Jeff Young wrote: >> Hi Wayne, >> >> I checked in some new code. Give it a go when you get a chance. >> >> Cheers, >> Jeff. >> >> >>> On 18 Jun 2019, at 13:01, Wayne Stambaugh >>> wrote: >>> >>> Wire, bus, graphic line, and sheet but only when enabled with an >>> immediate hotkey. When I enable the tool via a toolbar button or >>> selecting a menu entry, then the behavior is the same as the legacy >>> tool >>> framework. It really should not matter how a tool is enabled, only >>> the >>> initial behavior. >>> >>> On 6/18/2019 7:53 AM, Jeff Young wrote: Hi Wayne, I wrote the whole PushTool/PopTool stuff exactly for that case. Which action in particular is going back to the SelectionTool? (Note that some are “supposed” to. If you click on a tool in the toolbar, or select it from the Place menu, then
Re: [Kicad-developers] Immediate mode actions
There haven’t been any additional comments on this. Is everyone happy with it? Should I push the changes to Pcbnew? Cheers, Jeff. > On 19 Jun 2019, at 18:36, Jeff Young wrote: > > New bits are in…. > >> On 19 Jun 2019, at 18:04, Wayne Stambaugh wrote: >> >> For new features like bus unfolding, we have some leeway to decide how >> we want to handle things. I think in the case of bus unfolding, >> selecting the wire tool makes sense. Whether or not drawing a wire >> should immediately happen after unfolding a bus is debatable. I'm open >> to ideas on this. >> >> On 6/19/19 10:27 AM, Jeff Young wrote: >>> I take the question back. It will be *far* easier to implement it like >>> “start wire”, so unless anyone objects I’ll go that way. >>> >>> Cheers, >>> Jeff. >>> On 19 Jun 2019, at 15:18, Jeff Young wrote: What about “unfold bus”? Leaves you in the wire tool (like “start wire”), or in the previous tool (like “move”)? > On 19 Jun 2019, at 15:08, Jeff Young wrote: > > Ahh, I misunderstood your earlier comments. When you said they should > act the same I thought you meant both like the old immediate action > behaviour, not both like the old toolbar behaviour. > >> On 19 Jun 2019, at 13:46, Wayne Stambaugh wrote: >> >> The immediate actions are back to the same behavior as the initial >> commit (one shot) and using the toolbar or menu to select a tool now >> stacks tools so each escape to exit the current tool brings up the >> previous tool until you finally end up back at the selection tool. I >> think users are going to expect exiting a tool to always end up back at >> the selection tool not the previously selected tool. Here is a synopsis >> of the behavior I think we should aim for: >> >> Immediate actions: >> >> 1. The appropriate tool should be enabled and begin drawing at the >> current cursor location (works). >> 2. When the tool is busy drawing, the escape key should cancel the >> current edit and the selected tool should remain enabled. Immediate >> actions like move, rotate, mirror, etc. should be blocked until the tool >> is idle but I'm open to suggestion on this. I can see the utility in >> canceling the edit and performing the requested action. >> 3. When the tool is idle, the escape key should exit the tool and return >> to the selection tool. Immediate actions like move, rotate, mirror, >> etc. should perform the expected operation and return to the selected >> tool. >> >> Using the toolbar and menu to select a tool should behave the same as >> above except that no drawing begins at the current cursor position >> because the cursor position is meaningless while it's over a toolbar >> button or menu entry. >> >> I hope I am explaining this well enough. >> >> On 6/18/19 5:35 PM, Jeff Young wrote: >>> OK, next attempt is in. ;) >>> On 18 Jun 2019, at 21:07, Wayne Stambaugh wrote: Better but now the second (third, fourth, fifth, ...) escape key does not exit after the first escape key cancels the immediate action. Using the toolbar or menu to select the tool does work correctly. One other new oddity is that selecting a second tool using the toolbar or menu will result in the previous tool being selected rather than the selection tool after escape is pressed when the tool is idle. I think you may have gone too far the other way. On 6/18/19 3:52 PM, Jeff Young wrote: > Hi Wayne, > > I checked in some new code. Give it a go when you get a chance. > > Cheers, > Jeff. > > >> On 18 Jun 2019, at 13:01, Wayne Stambaugh >> wrote: >> >> Wire, bus, graphic line, and sheet but only when enabled with an >> immediate hotkey. When I enable the tool via a toolbar button or >> selecting a menu entry, then the behavior is the same as the legacy >> tool >> framework. It really should not matter how a tool is enabled, only >> the >> initial behavior. >> >> On 6/18/2019 7:53 AM, Jeff Young wrote: >>> Hi Wayne, >>> >>> I wrote the whole PushTool/PopTool stuff exactly for that case. >>> Which action in particular is going back to the SelectionTool? >>> >>> (Note that some are “supposed” to. If you click on a tool in the >>> toolbar, or select it from the Place menu, then cancelling should >>> take you back to the SelectionTool. However, if you use the >>> context menu or a hotkey, it should push and then pop the drawing >>> tool. Not to say that it’s not buggy, or that the design behaviour >>> isn’t optimal.)
Re: [Kicad-developers] Immediate mode actions
New bits are in…. > On 19 Jun 2019, at 18:04, Wayne Stambaugh wrote: > > For new features like bus unfolding, we have some leeway to decide how > we want to handle things. I think in the case of bus unfolding, > selecting the wire tool makes sense. Whether or not drawing a wire > should immediately happen after unfolding a bus is debatable. I'm open > to ideas on this. > > On 6/19/19 10:27 AM, Jeff Young wrote: >> I take the question back. It will be *far* easier to implement it like >> “start wire”, so unless anyone objects I’ll go that way. >> >> Cheers, >> Jeff. >> >>> On 19 Jun 2019, at 15:18, Jeff Young wrote: >>> >>> What about “unfold bus”? Leaves you in the wire tool (like “start wire”), >>> or in the previous tool (like “move”)? >>> On 19 Jun 2019, at 15:08, Jeff Young wrote: Ahh, I misunderstood your earlier comments. When you said they should act the same I thought you meant both like the old immediate action behaviour, not both like the old toolbar behaviour. > On 19 Jun 2019, at 13:46, Wayne Stambaugh wrote: > > The immediate actions are back to the same behavior as the initial > commit (one shot) and using the toolbar or menu to select a tool now > stacks tools so each escape to exit the current tool brings up the > previous tool until you finally end up back at the selection tool. I > think users are going to expect exiting a tool to always end up back at > the selection tool not the previously selected tool. Here is a synopsis > of the behavior I think we should aim for: > > Immediate actions: > > 1. The appropriate tool should be enabled and begin drawing at the > current cursor location (works). > 2. When the tool is busy drawing, the escape key should cancel the > current edit and the selected tool should remain enabled. Immediate > actions like move, rotate, mirror, etc. should be blocked until the tool > is idle but I'm open to suggestion on this. I can see the utility in > canceling the edit and performing the requested action. > 3. When the tool is idle, the escape key should exit the tool and return > to the selection tool. Immediate actions like move, rotate, mirror, > etc. should perform the expected operation and return to the selected > tool. > > Using the toolbar and menu to select a tool should behave the same as > above except that no drawing begins at the current cursor position > because the cursor position is meaningless while it's over a toolbar > button or menu entry. > > I hope I am explaining this well enough. > > On 6/18/19 5:35 PM, Jeff Young wrote: >> OK, next attempt is in. ;) >> >>> On 18 Jun 2019, at 21:07, Wayne Stambaugh wrote: >>> >>> Better but now the second (third, fourth, fifth, ...) escape key does >>> not exit after the first escape key cancels the immediate action. Using >>> the toolbar or menu to select the tool does work correctly. One other >>> new oddity is that selecting a second tool using the toolbar or menu >>> will result in the previous tool being selected rather than the >>> selection tool after escape is pressed when the tool is idle. I think >>> you may have gone too far the other way. >>> >>> On 6/18/19 3:52 PM, Jeff Young wrote: Hi Wayne, I checked in some new code. Give it a go when you get a chance. Cheers, Jeff. > On 18 Jun 2019, at 13:01, Wayne Stambaugh > wrote: > > Wire, bus, graphic line, and sheet but only when enabled with an > immediate hotkey. When I enable the tool via a toolbar button or > selecting a menu entry, then the behavior is the same as the legacy > tool > framework. It really should not matter how a tool is enabled, only > the > initial behavior. > > On 6/18/2019 7:53 AM, Jeff Young wrote: >> Hi Wayne, >> >> I wrote the whole PushTool/PopTool stuff exactly for that case. >> Which action in particular is going back to the SelectionTool? >> >> (Note that some are “supposed” to. If you click on a tool in the >> toolbar, or select it from the Place menu, then cancelling should >> take you back to the SelectionTool. However, if you use the context >> menu or a hotkey, it should push and then pop the drawing tool. Not >> to say that it’s not buggy, or that the design behaviour isn’t >> optimal.) >> >> Cheers, >> Jeff. >> >> PS: should I make the same changes to Pcbnew, or should be await >> more feedback? (Feedback on the forums has been uniformly positive >> so far, but pretty sparse with only 3 likes.) >> >>
Re: [Kicad-developers] Immediate mode actions
For new features like bus unfolding, we have some leeway to decide how we want to handle things. I think in the case of bus unfolding, selecting the wire tool makes sense. Whether or not drawing a wire should immediately happen after unfolding a bus is debatable. I'm open to ideas on this. On 6/19/19 10:27 AM, Jeff Young wrote: > I take the question back. It will be *far* easier to implement it like > “start wire”, so unless anyone objects I’ll go that way. > > Cheers, > Jeff. > >> On 19 Jun 2019, at 15:18, Jeff Young wrote: >> >> What about “unfold bus”? Leaves you in the wire tool (like “start wire”), >> or in the previous tool (like “move”)? >> >>> On 19 Jun 2019, at 15:08, Jeff Young wrote: >>> >>> Ahh, I misunderstood your earlier comments. When you said they should act >>> the same I thought you meant both like the old immediate action behaviour, >>> not both like the old toolbar behaviour. >>> On 19 Jun 2019, at 13:46, Wayne Stambaugh wrote: The immediate actions are back to the same behavior as the initial commit (one shot) and using the toolbar or menu to select a tool now stacks tools so each escape to exit the current tool brings up the previous tool until you finally end up back at the selection tool. I think users are going to expect exiting a tool to always end up back at the selection tool not the previously selected tool. Here is a synopsis of the behavior I think we should aim for: Immediate actions: 1. The appropriate tool should be enabled and begin drawing at the current cursor location (works). 2. When the tool is busy drawing, the escape key should cancel the current edit and the selected tool should remain enabled. Immediate actions like move, rotate, mirror, etc. should be blocked until the tool is idle but I'm open to suggestion on this. I can see the utility in canceling the edit and performing the requested action. 3. When the tool is idle, the escape key should exit the tool and return to the selection tool. Immediate actions like move, rotate, mirror, etc. should perform the expected operation and return to the selected tool. Using the toolbar and menu to select a tool should behave the same as above except that no drawing begins at the current cursor position because the cursor position is meaningless while it's over a toolbar button or menu entry. I hope I am explaining this well enough. On 6/18/19 5:35 PM, Jeff Young wrote: > OK, next attempt is in. ;) > >> On 18 Jun 2019, at 21:07, Wayne Stambaugh wrote: >> >> Better but now the second (third, fourth, fifth, ...) escape key does >> not exit after the first escape key cancels the immediate action. Using >> the toolbar or menu to select the tool does work correctly. One other >> new oddity is that selecting a second tool using the toolbar or menu >> will result in the previous tool being selected rather than the >> selection tool after escape is pressed when the tool is idle. I think >> you may have gone too far the other way. >> >> On 6/18/19 3:52 PM, Jeff Young wrote: >>> Hi Wayne, >>> >>> I checked in some new code. Give it a go when you get a chance. >>> >>> Cheers, >>> Jeff. >>> >>> On 18 Jun 2019, at 13:01, Wayne Stambaugh wrote: Wire, bus, graphic line, and sheet but only when enabled with an immediate hotkey. When I enable the tool via a toolbar button or selecting a menu entry, then the behavior is the same as the legacy tool framework. It really should not matter how a tool is enabled, only the initial behavior. On 6/18/2019 7:53 AM, Jeff Young wrote: > Hi Wayne, > > I wrote the whole PushTool/PopTool stuff exactly for that case. > Which action in particular is going back to the SelectionTool? > > (Note that some are “supposed” to. If you click on a tool in the > toolbar, or select it from the Place menu, then cancelling should > take you back to the SelectionTool. However, if you use the context > menu or a hotkey, it should push and then pop the drawing tool. Not > to say that it’s not buggy, or that the design behaviour isn’t > optimal.) > > Cheers, > Jeff. > > PS: should I make the same changes to Pcbnew, or should be await more > feedback? (Feedback on the forums has been uniformly positive so > far, but pretty sparse with only 3 likes.) > > >> On 18 Jun 2019, at 12:48, Wayne Stambaugh >> wrote: >> >> Hey Jeff, >> >> I spent some time this morning playing around with the "immediate" >> hotkeys in Eeschema and it's better but there
Re: [Kicad-developers] Immediate mode actions
If you are unsure, spin a quick 5.1 branch build for comparison purposes. On 6/19/19 10:08 AM, Jeff Young wrote: > Ahh, I misunderstood your earlier comments. When you said they should act > the same I thought you meant both like the old immediate action behaviour, > not both like the old toolbar behaviour. > >> On 19 Jun 2019, at 13:46, Wayne Stambaugh wrote: >> >> The immediate actions are back to the same behavior as the initial >> commit (one shot) and using the toolbar or menu to select a tool now >> stacks tools so each escape to exit the current tool brings up the >> previous tool until you finally end up back at the selection tool. I >> think users are going to expect exiting a tool to always end up back at >> the selection tool not the previously selected tool. Here is a synopsis >> of the behavior I think we should aim for: >> >> Immediate actions: >> >> 1. The appropriate tool should be enabled and begin drawing at the >> current cursor location (works). >> 2. When the tool is busy drawing, the escape key should cancel the >> current edit and the selected tool should remain enabled. Immediate >> actions like move, rotate, mirror, etc. should be blocked until the tool >> is idle but I'm open to suggestion on this. I can see the utility in >> canceling the edit and performing the requested action. >> 3. When the tool is idle, the escape key should exit the tool and return >> to the selection tool. Immediate actions like move, rotate, mirror, >> etc. should perform the expected operation and return to the selected tool. >> >> Using the toolbar and menu to select a tool should behave the same as >> above except that no drawing begins at the current cursor position >> because the cursor position is meaningless while it's over a toolbar >> button or menu entry. >> >> I hope I am explaining this well enough. >> >> On 6/18/19 5:35 PM, Jeff Young wrote: >>> OK, next attempt is in. ;) >>> On 18 Jun 2019, at 21:07, Wayne Stambaugh wrote: Better but now the second (third, fourth, fifth, ...) escape key does not exit after the first escape key cancels the immediate action. Using the toolbar or menu to select the tool does work correctly. One other new oddity is that selecting a second tool using the toolbar or menu will result in the previous tool being selected rather than the selection tool after escape is pressed when the tool is idle. I think you may have gone too far the other way. On 6/18/19 3:52 PM, Jeff Young wrote: > Hi Wayne, > > I checked in some new code. Give it a go when you get a chance. > > Cheers, > Jeff. > > >> On 18 Jun 2019, at 13:01, Wayne Stambaugh wrote: >> >> Wire, bus, graphic line, and sheet but only when enabled with an >> immediate hotkey. When I enable the tool via a toolbar button or >> selecting a menu entry, then the behavior is the same as the legacy tool >> framework. It really should not matter how a tool is enabled, only the >> initial behavior. >> >> On 6/18/2019 7:53 AM, Jeff Young wrote: >>> Hi Wayne, >>> >>> I wrote the whole PushTool/PopTool stuff exactly for that case. Which >>> action in particular is going back to the SelectionTool? >>> >>> (Note that some are “supposed” to. If you click on a tool in the >>> toolbar, or select it from the Place menu, then cancelling should take >>> you back to the SelectionTool. However, if you use the context menu or >>> a hotkey, it should push and then pop the drawing tool. Not to say >>> that it’s not buggy, or that the design behaviour isn’t optimal.) >>> >>> Cheers, >>> Jeff. >>> >>> PS: should I make the same changes to Pcbnew, or should be await more >>> feedback? (Feedback on the forums has been uniformly positive so far, >>> but pretty sparse with only 3 likes.) >>> >>> On 18 Jun 2019, at 12:48, Wayne Stambaugh wrote: Hey Jeff, I spent some time this morning playing around with the "immediate" hotkeys in Eeschema and it's better but there is still one annoying difference from the legacy behavior. When cancelling (escape key) a drawing in progress, the drawing is aborted, the current tool is canceled, and the selection tool is enable. The legacy behavior was abort the drawing in progress and keep the current tool enabled. The current tool would only be canceled when it was not busy drawing something. It's rather cumbersome to have to keep enabling the drawing tool every time you exit a drawing when you make a mistake. Cheers, Wayne On 6/15/2019 3:45 PM, Jeff Young wrote: > I’ve checked in code which makes the drawing hotkeys “immediate” in > Eeschema and the Symbol Editor. It was more involved than I was
Re: [Kicad-developers] Immediate mode actions
Another scenario: I’m in the Wire Tool. I go to the Library Browser, look around, and then double-click a symbol. Back in the canvas, with the Add Symbol tool now active, I click to place my new symbol. What now? Add Symbol stays active, or back to the Wire Tool? Cheers, Jeff. > On 19 Jun 2019, at 15:27, Jeff Young wrote: > > I take the question back. It will be *far* easier to implement it like > “start wire”, so unless anyone objects I’ll go that way. > > Cheers, > Jeff. > >> On 19 Jun 2019, at 15:18, Jeff Young wrote: >> >> What about “unfold bus”? Leaves you in the wire tool (like “start wire”), >> or in the previous tool (like “move”)? >> >>> On 19 Jun 2019, at 15:08, Jeff Young wrote: >>> >>> Ahh, I misunderstood your earlier comments. When you said they should act >>> the same I thought you meant both like the old immediate action behaviour, >>> not both like the old toolbar behaviour. >>> On 19 Jun 2019, at 13:46, Wayne Stambaugh wrote: The immediate actions are back to the same behavior as the initial commit (one shot) and using the toolbar or menu to select a tool now stacks tools so each escape to exit the current tool brings up the previous tool until you finally end up back at the selection tool. I think users are going to expect exiting a tool to always end up back at the selection tool not the previously selected tool. Here is a synopsis of the behavior I think we should aim for: Immediate actions: 1. The appropriate tool should be enabled and begin drawing at the current cursor location (works). 2. When the tool is busy drawing, the escape key should cancel the current edit and the selected tool should remain enabled. Immediate actions like move, rotate, mirror, etc. should be blocked until the tool is idle but I'm open to suggestion on this. I can see the utility in canceling the edit and performing the requested action. 3. When the tool is idle, the escape key should exit the tool and return to the selection tool. Immediate actions like move, rotate, mirror, etc. should perform the expected operation and return to the selected tool. Using the toolbar and menu to select a tool should behave the same as above except that no drawing begins at the current cursor position because the cursor position is meaningless while it's over a toolbar button or menu entry. I hope I am explaining this well enough. On 6/18/19 5:35 PM, Jeff Young wrote: > OK, next attempt is in. ;) > >> On 18 Jun 2019, at 21:07, Wayne Stambaugh wrote: >> >> Better but now the second (third, fourth, fifth, ...) escape key does >> not exit after the first escape key cancels the immediate action. Using >> the toolbar or menu to select the tool does work correctly. One other >> new oddity is that selecting a second tool using the toolbar or menu >> will result in the previous tool being selected rather than the >> selection tool after escape is pressed when the tool is idle. I think >> you may have gone too far the other way. >> >> On 6/18/19 3:52 PM, Jeff Young wrote: >>> Hi Wayne, >>> >>> I checked in some new code. Give it a go when you get a chance. >>> >>> Cheers, >>> Jeff. >>> >>> On 18 Jun 2019, at 13:01, Wayne Stambaugh wrote: Wire, bus, graphic line, and sheet but only when enabled with an immediate hotkey. When I enable the tool via a toolbar button or selecting a menu entry, then the behavior is the same as the legacy tool framework. It really should not matter how a tool is enabled, only the initial behavior. On 6/18/2019 7:53 AM, Jeff Young wrote: > Hi Wayne, > > I wrote the whole PushTool/PopTool stuff exactly for that case. > Which action in particular is going back to the SelectionTool? > > (Note that some are “supposed” to. If you click on a tool in the > toolbar, or select it from the Place menu, then cancelling should > take you back to the SelectionTool. However, if you use the context > menu or a hotkey, it should push and then pop the drawing tool. Not > to say that it’s not buggy, or that the design behaviour isn’t > optimal.) > > Cheers, > Jeff. > > PS: should I make the same changes to Pcbnew, or should be await more > feedback? (Feedback on the forums has been uniformly positive so > far, but pretty sparse with only 3 likes.) > > >> On 18 Jun 2019, at 12:48, Wayne Stambaugh >> wrote: >> >> Hey Jeff, >> >> I spent some time this morning playing around with the "immediate" >> hotkeys in
Re: [Kicad-developers] Immediate mode actions
I take the question back. It will be *far* easier to implement it like “start wire”, so unless anyone objects I’ll go that way. Cheers, Jeff. > On 19 Jun 2019, at 15:18, Jeff Young wrote: > > What about “unfold bus”? Leaves you in the wire tool (like “start wire”), or > in the previous tool (like “move”)? > >> On 19 Jun 2019, at 15:08, Jeff Young wrote: >> >> Ahh, I misunderstood your earlier comments. When you said they should act >> the same I thought you meant both like the old immediate action behaviour, >> not both like the old toolbar behaviour. >> >>> On 19 Jun 2019, at 13:46, Wayne Stambaugh wrote: >>> >>> The immediate actions are back to the same behavior as the initial >>> commit (one shot) and using the toolbar or menu to select a tool now >>> stacks tools so each escape to exit the current tool brings up the >>> previous tool until you finally end up back at the selection tool. I >>> think users are going to expect exiting a tool to always end up back at >>> the selection tool not the previously selected tool. Here is a synopsis >>> of the behavior I think we should aim for: >>> >>> Immediate actions: >>> >>> 1. The appropriate tool should be enabled and begin drawing at the >>> current cursor location (works). >>> 2. When the tool is busy drawing, the escape key should cancel the >>> current edit and the selected tool should remain enabled. Immediate >>> actions like move, rotate, mirror, etc. should be blocked until the tool >>> is idle but I'm open to suggestion on this. I can see the utility in >>> canceling the edit and performing the requested action. >>> 3. When the tool is idle, the escape key should exit the tool and return >>> to the selection tool. Immediate actions like move, rotate, mirror, >>> etc. should perform the expected operation and return to the selected tool. >>> >>> Using the toolbar and menu to select a tool should behave the same as >>> above except that no drawing begins at the current cursor position >>> because the cursor position is meaningless while it's over a toolbar >>> button or menu entry. >>> >>> I hope I am explaining this well enough. >>> >>> On 6/18/19 5:35 PM, Jeff Young wrote: OK, next attempt is in. ;) > On 18 Jun 2019, at 21:07, Wayne Stambaugh wrote: > > Better but now the second (third, fourth, fifth, ...) escape key does > not exit after the first escape key cancels the immediate action. Using > the toolbar or menu to select the tool does work correctly. One other > new oddity is that selecting a second tool using the toolbar or menu > will result in the previous tool being selected rather than the > selection tool after escape is pressed when the tool is idle. I think > you may have gone too far the other way. > > On 6/18/19 3:52 PM, Jeff Young wrote: >> Hi Wayne, >> >> I checked in some new code. Give it a go when you get a chance. >> >> Cheers, >> Jeff. >> >> >>> On 18 Jun 2019, at 13:01, Wayne Stambaugh wrote: >>> >>> Wire, bus, graphic line, and sheet but only when enabled with an >>> immediate hotkey. When I enable the tool via a toolbar button or >>> selecting a menu entry, then the behavior is the same as the legacy tool >>> framework. It really should not matter how a tool is enabled, only the >>> initial behavior. >>> >>> On 6/18/2019 7:53 AM, Jeff Young wrote: Hi Wayne, I wrote the whole PushTool/PopTool stuff exactly for that case. Which action in particular is going back to the SelectionTool? (Note that some are “supposed” to. If you click on a tool in the toolbar, or select it from the Place menu, then cancelling should take you back to the SelectionTool. However, if you use the context menu or a hotkey, it should push and then pop the drawing tool. Not to say that it’s not buggy, or that the design behaviour isn’t optimal.) Cheers, Jeff. PS: should I make the same changes to Pcbnew, or should be await more feedback? (Feedback on the forums has been uniformly positive so far, but pretty sparse with only 3 likes.) > On 18 Jun 2019, at 12:48, Wayne Stambaugh > wrote: > > Hey Jeff, > > I spent some time this morning playing around with the "immediate" > hotkeys in Eeschema and it's better but there is still one annoying > difference from the legacy behavior. When cancelling (escape key) a > drawing in progress, the drawing is aborted, the current tool is > canceled, and the selection tool is enable. The legacy behavior was > abort the drawing in progress and keep the current tool enabled. The > current tool would only be canceled when it was not busy drawing > something. It's
Re: [Kicad-developers] Immediate mode actions
What about “unfold bus”? Leaves you in the wire tool (like “start wire”), or in the previous tool (like “move”)? > On 19 Jun 2019, at 15:08, Jeff Young wrote: > > Ahh, I misunderstood your earlier comments. When you said they should act > the same I thought you meant both like the old immediate action behaviour, > not both like the old toolbar behaviour. > >> On 19 Jun 2019, at 13:46, Wayne Stambaugh wrote: >> >> The immediate actions are back to the same behavior as the initial >> commit (one shot) and using the toolbar or menu to select a tool now >> stacks tools so each escape to exit the current tool brings up the >> previous tool until you finally end up back at the selection tool. I >> think users are going to expect exiting a tool to always end up back at >> the selection tool not the previously selected tool. Here is a synopsis >> of the behavior I think we should aim for: >> >> Immediate actions: >> >> 1. The appropriate tool should be enabled and begin drawing at the >> current cursor location (works). >> 2. When the tool is busy drawing, the escape key should cancel the >> current edit and the selected tool should remain enabled. Immediate >> actions like move, rotate, mirror, etc. should be blocked until the tool >> is idle but I'm open to suggestion on this. I can see the utility in >> canceling the edit and performing the requested action. >> 3. When the tool is idle, the escape key should exit the tool and return >> to the selection tool. Immediate actions like move, rotate, mirror, >> etc. should perform the expected operation and return to the selected tool. >> >> Using the toolbar and menu to select a tool should behave the same as >> above except that no drawing begins at the current cursor position >> because the cursor position is meaningless while it's over a toolbar >> button or menu entry. >> >> I hope I am explaining this well enough. >> >> On 6/18/19 5:35 PM, Jeff Young wrote: >>> OK, next attempt is in. ;) >>> On 18 Jun 2019, at 21:07, Wayne Stambaugh wrote: Better but now the second (third, fourth, fifth, ...) escape key does not exit after the first escape key cancels the immediate action. Using the toolbar or menu to select the tool does work correctly. One other new oddity is that selecting a second tool using the toolbar or menu will result in the previous tool being selected rather than the selection tool after escape is pressed when the tool is idle. I think you may have gone too far the other way. On 6/18/19 3:52 PM, Jeff Young wrote: > Hi Wayne, > > I checked in some new code. Give it a go when you get a chance. > > Cheers, > Jeff. > > >> On 18 Jun 2019, at 13:01, Wayne Stambaugh wrote: >> >> Wire, bus, graphic line, and sheet but only when enabled with an >> immediate hotkey. When I enable the tool via a toolbar button or >> selecting a menu entry, then the behavior is the same as the legacy tool >> framework. It really should not matter how a tool is enabled, only the >> initial behavior. >> >> On 6/18/2019 7:53 AM, Jeff Young wrote: >>> Hi Wayne, >>> >>> I wrote the whole PushTool/PopTool stuff exactly for that case. Which >>> action in particular is going back to the SelectionTool? >>> >>> (Note that some are “supposed” to. If you click on a tool in the >>> toolbar, or select it from the Place menu, then cancelling should take >>> you back to the SelectionTool. However, if you use the context menu or >>> a hotkey, it should push and then pop the drawing tool. Not to say >>> that it’s not buggy, or that the design behaviour isn’t optimal.) >>> >>> Cheers, >>> Jeff. >>> >>> PS: should I make the same changes to Pcbnew, or should be await more >>> feedback? (Feedback on the forums has been uniformly positive so far, >>> but pretty sparse with only 3 likes.) >>> >>> On 18 Jun 2019, at 12:48, Wayne Stambaugh wrote: Hey Jeff, I spent some time this morning playing around with the "immediate" hotkeys in Eeschema and it's better but there is still one annoying difference from the legacy behavior. When cancelling (escape key) a drawing in progress, the drawing is aborted, the current tool is canceled, and the selection tool is enable. The legacy behavior was abort the drawing in progress and keep the current tool enabled. The current tool would only be canceled when it was not busy drawing something. It's rather cumbersome to have to keep enabling the drawing tool every time you exit a drawing when you make a mistake. Cheers, Wayne On 6/15/2019 3:45 PM, Jeff Young wrote: > I’ve checked in code which makes the drawing hotkeys “immediate” in
Re: [Kicad-developers] Immediate mode actions
Ahh, I misunderstood your earlier comments. When you said they should act the same I thought you meant both like the old immediate action behaviour, not both like the old toolbar behaviour. > On 19 Jun 2019, at 13:46, Wayne Stambaugh wrote: > > The immediate actions are back to the same behavior as the initial > commit (one shot) and using the toolbar or menu to select a tool now > stacks tools so each escape to exit the current tool brings up the > previous tool until you finally end up back at the selection tool. I > think users are going to expect exiting a tool to always end up back at > the selection tool not the previously selected tool. Here is a synopsis > of the behavior I think we should aim for: > > Immediate actions: > > 1. The appropriate tool should be enabled and begin drawing at the > current cursor location (works). > 2. When the tool is busy drawing, the escape key should cancel the > current edit and the selected tool should remain enabled. Immediate > actions like move, rotate, mirror, etc. should be blocked until the tool > is idle but I'm open to suggestion on this. I can see the utility in > canceling the edit and performing the requested action. > 3. When the tool is idle, the escape key should exit the tool and return > to the selection tool. Immediate actions like move, rotate, mirror, > etc. should perform the expected operation and return to the selected tool. > > Using the toolbar and menu to select a tool should behave the same as > above except that no drawing begins at the current cursor position > because the cursor position is meaningless while it's over a toolbar > button or menu entry. > > I hope I am explaining this well enough. > > On 6/18/19 5:35 PM, Jeff Young wrote: >> OK, next attempt is in. ;) >> >>> On 18 Jun 2019, at 21:07, Wayne Stambaugh wrote: >>> >>> Better but now the second (third, fourth, fifth, ...) escape key does >>> not exit after the first escape key cancels the immediate action. Using >>> the toolbar or menu to select the tool does work correctly. One other >>> new oddity is that selecting a second tool using the toolbar or menu >>> will result in the previous tool being selected rather than the >>> selection tool after escape is pressed when the tool is idle. I think >>> you may have gone too far the other way. >>> >>> On 6/18/19 3:52 PM, Jeff Young wrote: Hi Wayne, I checked in some new code. Give it a go when you get a chance. Cheers, Jeff. > On 18 Jun 2019, at 13:01, Wayne Stambaugh wrote: > > Wire, bus, graphic line, and sheet but only when enabled with an > immediate hotkey. When I enable the tool via a toolbar button or > selecting a menu entry, then the behavior is the same as the legacy tool > framework. It really should not matter how a tool is enabled, only the > initial behavior. > > On 6/18/2019 7:53 AM, Jeff Young wrote: >> Hi Wayne, >> >> I wrote the whole PushTool/PopTool stuff exactly for that case. Which >> action in particular is going back to the SelectionTool? >> >> (Note that some are “supposed” to. If you click on a tool in the >> toolbar, or select it from the Place menu, then cancelling should take >> you back to the SelectionTool. However, if you use the context menu or >> a hotkey, it should push and then pop the drawing tool. Not to say that >> it’s not buggy, or that the design behaviour isn’t optimal.) >> >> Cheers, >> Jeff. >> >> PS: should I make the same changes to Pcbnew, or should be await more >> feedback? (Feedback on the forums has been uniformly positive so far, >> but pretty sparse with only 3 likes.) >> >> >>> On 18 Jun 2019, at 12:48, Wayne Stambaugh wrote: >>> >>> Hey Jeff, >>> >>> I spent some time this morning playing around with the "immediate" >>> hotkeys in Eeschema and it's better but there is still one annoying >>> difference from the legacy behavior. When cancelling (escape key) a >>> drawing in progress, the drawing is aborted, the current tool is >>> canceled, and the selection tool is enable. The legacy behavior was >>> abort the drawing in progress and keep the current tool enabled. The >>> current tool would only be canceled when it was not busy drawing >>> something. It's rather cumbersome to have to keep enabling the drawing >>> tool every time you exit a drawing when you make a mistake. >>> >>> Cheers, >>> >>> Wayne >>> >>> On 6/15/2019 3:45 PM, Jeff Young wrote: I’ve checked in code which makes the drawing hotkeys “immediate” in Eeschema and the Symbol Editor. It was more involved than I was expecting, so there may be some nasty surprises. I folks like it, I can apply the same architecture to Pcbnew. Cheers, Jeff.
Re: [Kicad-developers] Immediate mode actions
The immediate actions are back to the same behavior as the initial commit (one shot) and using the toolbar or menu to select a tool now stacks tools so each escape to exit the current tool brings up the previous tool until you finally end up back at the selection tool. I think users are going to expect exiting a tool to always end up back at the selection tool not the previously selected tool. Here is a synopsis of the behavior I think we should aim for: Immediate actions: 1. The appropriate tool should be enabled and begin drawing at the current cursor location (works). 2. When the tool is busy drawing, the escape key should cancel the current edit and the selected tool should remain enabled. Immediate actions like move, rotate, mirror, etc. should be blocked until the tool is idle but I'm open to suggestion on this. I can see the utility in canceling the edit and performing the requested action. 3. When the tool is idle, the escape key should exit the tool and return to the selection tool. Immediate actions like move, rotate, mirror, etc. should perform the expected operation and return to the selected tool. Using the toolbar and menu to select a tool should behave the same as above except that no drawing begins at the current cursor position because the cursor position is meaningless while it's over a toolbar button or menu entry. I hope I am explaining this well enough. On 6/18/19 5:35 PM, Jeff Young wrote: > OK, next attempt is in. ;) > >> On 18 Jun 2019, at 21:07, Wayne Stambaugh wrote: >> >> Better but now the second (third, fourth, fifth, ...) escape key does >> not exit after the first escape key cancels the immediate action. Using >> the toolbar or menu to select the tool does work correctly. One other >> new oddity is that selecting a second tool using the toolbar or menu >> will result in the previous tool being selected rather than the >> selection tool after escape is pressed when the tool is idle. I think >> you may have gone too far the other way. >> >> On 6/18/19 3:52 PM, Jeff Young wrote: >>> Hi Wayne, >>> >>> I checked in some new code. Give it a go when you get a chance. >>> >>> Cheers, >>> Jeff. >>> >>> On 18 Jun 2019, at 13:01, Wayne Stambaugh wrote: Wire, bus, graphic line, and sheet but only when enabled with an immediate hotkey. When I enable the tool via a toolbar button or selecting a menu entry, then the behavior is the same as the legacy tool framework. It really should not matter how a tool is enabled, only the initial behavior. On 6/18/2019 7:53 AM, Jeff Young wrote: > Hi Wayne, > > I wrote the whole PushTool/PopTool stuff exactly for that case. Which > action in particular is going back to the SelectionTool? > > (Note that some are “supposed” to. If you click on a tool in the > toolbar, or select it from the Place menu, then cancelling should take > you back to the SelectionTool. However, if you use the context menu or a > hotkey, it should push and then pop the drawing tool. Not to say that > it’s not buggy, or that the design behaviour isn’t optimal.) > > Cheers, > Jeff. > > PS: should I make the same changes to Pcbnew, or should be await more > feedback? (Feedback on the forums has been uniformly positive so far, > but pretty sparse with only 3 likes.) > > >> On 18 Jun 2019, at 12:48, Wayne Stambaugh wrote: >> >> Hey Jeff, >> >> I spent some time this morning playing around with the "immediate" >> hotkeys in Eeschema and it's better but there is still one annoying >> difference from the legacy behavior. When cancelling (escape key) a >> drawing in progress, the drawing is aborted, the current tool is >> canceled, and the selection tool is enable. The legacy behavior was >> abort the drawing in progress and keep the current tool enabled. The >> current tool would only be canceled when it was not busy drawing >> something. It's rather cumbersome to have to keep enabling the drawing >> tool every time you exit a drawing when you make a mistake. >> >> Cheers, >> >> Wayne >> >> On 6/15/2019 3:45 PM, Jeff Young wrote: >>> I’ve checked in code which makes the drawing hotkeys “immediate” in >>> Eeschema and the Symbol Editor. It was more involved than I was >>> expecting, so there may be some nasty surprises. >>> >>> I folks like it, I can apply the same architecture to Pcbnew. >>> >>> Cheers, >>> Jeff. >>> ___ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> ___ >> Mailing list:
Re: [Kicad-developers] Immediate mode actions
OK, next attempt is in. ;) > On 18 Jun 2019, at 21:07, Wayne Stambaugh wrote: > > Better but now the second (third, fourth, fifth, ...) escape key does > not exit after the first escape key cancels the immediate action. Using > the toolbar or menu to select the tool does work correctly. One other > new oddity is that selecting a second tool using the toolbar or menu > will result in the previous tool being selected rather than the > selection tool after escape is pressed when the tool is idle. I think > you may have gone too far the other way. > > On 6/18/19 3:52 PM, Jeff Young wrote: >> Hi Wayne, >> >> I checked in some new code. Give it a go when you get a chance. >> >> Cheers, >> Jeff. >> >> >>> On 18 Jun 2019, at 13:01, Wayne Stambaugh wrote: >>> >>> Wire, bus, graphic line, and sheet but only when enabled with an >>> immediate hotkey. When I enable the tool via a toolbar button or >>> selecting a menu entry, then the behavior is the same as the legacy tool >>> framework. It really should not matter how a tool is enabled, only the >>> initial behavior. >>> >>> On 6/18/2019 7:53 AM, Jeff Young wrote: Hi Wayne, I wrote the whole PushTool/PopTool stuff exactly for that case. Which action in particular is going back to the SelectionTool? (Note that some are “supposed” to. If you click on a tool in the toolbar, or select it from the Place menu, then cancelling should take you back to the SelectionTool. However, if you use the context menu or a hotkey, it should push and then pop the drawing tool. Not to say that it’s not buggy, or that the design behaviour isn’t optimal.) Cheers, Jeff. PS: should I make the same changes to Pcbnew, or should be await more feedback? (Feedback on the forums has been uniformly positive so far, but pretty sparse with only 3 likes.) > On 18 Jun 2019, at 12:48, Wayne Stambaugh wrote: > > Hey Jeff, > > I spent some time this morning playing around with the "immediate" > hotkeys in Eeschema and it's better but there is still one annoying > difference from the legacy behavior. When cancelling (escape key) a > drawing in progress, the drawing is aborted, the current tool is > canceled, and the selection tool is enable. The legacy behavior was > abort the drawing in progress and keep the current tool enabled. The > current tool would only be canceled when it was not busy drawing > something. It's rather cumbersome to have to keep enabling the drawing > tool every time you exit a drawing when you make a mistake. > > Cheers, > > Wayne > > On 6/15/2019 3:45 PM, Jeff Young wrote: >> I’ve checked in code which makes the drawing hotkeys “immediate” in >> Eeschema and the Symbol Editor. It was more involved than I was >> expecting, so there may be some nasty surprises. >> >> I folks like it, I can apply the same architecture to Pcbnew. >> >> Cheers, >> Jeff. >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >> ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Immediate mode actions
Better but now the second (third, fourth, fifth, ...) escape key does not exit after the first escape key cancels the immediate action. Using the toolbar or menu to select the tool does work correctly. One other new oddity is that selecting a second tool using the toolbar or menu will result in the previous tool being selected rather than the selection tool after escape is pressed when the tool is idle. I think you may have gone too far the other way. On 6/18/19 3:52 PM, Jeff Young wrote: > Hi Wayne, > > I checked in some new code. Give it a go when you get a chance. > > Cheers, > Jeff. > > >> On 18 Jun 2019, at 13:01, Wayne Stambaugh wrote: >> >> Wire, bus, graphic line, and sheet but only when enabled with an >> immediate hotkey. When I enable the tool via a toolbar button or >> selecting a menu entry, then the behavior is the same as the legacy tool >> framework. It really should not matter how a tool is enabled, only the >> initial behavior. >> >> On 6/18/2019 7:53 AM, Jeff Young wrote: >>> Hi Wayne, >>> >>> I wrote the whole PushTool/PopTool stuff exactly for that case. Which >>> action in particular is going back to the SelectionTool? >>> >>> (Note that some are “supposed” to. If you click on a tool in the toolbar, >>> or select it from the Place menu, then cancelling should take you back to >>> the SelectionTool. However, if you use the context menu or a hotkey, it >>> should push and then pop the drawing tool. Not to say that it’s not buggy, >>> or that the design behaviour isn’t optimal.) >>> >>> Cheers, >>> Jeff. >>> >>> PS: should I make the same changes to Pcbnew, or should be await more >>> feedback? (Feedback on the forums has been uniformly positive so far, but >>> pretty sparse with only 3 likes.) >>> >>> On 18 Jun 2019, at 12:48, Wayne Stambaugh wrote: Hey Jeff, I spent some time this morning playing around with the "immediate" hotkeys in Eeschema and it's better but there is still one annoying difference from the legacy behavior. When cancelling (escape key) a drawing in progress, the drawing is aborted, the current tool is canceled, and the selection tool is enable. The legacy behavior was abort the drawing in progress and keep the current tool enabled. The current tool would only be canceled when it was not busy drawing something. It's rather cumbersome to have to keep enabling the drawing tool every time you exit a drawing when you make a mistake. Cheers, Wayne On 6/15/2019 3:45 PM, Jeff Young wrote: > I’ve checked in code which makes the drawing hotkeys “immediate” in > Eeschema and the Symbol Editor. It was more involved than I was > expecting, so there may be some nasty surprises. > > I folks like it, I can apply the same architecture to Pcbnew. > > Cheers, > Jeff. > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp >>> > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Immediate mode actions
Hi Wayne, I checked in some new code. Give it a go when you get a chance. Cheers, Jeff. > On 18 Jun 2019, at 13:01, Wayne Stambaugh wrote: > > Wire, bus, graphic line, and sheet but only when enabled with an > immediate hotkey. When I enable the tool via a toolbar button or > selecting a menu entry, then the behavior is the same as the legacy tool > framework. It really should not matter how a tool is enabled, only the > initial behavior. > > On 6/18/2019 7:53 AM, Jeff Young wrote: >> Hi Wayne, >> >> I wrote the whole PushTool/PopTool stuff exactly for that case. Which >> action in particular is going back to the SelectionTool? >> >> (Note that some are “supposed” to. If you click on a tool in the toolbar, >> or select it from the Place menu, then cancelling should take you back to >> the SelectionTool. However, if you use the context menu or a hotkey, it >> should push and then pop the drawing tool. Not to say that it’s not buggy, >> or that the design behaviour isn’t optimal.) >> >> Cheers, >> Jeff. >> >> PS: should I make the same changes to Pcbnew, or should be await more >> feedback? (Feedback on the forums has been uniformly positive so far, but >> pretty sparse with only 3 likes.) >> >> >>> On 18 Jun 2019, at 12:48, Wayne Stambaugh wrote: >>> >>> Hey Jeff, >>> >>> I spent some time this morning playing around with the "immediate" >>> hotkeys in Eeschema and it's better but there is still one annoying >>> difference from the legacy behavior. When cancelling (escape key) a >>> drawing in progress, the drawing is aborted, the current tool is >>> canceled, and the selection tool is enable. The legacy behavior was >>> abort the drawing in progress and keep the current tool enabled. The >>> current tool would only be canceled when it was not busy drawing >>> something. It's rather cumbersome to have to keep enabling the drawing >>> tool every time you exit a drawing when you make a mistake. >>> >>> Cheers, >>> >>> Wayne >>> >>> On 6/15/2019 3:45 PM, Jeff Young wrote: I’ve checked in code which makes the drawing hotkeys “immediate” in Eeschema and the Symbol Editor. It was more involved than I was expecting, so there may be some nasty surprises. I folks like it, I can apply the same architecture to Pcbnew. Cheers, Jeff. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp >>> >>> ___ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >> ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Immediate mode actions
Wire, bus, graphic line, and sheet but only when enabled with an immediate hotkey. When I enable the tool via a toolbar button or selecting a menu entry, then the behavior is the same as the legacy tool framework. It really should not matter how a tool is enabled, only the initial behavior. On 6/18/2019 7:53 AM, Jeff Young wrote: > Hi Wayne, > > I wrote the whole PushTool/PopTool stuff exactly for that case. Which action > in particular is going back to the SelectionTool? > > (Note that some are “supposed” to. If you click on a tool in the toolbar, or > select it from the Place menu, then cancelling should take you back to the > SelectionTool. However, if you use the context menu or a hotkey, it should > push and then pop the drawing tool. Not to say that it’s not buggy, or that > the design behaviour isn’t optimal.) > > Cheers, > Jeff. > > PS: should I make the same changes to Pcbnew, or should be await more > feedback? (Feedback on the forums has been uniformly positive so far, but > pretty sparse with only 3 likes.) > > >> On 18 Jun 2019, at 12:48, Wayne Stambaugh wrote: >> >> Hey Jeff, >> >> I spent some time this morning playing around with the "immediate" >> hotkeys in Eeschema and it's better but there is still one annoying >> difference from the legacy behavior. When cancelling (escape key) a >> drawing in progress, the drawing is aborted, the current tool is >> canceled, and the selection tool is enable. The legacy behavior was >> abort the drawing in progress and keep the current tool enabled. The >> current tool would only be canceled when it was not busy drawing >> something. It's rather cumbersome to have to keep enabling the drawing >> tool every time you exit a drawing when you make a mistake. >> >> Cheers, >> >> Wayne >> >> On 6/15/2019 3:45 PM, Jeff Young wrote: >>> I’ve checked in code which makes the drawing hotkeys “immediate” in >>> Eeschema and the Symbol Editor. It was more involved than I was expecting, >>> so there may be some nasty surprises. >>> >>> I folks like it, I can apply the same architecture to Pcbnew. >>> >>> Cheers, >>> Jeff. >>> ___ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Immediate mode actions
Hi Wayne, I wrote the whole PushTool/PopTool stuff exactly for that case. Which action in particular is going back to the SelectionTool? (Note that some are “supposed” to. If you click on a tool in the toolbar, or select it from the Place menu, then cancelling should take you back to the SelectionTool. However, if you use the context menu or a hotkey, it should push and then pop the drawing tool. Not to say that it’s not buggy, or that the design behaviour isn’t optimal.) Cheers, Jeff. PS: should I make the same changes to Pcbnew, or should be await more feedback? (Feedback on the forums has been uniformly positive so far, but pretty sparse with only 3 likes.) > On 18 Jun 2019, at 12:48, Wayne Stambaugh wrote: > > Hey Jeff, > > I spent some time this morning playing around with the "immediate" > hotkeys in Eeschema and it's better but there is still one annoying > difference from the legacy behavior. When cancelling (escape key) a > drawing in progress, the drawing is aborted, the current tool is > canceled, and the selection tool is enable. The legacy behavior was > abort the drawing in progress and keep the current tool enabled. The > current tool would only be canceled when it was not busy drawing > something. It's rather cumbersome to have to keep enabling the drawing > tool every time you exit a drawing when you make a mistake. > > Cheers, > > Wayne > > On 6/15/2019 3:45 PM, Jeff Young wrote: >> I’ve checked in code which makes the drawing hotkeys “immediate” in Eeschema >> and the Symbol Editor. It was more involved than I was expecting, so there >> may be some nasty surprises. >> >> I folks like it, I can apply the same architecture to Pcbnew. >> >> Cheers, >> Jeff. >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Immediate mode actions
Hey Jeff, I spent some time this morning playing around with the "immediate" hotkeys in Eeschema and it's better but there is still one annoying difference from the legacy behavior. When cancelling (escape key) a drawing in progress, the drawing is aborted, the current tool is canceled, and the selection tool is enable. The legacy behavior was abort the drawing in progress and keep the current tool enabled. The current tool would only be canceled when it was not busy drawing something. It's rather cumbersome to have to keep enabling the drawing tool every time you exit a drawing when you make a mistake. Cheers, Wayne On 6/15/2019 3:45 PM, Jeff Young wrote: > I’ve checked in code which makes the drawing hotkeys “immediate” in Eeschema > and the Symbol Editor. It was more involved than I was expecting, so there > may be some nasty surprises. > > I folks like it, I can apply the same architecture to Pcbnew. > > Cheers, > Jeff. > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Immediate mode actions
I’ve checked in code which makes the drawing hotkeys “immediate” in Eeschema and the Symbol Editor. It was more involved than I was expecting, so there may be some nasty surprises. I folks like it, I can apply the same architecture to Pcbnew. Cheers, Jeff. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
