Re: [Kicad-developers] DRC Dialog Improvements

[Oliver Walters]

I can update the text alignment of that field. I agree that it looks a bit
weird.

Anyone else have any thoughts?

On Thu, Dec 1, 2016 at 1:24 AM, Clemens Koller  wrote:

> Looks good!
>
> Just a few comments:
>
> I'd prefer to have the text "Specific via diameters and track width, ...
> track segments." wrap on dialog
> width and left aligned.
>
> The grey table header background color extend right of the tables. Looks
> odd.
>
> The Vias might need an additional assigned Layer-pair to be able to check
> that i.e. 100um uVias don't
> get drilled through all layers.
>
> Regards,
>
> Clemens
>
>
> On 2016-11-30 10:09, Oliver Walters wrote:
> > Ah, here's the actual screenshot: http://i.imgur.com/UQl0ziD.png
> >
> > On Wed, Nov 30, 2016 at 8:03 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com >
> wrote:
> >
> > Hi All,
> >
> > This is a small patch that adds floating point validation to the VIA
> and TRACK options in the Global Design Rules tab on the DRC dialog in
> pcbnew.
> >
> > The validators also prevent negative values from being entered.
> >
> > I have also swapped the radio buttons for checkboxes, and performed
> some slight rearranging. Toggling the "Allow Micro Vias" box changes the
> enable status of the micro via controls.
> >
> > Here is a screenshot:
> > blob:http://imgur.com/62c32a26-c6f7-46bd-b437-2ad99fabf579 <
> http://imgur.com/62c32a26-c6f7-46bd-b437-2ad99fabf579>
> >
> > Patch is attached.
> >
> > Cheers,
> > Oliver
> >
> >
> >
> >
> > ___
> > 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] configuration files for KiCad

[Jon Evans]

Thanks Wayne.  I will look in to wxConfig paths and see if I can see any
compelling disadvantages to bring up vs. JSON (note that JSON could be
handled by Boost.PropertyTree so no additional dependency).  If I can see a
clear way to achieve the things I want to propose using wxConfig, I'm fine
with that, no need to change for change's sake.

-Jon

On Thu, Dec 1, 2016 at 3:24 PM, Wayne Stambaugh 
wrote:

> On 12/1/2016 11:44 AM, Jon Evans wrote:
> > Hi all,
> >
> > Per my recent email, I'm going to be looking in to various UI/UX things,
> > starting with Eeschema, and I thought of a topic that probably warrants
> > its own thread.
> >
> > Some of the things I want to propose would involve giving the user more
> > options for customization of the tool (i.e. more preferences, color
> > themes, etc).
> >
> > Right now, it seems like all KiCad configuration data is stored in a
> > INI-style key-value file per binary (one for eeschema, one for pcbnew,
> > etc) in the user's application data folder.
> >
> > What do the core developers think about the possibility of
> > changing/expanding the way KiCad uses files for configuration?
> >
> > Some examples I thought of:
> >
> > - Switching to a format like YAML or JSON that allows nesting of
> > configuration parameters, for more clean configuration
>
> I'm not thrilled about using YAML or JSON.  It would add another build
> dependency and I can't think of any config settings in kicad that need
> this kind of nested file complexity.  That being said, we certainly
> could clean up our current config files.  I've never been a big fan of
> prefixing the window frame name to the key (SchematicFramePos_y,
> LibeditFrameShowGrid, ViewlibFrameSize_y, etc) in on one huge section.
> I would like to see the config settings take advantage of the wxConfig
> paths so the config files would look something like:
>
> [Schematic/Frame]
> X=0
> Y=0
> Width=600
> Height=400
> [LibViewer/Frame]
> X=200
> Y=100
> Width=400
> Height=200
>
> This would certainly be a lot cleaner (more readable) than what we are
> currently doing.
>
> See http://docs.wxwidgets.org/3.0/classwx_config_base.html for examples
> using wxConfig paths.
>
> >
> > - A "configuration hierarchy" system, meaning that there are "system
> > defaults" for all values stored in a file somewhere, and when the user
> > starts changing them, they are creating a new file in their home
> > directory that "overrides" whatever settings they have changed, rather
> > than updating the system config.  This would allow the default config to
> > be preserved if multiple users on one PC want to have different local
> > settings.  It would also make it easier for people to send config to
> > each other, and to back up their config by checking it in to a Git
> > repository for example.  Sublime Text is one example of a program that
> > does this, and it works really well in my opinion.
>
> I'm OK with this.  Most of the default config settings are hard coded
> since there is no config on startup so you may have a lot of work to do
> in this regard.
>
> >
> > - Splitting out certain configuration items into distinct files, rather
> > than using a single file for all config of a certain program.  Color
> > themes are one area where this is often done in other programs, so that
> > people can download/share new color themes without having to copy/paste
> > certain areas of a global config file.
>
> I'm OK with this too.  You could split out the viewer and editor frame
> settings into separate config files so they are more manageable.
>
> >
> > So, any opinions on this?  Just knowing something like "never gonna
> > happen" versus "sounds interesting, send more details" is good feedback
> > for me at this point, that way I can know up front what kind of changes
> > are likely to be accepted when I come up with more detailed proposals.
> >
> > Best,
> > Jon
> >
> >
> > ___
> > 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] configuration files for KiCad

[Wayne Stambaugh]

On 12/1/2016 11:44 AM, Jon Evans wrote:
> Hi all,
> 
> Per my recent email, I'm going to be looking in to various UI/UX things,
> starting with Eeschema, and I thought of a topic that probably warrants
> its own thread.
> 
> Some of the things I want to propose would involve giving the user more
> options for customization of the tool (i.e. more preferences, color
> themes, etc).
> 
> Right now, it seems like all KiCad configuration data is stored in a
> INI-style key-value file per binary (one for eeschema, one for pcbnew,
> etc) in the user's application data folder.
> 
> What do the core developers think about the possibility of
> changing/expanding the way KiCad uses files for configuration?
> 
> Some examples I thought of:
> 
> - Switching to a format like YAML or JSON that allows nesting of
> configuration parameters, for more clean configuration

I'm not thrilled about using YAML or JSON.  It would add another build
dependency and I can't think of any config settings in kicad that need
this kind of nested file complexity.  That being said, we certainly
could clean up our current config files.  I've never been a big fan of
prefixing the window frame name to the key (SchematicFramePos_y,
LibeditFrameShowGrid, ViewlibFrameSize_y, etc) in on one huge section.
I would like to see the config settings take advantage of the wxConfig
paths so the config files would look something like:

[Schematic/Frame]
X=0
Y=0
Width=600
Height=400
[LibViewer/Frame]
X=200
Y=100
Width=400
Height=200

This would certainly be a lot cleaner (more readable) than what we are
currently doing.

See http://docs.wxwidgets.org/3.0/classwx_config_base.html for examples
using wxConfig paths.

> 
> - A "configuration hierarchy" system, meaning that there are "system
> defaults" for all values stored in a file somewhere, and when the user
> starts changing them, they are creating a new file in their home
> directory that "overrides" whatever settings they have changed, rather
> than updating the system config.  This would allow the default config to
> be preserved if multiple users on one PC want to have different local
> settings.  It would also make it easier for people to send config to
> each other, and to back up their config by checking it in to a Git
> repository for example.  Sublime Text is one example of a program that
> does this, and it works really well in my opinion.

I'm OK with this.  Most of the default config settings are hard coded
since there is no config on startup so you may have a lot of work to do
in this regard.

> 
> - Splitting out certain configuration items into distinct files, rather
> than using a single file for all config of a certain program.  Color
> themes are one area where this is often done in other programs, so that
> people can download/share new color themes without having to copy/paste
> certain areas of a global config file.

I'm OK with this too.  You could split out the viewer and editor frame
settings into separate config files so they are more manageable.

> 
> So, any opinions on this?  Just knowing something like "never gonna
> happen" versus "sounds interesting, send more details" is good feedback
> for me at this point, that way I can know up front what kind of changes
> are likely to be accepted when I come up with more detailed proposals.
> 
> Best,
> Jon
> 
> 
> ___
> 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] eeschema status and features safe to work on

[Wayne Stambaugh]

Hi Jon,

Anything that requires access to the schematic objects is going to get
changed so if you don't mind the disruptions to your work then feel work
on things like your autorouter.  If you don't need access to the
schematic objects such as your color selection, then I would think the
probability of conflicts would be low.  Keep in mind during the next
development cycle (version 6), any new tools will have to be ported to
the new toolkit.

Cheers,

Wayne

On 12/1/2016 10:38 AM, Jon Evans wrote:
> Hi Orson,
> 
> Thanks much for your feedback and news about plans for eeschema.
> I agree that having a common codebase for selection filtering and object
> inspection across the tools is a great idea (especially since the
> roadmap has plans for eventually combining the tools more than they are
> today).
> 
> By "intelligent autorouter" in schematic editor, I meant that some of
> the high-end commercial tools have nicer ways to input wires and buses
> that act somewhat like an autorouter would for a PCB, meaning there are
> certain rules that can be set about how wires/buses should look (i.e.
> must be H/V, must not overlap existing wires, etc), and if you are
> drawing new wires in "auto" mode, you can simply pick two points to wire
> between (i.e. two pins, or a pin and existing wire, etc) and the program
> will draw a wire between them that meets the rules if possible.
> 
> Of course this requires some tuning and tweaking to be user-friendly,
> because the constraints are different -- a PCB autorouter can fail and
> tell the user it isn't possible to route a net.  The schematic wire
> "autorouter" must always place a trace, and the "autorouting" is about
> making it visually the "best" looking.
> 
> I have some more concrete examples in my head, and I think I will try to
> put together some examples to show more about what I mean and how my
> proposal would work in eeschema.  But basically, I think we can get a
> lot closer to the designer saying "I want to connect X to Y" and having
> to spend minimal mental energy on picking each corner of the wire, much
> like the P router is designed to reduce mental energy of routing the PCB.
> 
> Best,
> Jon
> 
> On Thu, Dec 1, 2016 at 10:28 AM, Maciej Sumiński
> > wrote:
> 
> Hi Jon,
> 
> We really appreciate your offer. I am quite positive that most of people
> here would admit that KiCad begs for some UX improvements.
> 
> GALifying eeschema is going to be a significant refactor, but it will
> not happen before v5 release, which is currently planned for Feb 2017.
> 
> IIRC Wayne works on the new file format. I have in my stash some changes
> to the symbol library editor (I hope to publish them soon for testing).
> The on-going work does not seem to collide with your proposal, unless
> there are other plans I am not aware about.
> 
> During a recent KiCad hackathon [1] Oswaldo has volunteered [2] to work
> on the Selection Filter for pcbnew. I wonder if it would be possible to
> write code generic enough to handle schematic & layout editors or at
> least have a common base. Combined with the Object Inspector, which is
> also supposed to work with eeschema at one point, it creates a really
> powerful toolset.
> 
> Would you elaborate on the "intelligent autorouter" idea?
> 
> Regards,
> Orson
> 
> 1. http://www.ohwr.org/projects/cern-kicad/wiki/Hackathon-ehal
> 
> 2. https://lists.launchpad.net/kicad-developers/msg26722.html
> 
> 
> On 12/01/2016 02:54 AM, Jon Evans wrote:
> > Hi all,
> >
> > I am an EE and sometimes software developer who has wanted to
> contribute to
> > KiCad for a while and finally might have some time to do things. 
> I am kind
> > of excited about UI/UX improvement possibilities, and have been
> compiling a
> > list of things that I might want to work on at some point or at
> least just
> > poke at to get familiar with the codebase.
> >
> > I know a big refactor of eeschema is planned/in progress.  Can the
> people
> > working on that please advise whether it makes sense for me to
> work on any
> > of the things in the following list, or if it would be likely to
> be wasted
> > effort based on what will likely change in the refactor?
> >
> > - Improvements to wire / bus routing: several bugs here and also some
> > wishlist items (H/V restriction working in drag mode,
> > auto-connection/junction creation at points on a wire that aren't the
> > endpoints, "intelligent autorouter" for schematic wires, fix wires
> after
> > drag, etc)
> > - Selection filtering (select anything vs. only components, wires,
> text,
> > etc)
> > - Color system improvements -- 

Re: [Kicad-developers] configuration files for KiCad

[Jon Evans]

Hi JP,

You are correct, I'm talking about the "program configuration", not the
"project configuration" or "library configuration". I understand your
concern about adding more maintenance burden.  I think there are possible
solutions that would not be significantly more complicated than wxConfig
(and also be equally cross-platform) although it would definitely mean a
one-time rewrite.

I think I will put together a more detailed proposal including more clear
statements on what I think the benefits are as well as my analysis of the
costs, and will come back with that proposal.  I think the current config
system is quite limiting in terms of where KiCad could go in the future,
but perhaps it is easier to explain why I think that with some more
concrete examples that will take me some time to write up.

Best,
Jon

On Thu, Dec 1, 2016 at 1:46 PM, jp charras  wrote:

> Le 01/12/2016 à 17:44, Jon Evans a écrit :
> > Hi all,
> >
> > Per my recent email, I'm going to be looking in to various UI/UX things,
> starting with Eeschema, and
> > I thought of a topic that probably warrants its own thread.
> >
> > Some of the things I want to propose would involve giving the user more
> options for customization of
> > the tool (i.e. more preferences, color themes, etc).
> >
> > Right now, it seems like all KiCad configuration data is stored in a
> INI-style key-value file per
> > binary (one for eeschema, one for pcbnew, etc) in the user's application
> data folder.
> >
> > What do the core developers think about the possibility of
> changing/expanding the way KiCad uses
> > files for configuration?
> >
> > Some examples I thought of:
> >
> > - Switching to a format like YAML or JSON that allows nesting of
> configuration parameters, for more
> > clean configuration
>
> Library tables are not in INI-style key-value.
> Some config settings like plot options for boards, design rules... are
> stored inside the .kicad_pcb
> files.
>
> I am thinking you are talking about other config files containing current
> setting (colors, frame
> position and size, last opened files...)
>
> These config files are managed by wxWidgets, not by Kicad.
> Changing the file format means rewrite (therefore maintain) the wxConfig
> classes inside Kicad, and
> make them compatible between all OS.
>
> I am not sure this is a good idea (I mean: high cost, (very) low benefit).
>
>
> >
> > - A "configuration hierarchy" system, meaning that there are "system
> defaults" for all values stored
> > in a file somewhere, and when the user starts changing them, they are
> creating a new file in their
> > home directory that "overrides" whatever settings they have changed,
> rather than updating the system
> > config.  This would allow the default config to be preserved if multiple
> users on one PC want to
> > have different local settings.  It would also make it easier for people
> to send config to each
> > other, and to back up their config by checking it in to a Git repository
> for example.  Sublime Text
> > is one example of a program that does this, and it works really well in
> my opinion.
> >
> > - Splitting out certain configuration items into distinct files, rather
> than using a single file for
> > all config of a certain program.  Color themes are one area where this
> is often done in other
> > programs, so that people can download/share new color themes without
> having to copy/paste certain
> > areas of a global config file.
> >
> > So, any opinions on this?  Just knowing something like "never gonna
> happen" versus "sounds
> > interesting, send more details" is good feedback for me at this point,
> that way I can know up front
> > what kind of changes are likely to be accepted when I come up with more
> detailed proposals.
> >
> > Best,
> > Jon
> >
> >
> > ___
> > 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
> >
>
>
> --
> 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] configuration files for KiCad

[jp charras]

Le 01/12/2016 à 17:44, Jon Evans a écrit :
> Hi all,
> 
> Per my recent email, I'm going to be looking in to various UI/UX things, 
> starting with Eeschema, and
> I thought of a topic that probably warrants its own thread.
> 
> Some of the things I want to propose would involve giving the user more 
> options for customization of
> the tool (i.e. more preferences, color themes, etc).
> 
> Right now, it seems like all KiCad configuration data is stored in a 
> INI-style key-value file per
> binary (one for eeschema, one for pcbnew, etc) in the user's application data 
> folder.
> 
> What do the core developers think about the possibility of changing/expanding 
> the way KiCad uses
> files for configuration?
> 
> Some examples I thought of:
> 
> - Switching to a format like YAML or JSON that allows nesting of 
> configuration parameters, for more
> clean configuration

Library tables are not in INI-style key-value.
Some config settings like plot options for boards, design rules... are stored 
inside the .kicad_pcb
files.

I am thinking you are talking about other config files containing current 
setting (colors, frame
position and size, last opened files...)

These config files are managed by wxWidgets, not by Kicad.
Changing the file format means rewrite (therefore maintain) the wxConfig 
classes inside Kicad, and
make them compatible between all OS.

I am not sure this is a good idea (I mean: high cost, (very) low benefit).


> 
> - A "configuration hierarchy" system, meaning that there are "system 
> defaults" for all values stored
> in a file somewhere, and when the user starts changing them, they are 
> creating a new file in their
> home directory that "overrides" whatever settings they have changed, rather 
> than updating the system
> config.  This would allow the default config to be preserved if multiple 
> users on one PC want to
> have different local settings.  It would also make it easier for people to 
> send config to each
> other, and to back up their config by checking it in to a Git repository for 
> example.  Sublime Text
> is one example of a program that does this, and it works really well in my 
> opinion.
> 
> - Splitting out certain configuration items into distinct files, rather than 
> using a single file for
> all config of a certain program.  Color themes are one area where this is 
> often done in other
> programs, so that people can download/share new color themes without having 
> to copy/paste certain
> areas of a global config file.
> 
> So, any opinions on this?  Just knowing something like "never gonna happen" 
> versus "sounds
> interesting, send more details" is good feedback for me at this point, that 
> way I can know up front
> what kind of changes are likely to be accepted when I come up with more 
> detailed proposals.
> 
> Best,
> Jon
> 
> 
> ___
> 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
> 


-- 
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

Re: [Kicad-developers] configuration files for KiCad

[Tomasz Wlostowski]

On 01.12.2016 17:44, Jon Evans wrote:
> Hi all,
> 
> Per my recent email, I'm going to be looking in to various UI/UX things,
> starting with Eeschema, and I thought of a topic that probably warrants
> its own thread.
> 
> Some of the things I want to propose would involve giving the user more
> options for customization of the tool (i.e. more preferences, color
> themes, etc).
> 
> Right now, it seems like all KiCad configuration data is stored in a
> INI-style key-value file per binary (one for eeschema, one for pcbnew,
> etc) in the user's application data folder.
> 
> What do the core developers think about the possibility of
> changing/expanding the way KiCad uses files for configuration?
> 
> Some examples I thought of:
> 
> - Switching to a format like YAML or JSON that allows nesting of
> configuration parameters, for more clean configuration
> 
> - A "configuration hierarchy" system, meaning that there are "system
> defaults" for all values stored in a file somewhere, and when the user
> starts changing them, they are creating a new file in their home
> directory that "overrides" whatever settings they have changed, rather
> than updating the system config.  This would allow the default config to
> be preserved if multiple users on one PC want to have different local
> settings.  It would also make it easier for people to send config to
> each other, and to back up their config by checking it in to a Git
> repository for example.  Sublime Text is one example of a program that
> does this, and it works really well in my opinion.
> 
> - Splitting out certain configuration items into distinct files, rather
> than using a single file for all config of a certain program.  Color
> themes are one area where this is often done in other programs, so that
> people can download/share new color themes without having to copy/paste
> certain areas of a global config file.
> 
> So, any opinions on this?  Just knowing something like "never gonna
> happen" versus "sounds interesting, send more details" is good feedback
> for me at this point, that way I can know up front what kind of changes
> are likely to be accepted when I come up with more detailed proposals.

Hi John,

Don't have much time to answer, so I'll be short:
yes, yes, yes.

If you'll add an easy way of serializing/deserializing C++ configuration
classes (e.g. PNS_ROUTING_SETTINGS) to an appropriate section of a
config file, it would be even better ;-)

Cheers,
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

[Kicad-developers] configuration files for KiCad

[Jon Evans]

Hi all,

Per my recent email, I'm going to be looking in to various UI/UX things,
starting with Eeschema, and I thought of a topic that probably warrants its
own thread.

Some of the things I want to propose would involve giving the user more
options for customization of the tool (i.e. more preferences, color themes,
etc).

Right now, it seems like all KiCad configuration data is stored in a
INI-style key-value file per binary (one for eeschema, one for pcbnew, etc)
in the user's application data folder.

What do the core developers think about the possibility of
changing/expanding the way KiCad uses files for configuration?

Some examples I thought of:

- Switching to a format like YAML or JSON that allows nesting of
configuration parameters, for more clean configuration

- A "configuration hierarchy" system, meaning that there are "system
defaults" for all values stored in a file somewhere, and when the user
starts changing them, they are creating a new file in their home directory
that "overrides" whatever settings they have changed, rather than updating
the system config.  This would allow the default config to be preserved if
multiple users on one PC want to have different local settings.  It would
also make it easier for people to send config to each other, and to back up
their config by checking it in to a Git repository for example.  Sublime
Text is one example of a program that does this, and it works really well
in my opinion.

- Splitting out certain configuration items into distinct files, rather
than using a single file for all config of a certain program.  Color themes
are one area where this is often done in other programs, so that people can
download/share new color themes without having to copy/paste certain areas
of a global config file.

So, any opinions on this?  Just knowing something like "never gonna happen"
versus "sounds interesting, send more details" is good feedback for me at
this point, that way I can know up front what kind of changes are likely to
be accepted when I come up with more detailed proposals.

Best,
Jon
___
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] ransomware locky detected on version 4.0.4 and 4.0.3

[Nick Østergaard]

Paolo,

Does that firewall software of yours not provide any technical info about
this? Like filenames or byte sequences or similar?

Den 01/12/2016 16.41 skrev "Wayne Stambaugh" :

> Paolo,
>
> This might be a false positive.  We've seen this in the past.  Would one
> of our windows package devs please verify the windows installer binaries
> on the kicad download page are still valid?
>
> In the future, please post your questions to the developers mailing list.
>
> Cheers,
>
> Wayne
>
> On 12/1/2016 7:56 AM, Paolo Barbato wrote:
> > Dear devolopers,
> >
> > I’m in charge fro internet security at Consorzio RFX laboratpry.
> >
> > We’ve blocked, using ChcekPoint firewall, a download attempt of an
> >  internal user of kicad from your official link
> > http://kicad-pcb.org/download/windows/ .
> > Compromised version are 4.0.4 and 4.0.3  both 64 and 32 bits that seems
> > have exploited by locky ransomware.
> >
> >
> >
> > Please check, and let me know.
> >
> >
> >
> >
> > 
> 
> > Paolo Barbato
> >
> > Consorzio RFX
> > corso Stati Uniti,4
> >
> > 35127 Padova - Italy
> > Network Administrator
> > phone: +39 049 8295097 fax: +39 049 8700718
> > 
> 
> >
>
> ___
> 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] ransomware locky detected on version 4.0.4 and 4.0.3

[Wayne Stambaugh]

Paolo,

This might be a false positive.  We've seen this in the past.  Would one
of our windows package devs please verify the windows installer binaries
on the kicad download page are still valid?

In the future, please post your questions to the developers mailing list.

Cheers,

Wayne

On 12/1/2016 7:56 AM, Paolo Barbato wrote:
> Dear devolopers,
> 
> I’m in charge fro internet security at Consorzio RFX laboratpry.
> 
> We’ve blocked, using ChcekPoint firewall, a download attempt of an
>  internal user of kicad from your official link
> http://kicad-pcb.org/download/windows/ .
> Compromised version are 4.0.4 and 4.0.3  both 64 and 32 bits that seems
> have exploited by locky ransomware.
> 
> 
> 
> Please check, and let me know.
> 
> 
> 
> 
> 
> Paolo Barbato
> 
> Consorzio RFX
> corso Stati Uniti,4 
> 
> 35127 Padova - Italy  
> Network Administrator 
> phone: +39 049 8295097 fax: +39 049 8700718
> 
> 

___
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] eeschema status and features safe to work on

[Jon Evans]

Hi Orson,

Thanks much for your feedback and news about plans for eeschema.
I agree that having a common codebase for selection filtering and object
inspection across the tools is a great idea (especially since the roadmap
has plans for eventually combining the tools more than they are today).

By "intelligent autorouter" in schematic editor, I meant that some of the
high-end commercial tools have nicer ways to input wires and buses that act
somewhat like an autorouter would for a PCB, meaning there are certain
rules that can be set about how wires/buses should look (i.e. must be H/V,
must not overlap existing wires, etc), and if you are drawing new wires in
"auto" mode, you can simply pick two points to wire between (i.e. two pins,
or a pin and existing wire, etc) and the program will draw a wire between
them that meets the rules if possible.

Of course this requires some tuning and tweaking to be user-friendly,
because the constraints are different -- a PCB autorouter can fail and tell
the user it isn't possible to route a net.  The schematic wire "autorouter"
must always place a trace, and the "autorouting" is about making it
visually the "best" looking.

I have some more concrete examples in my head, and I think I will try to
put together some examples to show more about what I mean and how my
proposal would work in eeschema.  But basically, I think we can get a lot
closer to the designer saying "I want to connect X to Y" and having to
spend minimal mental energy on picking each corner of the wire, much like
the P router is designed to reduce mental energy of routing the PCB.

Best,
Jon

On Thu, Dec 1, 2016 at 10:28 AM, Maciej Sumiński 
wrote:

> Hi Jon,
>
> We really appreciate your offer. I am quite positive that most of people
> here would admit that KiCad begs for some UX improvements.
>
> GALifying eeschema is going to be a significant refactor, but it will
> not happen before v5 release, which is currently planned for Feb 2017.
>
> IIRC Wayne works on the new file format. I have in my stash some changes
> to the symbol library editor (I hope to publish them soon for testing).
> The on-going work does not seem to collide with your proposal, unless
> there are other plans I am not aware about.
>
> During a recent KiCad hackathon [1] Oswaldo has volunteered [2] to work
> on the Selection Filter for pcbnew. I wonder if it would be possible to
> write code generic enough to handle schematic & layout editors or at
> least have a common base. Combined with the Object Inspector, which is
> also supposed to work with eeschema at one point, it creates a really
> powerful toolset.
>
> Would you elaborate on the "intelligent autorouter" idea?
>
> Regards,
> Orson
>
> 1. http://www.ohwr.org/projects/cern-kicad/wiki/Hackathon-ehal
> 2. https://lists.launchpad.net/kicad-developers/msg26722.html
>
> On 12/01/2016 02:54 AM, Jon Evans wrote:
> > Hi all,
> >
> > I am an EE and sometimes software developer who has wanted to contribute
> to
> > KiCad for a while and finally might have some time to do things.  I am
> kind
> > of excited about UI/UX improvement possibilities, and have been
> compiling a
> > list of things that I might want to work on at some point or at least
> just
> > poke at to get familiar with the codebase.
> >
> > I know a big refactor of eeschema is planned/in progress.  Can the people
> > working on that please advise whether it makes sense for me to work on
> any
> > of the things in the following list, or if it would be likely to be
> wasted
> > effort based on what will likely change in the refactor?
> >
> > - Improvements to wire / bus routing: several bugs here and also some
> > wishlist items (H/V restriction working in drag mode,
> > auto-connection/junction creation at points on a wire that aren't the
> > endpoints, "intelligent autorouter" for schematic wires, fix wires after
> > drag, etc)
> > - Selection filtering (select anything vs. only components, wires, text,
> > etc)
> > - Color system improvements -- arbitrary color picker, color themes, etc.
> > - Drag selection mode option -- select anything touching vs. select
> things
> > completely enclosed by drag area
> >
> >
> > Thanks,
> > Jon
>
>
>
___
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] eeschema status and features safe to work on

[Maciej Sumiński]

Hi Jon,

We really appreciate your offer. I am quite positive that most of people
here would admit that KiCad begs for some UX improvements.

GALifying eeschema is going to be a significant refactor, but it will
not happen before v5 release, which is currently planned for Feb 2017.

IIRC Wayne works on the new file format. I have in my stash some changes
to the symbol library editor (I hope to publish them soon for testing).
The on-going work does not seem to collide with your proposal, unless
there are other plans I am not aware about.

During a recent KiCad hackathon [1] Oswaldo has volunteered [2] to work
on the Selection Filter for pcbnew. I wonder if it would be possible to
write code generic enough to handle schematic & layout editors or at
least have a common base. Combined with the Object Inspector, which is
also supposed to work with eeschema at one point, it creates a really
powerful toolset.

Would you elaborate on the "intelligent autorouter" idea?

Regards,
Orson

1. http://www.ohwr.org/projects/cern-kicad/wiki/Hackathon-ehal
2. https://lists.launchpad.net/kicad-developers/msg26722.html

On 12/01/2016 02:54 AM, Jon Evans wrote:
> Hi all,
> 
> I am an EE and sometimes software developer who has wanted to contribute to
> KiCad for a while and finally might have some time to do things.  I am kind
> of excited about UI/UX improvement possibilities, and have been compiling a
> list of things that I might want to work on at some point or at least just
> poke at to get familiar with the codebase.
> 
> I know a big refactor of eeschema is planned/in progress.  Can the people
> working on that please advise whether it makes sense for me to work on any
> of the things in the following list, or if it would be likely to be wasted
> effort based on what will likely change in the refactor?
> 
> - Improvements to wire / bus routing: several bugs here and also some
> wishlist items (H/V restriction working in drag mode,
> auto-connection/junction creation at points on a wire that aren't the
> endpoints, "intelligent autorouter" for schematic wires, fix wires after
> drag, etc)
> - Selection filtering (select anything vs. only components, wires, text,
> etc)
> - Color system improvements -- arbitrary color picker, color themes, etc.
> - Drag selection mode option -- select anything touching vs. select things
> completely enclosed by drag area
> 
> 
> Thanks,
> Jon




signature.asc
Description: OpenPGP digital signature
___
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