Would not "automatic file version switching" result into even stranger
situations? i.e. that users of "newer" kicad version would generate
files which are sometimes compatible and sometimes not without "obvious"
reason? What normally is done is offering users to save as an older
fileversion.
t editors do
when you replace in multiple files -- they warn the user that the
change cannot be undone, and sometimes leave the files/sheets in an
"unsaved" state so there is actually a way to undo it for certain
files (i.e. by closing them without saving)
-Jon
On Tue, Apr 18, 2017 at 7:46 AM
s actually a way to undo it for certain files (i.e. by
closing them without saving)
This is perfectly valid solution as well which I find acceptable. We
already do this with annotation.
-Jon
On Tue, Apr 18, 2017 at 7:46 AM, Nox <noxfiregal...@gmail.com
<mailto:noxfiregal...@gmail.com>
to maintain? Or should global operations
simply always "break" the local undo/redo stacks (so our "state of the
art"-handling)?
P.S: should we branch the discussion here maybe?
Am 18.04.2017 um 09:12 schrieb jp charras:
Le 17/04/2017 à 22:51, Nox a écrit :
I know that I
I know that I already suggested that in another context but what about
changing the undo/redo semantic to the more common approach to maintain
an global undo/redo stack and switch the view accordingly? I know that
the "per screen" is the established way in kicad and that it is very
dangerous
Really good to know. Maybe these results should be noted down somewhere
(code or guidelines?) so this information is not lost over time.
Am 19.02.2017 um 10:27 schrieb John Beard:
On Sat, Feb 18, 2017 at 1:08 AM, Nox <noxfiregal...@gmail.com> wrote:
What about wxFFileInputStream i
What about wxFFileInputStream instead of wxFileInputStream?
Am 17.02.2017 um 16:24 schrieb Wayne Stambaugh:
On 2/16/2017 8:59 PM, John Beard wrote:
Hi Wayne,
I added some new profiles for the INPUTSTREAM_LINE_READER.
The results are very surprising to me. In debug and release mode,
using
yed would not break any designs. Not in
its current implementation. But some support for stacked pins would be
needed before that.
- Kristoffer
On 2017-02-07 20:15, Chris Pavlina wrote:
On Tue, Feb 07, 2017 at 01:57:53PM -0500, Wayne Stambaugh wrote:
On 2/7/2017 1:15 PM, Andy Peters wrote:
From a user point of perspective I would claim that the issue only
raises because there is the possibility to make pins invisible. Maybe
someone can explain to me the semantically need of invisible pins in
general (beside the fact that kicad needs it to solve n pads: 1 pin and
global label
Some other program simply uses multiple autosaves. Although this is not
the smartest solution it is relative effective and allow for some
retracing the steps as well.
Am 24.01.2017 um 00:26 schrieb Chris Pavlina:
I'm talking to someone on IRC right now who lost two hours of routing
because
What about a general warning in the python console that the python
interface is experimental and highly volatile + a "version" check? So
that a script has to provide a version string and if this version string
does not match to kicad version the script execution will be stopped -
just to avoid
Hi,
Well maybe I am naive (again) but as an user I would expect that
undo/redo "follows" my actions i.e. switches between sheets as well. Of
course I see the advantages of seperate undo/redo stacks for every
single sheet but I am not really convinced that the advantages
outweights the
be
sure about my claims.
best regards,
Nox
Am 22.12.2016 um 09:20 schrieb Dino Ghilardi:
Il 20/12/2016 09:59, jp charras ha scritto:
Le 08/11/2016 à 01:29, Dino Ghilardi a écrit :
Hello everyone,
Thanks for the comments on this tool and the video.
...
Hi Dino,
Have you a more rece
Okay I respect that decision. I hoped to collect all the made statements
and sugguestion to wrap it up, to avoid further double doing and maybe
give a proposal for a common ground agreement but due to an accident I
am currently not really capable to work on it properly. I wanted to try
to
anged
(maybe adding a warning in the DRC what floating elements exists)? What
would be your concern regarding this approach?
Am 10.10.2016 um 17:36 schrieb Wayne Stambaugh:
On 10/10/2016 1:25 AM, Strontium wrote:
On 09/10/16 23:11, Wayne Stambaugh wrote:
On 10/8/2016 1:20 PM, Nox wrote:
e some issues which are around and all are aware of
it since years. I think a tool which is developed under the permise of
being open and from users for users might deligate some more decision
power during workflow to the end users and increase accessability on the
data.
best regards,
Nox
Am
as well if auto renaming needs to be a
mandatory step or if it could be a tool instead or if one could
implement a option to preserve names of not or ambiguous connected
elements during the auto renaming.
Regards,
Nox
Am 07.10.2016 um 19:14 schrieb Maciej Sumiński:
Hi Nox,
Tracks & vias ob
Hello,
what do you guys think about enabling edit of net names for tracks
via the property dialog? Is it silly to allow that?
I thought about something like that: http://codepad.org/F2sGzw7u .
best regards
___
Mailing list:
Sorry for Gravedigging. Maybe some heretic (and mostlikely stupid)
questions but:
why is there even an automatic relabeling implement? Would not it be
much more convenient to have it as seperate tool instead of a mandatory
step (like the cleaning up)?
Further more it seems like
19 matches
Mail list logo
