Because this case has not been properly reported and doesn’t affect the experience users who write the software.
Step 1) Make a bug report with all information contained in the report. Include example board, version information and screenshot or video attached in the bug report.
Step 2) Get your bug fixed.
Skipping step (1) means that you never get to step (2)
eh maybe once they abandon Launchpad
This is not meant as a defence of the router but as a tip for you to be able to work more efficient with the current tools available:
In your particular case i think you did not leave enough degrees of freedom for the router to make something nice out of the situation (coarse grid plus fixing a point this close to the pad)
Try to have a similar situation but do not click this close to the pad. I suspect the result will look better.
It also sometimes helps to start the trace from the other direction. And the crtl key is also quite useful (allows more control as it deactivates the snapping to the pad center.)
Any particular reason for this?
I don’t really want an Ubuntu One account
Thanks. I have noticed result are often different going the other direction. My grid is already 50 micron so I don’t think that’s the issue. I didn’t know about CTRL though, will give that a try.
GitHub or GitLab is much more diffused and easier to open an issue and report it…
And this goes further if you want to make a PR
Yep, people underestimate how much a bad design can hold back a product and prevent new users from using it. Launchpad is functional, I’ll give it that, but on a scale of 1 to 10 of how bad the UI is I would put it at “repulsive”.
People who use it for awhile and got used to it just don’t notice it.
Can’t wait for the switch to gitlab.
I am not so sure github is easier to use when it comes to reporting issues (or bugs). The search features of launchpad for example are much easier to use (it is easier to search for existing reports on launchpad than on github.)
Entering the information of an issue is not really different either. Both systems simply have a text field where you enter your stuff. Main difference is that github allows for inline images while launchpad requires them to be attached separately. But here again i like the launchpad feature of it trying to find similar reports to avoid getting too many duplicates.
My limited experience with gitlab indicates that it is very similar in feature set to github so i think the same applies there as well.
But yes the pull request workflow is definitely superior to the patch workflow. It is not only simpler to use for contributors but also has the massive benefit that the discussion of an addition is easily linked to the source code changes (instead of being hidden somewhere in the mailing list discussions if a change is even discussed at all).
This really shouldn’t be up for debate. Simply look at how github has exploded the popularity and number of contributors to OSS. Github is practically synonymous with open source at this point.
I fully agree with regards to contributions of assets. I am however uncertain with regards to bug report handling.
Github issues are so easy to use they’re basically a form of social media, and they are widely used even by non-technical users.
You might be able to make an argument that they encourage too much participation, but I would wager any sum that kicad bug reporting would explode if it moved to github.
It would be better to talk about gitlab, because that’s where KiCad is going.
a person can dream. but gitlab does have PRs, issues, and OAuth login, so it should be a big improvement.
lol apparently gitlab gained more projects when microsoft bought github than launchpad has in total…
and github still has 2500 times as many repos as launchpad
Yet we have to remember that github (and gitlab) encourages easy and quick “create and abandon” workflow. Most projects are inactive or just some testing or playground or fork, not really active projects.
Dragging this thread back on topic, I have noticed track dragging behaviour is much better in 5.1.5 rc1 than it was in 5.1.4.
I used to find it very fiddly to drag a track reasonably centrally between pins of a SOT-23 to maximize clearances
There have been several bug fixes to do with track connectivity and how the software handles the actual pad shape
This is very understated in my opinion.
My designs have required both imperial and metric parts; as well as what grid (in/mm) the part was created with, and the grid (in/mm) the layout is currently in.
KiCad recent nightlies have been amazingly much better at handling these issues regarding the routing.
Can only second that. Master gets better by the day!
I discovered that changing the interactive router mode to “highlight collisions” brings back the normal behaviour. However, I’ll have to test it more to be sure.
I’ve also discovered this article that explains the interactive router: https://techexplorations.com/blog_kicad-interactive-routing/
This depends on what you mean by “normal behavior”. In v4 the default canvas was what is now called the legacy toolset. It did not come with the interactive router and therefore required micromanaging every trace. The interactive router was available in v4 by use of the cairo or open-gl canvases.
I would argue that the interactive router is worth learning as it will significantly improve ones productivity. (I typically lay down traces with two clicks. No mater if they are short or over the full board. I let kicad find the best way and only use additional tools like the dragging of sections if the path found was not to my satisfaction. It however required a bit of learning to get good results from the interactive router modes. See my post above.)
Of course there will always be specific cases where one goes back to highlight collision and micro manage a very important trace. But for the most part even important traces are done faster with the full walk around or shove modes plus a bit of dragging.