In 5.1.6 schematics on macOS Catalina, which is what I’m using, and this may be
older …
When you choose “place wire to bus entry” (or the ‘z’ key) or “place bus to bus
entry” (or ‘/‘), you don’t see the entry until you click the mouse on the
schematic. And there’s no way to change the angle of
Hi,
FWIW, I've been running the tests with memory checking enabled on both
Linux and Windows (MSVC), and we have several leaks there already, some
from us, some from wxWidgets, some from Gtk, some from Python, and
apparently some from Boost.Test. I don't exactly trust DrMemory yet, it
seems to
No. The dialogs would all have to be beefed up to listen to changes in the
document and update their values, pointers, etc.
We do have some work in progress for an Inspector, which would be modeless and
show the selected items’ properties.
Cheers,
Jeff.
> On 29 May 2020, at 19:31, Andrea
Dialog modality has nothing to do with DIALOG_SHIM. It depends on how
you show the dialog. See the documentation for wxDialog.
I will warn you up front that modeless dialogs are not trivial to
implement. I will expect bidirectional data updating between objects in
the main frame window and the
Hi,
Is there any way to configure the file “dialogshim” in eeschema to be
modeless instead of modal?
Cheers,
Andrea
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe :
On 5/29/20 11:36 AM, Ian McInerney wrote:
Steve,
Thanks for the update to it, and it looks good, so I have set it to merge to
master when the CI build completes. I will then manually cherry-pick this to
the 5.1 branch.
Thanks Ian. I appreciate your help. I'm glad we don't need two merge
Steve,
Thanks for the update to it, and it looks good, so I have set it to merge
to master when the CI build completes. I will then manually cherry-pick
this to the 5.1 branch.
I do wonder if there is a better way for us to structure this search so
that we don't have to touch the file every time
I pushed a change to my KiCad code repo to add python 3.9 as a supported
version, because Fedora is actively rebuilding everything for python 3.9.
As this is my first contribution via gitlab, please let me know if I created
the merge request properly.
In particular, this should go into both
On 2020-05-29 10:24 a.m., Wayne Stambaugh wrote:
They also have all of the features planned for V6 which haven't been
implemented yet so they are actually ahead of the current file formats.
I don't know how motivated I am to rip out all of the new stuff and then
add it back in later.
Where the
I would prefer a single MR for each leak just in case we need to revert
something that gets broken. I'm fine with grouping related leaks in a
single MR. There is no need to file an issue report.
On 5/29/20 10:51 AM, Johannes Pfister wrote:
> At least one leak is not in this issues. I made a MR
> If the memory is allocated at startup and doesn't grow in size, I
> wouldn't be too worried about not freeing it at shutdown.
But removing them can help remove real leaks since the output of
valgrind / ASan will be shorter and therefore clearer.
Am Fr., 29. Mai 2020 um 14:33 Uhr schrieb Andrew
At least one leak is not in this issues. I made a MR for the one i
found https://gitlab.com/kicad/code/kicad/-/merge_requests/231
Question, when i see multiple ones but have only fixed one of them,
while the others will take a few days, should i make a MR for each one
of them or is it better to
There are quite a few leaks in the code at present, and every now and then
I go through and try to plug some of them (but I don't find all of them,
that is for sure). My suggestion is that you can either propose a patch in
a merge request if you think you know where the memory should be freed and
If the memory is allocated at startup and doesn't grow in size, I
wouldn't be too worried about not freeing it at shutdown.
True leaks (growing in size over time) are a major problem. I routinely
leave kicad instances open for weeks or months while working on large
projects.
On 5/29/20 7:22 AM,
We should not be leaking memory in either case and we should care about it.
Which plot window are you are you talking about?
On 5/29/20 10:22 AM, Johannes Pfister wrote:
> As an example, if opening and closing the plot window would leak 3 kB
> each time, would we care about that? And is it
This will happen at some point but I still haven't decided where I want
to put the file format documentation. The current documents are in
google docs so they have to be converted to markdown or asciidoc
depending on where they get saved. They also have all of the features
planned for V6 which
As an example, if opening and closing the plot window would leak 3 kB
each time, would we care about that? And is it justified to increase
code complexity to avoid this leak?
If yes, what about "leaks" that alloc memory only once, use the same
memory till the application is closed and don't free
Might I suggest the file format being documented into the repo first?
That way any new additions to the format should involve adding to said
documentation.
On Fri, May 29, 2020 at 9:12 AM Wayne Stambaugh
wrote:
> As soon as the rebase and CI pipeline completes, the merge request to
> disable
As soon as the rebase and CI pipeline completes, the merge request to
disable writing legacy schematic and symbol library file formats[1] will
get merged into master. For those of you still using master to maintain
legacy symbol libraries, you will have to keep an older version of
master or 5.1
19 matches
Mail list logo
