[Kicad-developers] General question about Kicad libraries...
I have what might be a dumb question about Kicad libraries. Why does Kicad not use a standard SQL database, such as MariaDB, SQLite, etc? There may be really good reasons not to do this but it seems, at least to me, that it would make some things simpler such as making it easier to incorporate Kicad into company inventory systems. ___ 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] Pcbnew zoom to fit behavior changed
Thanks Jon, now this makes sense. With ability to disable worksheet in items panel to revert to old behavior I am mostly satisfied. Ideally I wouldn't have to do that since honestly the only time I pay attention to worksheet is in the very last stage of the project when gerbers are already done and I just fill in the metadata for publishing. But I can see the consistency argument and unchecking one tick box at the start of the project is certainly not a big deal. Andrew On Mon, May 27, 2019 at 4:10 PM Jon Evans wrote: > Hi Andrew, > > This was intentional but I'm open to input on this. > The previous behavior would zoom to fit all items (including items on > hidden layers), or the worksheet if there are no items. > The new behavior zooms in on all visible items. > So, if you don't want to zoom to fit the worksheet, you can just turn off > the worksheet layers (in the Items panel) > > Is that enough of an option for you? > We could go back to the behavior of "only consider the worksheet if there > are no items" but it made less sense to me. > > (The relevant commit is 549b767) > > -Jon > > On Mon, May 27, 2019 at 7:04 PM Andrew Lutsenko > wrote: > >> Hi all, >> >> On current master (50d2aaa97) I noticed that zoom to fit action in pcbnew >> now zooms on the whole drawing, including the template border instead of >> just on the board. >> >> Is that intentional? If so can we have an option in preferences to revert >> to old behavior? >> It is much more sensible in my opinion and I use that function a lot, I'm >> sure others do too. >> >> Regards, >> Andrew >> ___ >> 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] Pcbnew zoom to fit behavior changed
Hi Andrew, This was intentional but I'm open to input on this. The previous behavior would zoom to fit all items (including items on hidden layers), or the worksheet if there are no items. The new behavior zooms in on all visible items. So, if you don't want to zoom to fit the worksheet, you can just turn off the worksheet layers (in the Items panel) Is that enough of an option for you? We could go back to the behavior of "only consider the worksheet if there are no items" but it made less sense to me. (The relevant commit is 549b767) -Jon On Mon, May 27, 2019 at 7:04 PM Andrew Lutsenko wrote: > Hi all, > > On current master (50d2aaa97) I noticed that zoom to fit action in pcbnew > now zooms on the whole drawing, including the template border instead of > just on the board. > > Is that intentional? If so can we have an option in preferences to revert > to old behavior? > It is much more sensible in my opinion and I use that function a lot, I'm > sure others do too. > > Regards, > Andrew > ___ > 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] Pcbnew zoom to fit behavior changed
Hi all, On current master (50d2aaa97) I noticed that zoom to fit action in pcbnew now zooms on the whole drawing, including the template border instead of just on the board. Is that intentional? If so can we have an option in preferences to revert to old behavior? It is much more sensible in my opinion and I use that function a lot, I'm sure others do too. Regards, Andrew ___ 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] [PATCH] Crash Reporter
On 27/05/2019 17:39, Seth Hillbrand wrote: > On 2019-05-02 17:41, Tomasz Wlostowski wrote: >> On 02/05/2019 07:06, Wayne Stambaugh wrote: >>> >>> By chance did you build with OCC instead of OCE which is what I am >>> using? Please fix this when you get a chance, I would like to get this >>> merged but I need to be able to test. >>> >>> Why did your remove the GDK_* and GTK_* environment variables from >>> APP_KICAD ctor? Wont this break the compatibility support we currently >>> have? >>> >>> I noticed quite a bit of trailing whitespace in patches 5 and 10 so that >>> will need to be cleaned up. >>> >>> Please send me the link to your remote branch for this. It's easier for >>> me to just pull a branch into my repo than apply a large patch set using >>> `git am`. >> >> Hi Wayne, >> >> Probably I screwed something up while rebasing the code on top of fresh >> master. I'll check/fix the errors in the evening. >> >> Greetings from CO, >> Tom > > Ping! Hi Seth, Rebasing it on the latest master right now. I'm still getting some Windows build issues, hope to sort them out by tomorrow. T. ___ 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] Undo paradigms
On 5/27/19 11:11 AM, Seth Hillbrand wrote: > On 2019-05-27 11:05, Tomasz Wlostowski wrote: >> On 27/05/2019 16:46, Jeff Young wrote: >>> Hi Seth, >>> >>> The Eeschema has one advantage that if you mess it up you get too >>> many undo steps rather than too few. But it is somewhat crankier >>> code to get right. >>> >>> I agree that we should have only one scheme. I don’t believe >>> anyone’s working on it — although it would probably be Tom if anyone >>> was. >> >> Hi, >> >> Some time ago we introduced with Orson the COMMIT object, which manages >> atomic updates to the PCB, lightweight notifications as well as creation >> of undo entries. How about porting this to eeschema? >> >> Tom > > Yup, that's exactly the idea. > > -Seth It seems to me the obvious place to put this would be the concrete SCHEMATIC object in a similar manner to the BOARD object so I'll take a look at it when I'm working on that. It will be substantially more difficult do to the hierarchical sheet issues. I haven't thought about it that much yet but it's definitely on my radar. We've needed a decent undo/redo solution for hierarchical sheets since I joined the project. 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] Why is the schematic view boundary set as small as it is?
Thanks, I'll change the code to 3x3 and fix the zoom/move issues. On Mon, May 27, 2019 at 3:25 AM jp charras wrote: > Le 26/05/2019 à 17:36, Jon Evans a écrit : > > Hi all, > > > > This question is particularly for JP since you have written the relevant > > code. > > > > Why is SCH_VIEW initialized to such a small size compared to the area > > that is accessible if you zoom out? > > > > You can see in my screenshot that the view boundary is initialized to > > the pink rectangle, but it is quite easy to zoom out way past that > > boundary and move components there. But because of the boundary being > > checked in some places (like zoom to selection), it causes various > > problems such as the bug report in [1] > > > > If we really want to set such a small view boundary, we should prevent > > moving objects outside of it, and restrict the minimum zoom level to > > something more reasonable. In my opinion, though, we should have some > > middle ground -- the current view boundary is too small for some use > > cases. It can be useful to drag the entire sheet contents off-sheet > > for some workflows, so I think the view boundary should be at least the > > size of a 3x3 grid of worksheets, if not larger than that. > > > > Any thoughts on this? > > > > Screenshot from 2019-05-26 11-30-44.png > > > > [1] https://bugs.launchpad.net/kicad/+bug/1822442 > > > > Thanks, > > -Jon > > > We have to limit the view boundary to make Scrollbars more easy to use, > especially for "small" page sizes like A or B. > > A boundary size of a 3x3 grid of worksheets is possible, at least for > "small" pages (I am not sure Scrollbars are still usable if the boundary > size in 6 x 9 meters (max size of a page in eeschema: 2x3m) ). > (this is what is in SCH_VIEW::ResizeSheetWorkingArea() comments but not > in code). > > And obviously the zoom level (and moving objects) need to be limited to > respect this boundary size. > > -- > 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] [PATCH] Crash Reporter
On 2019-05-02 17:41, Tomasz Wlostowski wrote: On 02/05/2019 07:06, Wayne Stambaugh wrote: By chance did you build with OCC instead of OCE which is what I am using? Please fix this when you get a chance, I would like to get this merged but I need to be able to test. Why did your remove the GDK_* and GTK_* environment variables from APP_KICAD ctor? Wont this break the compatibility support we currently have? I noticed quite a bit of trailing whitespace in patches 5 and 10 so that will need to be cleaned up. Please send me the link to your remote branch for this. It's easier for me to just pull a branch into my repo than apply a large patch set using `git am`. Hi Wayne, Probably I screwed something up while rebasing the code on top of fresh master. I'll check/fix the errors in the evening. Greetings from CO, Tom Ping! ___ 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] Undo paradigms
On 2019-05-27 11:05, Tomasz Wlostowski wrote: On 27/05/2019 16:46, Jeff Young wrote: Hi Seth, The Eeschema has one advantage that if you mess it up you get too many undo steps rather than too few. But it is somewhat crankier code to get right. I agree that we should have only one scheme. I don’t believe anyone’s working on it — although it would probably be Tom if anyone was. Hi, Some time ago we introduced with Orson the COMMIT object, which manages atomic updates to the PCB, lightweight notifications as well as creation of undo entries. How about porting this to eeschema? Tom Yup, that's exactly the idea. -Seth ___ 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] Undo paradigms
On 27/05/2019 16:46, Jeff Young wrote: > Hi Seth, > > The Eeschema has one advantage that if you mess it up you get too many undo > steps rather than too few. But it is somewhat crankier code to get right. > > I agree that we should have only one scheme. I don’t believe anyone’s > working on it — although it would probably be Tom if anyone was. Hi, Some time ago we introduced with Orson the COMMIT object, which manages atomic updates to the PCB, lightweight notifications as well as creation of undo entries. How about porting this to eeschema? 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] Undo paradigms
Hi Seth, The Eeschema has one advantage that if you mess it up you get too many undo steps rather than too few. But it is somewhat crankier code to get right. I agree that we should have only one scheme. I don’t believe anyone’s working on it — although it would probably be Tom if anyone was. Cheers, Jeff. > On 27 May 2019, at 15:30, Seth Hillbrand wrote: > > Hi Devs- > > We have two different paradigms for undo/redo stacks. The eeschema paradigm > and the pcbnew paradigm. In Eeschema, we add things directly to the undo > stack, optionally appending to the last item. In Pcbnew, we queue an undo > step in the frame until all items are added and then push the step to the > stack. > > Personally, I have found the pcbnew model to be much more robust and it > avoids passing around the "are we appending now?" flag to each intermediate > step. It also avoids having to change the undo stack when a command is > canceled. > > I'd like to move eeschema over to the pcbnew model. Is anyone working on > this already? > > -Seth > > ___ > 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] Undo paradigms
Hi Devs- We have two different paradigms for undo/redo stacks. The eeschema paradigm and the pcbnew paradigm. In Eeschema, we add things directly to the undo stack, optionally appending to the last item. In Pcbnew, we queue an undo step in the frame until all items are added and then push the step to the stack. Personally, I have found the pcbnew model to be much more robust and it avoids passing around the "are we appending now?" flag to each intermediate step. It also avoids having to change the undo stack when a command is canceled. I'd like to move eeschema over to the pcbnew model. Is anyone working on this already? -Seth ___ 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] Floating Point Exceptions
Agreed. We should have FPE on for debug. That said, I _think_ they are as I just fixed an Eagle import bug that was choking on one. Of course, I might be mistaken and only seen the exception because I was in gdb. If the code isn't explicit in CMake, we should probably have the "enable in debug"/"disable in release" set explicitly. -Seth On 2019-05-27 05:12, Jeff Young wrote: I think we should at least give it a try. If we end up getting exceptions everywhere then we can either fix them or turn it back off. Cheers, Jeff. On 27 May 2019, at 09:23, Simon Richter wrote: Hi, I just got a notification that bug #1821758 expired. I'd rather not ignore this, because I can see that there are likely to be two issues here: - Context code not setting up the floating point environment correctly on POWER - Some floating point operation running into an exception (which itself shouldn't happen, and usually means that some value is now NaN). I wonder if it would make sense to enable floating point exceptions in Debug builds so we at least stumble over these bugs occasionally. I'd turn the original bug into a "check FPE on POWER" minor bug then. Simon ___ 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] Floating Point Exceptions
I think we should at least give it a try. If we end up getting exceptions everywhere then we can either fix them or turn it back off. Cheers, Jeff. > On 27 May 2019, at 09:23, Simon Richter wrote: > > Hi, > > I just got a notification that bug #1821758 expired. I'd rather not ignore > this, because I can see that there are likely to be two issues here: > > - Context code not setting up the floating point environment correctly on > POWER > - Some floating point operation running into an exception (which itself > shouldn't happen, and usually means that some value is now NaN). > > I wonder if it would make sense to enable floating point exceptions in > Debug builds so we at least stumble over these bugs occasionally. > > I'd turn the original bug into a "check FPE on POWER" minor bug then. > > Simon > > ___ > 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] Floating Point Exceptions
Hi, I just got a notification that bug #1821758 expired. I'd rather not ignore this, because I can see that there are likely to be two issues here: - Context code not setting up the floating point environment correctly on POWER - Some floating point operation running into an exception (which itself shouldn't happen, and usually means that some value is now NaN). I wonder if it would make sense to enable floating point exceptions in Debug builds so we at least stumble over these bugs occasionally. I'd turn the original bug into a "check FPE on POWER" minor bug then. Simon ___ 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] Why is the schematic view boundary set as small as it is?
Le 26/05/2019 à 17:36, Jon Evans a écrit : > Hi all, > > This question is particularly for JP since you have written the relevant > code. > > Why is SCH_VIEW initialized to such a small size compared to the area > that is accessible if you zoom out? > > You can see in my screenshot that the view boundary is initialized to > the pink rectangle, but it is quite easy to zoom out way past that > boundary and move components there. But because of the boundary being > checked in some places (like zoom to selection), it causes various > problems such as the bug report in [1] > > If we really want to set such a small view boundary, we should prevent > moving objects outside of it, and restrict the minimum zoom level to > something more reasonable. In my opinion, though, we should have some > middle ground -- the current view boundary is too small for some use > cases. It can be useful to drag the entire sheet contents off-sheet > for some workflows, so I think the view boundary should be at least the > size of a 3x3 grid of worksheets, if not larger than that. > > Any thoughts on this? > > Screenshot from 2019-05-26 11-30-44.png > > [1] https://bugs.launchpad.net/kicad/+bug/1822442 > > Thanks, > -Jon We have to limit the view boundary to make Scrollbars more easy to use, especially for "small" page sizes like A or B. A boundary size of a 3x3 grid of worksheets is possible, at least for "small" pages (I am not sure Scrollbars are still usable if the boundary size in 6 x 9 meters (max size of a page in eeschema: 2x3m) ). (this is what is in SCH_VIEW::ResizeSheetWorkingArea() comments but not in code). And obviously the zoom level (and moving objects) need to be limited to respect this boundary size. -- 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
