Hi,
I've attached a patch to make the footprint preview and selection
functionality in eeschema optional, to address primarily performance
concerns some users have, and also to address the handful of planned
features still unimplemented. It's a runtime option, default OFF, so
users can easily enab
I think the wiki page Carsten made on https://wiki.debian.org/KiCad/ngspice
is a good overview of that.
2018-01-02 23:43 GMT+01:00 Carsten Schoenert :
> Hello Tomasz,
>
> Am 02.01.2018 um 23:20 schrieb Tomasz Wlostowski:
> > Forgive my ignorance, but what's the problem with ngspice's license that
Hello Tomasz,
Am 02.01.2018 um 23:20 schrieb Tomasz Wlostowski:
> Forgive my ignorance, but what's the problem with ngspice's license that
> makes it non-free?
the license situation for ngspice 27 is much better than before but
there are still files or folders licensed by a non free-license from
On 02/01/18 16:12, Carsten Schoenert wrote:
> the recently uploaded new version of ngspice into Debian unstable is
> still non-free. By this I can't use it for building KiCad in Debian main.
Carsten,
Forgive my ignorance, but what's the problem with ngspice's license that
makes it non-free?
Rega
Carsten,
I think you can also do this using environment variable NGSPICE_ROOT_DIR,
which the findngspice.cmake also looks in.
Thanks,
Dan W
On Tuesday, 2 January 2018 20:42:11 GMT Carsten Schoenert wrote:
> Hi Wayne,
>
> Am 02.01.2018 um 16:50 schrieb Wayne Stambaugh:
> > Thank you for the up
Hi Jeff
I was just working on this bug. I was able to fix it by checking if all
the selection possibilities in the disambiguation menu had the same net
in SELECTION_TOOL::guessSelectionCandidates( ... ) , and not displaying
the menu if they where all the same net.
This works but sort of breaks th
Hi Wayne,
Am 02.01.2018 um 16:50 schrieb Wayne Stambaugh:
> Thank you for the update. I did not realize all of this was going on in
> order to get a new ngspice package into Debian. I appreciate your
> efforts. I will try to build this package, install it on my system, and
> build and test kic
That's good, I just worry that if people need to read the manual for
something as mundane as importing old projects, it might not be ready
for release yet. I don't mean to whine at you over this, I understand
that this is a complicated thing to get right and there are a lot of
corner cases and weir
I plan on adding the remapping feature to the Eeschema documentation
before the stable 5 release. Hopefully I can find the time to knock it
out it the next week or two to give our translators plenty of time.
On 1/2/2018 2:59 PM, Chris Pavlina wrote:
> Of course. My confusion mostly surrounds how
Of course. My confusion mostly surrounds how it interacts with rescue
and when it does and does not decide to write things to disk (see José's
point about it clobbering its own backups).
In any case, I don't need you to explain it to me. You and I aren't the
only KiCad users, and if people who've
Hi,
Just want to get a word in on this before anyone pulls an RC - due to a
large number of user complaints about behavior of the footprint
selector/preview in the symbol chooser and a number of unimplemented
features, I intend to put it behind a default-off runtime option for V5.
I don't have tim
Let's start at the beginning. Are you clear on why symbols need to be
remapped?
On 1/2/2018 2:52 PM, Chris Pavlina wrote:
> Honestly, with this symbol library stuff it's been hard for me to figure
> out what's a bug and what's a confusing design decision. Bug reports for
> the latter are rather f
Honestly, with this symbol library stuff it's been hard for me to figure
out what's a bug and what's a confusing design decision. Bug reports for
the latter are rather frowned upon so I've been refraining from filing
many bugs.
On Tue, Jan 02, 2018 at 02:51:14PM -0500, Wayne Stambaugh wrote:
> I j
I just tested this repo and it failed to remap every symbol so either
something has been broken or this project is a corner case that I
haven't stumbled across yet. I will keep informed of my progress. In
the future, please file bug report when you see something like this. If
you just discuss it
Maybe one quick and helpful change would be to make
DIALOG_SYMBOL_REMAP::backupProject() add a timestamp or other unique ID to
the backup file name, so it won't clobber old backups if run multiple times
due to "non-standard" workflows?
On Tue, Jan 2, 2018 at 2:42 PM, José Ignacio wrote:
> This s
This sequence of actions is what puts the project on a stuffed up state:
* Open schematic and be greeted with some symbols that need rescue, rescue
a couple symbols
* Be greeted by the remap dialog (1)
* Regret remapping and quit without save
* Open schematic again
* Be greeted by the rescue dialo
On Tue, Jan 02, 2018 at 02:20:10PM -0500, Wayne Stambaugh wrote:
> It's exactly as insane as the cache has always been.
I respectfully disagree. As I recall from many years of using KiCad
before this, nothing about the cache has ever spontaneously deleted all
libraries without warning. That's a wh
I stand corrected. ‘G’ in the middle of a segment does not work: it moves the
closer segment end to the current position and drags the intersection from
there.
> On 2 Jan 2018, at 17:42, Jeff Young wrote:
>
> Since segments in OpenGL can be selected, the semantics are a bit different.
> Sel
It's exactly as insane as the cache has always been. The only way I can
think of this happening is that the schematic was not saved after the
remapping and once all of the libraries are removed from the project
file but cache should still be valid if no save was performed. Let me
try remapping th
This is doubly compounded if the project has symbols with (newly) illegal
names. The cache gets symbols with the original names but the code cant
find them anymore, even though the remapper can find it in the library with
the slashes, so you have to manually edit the library before opening, or
oper
I have a slight feeling it should be doing the remap _before_ rescue
instead of after, but I'm at work now so I can't really poke around at
it.
It's stuffing everything up in multiple ways, depending on exactly what
I tell it to do and I'm still not sure what I'm doing wrong. In one
case, it rescu
Ah, that explains my question mark case. That's insane.
On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
> One big problem is that even if everything fails, the project will show up
> fine with all symbols, but they wont have the remap done. at the same time
> the remapper deletes all
One big problem is that even if everything fails, the project will show up
fine with all symbols, but they wont have the remap done. at the same time
the remapper deletes all library entries from the project file, which
causes it to open with question marks only if you reopen it again after
saving.
You're going to have to give me a bit more than "stuffing everything
up". Are the symbols being incorrectly remapped? Even if the symbol
library table is empty, the recovery should still be correct as long as
the cache library is valid. If as you suggest it's so opaque that users
cannot understa
Are we really going to do an RC now without any more work to the remap
stuff? I just had it ruin another project last night. It behaves very
poorly when things also have to be rescued or libraries are missing, it
seems.
On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
> On 1/2/2018
Please send me a sample project if possible. I have tested this every
which way I can think of and it works fine for everything I throw at it.
The only time things fall apart are when the cache is corrupted or
missing and/or rescues have be ignored. In those cases there is nothing
I can do becau
Keep in mind my problem is not necessarily that things are _broken_ but
perhaps that they are so opaque that they only make sense in the mind of
the designer. As I said in the previous message, we've been getting TONS
of people on IRC who can't figure out how the hell to drive this thing,
and I cou
We're currently close to inundated on IRC with people using nightlies
wondering what to do because their projects don't load properly. If it's
not _broken_ it's definitely so unintuitive that most people seem unable
to figure it out. Myself included, it took me way too long to figure out
how to loa
Since segments in OpenGL can be selected, the semantics are a bit different.
Select a segment and a ‘G’ near its end gives you get drag-intersection
behaviour while a ‘G’ in its middle gives you drag-segment.
‘M’ works in both cases as well: ‘M’ near an end gives you move-endpoint; ‘M’
in the
On Tue, Jan 2, 2018 at 11:18 AM, André S.
wrote:
> Hi everyone,
>
> I want to add from a users view:
> In the current KiCad 4.0.7 (Windows 64 bit) you can't drag traces in
> OpenGL/Cairo, only in legacy. (With this I mean: move a segment of a trace
> and it stays attached to the other segments of
Hi everyone,
I want to add from a users view:
In the current KiCad 4.0.7 (Windows 64 bit) you can't drag traces in
OpenGL/Cairo, only in legacy. (With this I mean: move a segment of a
trace and it stays attached to the other segments of the trace (Hotkey:
'G')).
Hotkey 'M' moves segments in Op
Hey Carsten,
On 1/2/2018 10:12 AM, Carsten Schoenert wrote:
> Hello Wayne,
>
> Am 02.01.2018 um 15:33 schrieb Wayne Stambaugh:
>> Would one of our Debian developers please prod the Debian ngspice
>> package[1] maintainer(s) to enable building ngspice with a shared
>> library and a -dev package.
Hello Wayne,
Am 02.01.2018 um 15:33 schrieb Wayne Stambaugh:
> Would one of our Debian developers please prod the Debian ngspice
> package[1] maintainer(s) to enable building ngspice with a shared
> library and a -dev package. A bug report[2] for this was filed almost a
> 1 1/2 years ago (aug 201
Who are the Mac developers with committer status? Can one of them get this
wxWidgets branch setup?
(I can help with testing, but I think someone will probably barf if I upload a
patch containing the whole source tree. ;)
Cheers,
Jeff.
> On 1 Jan 2018, at 02:03, Simon Wells wrote:
>
> ah fou
Would one of our Debian developers please prod the Debian ngspice
package[1] maintainer(s) to enable building ngspice with a shared
library and a -dev package. A bug report[2] for this was filed almost a
1 1/2 years ago (aug 2016) and it still has not be resolved. Carsten
was kind enough to even
On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> On 28/12/17 20:24, Wayne Stambaugh wrote:
>> There are a few outstanding crash bugs that need to be fixed before we
>> can consider branching the stable 5 release. Here is the list of
>> unresolved crash bugs that effect the development branch:
>>
>>
On 28/12/17 20:24, Wayne Stambaugh wrote:
> There are a few outstanding crash bugs that need to be fixed before we
> can consider branching the stable 5 release. Here is the list of
> unresolved crash bugs that effect the development branch:
>
> https://bugs.launchpad.net/kicad/+bug/1562788
> htt
There’s a bug report[1] which complains that every time you attempt to drag a
track corner it asks you which track (when of course they share the same
corner).
The SELECTION_TOOL shouldn’t know about this kind of stuff, though, so I
propose to add a client filter to SELECTION_TOOL::RequestSelec
38 matches
Mail list logo