Re: [Kicad-developers] Hotkeys Editor

I really don't care. The original motivation was simply being able to cleanly put it as a tab inside the preferences dialog without nesting, I really didn't think putting them in a single list would make them undiscoverable (and this is the first I've heard that comment, to be honest). But I have

Re: [Kicad-developers] [PATCH] Defer canvas type setting save until destruction of EDA_DRAW_FRAME

Updated patch attached (missed initializers in the original) On Wed, Jan 10, 2018 at 11:40 PM, Jon Evans wrote: > Hopefully this fixes: > https://bugs.launchpad.net/kicad/+bug/1741787 > although I don't currently have a good way of reproducing the crash. > > Chris, if you

Re: [Kicad-developers] Hotkeys Editor

Hi All- Sorry, this seems to have gotten off-track. Let's pause the button discussion for a moment. I'm really more concerned about the tree-list layout hiding hotkeys from users. Does anyone feel like we need the treelist here? Chris, I know this was originally your commit and I don't mean

Re: [Kicad-developers] Libedit and Modedit Icons

Awesome, thanks! Looks good. On Thu, Jan 11, 2018 at 7:27 PM Oliver Walters < oliver.henry.walt...@gmail.com> wrote: > Andrey, > > Here's all I can provide currently (at work!) > > [image: Inline image 1] > > I have sent the entire patch to Wayne and JP privately so the merging is > now in

Re: [Kicad-developers] Libedit and Modedit Icons

Andrey, Here's all I can provide currently (at work!) [image: Inline image 1] I have sent the entire patch to Wayne and JP privately so the merging is now in their capable hands :) On Fri, Jan 12, 2018 at 2:20 PM, Andrey Kuznetsov wrote: > Also the attached image of the

Re: [Kicad-developers] Hotkeys Editor

If that would be the intended functionality, then I'd suggest "Reset Selected" instead of "Reset". On Thu, Jan 11, 2018 at 5:01 AM, yann jautard wrote: > what about keeping four buttons : > > *Defaults* that reset all hotkeys *of the current tab* to default > > *Reset* that

Re: [Kicad-developers] Libedit and Modedit Icons

Also the attached image of the final icon set was discarded, can you please resend the final icon image set? Thank you On Thu, Jan 11, 2018 at 8:35 AM, jp charras wrote: > Le 11/01/2018 à 08:54, Oliver Walters a écrit : > > Wayne, > > > > I have taken further suggestions

[Kicad-developers] [PATCH] Save view control settings before dispatching new tool events

Fix another cause of https://bugs.launchpad.net/kicad/+bug/1741357 Using the "add via" hotkey was causing an immediate dispatch of that tool event, which was overriding the view settings of the active tool (i.e. router tool with cursor displayed). This patch saves and restores the view settings

Re: [Kicad-developers] desired layer sequence for pcb technical layers

My original question is about the structure of the kicad code, not about the layer manager. I'm asking if there is any technical reason why back layers are listed first in a specific part of the code base. If no one has a good answer, I'm going to submit a patch to change it to have front layers

Re: [Kicad-developers] desired layer sequence for pcb technical layers

Actually, programs like Altium and Allegro allow you to swap the order of layers, to change visibility of transparent layers. For example, make back layer have higher priority, and front layer lower priority, with the back layer setting to 50% transparency, etc. But I guess this layer manager is

Re: [Kicad-developers] desired layer sequence for pcb technical layers

Yes, in the KiCad codebase, they are called Front and Back, and my question is independent of whether or not they should be called Top and Bottom :-) On Thu, Jan 11, 2018 at 2:16 PM, Diego Herranz < diegoherr...@diegoherranz.com> wrote: > Regarding Front vs Top, I see it called Top everywhere

Re: [Kicad-developers] desired layer sequence for pcb technical layers

Regarding Front vs Top, I see it called Top everywhere else, but back to the original question: +1 for Top/Front first. Thanks, Diego On Thu, Jan 11, 2018 at 5:52 AM, Andrey Kuznetsov wrote: > Why is it Front and Back, as opposed to Top and Bottom? > Front/Top should be

Re: [Kicad-developers] wxStaticBoxSizer fixes

Le 11/01/2018 à 19:29, Chris Pavlina a écrit : > Interesting. I wonder if we could implement a wrapper around > wxStaticBoxSizers to fix the issue rather than switching away from them > - they look much nicer than the replacement. Which KDE version are you > using specifically? I'd like to have a

Re: [Kicad-developers] Minor releases (post v5.0.0)

I think this is relevant now so the feature set can be frozen definitely, but also don't make people feel like they either have to rush it now or wait years for their pet feature to appear on the next stable release, this could also mean dropping unfinished features in the interest of having v5

Re: [Kicad-developers] Minor releases (post v5.0.0)

Please save this for the post v5 discussion. On 1/11/2018 1:27 PM, Chris Pavlina wrote: > I agree with all of this 100%. > > On Thu, Jan 11, 2018 at 11:45:58AM -0600, José Ignacio wrote: >> I've started to see a flurry of features that are either getting rushed in >> for v5.0 or being pushed

Re: [Kicad-developers] wxStaticBoxSizer fixes

Interesting. I wonder if we could implement a wrapper around wxStaticBoxSizers to fix the issue rather than switching away from them - they look much nicer than the replacement. Which KDE version are you using specifically? I'd like to have a look at this. (Would be nice if these fixes could also

Re: [Kicad-developers] Minor releases (post v5.0.0)

I agree with all of this 100%. On Thu, Jan 11, 2018 at 11:45:58AM -0600, José Ignacio wrote: > I've started to see a flurry of features that are either getting rushed in > for v5.0 or being pushed aside to the future "v6" version of kicad. Due to > the limited resources of the development team

Re: [Kicad-developers] wxStaticBoxSizer fixes

Le 11/01/2018 à 18:27, Chris Pavlina a écrit : > Hi (@JP mostly), > > I see you're removing wxStaticBoxSizers [1] due to issues with KDE. Have > you tried the fix I implemented in [2] for what I think is the same > issue? You commented on the bug report and said it worked for you, and I > didn't

[Kicad-developers] Minor releases (post v5.0.0)

I've started to see a flurry of features that are either getting rushed in for v5.0 or being pushed aside to the future "v6" version of kicad. Due to the limited resources of the development team and the sheer amount of work for each major release, the development cycles get pretty long, and many

[Kicad-developers] wxStaticBoxSizer fixes

Hi (@JP mostly), I see you're removing wxStaticBoxSizers [1] due to issues with KDE. Have you tried the fix I implemented in [2] for what I think is the same issue? You commented on the bug report and said it worked for you, and I didn't have to remove the wxStaticBoxSizer, only change a property

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

Yup. For reference my own display is around 280 DPI. On Thu, Jan 11, 2018 at 10:35:15AM +, Jeff Young wrote: > 2560x1440 @ 24” is only 122 DPI. > > Apple’s Retina displays are 220 or 227, and the Surface Book in the original > bug report is 267 DPI. > > > On 11 Jan 2018, at 09:54,

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

You're right on the threshold I chose (somewhat arbitrarily). 5mm sounds decent. I made an intentional choice not to start scaling until it's quite necessary, because it's just simple bitmap scaling and on displays that are lower in DPI they _look_ scaled. On Thu, Jan 11, 2018 at 09:53:52AM

Re: [Kicad-developers] Daily build for KiCad on Ubuntu (ppa)

Hi all, Ubuntu had re-enable the build farm but there is a large number of other packages waiting for rebuild. As I see, it should take 1 or 2 days before daily build of new packages. Regards, Le 09/01/2018 à 20:36, Jean-Samuel Reynaud a écrit : > Hi all, > > Launchpad build farm is currently

Re: [Kicad-developers] Libedit and Modedit Icons

Le 11/01/2018 à 08:54, Oliver Walters a écrit : > Wayne, > > I have taken further suggestions and final icon set is shown below: > > [image: Inline image 1] > > The attached patch incorporates all of the icon changes thus far > implemented. > > Thanks, > Oliver > Oliver, For some unknown

Re: [Kicad-developers] Libedit and Modedit Icons

Wayne, I have taken further suggestions and final icon set is shown below: [image: Inline image 1] The attached patch incorporates all of the icon changes thus far implemented. Thanks, Oliver On Thu, Jan 11, 2018 at 1:58 AM, Wayne Stambaugh wrote: > I see scope creep

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

Chris, I submitted the bug report[1] for this issue. Thanks for looking into it. Cheers, Wayne [1]: https://bugs.launchpad.net/kicad/+bug/1742701 On 1/10/2018 4:23 PM, Chris Pavlina wrote: > Sure, assign me to it. I should have time to work on it tonight or > tomorrow. > > On Wed, Jan 10,

Re: [Kicad-developers] Hotkeys Editor

what about  keeping four buttons : *Defaults* that reset all hotkeys *of the current tab* to default *Reset* that reset *the selected* hotkey only to default *Cancel* that close the window and undo the current changes *Save* that close the window and save the current changes With a tooltip

Re: [Kicad-developers] Libedit and Modedit Icons

On 2018-01-11 11:06, Jörg Hermann wrote: > After all of Olivers work and the amount of time discussed here, I strongly > vote for accepting the changes, as they are a huge improvement. > I agree on keeping the “old” pixelated a and PCB calculator, if that helps > accepting the remaining

Re: [Kicad-developers] Hotkeys Editor

I agree that the tabs were better. And I agree that the Defaults button is a good addition. I don’t agree about the Reset button. Too much visual complexity when the user can just hit Cancel and then Edit Hotkeys again to achieve the same effect. Cheers, Jeff. > On 11 Jan 2018, at 01:07,

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

2560x1440 @ 24” is only 122 DPI. Apple’s Retina displays are 220 or 227, and the Surface Book in the original bug report is 267 DPI. > On 11 Jan 2018, at 09:54, kristoffer Ödmark > wrote: > > I have 2560x1440, 24" screens, I think those qualifies as high DPI? >

Re: [Kicad-developers] COMPONENT_TREE performance

Gaurav asked for examples using Qt: Eagle. As they implemented their awkward UI across all OS, I see no problems whatsoever for Kicad. Having done multiplatform / multiarchitecture releases with Qt, I can confirm it was totally stable and automatized. Wayne is correct, a huge amount of effort

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

I have 2560x1440, 24" screens, I think those qualifies as high DPI? The slider value is at 100, and the diag value is at 23. The icons are ish 5mm large. But i guess that is uneccesary since It seems the scaling works as intended, I was just doing it wrong, so no errors, sorry :) The

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

I have 2560x1440, 24" screens, I think those qualifies as high DPI? The slider value is at 100, and the diag value is at 23. The icons are ish 5mm large. But i guess that is uneccesary since It seems the scaling works as intended, I was just doing it wrong, so no errors, sorry :) The

Re: [Kicad-developers] Hotkeys Editor

On Thu, January 11, 2018 09:37, Andrey Kuznetsov wrote: > I wonder if "Undo All" is more appropriate if all the changes during that > session are undone, as opposed to just the last one. > That's very similar to "Cancel" then. Perhaps, we can remove the Undo button entirely in this case. > On

Re: [Kicad-developers] Hotkeys Editor

I wonder if "Undo All" is more appropriate if all the changes during that session are undone, as opposed to just the last one. On Thu, Jan 11, 2018 at 12:35 AM, Thomas Kindler wrote: > > On Thu, January 11, 2018 02:07, Seth Hillbrand wrote: > > I feel that there is a

Re: [Kicad-developers] Hotkeys Editor

On Thu, January 11, 2018 02:07, Seth Hillbrand wrote: > I feel that there is a usability issue with the current hotkeys editor > that is a regression from the 4.0.7 hotkeys editor. > > I've attached images for both to this message. The current editor opens > with a tree view that hides the