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

2018-01-10 Thread Jon Evans
Hi all, Right now, we have conflicting "desired order" for technical layers in various places. The layer widget displays "front first", i.e. F.Paste before B.Paste, F.Fab before B.Fab, etc. Everywhere else in the codebase is "back first". This leads to this bug:

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

2018-01-10 Thread Jon Evans
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 can give it a try on your crashing machine that would be greatly appreciated. Thanks -Jon From 764a1cd4f222ef4a7ee08d495d89642950653061 Mon Sep

[Kicad-developers] [PATCH] Don't draw invisible pins in component chooser

2018-01-10 Thread Jon Evans
Implemented an override flag that makes it possible to turn off invisible pin rendering outside of the EDA_DRAW_FRAME. Fixes: https://bugs.launchpad.net/kicad/+bug/1742485 IMHO this is a bug, not a feature request, because the invisible pins clutter the view in the preview pane of the component

[Kicad-developers] [PATCH] Use worksheet bounding box when the board is empty

2018-01-10 Thread Jon Evans
Adds a mechanism for EDA_DRAW_PANEL_GAL children to define what the default bounding box should be when the model doesn't provide a valid bounding box. Fixes: https://bugs.launchpad.net/kicad/+bug/1742140 -Jon From caac1e0bfa0c0e166d6cb55c8eefd7f8706238bb Mon Sep 17 00:00:00 2001 From: Jon Evans

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

2018-01-10 Thread Chris Pavlina
If your system DPI is already within a certain range it won't do anything. Are you using a high DPI display? If it's not scaled correctly, would you please share with me the diagnostic number reported by the scale slider in eeschema prefs as well as a rough indication of the icons' physical size?

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

2018-01-10 Thread Kevin Cozens
On 2018-01-10 09:05 AM, Jörg Hermann wrote: Wayne disapproves the introduction of a version number. While I see the benefit - data format is always crystal clear, it makes parsers more complex all the time. From a maintenance pov I agree with Wayne, not introducing a version number. With

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

2018-01-10 Thread Chris Pavlina
Sure, assign me to it. I should have time to work on it tonight or tomorrow. On Wed, Jan 10, 2018 at 04:20:21PM -0500, Wayne Stambaugh wrote: > FYI, the edit footprint dialog in Pcbnew is not sized properly (at least > on windows) which I'm pretty sure is related to your recent HiDPI work. > Do

Re: [Kicad-developers] Strawman for new Exchange Footprint and Update Footprints dialogs

2018-01-10 Thread Jon Evans
Now I'm nit-picking but wouldn't "replace" be even better than "change"? That's what I see used in other tools and it might be less ambiguous for translation. On Wed, Jan 10, 2018 at 4:15 PM, Wayne Stambaugh wrote: > Jeff, > > Please use "change" rather than "exchange".

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

2018-01-10 Thread Wayne Stambaugh
FYI, the edit footprint dialog in Pcbnew is not sized properly (at least on windows) which I'm pretty sure is related to your recent HiDPI work. Do you want me to file a bug report for it? On 1/10/2018 2:01 PM, Chris Pavlina wrote: > By the way, I'm going to go ahead and push this tonight-ish if

Re: [Kicad-developers] Strawman for new Exchange Footprint and Update Footprints dialogs

2018-01-10 Thread Wayne Stambaugh
Jeff, Please use "change" rather than "exchange". Exchange means that there is some bidirectional event taking place. This is not the case here. The existing footprint(s) is merely being replaced. I would prefer that the text edit control always be editable. That way the user can change the

Re: [Kicad-developers] Some thoughts on symbol remapping

2018-01-10 Thread Rene Pöschl
On 10/01/18 19:54, Matthijs Kooijman wrote: Hi Wayne, If the remapping algorithm cannot find the exact library match which is currently being used (and should be in the project library list or the cache) to provide the symbol, then there is no way to determine the correct library and therefore

Re: [Kicad-developers] Libedit and Modedit Icons

2018-01-10 Thread Andrey Kuznetsov
I agree on Calculator revert, Bitmap revert, keeping the new GBR icon (looks really nice). On Wed, Jan 10, 2018 at 7:47 AM, Kristoffer Ödmark < kristofferodmar...@gmail.com> wrote: > Practially I would read this as: > > Go back to the single calculator icon, instead of the +-= boxes. > Revert

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

2018-01-10 Thread Chris Pavlina
By the way, I'm going to go ahead and push this tonight-ish if nobody objects. I know it's on the big side, but due to my limited number of machines to test on I really want time for user feedback. I'll be around to put out any fires. On Wed, Jan 10, 2018 at 11:07:49AM -0700, Chris Pavlina wrote:

Re: [Kicad-developers] Some thoughts on symbol remapping

2018-01-10 Thread Matthijs Kooijman
Hey Rene, > This is not as easy as simply a one to one mapping. The connectors > library has been split into 3 libs. Most other libs into even more. > (Especially manufacturer specific libs.) > In reality the best option for old projects will be to have the v4 libs > installed in addition to the

Re: [Kicad-developers] Some thoughts on symbol remapping

2018-01-10 Thread Matthijs Kooijman
Hi Wayne, > >> If the remapping algorithm cannot find the exact library match which > >> is currently being used (and should be in the project library list or > >> the cache) to provide the symbol, then there is no way to determine > >> the correct library and therefore cannot be remapped. It

Re: [Kicad-developers] Libedit and Modedit Icons

2018-01-10 Thread Kristoffer Ödmark
Practially I would read this as: Go back to the single calculator icon, instead of the +-= boxes. Revert the camera icon to the "a" character, cleanup if wanted but dont change concept fundamentally. Otherwise I went throught the old icons in my current build and checked them against the

Re: [Kicad-developers] Libedit and Modedit Icons

2018-01-10 Thread Jeff Young
To limit scope-creep I think the importance of the changes would be as follows: 1) sorting out the damn arrows 2) cleaning up the libedit and modedit icons 3) regularising eeschema, pcbnew and gerberview icons 4) regularising calculator, drawing frame, etc. The largest usability improvements are

Re: [Kicad-developers] Libedit and Modedit Icons

2018-01-10 Thread Wayne Stambaugh
I see scope creep happening here. I thought the original goal was to make some minor tweaks to our existing icons not wholesale replacement of the them. I don't like the camera either. I'm not a big fan of the calculator icon. Both of these icons looks completely out of place with our other

Re: [Kicad-developers] Libedit and Modedit Icons

2018-01-10 Thread Jeff Young
Splendid! Although I agree with Kristoffer that the new bitmap2component icon isn’t much help. Import/Export is the one area where we’ve kept the arrows (which I think is fine). Given that, the pixelated “a” with an import arrow would be perfect. FWIW, this is one area where I disagree with

Re: [Kicad-developers] Libedit and Modedit Icons

2018-01-10 Thread Oliver Walters
> > Also, would it be too much to ask for getting the arrows, the diskette and > the folder in the repo with the patch, basically if someone wants to create > future icons. They could use the same arrows for any kind of export, > import, save, inspect or view. I have created a set of "common

Re: [Kicad-developers] Libedit and Modedit Icons

2018-01-10 Thread Jon Evans
This is a common way to test software too, in case we ever want to try to build automated tests. On Jan 10, 2018 09:02, "Kristoffer Ödmark" wrote: I think trying to replicate what this guy does here would be quite time saving wouldnt it?

Re: [Kicad-developers] Libedit and Modedit Icons

2018-01-10 Thread Kristoffer Ödmark
Wow, really nice! Although, the icon for the bitmap2component basically looks like a screenshot symbol to me, or something related to a webcam. The old one isnt as polished, but I think it fits better. Also, would it be too much to ask for getting the arrows, the diskette and the folder in

Re: [Kicad-developers] Some thoughts on symbol remapping

2018-01-10 Thread Wayne Stambaugh
On 1/10/2018 5:46 AM, Matthijs Kooijman wrote: > Hi Wayne, > >> The symlink issue has been fixed so duplicate libraries will not show up >> in the project symbol library table with different nicknames. > I noticed some issues with my previous build (2017-12-22), but using the > 2018-01-03 build,

Re: [Kicad-developers] Libedit and Modedit Icons

2018-01-10 Thread Nick Østergaard
I think you need to do a side by side comparison with the old and also showcase it with a dark theme. I would also like to see a summary of why specific features was changed on the icons. Otherwise we have not got any further and I think the updates should be rejected. In seven months or so

Re: [Kicad-developers] Libedit and Modedit Icons

2018-01-10 Thread Oliver Walters
Wayne, Here is the outcome of removing the save / load arrows and replacing with standard load / save icons. I have also further tweaked the main icons as per suggestions. Screenshots here: https://imgur.com/a/DzZhZ This is about as far as I want to go with this, please let me know if there

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

2018-01-10 Thread Oliver Walters
Jorg, this has already been fixed and merged :) On Thu, Jan 11, 2018 at 1:05 AM, Jörg Hermann wrote: > The summary of this thread to me is: > > 1) Everybody is in favour of uniform, consistent measurement units, mm > that is. > 2) Everybody sees a long term benefit. > 3)

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

2018-01-10 Thread Jörg Hermann
The summary of this thread to me is: 1) Everybody is in favour of uniform, consistent measurement units, mm that is. 2) Everybody sees a long term benefit. 3) Everybody agrees V5 is disruptive due to library changes. 4) There seems to be consensus that only few users will be bitten by the 3D

Re: [Kicad-developers] Libedit and Modedit Icons

2018-01-10 Thread Kristoffer Ödmark
I think trying to replicate what this guy does here would be quite time saving wouldnt it? http://scottbezek.blogspot.se/2016/04/automated-kicad-schematic-export.html Basically scripting keypresses, and then using something like scrot to take a screenshot of the intended area. This would keep

Re: [Kicad-developers] Libedit and Modedit Icons

2018-01-10 Thread Jörg Hermann
Hello Oliver, congrats on the huge improvement on the icons! For further simplification I would remove the gray “paper-boundary” on schematic and worksheet icons, citing Jeff Young: “… adding visual complexity without any cognitive benefit”. When Wayne refers to the doc team - I expect the

Re: [Kicad-developers] Libedit and Modedit Icons

2018-01-10 Thread jp charras
Le 10/01/2018 à 13:55, Jörg Hermann a écrit : > Hello Oliver, > > congrats on the huge improvement on the icons! > For further simplification I would remove the gray “paper-boundary” on > schematic and worksheet icons, citing Jeff Young: “… adding visual complexity > without any cognitive

Re: [Kicad-developers] Some thoughts on symbol remapping

2018-01-10 Thread Rene Pöschl
On 10/01/18 11:46, Matthijs Kooijman wrote: A related question: How are the changes in library layout intended to be handled, when combined with the remapping dialog? AFAIU the migration to the new kicad-symbols repository also involves renaming a lot of libraries (e.g. Connectors.lib ->

Re: [Kicad-developers] Some thoughts on symbol remapping

2018-01-10 Thread Matthijs Kooijman
Hi Wayne, > The symlink issue has been fixed so duplicate libraries will not show up > in the project symbol library table with different nicknames. I noticed some issues with my previous build (2017-12-22), but using the 2018-01-03 build, symlinks (both in the directory and filename) indeed seem