Re: [Kicad-developers] HotKey user model
I suppose " doing an immediate action and selecting the tool" has the best of both worlds, but off the top of my head I cant think of any other piece of mainstream software (CAD or otherwise) that does this. I think I'd lean also towards 'hotkey activates the tool' seeing as its the most common. Cheers, Michael On Fri, 26 Apr 2019 at 19:47, Jeff Young wrote: > Hi JP, > > > On 26 Apr 2019, at 19:12, jp charras wrote: > > > > Le 26/04/2019 à 19:21, Jeff Young a écrit : > >> I’ve been talking to Wayne about the ‘W’ and ‘X’ hotkeys. It appears > the design goal is to have these be immediate actions (that is, they start > a wire or a track, rather than just selecting the wire or track tool). > >> > >> Presumably this would then also apply to ‘A’, ‘P’, ‘L’, ‘H’, ‘J’, ‘Q’, > etc. (None of these perform an immediate action today, right?) > > > > In short: Yes. This is how the hotkeys worked, previously. > >> > >> Do we want there to be some related way to select the tools? That is, > if ‘Q’ places a no-connect then shift-Q would select the no-connect tool? > If yes, would these be separately editable, or would they simply follow > whatever the user changed the main hotkeys to? > >> > >> Or is there some other facility that’s already supposed to work for > tools? > > > > Why do you want to change the previous behavior? Is it not good? > > > > It was already changed. I don’t know when or why. > > I don’t have a problem with doing an immediate action and > selecting the tool, but that’s not how it works today. > > (Note that I don’t have a problem with the other way either. As long as > all the tools are consistent.) > > 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
Re: [Kicad-developers] Kudos to Michael Kavanagh
Ha, thanks! On that note, there are a lot of old bugs marked as "Fix Committed", but because they were never associated to a milestone (or some other reason) the Janitor never cleaned them up to "Fix Released" when they were in fact released. At the time of writing: 467 fix committed 13 off 5.1.0-rc2 59 off 5.1.1 315 with no milestone assigned Is there any reason why we are leaving these long released bug fixes as "Fix Committed" in the bug tracker? If not, I can go through, check if/when the fixes were released and and clean them up. Cheers, Michael On Fri, 26 Apr 2019 at 10:24, Jeff Young wrote: > Just wanted to send out a quick note of appreciation regarding all the > work Michael is doing to keep the bug database clean. > > 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
Re: [Kicad-developers] HotKey user model
Hi JP, > On 26 Apr 2019, at 19:12, jp charras wrote: > > Le 26/04/2019 à 19:21, Jeff Young a écrit : >> I’ve been talking to Wayne about the ‘W’ and ‘X’ hotkeys. It appears the >> design goal is to have these be immediate actions (that is, they start a >> wire or a track, rather than just selecting the wire or track tool). >> >> Presumably this would then also apply to ‘A’, ‘P’, ‘L’, ‘H’, ‘J’, ‘Q’, etc. >> (None of these perform an immediate action today, right?) > > In short: Yes. This is how the hotkeys worked, previously. >> >> Do we want there to be some related way to select the tools? That is, if >> ‘Q’ places a no-connect then shift-Q would select the no-connect tool? If >> yes, would these be separately editable, or would they simply follow >> whatever the user changed the main hotkeys to? >> >> Or is there some other facility that’s already supposed to work for tools? > > Why do you want to change the previous behavior? Is it not good? > It was already changed. I don’t know when or why. I don’t have a problem with doing an immediate action and selecting the tool, but that’s not how it works today. (Note that I don’t have a problem with the other way either. As long as all the tools are consistent.) 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
Re: [Kicad-developers] HotKey user model
On 26/04/2019 13:12, jp charras wrote: > Le 26/04/2019 à 19:21, Jeff Young a écrit : >> I’ve been talking to Wayne about the ‘W’ and ‘X’ hotkeys. It appears the >> design goal is to have these be immediate actions (that is, they start a >> wire or a track, rather than just selecting the wire or track tool). >> >> Presumably this would then also apply to ‘A’, ‘P’, ‘L’, ‘H’, ‘J’, ‘Q’, etc. >> (None of these perform an immediate action today, right?) > > Why do you want to change the previous behavior? Is it not good? > Hi JP, I'm from the 'hotkey activates the tool camp' like Brian (for similar reasons). I realize hotkeys and accelerators working *simultaneously* would be difficult to have, but what about an option to select the 'start tool here'/'activate tool' hotkey behaviour globally? Cheers, Tom ___ 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] HotKey user model
No, and I'll be adding that feature for 6.0
On Fri, Apr 26, 2019 at 1:14 PM Drew Van Zandt
wrote:
> On this general topic, is there a technical reason that one cannot assign
> a shortcut key for "select whole net"?
>
>
> *Drew Van Zandt*
>
>
> On Fri, Apr 26, 2019 at 2:13 PM jp charras wrote:
>
>> Le 26/04/2019 à 19:21, Jeff Young a écrit :
>> > I’ve been talking to Wayne about the ‘W’ and ‘X’ hotkeys. It appears
>> the design goal is to have these be immediate actions (that is, they start
>> a wire or a track, rather than just selecting the wire or track tool).
>> >
>> > Presumably this would then also apply to ‘A’, ‘P’, ‘L’, ‘H’, ‘J’, ‘Q’,
>> etc. (None of these perform an immediate action today, right?)
>>
>> In short: Yes. This is how the hotkeys worked, previously.
>> >
>> > Do we want there to be some related way to select the tools? That is,
>> if ‘Q’ places a no-connect then shift-Q would select the no-connect tool?
>> If yes, would these be separately editable, or would they simply follow
>> whatever the user changed the main hotkeys to?
>> >
>> > Or is there some other facility that’s already supposed to work for
>> tools?
>>
>> Why do you want to change the previous behavior? Is it not good?
>>
>> The reason of the behavior ('W' starts a wire and 'shift W' selects the
>> tool) is the fact we cannot (if we use the hotkey as accelerator) know
>> if a menu was clicked (in this case the mouse position is irrelevant) or
>> if a hotkey was pressed (in this case the mouse position can be used and
>> we start a wire immediately).
>> Therefore we cannot use the same key as hotkey and accelerator key.
>>
>> It is extremely hard to fix this issue because the workaround to fix it
>> are only workaround (and therefore can stop working after wxWidgets
>> changes) and each platform has its own workaround.
>>
>> For instance, if the 'W' key is used both as accelerator key and hotkey,
>> the key event is not generated on Windows (only the menu event), but is
>> generated on wxGTK.
>> I don't know what happens on OSX.
>>
>> Hotkey behavior versus accelerator key behavior is always strange.
>> And this is not only when using wxWidgets:
>> I found issues in many other applications (Using a French keyboard
>> instead of a US keyboard often shows these strange behaviors)
>>
>> Trying to fix this issue is a mined field.
>>
>> Wayne and me spent a lot of time about that without success.
>>
>>
>> --
>> Jean-Pierre CHARRAS
>>
>> ___
>> 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] HotKey user model
On this general topic, is there a technical reason that one cannot assign a
shortcut key for "select whole net"?
*Drew Van Zandt*
On Fri, Apr 26, 2019 at 2:13 PM jp charras wrote:
> Le 26/04/2019 à 19:21, Jeff Young a écrit :
> > I’ve been talking to Wayne about the ‘W’ and ‘X’ hotkeys. It appears
> the design goal is to have these be immediate actions (that is, they start
> a wire or a track, rather than just selecting the wire or track tool).
> >
> > Presumably this would then also apply to ‘A’, ‘P’, ‘L’, ‘H’, ‘J’, ‘Q’,
> etc. (None of these perform an immediate action today, right?)
>
> In short: Yes. This is how the hotkeys worked, previously.
> >
> > Do we want there to be some related way to select the tools? That is,
> if ‘Q’ places a no-connect then shift-Q would select the no-connect tool?
> If yes, would these be separately editable, or would they simply follow
> whatever the user changed the main hotkeys to?
> >
> > Or is there some other facility that’s already supposed to work for
> tools?
>
> Why do you want to change the previous behavior? Is it not good?
>
> The reason of the behavior ('W' starts a wire and 'shift W' selects the
> tool) is the fact we cannot (if we use the hotkey as accelerator) know
> if a menu was clicked (in this case the mouse position is irrelevant) or
> if a hotkey was pressed (in this case the mouse position can be used and
> we start a wire immediately).
> Therefore we cannot use the same key as hotkey and accelerator key.
>
> It is extremely hard to fix this issue because the workaround to fix it
> are only workaround (and therefore can stop working after wxWidgets
> changes) and each platform has its own workaround.
>
> For instance, if the 'W' key is used both as accelerator key and hotkey,
> the key event is not generated on Windows (only the menu event), but is
> generated on wxGTK.
> I don't know what happens on OSX.
>
> Hotkey behavior versus accelerator key behavior is always strange.
> And this is not only when using wxWidgets:
> I found issues in many other applications (Using a French keyboard
> instead of a US keyboard often shows these strange behaviors)
>
> Trying to fix this issue is a mined field.
>
> Wayne and me spent a lot of time about that without success.
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> 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] HotKey user model
Le 26/04/2019 à 19:21, Jeff Young a écrit :
> I’ve been talking to Wayne about the ‘W’ and ‘X’ hotkeys. It appears the
> design goal is to have these be immediate actions (that is, they start a wire
> or a track, rather than just selecting the wire or track tool).
>
> Presumably this would then also apply to ‘A’, ‘P’, ‘L’, ‘H’, ‘J’, ‘Q’, etc.
> (None of these perform an immediate action today, right?)
In short: Yes. This is how the hotkeys worked, previously.
>
> Do we want there to be some related way to select the tools? That is, if ‘Q’
> places a no-connect then shift-Q would select the no-connect tool? If yes,
> would these be separately editable, or would they simply follow whatever the
> user changed the main hotkeys to?
>
> Or is there some other facility that’s already supposed to work for tools?
Why do you want to change the previous behavior? Is it not good?
The reason of the behavior ('W' starts a wire and 'shift W' selects the
tool) is the fact we cannot (if we use the hotkey as accelerator) know
if a menu was clicked (in this case the mouse position is irrelevant) or
if a hotkey was pressed (in this case the mouse position can be used and
we start a wire immediately).
Therefore we cannot use the same key as hotkey and accelerator key.
It is extremely hard to fix this issue because the workaround to fix it
are only workaround (and therefore can stop working after wxWidgets
changes) and each platform has its own workaround.
For instance, if the 'W' key is used both as accelerator key and hotkey,
the key event is not generated on Windows (only the menu event), but is
generated on wxGTK.
I don't know what happens on OSX.
Hotkey behavior versus accelerator key behavior is always strange.
And this is not only when using wxWidgets:
I found issues in many other applications (Using a French keyboard
instead of a US keyboard often shows these strange behaviors)
Trying to fix this issue is a mined field.
Wayne and me spent a lot of time about that without success.
--
Jean-Pierre CHARRAS
___
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] HotKey user model
My $0.02: I don’t want a tool to start doing something while my eyes are possibly off the screen (looking at the keyboard to hit the right hotkey) because my mousing hand may have drifted, causing the action to be carried out in the wrong place (e.g. starting a track in the wrong spot). If most people disagree, fine, but please definitely include a hotkey action for “select tool” that doesn’t also immediately begin that tool’s action. Or perhaps make it a global user option whether a hotkey is “select tool” or “start tool action” (for lack of better wording), so us keyboard-lookers don’t have to perform manual gymnastics for every tool select. Cheers, -Brian > On Apr 26, 2019, at 1:21 PM, Jeff Young wrote: > > I’ve been talking to Wayne about the ‘W’ and ‘X’ hotkeys. It appears the > design goal is to have these be immediate actions (that is, they start a wire > or a track, rather than just selecting the wire or track tool). > > Presumably this would then also apply to ‘A’, ‘P’, ‘L’, ‘H’, ‘J’, ‘Q’, etc. > (None of these perform an immediate action today, right?) > > Do we want there to be some related way to select the tools? That is, if ‘Q’ > places a no-connect then shift-Q would select the no-connect tool? If yes, > would these be separately editable, or would they simply follow whatever the > user changed the main hotkeys to? > > Or is there some other facility that’s already supposed to work for tools? > ___ > 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] HotKey user model
I’ve been talking to Wayne about the ‘W’ and ‘X’ hotkeys. It appears the design goal is to have these be immediate actions (that is, they start a wire or a track, rather than just selecting the wire or track tool). Presumably this would then also apply to ‘A’, ‘P’, ‘L’, ‘H’, ‘J’, ‘Q’, etc. (None of these perform an immediate action today, right?) Do we want there to be some related way to select the tools? That is, if ‘Q’ places a no-connect then shift-Q would select the no-connect tool? If yes, would these be separately editable, or would they simply follow whatever the user changed the main hotkeys to? Or is there some other facility that’s already supposed to work for tools? ___ 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] 5.1.2 release.
I just pushed the 5.1.2 release announcement. The website will be updated on the next build cycle. Thank you to everyone for your continued efforts. Cheers, Wayne ___ 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] Kudos to Michael Kavanagh
Indeed! Keep up the great work Michael. Cheers, Wayne On 4/26/19 5:24 AM, Jeff Young wrote: Just wanted to send out a quick note of appreciation regarding all the work Michael is doing to keep the bug database clean. 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
Re: [Kicad-developers] kicad_pcb, kicad_mod format change for daily build?
> The unfortunate side effect of always quoting all layer names is the noisier file format and the one time change which would be an issue for vcs users. It shouldn't really be that bad? Git and even diff will just point out the new quotes. That's extremely tame. Noisy would be the list of layers changing each commit :P On Fri, Apr 26, 2019 at 8:44 AM Wayne Stambaugh wrote: > Dick, > > On 4/24/19 7:39 PM, Dick Hollenbeck wrote: > > On 4/15/19 8:50 AM, jp charras wrote: > >> Le 15/04/2019 à 15:34, Jeff Young a écrit : > >>> Yes, this was intentional. It allows users to put things like spaces > in layer names and other user-editable things. > >>> > >>> I’ll fix up the STEP exporter…. > >>> > On 15 Apr 2019, at 13:56, easyw wrote: > > Hi, > recently I have noticed that both kicad_pcb and kicad_mod seems to > have changed their format. > It have been introduced double quotes for layers pads etc. > Is that necessary or intentional? > > Here two related issues links: > footprint > > https://github.com/easyw/kicadStepUpMod/issues/13#issuecomment-481160108 > pcb > > https://forum.kicad.info/t/bad-layer-data-error-when-exporting-step/16322/11 > > and a small diff example: > > (layers > (0 F.Cu signal) > (31 B.Cu signal) > > (layers > (0 "F.Cu" signal) > (31 "B.Cu" signal) > > Thanks > Maurice > >> > >> Exactly, in these files, user strings (like fields, pad names, layer > >> names...) were previously quoted on request, i.e. if they contained a > >> space or some other special delimiter char. > >> > >> Now they are always quoted, which is better: user strings are always > >> clearly identified. > >> This is not really a format change. > > > > JP, I think you are blending syntax with grammar. I do not understand > the need for this > > change and currently do not agree with it. It creates noise in version > control systems, > > and makes the files bigger, for no real gain. > > > > The save functions have always done a nice job of deciding whether a > quote is necessary. > > At this pace the files will end up looking like javascript before long, > and will be noisy. > > > > Dick > > > > ___ > > 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 > > > > I understand and share your concerns. This was not a decision made > lightly but this change is on me. I gave the go ahead. It was a > decision based on the lesser of three evils. The decision to allow > users to rename copper layers and not rename non-copper layers when we > implemented the new file format was probably less than ideal. We are in > the process of allowing unrestricted layer names so quoting was > inevitable and so now we are paying the price for the initial decision. > I saw three potential paths forward: > > Option 1: > > Quote all layer names to prevent layer names from being both quoted and > unquoted. Allowing both quoted and unquoted layer names would have been > both ugly and confusing in the file format. The unfortunate side effect > of always quoting all layer names is the noisier file format and the one > time change which would be an issue for vcs users. The advantage is > that this was that no additional coding was required to support > unrestricted layer names on all layers. This option was the path of > least effort which is why I chose it. > > Option 2: > > Force all layer names to the default name for all internal objects and > add an optional quoted name to the layer definition. This option would > maintain the naming symmetry and not require any quoting resulting in a > smaller change set for vcs users who use the default names. For users > who changed copper layer names, there would still be a one time larger > change set hit. This also would have required a fair amount of code to > check for renamed copper layers and rename the internal layer names to > the default and all of the places in the code that display the user's > preferred layer name would have to be updated. > > Options 3: > > Add optional layer name string only to the non-copper layers. This > would make the layer table and the object layer names inconsistent. It > would also complicate any code that uses the user defined layer names. > This option would result in the least intrusive file changes. > > I'm am not opposed to option 2 but there will be a one time hit for vcs > users who rename their copper layers so I do not see any path forward > where we don't have to make a compromise. I really don't like option 3. > If you or anyone else has a better idea, I'm always open to suggestion. > > I am traveling and have a busy schedule over the weekend so my response > time will be a bit delayed.
Re: [Kicad-developers] kicad_pcb, kicad_mod format change for daily build?
Dick, On 4/24/19 7:39 PM, Dick Hollenbeck wrote: On 4/15/19 8:50 AM, jp charras wrote: Le 15/04/2019 à 15:34, Jeff Young a écrit : Yes, this was intentional. It allows users to put things like spaces in layer names and other user-editable things. I’ll fix up the STEP exporter…. On 15 Apr 2019, at 13:56, easyw wrote: Hi, recently I have noticed that both kicad_pcb and kicad_mod seems to have changed their format. It have been introduced double quotes for layers pads etc. Is that necessary or intentional? Here two related issues links: footprint https://github.com/easyw/kicadStepUpMod/issues/13#issuecomment-481160108 pcb https://forum.kicad.info/t/bad-layer-data-error-when-exporting-step/16322/11 and a small diff example: (layers (0 F.Cu signal) (31 B.Cu signal) (layers (0 "F.Cu" signal) (31 "B.Cu" signal) Thanks Maurice Exactly, in these files, user strings (like fields, pad names, layer names...) were previously quoted on request, i.e. if they contained a space or some other special delimiter char. Now they are always quoted, which is better: user strings are always clearly identified. This is not really a format change. JP, I think you are blending syntax with grammar. I do not understand the need for this change and currently do not agree with it. It creates noise in version control systems, and makes the files bigger, for no real gain. The save functions have always done a nice job of deciding whether a quote is necessary. At this pace the files will end up looking like javascript before long, and will be noisy. Dick ___ 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 I understand and share your concerns. This was not a decision made lightly but this change is on me. I gave the go ahead. It was a decision based on the lesser of three evils. The decision to allow users to rename copper layers and not rename non-copper layers when we implemented the new file format was probably less than ideal. We are in the process of allowing unrestricted layer names so quoting was inevitable and so now we are paying the price for the initial decision. I saw three potential paths forward: Option 1: Quote all layer names to prevent layer names from being both quoted and unquoted. Allowing both quoted and unquoted layer names would have been both ugly and confusing in the file format. The unfortunate side effect of always quoting all layer names is the noisier file format and the one time change which would be an issue for vcs users. The advantage is that this was that no additional coding was required to support unrestricted layer names on all layers. This option was the path of least effort which is why I chose it. Option 2: Force all layer names to the default name for all internal objects and add an optional quoted name to the layer definition. This option would maintain the naming symmetry and not require any quoting resulting in a smaller change set for vcs users who use the default names. For users who changed copper layer names, there would still be a one time larger change set hit. This also would have required a fair amount of code to check for renamed copper layers and rename the internal layer names to the default and all of the places in the code that display the user's preferred layer name would have to be updated. Options 3: Add optional layer name string only to the non-copper layers. This would make the layer table and the object layer names inconsistent. It would also complicate any code that uses the user defined layer names. This option would result in the least intrusive file changes. I'm am not opposed to option 2 but there will be a one time hit for vcs users who rename their copper layers so I do not see any path forward where we don't have to make a compromise. I really don't like option 3. If you or anyone else has a better idea, I'm always open to suggestion. I am traveling and have a busy schedule over the weekend so my response time will be a bit delayed. Cheers, Wayne ___ 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] Kudos to Michael Kavanagh
+1 much appreciated On Fri, Apr 26, 2019, 04:24 Jeff Young wrote: > Just wanted to send out a quick note of appreciation regarding all the > work Michael is doing to keep the bug database clean. > > 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] Kudos to Michael Kavanagh
Just wanted to send out a quick note of appreciation regarding all the work Michael is doing to keep the bug database clean. 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
Re: [Kicad-developers] Improving library editor checks
Hi, Am 25.04.19 um 16:15 schrieb Wayne Stambaugh: > Python scripting support is hopefully going to be implemented at some > point during V6 development. This should allow you to integrate the KLC > scripts directly into the symbol library editor. This will most likely > happen late in V6 development because there are some major functional > changes to the low level schematic and library objects. It doesn't make > sense to swig this until the low level object APIs stabilize. what I'd like to see in KiCad regarding some automatic QA while creating own symbols or footprints is a possibility to do an automatic checking of symbols or footprints while I'm working on it depending on selected rule set. At least a possible checking directly within the editors in KiCad. It's currently a bit uncomfortable and time consuming to check if a symbol is fulfilling the KLC's rules (or any other rules). Furthermore I'd appreciate if KiCad would pre ship such rule sets and I could choose one. And also if I could copy such an existing rule set to my own settings set and modify it afterwards. Own rule sets should be addable from a own dedicated folder and also selectable from and savable within a project. -- Regards Carsten Schoenert ___ 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
