Re: [Kicad-developers] fp-info-cache question

[Andrey Kuznetsov]

In addition to the issues described earlier, I filed a bug in parallel
about kicad freezing after closing pcbnew where fpinfo-cache writing to
network locations would take 10s (not a network speed issue).
https://bugs.launchpad.net/kicad/+bug/1838209

Global cache should not be written everytime pcbnew is closed to project
folder.

Every time I open pcbnew from kicad main app, and then immediately close
pcbnew, I have to wait 10 secs for the main app to respond while it's
writing the fp-info-cache.

On Wed, Jul 24, 2019 at 11:20 AM Seth Hillbrand  wrote:

> On 2019-07-24 13:58, Andy Peters wrote:
> >> On Jul 23, 2019, at 2:46 PM, Jeff Young  wrote:
> >>
> >> Hi Kevin,
> >>
> >> No this is just a cache of footprint library properties so that we can
> >> index and search footprints without loading them all into memory.
> >> It’s entirely for performance.
> >
> > User question:
> >
> > Should the project-level cache file be included in the SCC
> > respository, or is it rebuilt as necessary?
>
> Currently the cache file holds both project and global libraries.  Thus
> it leaks your system setup information and should be in your .gitignore
> file for the project.  It is rebuilt when missing.
>
> -S
>
> ___
> 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
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] RFC: KiCad windows installer proposal

[Andrey Kuznetsov]

+1 for small nightlies, it's always a pain to wait 30mins to download a
nightly to test when you have the time, but by the time it's done
downloading, you don't have time anymore.

On Wed, Jul 24, 2019 at 6:47 AM Mark Roszko  wrote:

> >The long term plan is to build an MSI based installer, because that leaves
> MSI is an absolute actual disaster to maintain and when it implodes you
> have to whip out the registry editors and system clenaers to erase any
> vestigal traces of metadata it uses to be able to even correct a package.
>
> Even Microsoft has gone away from using MSI for software distribution that
> isn't part of Windows itself. Incidentally Inno Setup seems to be their
> choice.
>
> On Wed, Jul 24, 2019 at 5:41 AM Simon Richter 
> wrote:
>
>> Hi,
>>
>> On Wed, Jul 24, 2019 at 02:04:15AM -0700, Andrew Lutsenko wrote:
>>
>> > I agree, if my proposal won't be accepted as is then whatever changes I
>> > will make should be properly tested and won't be rushed for 5.1.3. But
>> if
>> > no changes will be required then all the hard work is done already. Just
>> > need to merge the PR, run the build and upload both executables.
>>
>> I'm largely in favour, because I don't see myself getting around to
>> replacing the entire installer with something sensible soon.
>>
>> The long term plan is to build an MSI based installer, because that leaves
>> the option of either embedding the cabinet files into the MSI or leaving
>> them external, and allows building binary patch installers that can
>> upgrade
>> existing installations in-place.
>>
>>Simon
>>
>> ___
>> 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
>>
>
>
> --
> Mark
> ___
> 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
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] 5.1.0 package builds

[Andrey Kuznetsov]

Just wanted to drop a note, 4PM PST California time the download speed for
v5.1.0 Windows 64bit from CERN for v5.1.0 is 1Mbit/s on a 50Mbit/s line.
Futureware is 10Mbit/s and github is about the same.

On Fri, Mar 15, 2019 at 6:36 PM Adam Wolf 
wrote:

> Definitely!  This past week my bank account got seriously hacked, our
> basement flooded, I got a surprise 4 figure medical bill, and our car has a
> recall that can't get fixed for a month, but I think I am over the bad luck
> now!
>
> On Fri, Mar 15, 2019, 6:29 PM Nick Østergaard  wrote:
>
>> Thank you. Some guy on IRC says that the new binary works.
>>
>> Thank your fornyour efforts, and I hope you are back in good mood again.
>>
>> fre. 15. mar. 2019 20.51 skrev Adam Wolf :
>>
>>> I reuploaded the files to the downloads server.
>>>
>>> On Fri, Mar 15, 2019, 1:49 PM Wayne Stambaugh 
>>> wrote:
>>>
 Thank you everyone for all of your hard work in getting 5.1 released.
 It never ceases to amaze me the tireless efforts that everyone puts in
 to make this happen.  Here is to more great releases in the future.

 Cheers,

 Wayne

 On 3/14/2019 4:53 PM, Nick Østergaard wrote:
 > Release annoncement live now.
 >
 > On Thu, 14 Mar 2019 at 18:15, Wayne Stambaugh >>> > > wrote:
 >
 > Nick,
 >
 > I just pushed the last few changes to the release announcement so
 once
 > the website download links are updated everything should be ready
 to go.
 >
 > Thanks,
 >
 > Wayne
 >
 > On 3/14/2019 11:21 AM, Nick Østergaard wrote:
 > > Hi
 > >
 > > Essentially ready, meaning windows, PPA and macos builds are
 > done/sanity
 > > checked, but not moved to stable folder yet. Please push your
 > tweaks for
 > > the draft of the announcement ASAP.
 > >
 > > I intend to fixup the other things in a couple of hours.
 > >
 > > Nick
 > >
 > > On Thu, 14 Mar 2019 at 15:28, Wayne Stambaugh
 > mailto:stambau...@gmail.com>
 > > >>
 wrote:
 > >
 > > How are we doing on the 5.1.0 packaging?  I've only heard
 from
 > > Jean-Samuel thus far.  Are the windows and macos packages
 > ready to go
 > > yet?  I have a few minor tweaks to make to the release
 > announcement and
 > > it's ready to go.  Please let me know so I can make the
 > official release
 > > announcement.
 > >
 > > Cheers,
 > >
 > > Wayne
 > >
 > > ___
 > > 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
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Download speeds for nightly builds seem a bit slow to a lot of people over at the forum

[Andrey Kuznetsov]

Mirrors are better. Torrents are either not allowed on some networks or
people don't know how to use them or don't care to install the required
software, some of which is not malware/ad-free.
So my suggestion is to stay away from torrents.

On Sat, Mar 9, 2019 at 3:23 PM Andrew Lutsenko  wrote:

> I think torrents are the best solution.
> Even when servers function normally on each release there is a stampede to
> download new binary and things slow down to a crawl. I don't know if moving
> to CERN servers (AWS servers?) will help but torrents certainly would.
>
> It's as simple as creating a torrent with openbittorrent.com tracker or
> even just a magnet link relying on DHT.
> I can help script this if needed.
>
> On Sat, Mar 9, 2019 at 10:32 AM Marco Ciampa  wrote:
>
>> On Sat, Mar 09, 2019 at 01:22:39PM -0500, Wayne Stambaugh wrote:
>> > Thanks.  If we are having issues with the CERN download speeds (although
>> > it is not entirely evident that is the issue) it would be good to have
>> > alternate mirrors for users to try if they are having issues with the
>> > main download server.
>>
>> Why not adding torrent seeds like done for the Ubuntu iso images or
>> Libreoffice binary files? We must have a torrent tracker somewhere and
>> that should offload servers and should solve the peak download problems
>> if any...
>>
>> --
>>
>>
>> Marco Ciampa
>>
>> I know a joke about UDP, but you might not get it.
>>
>> 
>>
>>  GNU/Linux User #78271
>>  FSFE fellow #364
>>
>> 
>>
>>
>> ___
>> 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
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Processing older versions (topic split from v6 Upgrade)

[Andrey Kuznetsov]

Making the latest version of KiCad behave as older versions of KiCad is
like teaching a horse to eat with a fork.

On Thu, Feb 28, 2019 at 10:28 PM cedric.dew...@telfort.nl <
cedric.dew...@telfort.nl> wrote:

>
> >Origineel Bericht
> >Van : s...@hillbrand.org
> >Datum : 27/02/2019 18:00
> >Aan : simon.rich...@hogyros.de
> >Cc : kicad-developers@lists.launchpad.net
> >Onderwerp : Re: [Kicad-developers] Processing older versions (topic split
> from v6 Upgrade)
> >
> >Am 2019-02-27 11:52, schrieb Seth Hillbrand:
> >> Am 2019-02-26 12:11, schrieb Simon Richter:
> >>> Hi Cedric,
> >>>
> >>> On 26.02.19 06:55, cedric.dew...@telfort.nl wrote:
> >>>
>  I'm opposed to any program that modifies a file when I open
>  it.
>  In my opinion the file should only change when I press the
>  "save" button.
> >>>
> >>> Of course, we'd have to ask first. The advantage would be that you can
> >>> stop before you do any changes to the board, so if you meant to be
> >>> using
> >>> an older version, you don't have to re-do your changes, and you get a
> >>> defined time where only the upgrade has taken place, but no other
> >>> changes, so you can do another version control check-in there.
> >>
> >>
> >> Hi Simon-
> >>
> >> I like how Solidworks handles this situation.  You can open an older
> >> version but it has a flag so that as soon as you try to edit the file,
> >> you get the attached dialog (with the appropriate "Don't show again"
> >> checkbox).
> >>
> >> Would something similar address your concerns?
> >>
> >> -Seth
> >
> >As an aside, this also changes the save icon and tooltip for the save
> >button to warn the user as well.  As soon as you save it in the new
> >version, this reverts to normal.
> >
> >-S___
> >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
>
> Hi All,
>
> How does an earlier version of Kicad handles a file that has been created
> by a newer version of Kicad?
> Altium opens files that have been created by a newer version, and warns
> the user. I use an older version of Altium than my co worker and so far we
> did not have issues yet. I can copy and paste from his designs to my
> designs without problems.
>
> As far as I can see Pcbnew does not offer to save the file as an older
> version.
>
> My main motivation to let the user continue to use older version of the
> file format in newer versions of Kicad is to prevent the forced upgrade
> path that all the commercial vendors use. This boils down to the question:
> Do we want to force the entire team to upgrade to a the same version of
> Kicad if they collectively work on the same files?
>
> Cheers,
> Cedric
>
>
>
> ___
> 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
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Version 6 development planning

[Andrey Kuznetsov]

Or instead of trying to change how the ratsnests are displayed because they
are laying on top of each other, instead have the user hover over the
overlapping of nets and a popup appears showing what nets there are kind of
like a magnifying glass, would probably be better if this magnifying glass
is triggered by a key. Ctrl+mouse hover over the ratsnest and it shows what
nets are in the vicinity.

On Wed, Feb 13, 2019 at 11:36 PM Marco Ciampa  wrote:

> On Wed, Feb 13, 2019 at 08:25:01AM -0800, Evan Shultz wrote:
> > As nothing more than an example, here is another tool facing the same
> > issue. I've colored one net's ratsnest green (others are still blue) and
> > you can see pins at orthogonal locations to each other get a zig (or is
> > that a zag?) so the individual pins on the net can still be easily
> > identified.
>
> I may be saying something very stupid...I know...
>
> Why not a "dashed line" with a pseudo-random dashing pattern?
> In that way should be way easier to distinguish the rastsnets...
>
> sorry for my 0.002 cent 
>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
>  GNU/Linux User #78271
>  FSFE fellow #364
>
> 
>
>
> ___
> 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
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Debugging Kicad, can this be done with Qt creator?

[Andrey Kuznetsov]

I wish there was a setup environment already that I could just download and
run...
I used to code with Qt but now setting up projects, much less with
Makefiles is like learning bash all over again.

On Wed, Dec 19, 2018 at 12:55 AM Mário Luzeiro  wrote:

> I used Qt Creator to develop for KiCad.
> You just need to create a project that builds with a Makefile (not a QT
> project but a Makefile project), you can have multiple build targets (
> Release, Debug ) then you can debug the Debug exec. You can set the target
> executable and exec path to debug (eg: kicad, pcbnew, etc)
>
> Tip: remember to add -jx (where x is your CPU number) to the makefile
> extra arguments.
>
> Cheers,
> Mario
>
> 
> From: Kicad-developers  ua...@lists.launchpad.net> on behalf of cedric.dew...@telfort.nl <
> cedric.dew...@telfort.nl>
> Sent: 19 December 2018 08:21:12
> To: kicad-developers@lists.launchpad.net
> Subject: [Kicad-developers] Debugging Kicad,can this be done with Qt
> creator?
>
> Hi All,
>
> I would like to set breakpoints in the Kicad source, and then run a
> graphical debugger. I know how to set this up with Qt projects in Qt
> creator. What's your method? Is qt a workable solution, or should I use
> ecipse? I'm on Windows 7, with msys2
>
> Cheers,
> Cedric
>
> ___
> 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
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Is snap-to-grid zoom-level dependant?

[Andrey Kuznetsov]

Funny, I thought it's maddengly hard to keep things off grid if that's how
you need them to stay :D

Is there a shortcut button like SHIFT or CTRL or something that will
temporarily turn off snap to grid feature? To move things off grid, or at
least to like the smallest grid you've setup, ie from 100,100 to 149,100
instead of 148.76,101.1?

On Sat, Oct 20, 2018 at 2:41 PM Jeff Young  wrote:

> Hi Seth,
>
> I think I actually prefer (1), but I don’t feel strongly.  (When you do
> get things off grid, it can be maddeningly hard to get them back on.  I
> think both the arrow keys and dragging do (2) now.)
>
> Cheers,
> Jeff.
>
> > On 20 Oct 2018, at 21:56, Seth Hillbrand  wrote:
> >
> > Am 2018-10-20 15:39, schrieb Jeff Young:
> >> Hi Seth,
> >> Yes, sorry, graphic items.
> >> The problem is the initial snap.  Let’s say I have an item at [100,
> >> 25] and my snap/zoom resolution is currently set to 2.  If I right
> >> arrow key then I’m expecting [102, 25] but what I get is [102, 24] (or
> >> maybe [102, 26] depending on rounding).  That move on the Y-axis in
> >> response to an X-axis keystroke is what’s annoying.
> >
> > OK, I think I see what is happening.  If you start with a graphical item
> that is off-grid, highlight it, press 'm' and then use the arrow keys to
> move it, the anchor point will snap to grid points.  Since you are
> off-grid, this will cause the item to move both in the direction of the
> arrow key as well as perpendicular to the closest point.
> >
> > I can think of a few different "correct" behaviors here.
> > 1) Move in the direction of the arrow key to the closest grid _line_ but
> do not move perpendicular.
> >  - Second press in the same direction steps by the grid distance.
> > 2) Move in the direction of the arrow key by the grid size distance (so
> staying on the grid defined by the origin)
> > 3) Move in the direction of the arrow key stopping at _both_ the grid
> lines for the absolute and origin-relative steps.
> >
> > Personally, I like (3) best.  But you are correct, we shouldn't be
> moving perpendicular.  I'll code up a fix.
> >
> >> BTW: did either you or Wayne get a chance to try out the
> >> escaping-labels-and-netnames patch?
> >
> > I looked it over and didn't see obvious issues but I'd like to play with
> it a bit more and try to find any corners.
> >
> > Best-
> > Seth
>
>
> ___
> 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
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] GAL canvas strategy - testers needed!

[Andrey Kuznetsov]

Thank you Simon, I was hoping for this! Please continue to release as it
goes so those of use who cannot compile on our own can feedback!

On Sat, Sep 8, 2018 at 6:56 AM, Simon Richter 
wrote:

> Hi,
>
> in case anyone needs Windows binaries to test,
>
> http://downloads.kicad-pcb.org/windows/testing/patched/
> kicad-patched-134-d3c82b0b5-x86_64.exe
>
> is the state of the GAL branch of yesterday evening.
>
> The branch also compiles fine on MSVC.
>
>Simon
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Problem with our Cairo-only strategy

[Andrey Kuznetsov]

Remember about OpenGL and MacOS:
https://appleinsider.com/articles/18/06/04/opengl-opencl-deprecated-in-favor-of-metal-2-in-macos-1014-mojave

On Tue, Aug 28, 2018 at 2:40 PM, Jeff Young  wrote:

> >> My solution would be to stick to OpenGL with hardware antialiasing.
>
> To my knowledge none of the Mac graphics cards have an issue with OpenGL,
> so this is also my plan.
>
> Cheers,
> Jeff.
>
>
> > On 28 Aug 2018, at 22:32, Tomasz Wlostowski 
> wrote:
> >
> > On 28/08/18 19:55, Seth Hillbrand wrote:
> >> OK.  Then, you should be able to scale the cairo context by 0.5 and draw
> >> individual pixels instead of 2x2 blocks.
> >
> > It doesn't work this way on OSX. If you want smooth graphics, you either
> > have to request a full resolution framebuffer (see
> > common/gal/hidpi_gl_canvas.cpp) or use Quartz for drawing. Since Cairo
> > in Kicad renders to memory and then copies to framebuffer, if the FB's
> > resolution is downscaled by 2 by Apple, the output will be blocky.
> >
> > My solution would be to stick to OpenGL with hardware antialiasing.
> >
> > Tom
> >
> >
> >>
> >> -S
> >>
> >> Am Di., 28. Aug. 2018 um 10:35 Uhr schrieb Jeff Young  >> >:
> >>
> >>Scratch that last comment; I got myself tied in knots.
> >>
> >>It is Cairo that renders blocky.
> >>
> >>
> >>>On 28 Aug 2018, at 18:29, Jeff Young  >>>> wrote:
> >>>
> >>>Interesting.  It’s not Cairo.
> >>>
> >>>We currently have EDA_DRAW_PANEL_GAL hard-coded to OpenGL, so it’s
> >>>actually OpenGL that’s rendering blocky….
> >>>
> >>>
> On 28 Aug 2018, at 18:11, Jeff Young  > wrote:
> 
> Hi Seth,
> 
> The scaling comes out correct, it’s just blocky.
> 
> Is there some way to adjust what Cairo thinks the screen
> resolution is and then re-scale the canvas so that everything
> comes out the same again?  I don’t know.
> 
> Cheers,
> Jeff.
> 
> 
> >On 28 Aug 2018, at 18:06, Seth Hillbrand  >> wrote:
> >
> >Can we just use cairo_scale to adjust the axes for Mac retina?
> >
> >-S
> >
> >Am Di., 28. Aug. 2018 um 09:59 Uhr schrieb Jeff Young
> >mailto:j...@rokeby.ie>>:
> >
> >JP made the Footprint Wizard Cairo-only recently, and I
> >planned to do the same for the Eeschema dialog previews.
> >
> >However, I’ve just discovered that Cairo doesn’t handle
> >Retina displays on Mac.  (It essentially draws blocks of 2x2
> >pixels instead of individual ones.)
> >
> >Anyone know if this is something we can fix, or if we need
> >to use OpenGL on Mac?
> >___
> >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
> >>
> >
>
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Designer Encountering KiCad 5

[Andrey Kuznetsov]

Why does there need to be priority?

Shouldn't priority depend on how close the mouse is to the snap point/axis.
grid (point), axis (line between two trace vertices)

On Wed, Aug 22, 2018 at 11:30 AM, Jon Evans  wrote:

> I think Altium implements this behavior by considering object snap points
> to be more important than grid snap points if both are turned on.  So you
> can drag the kink and snap onto the endpoint of another segment, and it
> will stay there even if it's not on a grid point, because of that priority.
>
> On Wed, Aug 22, 2018 at 1:27 PM Andrey Kuznetsov 
> wrote:
>
>> Dave said that if the trace is not on a grid, and the trace has a kink in
>> it, like it is going around something, but there is no obstruction, when he
>> grabs to move the kink, the program should recognize that he is trying to
>> smooth out the kink and ignore grid snap rules and move the piece of trace
>> he grabbed in line with the main trace. Instead the piece he grabbed was
>> flipping between 2 grid snap positions, neither of which matched the
>> straight trace.
>>
>> Maybe a trace snap options should be added that when moving a trace, and
>> trace snap is enabled, the mouse snaps to the trace.
>>
>> Dave said that the following workaround methods are not what
>> professionals would easy to use software (paraphrasing):
>> 1. deleting the kink and redrawing it
>> 2. changing grid size
>>
>> On Wed, Aug 22, 2018 at 9:26 AM, Seth Hillbrand 
>> wrote:
>>
>>> Hi All-
>>>
>>> Dave Jones from eevblog recently hosted a live webcast [1] of him trying
>>> out KiCad v5.  For those who don't know him, Dave was a professional EE
>>> with Altium for a number of years before moving to eevblog full-time.  As
>>> such, it's an interesting play-by-play of an experienced Altium user with
>>> describing his impressions of using KiCad v5.
>>>
>>> FWIW, the video is 2hrs long, so be forewarned.  Skip the first 10
>>> minutes as it's a live stream, there's some setup time.  He plays to his
>>> regular viewers, so it feels at times a bit joke-y.
>>>
>>> That all said, he notes a number of issues with the UX that would be
>>> useful to address.  As we get used to the software, we tend to internalize
>>> our workarounds and it's interesting to see someone document how they try
>>> to work with the software before the workarounds.
>>>
>>> -S
>>>
>>>
>>> [1] http://youtu.be/qpw9dKxL2Ho?a
>>>
>>>
>>> ___
>>> 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
>>>
>>>
>>
>>
>> --
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the
>> future [JFK]
>>
>> kandre...@gmail.com
>> Live Long and Prosper,
>> Andrey
>> ___
>> 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
>>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Designer Encountering KiCad 5

[Andrey Kuznetsov]

Dave said that if the trace is not on a grid, and the trace has a kink in
it, like it is going around something, but there is no obstruction, when he
grabs to move the kink, the program should recognize that he is trying to
smooth out the kink and ignore grid snap rules and move the piece of trace
he grabbed in line with the main trace. Instead the piece he grabbed was
flipping between 2 grid snap positions, neither of which matched the
straight trace.

Maybe a trace snap options should be added that when moving a trace, and
trace snap is enabled, the mouse snaps to the trace.

Dave said that the following workaround methods are not what professionals
would easy to use software (paraphrasing):
1. deleting the kink and redrawing it
2. changing grid size

On Wed, Aug 22, 2018 at 9:26 AM, Seth Hillbrand  wrote:

> Hi All-
>
> Dave Jones from eevblog recently hosted a live webcast [1] of him trying
> out KiCad v5.  For those who don't know him, Dave was a professional EE
> with Altium for a number of years before moving to eevblog full-time.  As
> such, it's an interesting play-by-play of an experienced Altium user with
> describing his impressions of using KiCad v5.
>
> FWIW, the video is 2hrs long, so be forewarned.  Skip the first 10 minutes
> as it's a live stream, there's some setup time.  He plays to his regular
> viewers, so it feels at times a bit joke-y.
>
> That all said, he notes a number of issues with the UX that would be
> useful to address.  As we get used to the software, we tend to internalize
> our workarounds and it's interesting to see someone document how they try
> to work with the software before the workarounds.
>
> -S
>
>
> [1] http://youtu.be/qpw9dKxL2Ho?a
>
>
> ___
> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] [PATCH] RFC: toolbar button support for action plugins

[Andrey Kuznetsov]

Please do not throw errors like unable to load icon to users, that is
extremely annoying to users. It is the developer's responsibility to make
sure the icon is loaded correctly, not the users, so users should not be
bothered, since they cannot do anything about it anyway.

On Thu, Aug 16, 2018 at 2:26 AM Andrew Lutsenko 
wrote:

> Ok, tested this further and thought that it's silly that buttons on
> toolbar have icons but menu items have generic hammer.
>
> Second patch adds icons to menu and fixes compatibility with plugins that
> don't define icon.
>
> [image: actionmenu.png]
>
> If icon file doesn't exist or can't be loaded (wrong format for example)
> pcbnew will throw an error message
> and will continue with no button for that plugin and generic hammer icon
> in menu. I think that's reasonable
> behavior since it lets user know that the plugin is somewhat broken, but
> let me know if you want me to
> change it.
>
> Regards,
> Andrew
>
> On Wed, Aug 15, 2018 at 2:31 AM Andrew Lutsenko 
> wrote:
>
>> Hi KiCad devs,
>>
>> I am proposing an addition to plugin system.
>> Probably most will agree that menus suck. Toolbars suck less :)
>>
>> In my plugin I added a dirty hack to modify top toolbar from plugin init
>> code to add a button
>> that calls plugins run() method. It is broken on linux X11 and is not a
>> sustainable way others
>> can add buttons in their plugins. But having a button was quite popular
>> among users so I
>> decided to implement this functionality directly in pcbnew.
>>
>> I introduced one more field plugin writers can define in defaults() that
>> contains path to png icon
>> and if that string is not empty, pcbnew will attempt to load that icon
>> and add a button to top
>> toolbar with action that calls the same run() method. I traced in code
>> how plugin action menu
>> is generated and added similar logic for buttons.
>>
>> Here is how the result looks like:
>>
>> https://i.imgur.com/f3xg1FE.gif
>>
>> Sample dummy plugin __init__.py code:
>>
>> import os
>> import pcbnew
>> import wx
>>
>> class Plugin1(pcbnew.ActionPlugin):
>>
>> def defaults(self):
>> self.name = "Dummy Plugin 1"
>> self.category = "Read PCB"
>> self.description = ""
>> self.icon_file_name = os.path.join(os.path.dirname(__file__),
>> 'icon.png')
>>
>> def Run(self):
>> wx.MessageBox("Plugin 1")
>>
>> Plugin1().register()
>>
>> It's as simple as that.
>>
>> The patch is attached. It probably needs some error checking but seems to
>> be working great.
>> Tested in win64 so far.
>> I'm open to suggestions on how to get it to good state, I will also test
>> on linux asap.
>>
>> Regards,
>> Andrew
>>
> ___
> 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
>
-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] KiCad v5 MacOS Library Editor - Error Cannot Load Aliases

[Andrey Kuznetsov]

I asked here specifically because I kind of wanted to reach you, the guy
who packaged macOS and knows kicad on mac.

It's a fresh install, I had old version, but I deleted them from
Applications and from Application Support and then installed fresh.
I had no issued following the readme.

I'm confused why the Altera library is trying to load when it doesn't exist
in application support library location :S

On Wed, Aug 1, 2018 at 9:10 PM, Adam Wolf 
wrote:

> Hi Andrey!
>
> In general, this list is not for user support.  Kicad.info is a great
> place for that.
>
> This is not something I've seen before.
>
> It would be good to know if you are migrating from a previous version
> of KiCad, or starting fresh, and if you had issues following any of
> the steps in the migration instructions for the README.
>
> Adam
> On Wed, Aug 1, 2018 at 10:54 PM Andrey Kuznetsov 
> wrote:
> >
> > Hi,
> >
> > Just wanted to ping you guys, I got kicad installed on macOS and when I
> opened the library editor I got hit with like 30 error messages, once for
> each library saying Error cannot load aliases from library ***.
> > Library like Altera, and a ton of others.
> >
> > Anyone know what's going on?
> >
> > This was on a new project.
> >
> > --
> > Remember The Past, Live The Present, Change The Future
> > Those who look only to the past or the present are certain to miss the
> future [JFK]
> >
> > kandre...@gmail.com
> > Live Long and Prosper,
> > Andrey
> > ___
> > 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] KiCad 5 release announcement update

[Andrey Kuznetsov]

You guys may want to fix the announcement on the website:
http://kicad-pcb.org/blog/2018/07/KiCad-5--a-new-generation/

That is NOT how you spell simulation!
Packaging Changes

In regard to packaging the KiCad binaries, not a lot has changed. You
should mostly be able to bump the package version, but some new major
dependencies have been added with the SPICE *similation...*


On Sun, Jul 22, 2018 at 3:42 PM, Wayne Stambaugh 
wrote:

> Awesome!  Thank you for the last minute effort to get the macos package
> ready.
>
> Wayne
>
> On 07/22/2018 06:30 PM, Adam Wolf wrote:
> > Completely fine.  Nick asked me off list.
> >
> > MacOS should be up tonight, and I'll make a PR and no one will know the
> > difference :)
> >
> > Adam
> >
> > On Sun, Jul 22, 2018, 5:07 PM Wayne Stambaugh  > > wrote:
> >
> > Adam,
> >
> > Are you OK with this?  I don't want you to feel like we threw you
> under
> > the bus.  If not, I can set the release announcement status back to
> > draft until you are ready.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 07/22/2018 01:18 PM, Nick Østergaard wrote:
> > > Depending on what you like, I think we should just release the doc
> > > today, I will be away from tomorrow anyways, and it looks like
> > > different linux packagers starting to package it anyways, so it
> should
> > > begin to be available for many users anyways. We can just add a
> note
> > > that the macos package is not quite ready yet.
> > > Den søn. 22. jul. 2018 kl. 18.44 skrev Wayne Stambaugh
> > mailto:stambau...@gmail.com>>:
> > >>
> > >> I just pushed the updated version of the v5 release
> announcement[1].
> > >> Please let me know if you find any missing features.
> > >>
> > >> Cheers,
> > >>
> > >> Wayne
> > >>
> > >> [1]:
> > >>
> > https://github.com/KiCad/kicad-website/blob/master/
> content/blog/release-5.0.0.adoc
> > >>
> > >> ___
> > >> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] [RFC] Op-amp symbol icons

[Andrey Kuznetsov]

Can you do B4 body and C2 or B2 +-? except make sure +- don't look like
they're touching the body.

On Thu, Jul 26, 2018 at 1:33 AM, Jeff Young  wrote:

> Hi John,
>
> Most other icons use a heavier pen width (see the DeMorgan symbols, pin
> graphics, etc.), which would favour the B column.
>
> I like the wider stance of the input pins in row 4.
>
> BTW, the new black-and-white 16x16 icons for the dialog buttons also
> suffer from slight blurryness.  I don’t know if they’re worth fixing or
> not, but if you’re so inclined….
>
> Cheers,
> Jeff.
>
>
> On 25 Jul 2018, at 15:05, John Beard  wrote:
>
> Hi,
>
> The pixel alignment of the op-amp icons looks a bit fuzzy compared to
> the other newer icons. These are not the only misaligned icons, but
> they are a very prominent set of them.
>
> The problem is that both:
>
> 1) The lines are not on the pixel grid
> 2) The lines are not a whole number of pixels wide.
>
> If this *were* to be changed so horizontal lines are sharp, the icons
> have to be modified. However, going up to 2px or down to 1px line
> width changes the feel a bit.
>
> Attached are some options (for the full size op-amp icons at 26px). If
> a consensus or executive decision ever emerges, I will produce a patch
> for the op-amp icons in that style.
>
> Personally, my "vote" is 2A, or 5A for icons where the symbol is
> smaller, like "copycomponent".
>
> List of icons affected for reference:
>
> add_component.svg
> copycomponent.svg
> edit_cmp_symb_links.svg
> edit_comp_footprint.svg
> edit_comp_ref.svg
> edit_comp_value.svg
> edit_component.svg
> edit_part.svg
> export_part.svg
> field_properties.svg
> hidden_pin.svg
> icon_libedit.svg
> import_cmp_from_lib.svg
> import_part.svg
> libedit.svg
> new_component.svg
> new_cvpcb.svg
> part_properties.svg
> save_part.svg
> save_part_in_mem.svg
>
> Yours, bike-sheddingly,
>
> John
> ___
> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] macos rc3

[Andrey Kuznetsov]

Hi Adam,

While the macOS zoom issue I reported and said was fixed is still fixed in
your RC3 release, the panning and zooming performance appears to have
decreased 2-3x compared to a nightly I tried like yesterday I think? weird

On Fri, Jul 6, 2018 at 6:38 PM, Adam Wolf 
wrote:

> Hi folks!
> Many people may not know but there were *extensive* changes made to
> the macOS packaging since V4.  After we all get some more sleep I'll
> write up more on the details. :)
>
> The RC3 build is ready for *developer* and *superfan* testing.
>
> http://downloads.kicad-pcb.org/osx/testing/kicad-unified-5.0.0-rc3-2.dmg
>
> Please do not suggest this to casual users of KiCad until there is a
> little more confidence in it.  I have used it, made a schematic, and
> laid out a PCB with it, but there are many features I do not use.
>
> It is a V5 build, so if you are running on V4 right now there is some
> footprint table modification you will need to do.
>
> There are 2 outstanding issues in the mac builder repository:
>
> 1) I have a placeholder in the README to link to Wayne's migration
> doc.  I will fill it before V5 is released.
>
> 2) I do not yet have a good quick test procedure for ngspice.  If
> someone who knows how to use the ngspice integration could take a look
> at the test procedures in
> https://github.com/KiCad/kicad-mac-builder/blob/master/README.md, and
> help me out here: https://github.com/KiCad/kicad-mac-builder/issues/90
> that would be super, super awesome.
>
> Adam Wolf
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] rc3

[Andrey Kuznetsov]

Hi guys,

I just tried RC3 nightly on macOS, previously I was having issues
previously with eeschema inconsistent zoom levels and speed of panning and
zooming.
I tried it today and even in high resolution mode at 3200x1800, eeschema
panning and zooming is quite tolerable and there is no more zoom
inconsistencies.
I'd have to say that this user interface annoyance is gone and makes KiCAD
usable on MacOS.

Thank you for making speed improvements, I don't know which commit fixed
it, between 5.0.0-rc2-dev-30-geb94d2f and 5.0.0-rc3-dev-2-g101b68b

On Thu, Jul 5, 2018 at 3:33 PM, Nick Østergaard  wrote:

> It is now available on http://downloads.kicad-pcb.org/docs/
>
> Den tor. 5. jul. 2018 kl. 03.52 skrev Adam Wolf <
> adamw...@feelslikeburning.com>:
>
>> Ah, I see.  I meant a tarball of the output of the 5.0.0-rc3 tag.
>> Something like http://docs.kicad-pcb.org/ has.
>>
>> Adam Wolf
>> On Wed, Jul 4, 2018 at 12:05 PM Mark Roszko 
>> wrote:
>> >
>> > https://github.com/KiCad/kicad-doc/archive/5.0.0-rc3.tar.gz
>> >
>> > from https://github.com/KiCad/kicad-doc/releases
>> > On Wed, Jul 4, 2018 at 12:19 PM Adam Wolf <
>> adamw...@feelslikeburning.com> wrote:
>> > >
>> > > Is there a tarball of the tagged docs somewhere?
>> > >
>> > > Adam
>> > >
>> > > On Wed, Jul 4, 2018, 7:14 AM Steven A. Falco 
>> wrote:
>> > >>
>> > >> Perfect!  Thanks.
>> > >>
>> > >> Steve
>> > >>
>> > >> On 07/04/2018 04:33 AM, Nick Østergaard wrote:
>> > >> > kicad-doc and kicad-i18n is also tagged
>> > >> >
>> > >> > søn. 1. jul. 2018 00.34 skrev Rene Pöschl > >:
>> > >> >
>> > >> > template repo is now tagged (sorry forgot about that one)
>> > >> >
>> > >> > On 30/06/18 23:56, Steven A. Falco wrote:
>> > >> > > Thank you!
>> > >> > >
>> > >> > > There are three repos not yet tagged with rc3 on github -
>> two are probably awaiting translation work: kicad-doc and kicad-i18n.  Also
>> not tagged: kicad-templates.  Once everything catches up to rc3, I will
>> push them to Fedora Rawhide.
>> > >> > >
>> > >> > >   Steve
>> > >> > >
>> > >> > > On 06/30/2018 08:50 AM, Wayne Stambaugh wrote:
>> > >> > >> I will do this when I tag rc3.  I think I have done it for
>> every release tag.
>> > >> > >>
>> > >> > >> On 06/30/2018 08:28 AM, Steven A. Falco wrote:
>> > >> > >>> If possible, it would also be great if a tar file for -rc3
>> could be uploaded to launchpad, analogous to what was done for -rc2.
>> > >> > >>>
>> > >> > >>> We do have an -rc2 build in the official Fedora Rawhide
>> now, and I'm ready to step that up to -rc3 once available.
>> > >> > >>>
>> > >> > >>>  Thanks,
>> > >> > >>>  Steve
>> > >> > >>>
>> > >> > >>> On 06/29/2018 10:15 PM, Adam Wolf wrote:
>> > >> >  Folks, enjoy your vacations.  We've all earned them! :)
>> > >> > 
>> > >> >  Wayne, if you could please announce on the list when you
>> tag rc3, that
>> > >> >  would be awesome.
>> > >> > 
>> > >> >  Thanks!
>> > >> > 
>> > >> >  Adam
>> > >> >  On Fri, Jun 29, 2018 at 7:27 PM Rene Pöschl <
>> poesc...@gmail.com > wrote:
>> > >> > > What a coincidence. I will also be out of town for the
>> next one and a
>> > >> > > half weeks.
>> > >> > > As i can not guarantee that i will have internet access
>> during this time
>> > >> > > it might be necessary that somebody else tags the final
>> kicad 5 library
>> > >> > > release.
>> > >> > > (I should be back at June the 10th late at night CET.)
>> > >> > >
>> > >> > > So i would suggest you make an issue one or two days
>> before the intended
>> > >> > > release date to notify the library team. (I already made
>> one to warn
>> > >> > > them about this fact. See:
>> > >> > > https://github.com/KiCad/kicad-symbols/issues/712)
>> > >> > >
>> > >> > > On 30/06/18 01:59, Wayne Stambaugh wrote:
>> > >> > >> I think we are good to go with rc3.  I'm going to tag
>> it tomorrow unless
>> > >> > >> something comes up between now and then.  Once rc3 is
>> tagged, I would
>> > >> > >> like to hold off on any commits that are not critical
>> bug fixes.  Since
>> > >> > >> I will be out of the country all next week for
>> vacation, this will give
>> > >> > >> users time to test rc3 builds.  If no critical issues
>> arise during this
>> > >> > >> week, I will tag 5.0.0 when I get back.  If this is an
>> issue for our
>> > >> > >> doc, library, or translation devs, please let me know.
>> Once our 5.0.0
>> > >> > >> builds are ready to go, I will make the stable release
>> announcement and
>> > >> > >> proceed directly to the pub to celebrate.  We are
>> getting close.  Thanks
>> > >> > >> again for all of your hard work.
>> > >> > 

Re: [Kicad-developers] More default fields in schematic

[Andrey Kuznetsov]

I agree, I had the same issue when I was doing my board, I needed a field
for all components, and I had to manually add it for every item, there was
no way to add this field to all components at the same time or to have it
add by default from the addition of a new component to the sheet.

Which reminds me, Cadence Designer has tools to manipulate fields on a
large scale, whether to add, delete, show, hide, etc, this is something
that would be nice to have in KiCAD, either that or a table of all
components for the sheet or schematic and columns for each field, with
ability to show/hide each cell individually.

I think the ultimate goal is to make the Symbol Table more useful, but
that'll take to long for v5 so if Kristoffer's patch allows an easy way to
add fields to all components or similar, I'd say do it because people will
be pissed and waste their time doing it for every component in their
schematic.

On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> I obvviously disagree, the correct solution would be to have both. This
> does not hinder that, its not even the same problem.
>
> The problem is for everyone who want for example the Manufacturer Part
> Number will have to define a fieldname, which every time
> results in them abbreviating it to something different. Hence nobody can
> work with Manufacturer Part Numbers.
>
> Here is something similar, Imagine all of the colours in Kicad for all of
> the layers where white by default. Have fun defining all the colours
> yourself.
> Maybe you want to define them yourself, nobody is stopping you now either,
> just get cracking.
>
> How easy would it be for you to look at the board someone else made later
> and understand what is what? Maybe for some that is a better solution, but
> for me that
> would be an extreme example of bad default values.
>
> This is how the default fields are now, they are white, or more like
> see-throught, which makes life harder for anyone that
> wants to contribute or create tools that interact with kicad, and as I
> previously said, this is only a default, you are still
> equally able to add/remove or change the fields how you want to. But,
> tools like kibom or various other web-based tools can much
> easier integrate to it, or at least support a default value as well. So
> for the majority of users, who doesnt change defaults,
> the tool would just work.
>
> I will reiterate, I do not care what they are named, I want a default
> field where I can put my manufacturer part number, amongs others.
> The specific abbreviation or name does not matter, If i care, I can
> manually add/remove my own fields *JUST AS I DO NOW*, but for the people
> who use it, it will be easier across projects, for the people that dont,
> It will not matter.
>
> Sane defaults matter. A lot actually.
>
> - Kristoffer
>
> On 2018-05-20 23:40, José Ignacio wrote:
>
>> I dont like this, the right solution would be to allow for importing a
>> default config into kicad for things like that, as different groups will
>> have different policies.
>>
>> On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark <
>> kristofferodmar...@gmail.com >
>> wrote:
>>
>> The patch should only affect first startup, changes to the fields
>> will be saved
>>
>> On May 20, 2018 22:18, "Seth Hillbrand" > > wrote:
>>
>> ​Hi Kristoffer-
>>
>> This feels like a management issue rather than a tool issue.
>> If the user doesn't want any extra fields, how would your
>> patch allow that?
>>
>> -S
>>
>>
>> Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark
>> > >:
>>
>>
>> Hello!
>>
>> I will open this can of worms again, I feel that I have
>> to. So from what
>> I gather we have proffessionals as the main aim in Kicad.
>> The reason I will open this issue again is that I feel we
>> have a
>> collaboration issue, maybe not a mayor one. But one
>> nonetheless.
>>
>> We really need more default fields for our schematic
>> symbols. Im not
>> proposing required fields, I am *ONLY* proposing that
>> there should be default fields added into the default
>> fields settings
>> tab. I am not proposing they need to be filled in the
>> libraries, nor that people need to use them. only that
>> they need to
>> exist with a fresh install of kicad so that easy problems
>> such as theese do not happen:
>>
>>  - Collaborators working on the same project will not
>> create
>> duplicate fields in libs/projects describing the same
>> thing by mistake
>>   

Re: [Kicad-developers] 5.0 RC2 / release status

[Andrey Kuznetsov]

What about this bug for MacOS that makes it too frustrating to use eeschema?

Basically, I cannot navigate by zooming around in eeschema because the
mouse scroll triggers on fine steps of the scroll wheel instead of the
larger ratchet steps, it's not just that this is a granularity issue it's a
consistency of navigation issue because when the scroll wheel springs back
to the ratchet position of the original zoom, the actual zoom level is
different and I have to play with the scroll wheel until the zoom level
looks OK. Coupled with a HiDPI display which slows down Eeschema and GOOD
BYE KiCAD on MacOS, it's too frustrating.

https://bugs.launchpad.net/kicad/+bug/1753054

On Fri, May 18, 2018 at 2:45 PM, Wayne Stambaugh 
wrote:

> Hi Rene,
>
> On 05/18/2018 11:53 AM, Rene Pöschl wrote:
> > On 18/05/18 16:44, Wayne Stambaugh wrote:
> >> If any of our doc and library devs are on this mailing list, please
> >> forward this information so we aren't making major changes to the docs
> >> and libraries at the last minute.
> >>
> >
> > We have one important pull request open that i will fix up my self
> > tomorrow if the contributor does not fix the remaining issues him self.
> > (Removing duplicate power pins from symbols as this can be quite
> > dangerous if the user connects them multiple times.)
> >
> > After this is merged i will tag the library with "5.0.0-rc2" (Tomorrow
> > evening)
> >
> > After this tag is set we will no longer allow renaming of libs until v6
> > development. (Adding new libs will still be allowed.)
>
> I'm OK with this.
>
> >
> > I will also create a kicad 4 compatibility backport for this lib. (The
> > intention is to allow users to use the new library structure for new
> > projects even if they can not update to a nightly build. This should
> > reduce their work when they then switch over to kicad 5)
> >
> > This backport will contain a reduced number of footprints as footprints
> > with custom or roundrect pads are not supported by kicad 4. I will also
> > backport the symbol libs. The 3d lib does not need any work in this
> > regard but i will still ad a separate release tag to make it easier for
> > users. Not sure if i will make a backport of the templates.
> > Creating this backport will take some time but i hope to have it done
> > one week after the rc2 tag is set.
>
> Awesome!  I'm sure our v4 users will appreciate this.
>
> >
> >
> > Regarding the issue about footprint connection you reported in [1]:
> > All symbols that have a valid symbol in the footprint lib are now
> > correctly connected. Sadly a lot of symbols still need footprints to be
> > generated. (Symbols where in the lib that never had a valid footprint)
> > Some of this will be fixed after the rc2 release. This will not impact
> > the library structure so i assume we can include these changes in the
> > final v5 release. (It will simply add more footprints.)
>
> That fine by me.  If we are going add new symbol libraries during v5, I
> don't see any reason not to add new footprints and footprint libraries.
> We should try to avoid wholesale renaming and/or moving of libraries and
> their contents to avoid headaches for users.  If we have any major
> library reorganizations, we can always create a v5 branch as we do for
> the KiCad source.
>
> Thank you for all of your hard work on the libraries.  They really have
> come a long way since v4 was released.
>
> Cheers,
>
> Wayne
>
> >
> > [1]: https://github.com/KiCad/kicad-symbols/issues/520
> >
> > ___
> > 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Fwd: Re: What are the smallest values for pad paste and mask clearances? Why can't polygon pads not use negative mask clearance?

[Andrey Kuznetsov]

Explicit format is always better than an implicit one where 0 stands for
inherit, for example.

On Sat, Apr 28, 2018 at 8:10 PM, Strontium  wrote:

> Wayne,
>
> I think it is an acceptable solution for V5 because this shouldn't get in
> the way of a V5 release.
>
> For V6, would it be feasible to define 0.01/0.1% to be a special
> value (like zero) which means "effectively zero" and then the pad gui can
> be updated with this special knowledge so that users don't look at a pad
> and say "Why is this set to 0.01??" and then change it thinking its a
> rounding error or something.
>
> I am not a fan of coded values in gui's because the whole idea of a gui is
> to abstract the implementation details into something human friendly. And 0
> meaning "inherit", and 0.01 meaning "effectively zero" is an
> implementation issue and not something the user should have to know or
> think about.
>
> Actually, it would be nice in the pad gui, if it IS set to inherit that
> the field display a READ ONLY value that would be used NOW based on the
> current global/parent settings, and which is it (a global value or a parent
> value).
>
> Steven
>
>
>
> On 28/04/18 23:35, Wayne Stambaugh wrote:
>
>> Just to be clear, the library developers are asking for the ability to
>> ignore clearance and ratio settings when creating solder mask and solder
>> paste only pads.  If this is the case, it will require a board file format
>> change to add a flag to ignore the global and footprint level settings.  I
>> would be opposed to changing the code to just assume that if it's a solder
>> mask or solder paste only pad that no tolerance or ratio is applied.  This
>> would break an existing pads defined this way and silently change existing
>> boards.  Given that we are deep into feature freeze, the least painful
>> solution would be to set the tolerance to 1nm and the ratio (as JP
>> suggested) to 0.1% for the footprints that need to maintain the
>> dimensions of solder mask and solder paste only boards.  The change to the
>> overall pad dimensions using this method would be far below any board
>> manufacturer's tolerance capabilities.  Is this not an acceptable solution?
>>
>> Cheers,
>>
>> Wayne
>>
>> On 04/28/2018 08:44 AM, Eeli Kaikkonen wrote:
>>
>>>
>>>
>>> 2018-04-28 15:04 GMT+03:00 Rene Pöschl > poesc...@gmail.com>>:
>>>
>>> The global settings here are less for ensuring correct alignment and
>>> more for a global paste reduction.
>>>
>>>
>>> That's right, that's what I meant. In the example datasheet you have
>>> 0.05mm tolerance for the location of the mask in relation to the copper
>>> because. But making the mask openings larger or smaller by 0.05mm would be
>>> against the recommendation.
>>>
>>> It just doesn't make sense to apply global paste and solder mask
>>> clearance values to "pads" which don't have copper. The whole reason why
>>> non-copper pads can exist is that you need control over the size, shape and
>>> location of paste or mask, right? Changing the behavior could lead to
>>> problems but luckily the current behavior can be circumvented by adding to
>>> clearance fields a very small value which is negligible in practice.
>>>
>>> Eeli Kaikkonen
>>>
>>>
>>> ___
>>> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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: Mouse Warping on Navigating between Sheets

[Andrey Kuznetsov]

OK, some of it makes sense, although I would still argue that the solution
is not to warp the mouse but instead disable screen scrolling until the
mouse comes back into the screen and exits the screen scrolling trigger for
a sufficient amount of time.
Mouse warping is a really bad practice no matter how justified it may seem,
there are other solutions to the issues mouse warping deals with.

My bug doesn't deal with interactive anything, there is no reason to warp
the mouse when using exit/enter a subsheet.

Thanks Jeff

On Sun, Apr 8, 2018 at 1:01 PM, Jeff Young <j...@rokeby.ie> wrote:

> Hi Andrey,
>
> It’s more nuanced than that.
>
> Mouse warping is more-or-less necessary for interactive tools such as when
> routing or drawing a line — if you don’t mouse warp then you have a segment
> going to a random place (and a massive mess if using push routing).
>
> Mouse warping is more-or-less a nuisance after a dialog when not in an
> interactive tool.
>
> For more info see https://bugs.launchpad.net/kicad/+bug/1745731.
>
> Cheers,
> Jeff.
>
>
> On 8 Apr 2018, at 19:31, Andrey Kuznetsov <kandre...@gmail.com> wrote:
>
> Hi,
>
> I thought from numerous discussions on this list that mouse warping was
> not to be used, or removed from code if it exists?
>
> RE: https://bugs.launchpad.net/bugs/1762057
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
> ___
> 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
>
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] eeschema: Mouse Warping on Navigating between Sheets

[Andrey Kuznetsov]

Hi,

I thought from numerous discussions on this list that mouse warping was not
to be used, or removed from code if it exists?

RE: https://bugs.launchpad.net/bugs/1762057

-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Proposed roadmap changes

[Andrey Kuznetsov]

Are there plans to add Constraint Manager to KiCad?

In Allegro, CM allows Design Engineers to specify physical, electrical and
spacing rules for classes, groups and nets, so that the PCB Layout Engineer
will be constrained by these definitions when working on the layout. It's
an explicit engineering note that forces the layout designer to obey these
rules rather than by word of mouth or email for the layout engineer to
follow.

On Thu, Mar 8, 2018 at 10:49 AM, jp charras  wrote:

> Le 08/03/2018 à 19:02, Ouabache Designworks a écrit :
> >
> >
> > On Thu, Mar 8, 2018 at 9:47 AM, Jon Evans > wrote:
> >
> > Netlist export is a key feature of every schematic editor. So is
> multi-sheet support. These
> > aren't random extra features, they are a normal part of any modern
> schematic editor.
> >
> >
> >
> > Yes they are necessary features. My argument is that they have little to
> do with the core mission of
> > putting graphical objects on the screen and probably would not share
> much code with
> > the rest of the program. If you add this into the main program then it
> only makes it bigger and more
> > complex. I alway go  for the simpler and cleaner approach.  Calling the
> netlister is more
> > of a design management task than a schematic editor one so it should go
> into the Design Manager program.
> >
> > John Eaton
>
> "they have little to do with the core mission..."
> This is false.
> A internal netlister is mandatory in a schematic design tool at least
> because it is the key for ERC
> and net highlight.
> An especially for net highlight, it must be *very* fast.
>
> --
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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 Subsheets

[Andrey Kuznetsov]

Hi Seth,

OK, yeah that makes it clear, Subsheet A should not have shown contents of
subsheet D since subsheet D was created and or supposed to have it's own
contents.

On Thu, Mar 29, 2018 at 10:00 AM, Seth Hillbrand 
wrote:

> Hi JP-
>
> That's correct, A.sch does not get modified.  Only the contents shown are
> changed.
>
> Here is a video showing the behavior:
> https://drive.google.com/file/d/1LnG2khusuEal3E2I8-NPEZ-
> A9dA_ag8O/view?usp=sharing
>
> If you don't see the same behavior, perhaps this is linux-only?
>
> -S
>
> 2018-03-29 9:23 GMT-07:00 jp charras :
>
>> Le 29/03/2018 à 18:04, Seth Hillbrand a écrit :
>> > Thanks for the feedback.  It helps me get my head around how the
>> subsheets are meant to work.
>> >
>> > Here is one of the bugs:
>> >
>> > 1) Take the attached project and unzip into KiCad.
>> > 2) Open the schematic and you will find a schematic with 5 subsheets
>> referencing 3 subsheet files.
>> >   - Each subsheet file has a label with its associated file name.  So
>> A.sch contains "A".
>> > 3) Rename the file for Sheet B to "A.sch"
>> >   - This works as expected for linking.  There is a warning, you
>> replace the contents of B with the
>> > contents A.sch.
>> > 4) Rename the file for Sheet B again, this time to "D.sch"
>> >   - You get a warning about the sheet using shared data in a complex
>> hierarchy.  Click "OK"
>> >
>> > At this point, Eeschema creates "D.sch" using the data from "A.sch".
>> If I understand Wayne
>> > correctly, the mixing of these metaphors is fine.  Renaming a sheet
>> filename to an existing filename
>> > replaces the sheet's current contents with the existing file contents
>> but renaming a sheet filename
>> > to a non-existing filename will create a new copy of the current
>> contents.
>> >
>> > 5) Now, open the subsheet "B", notice that it has the label "A".  Edit
>> the contents to be "D" and save.
>> >
>> > The bug here is that if you now open the original subsheet A, its
>> contents have also been changed to
>> > "D".  But only until you close and re-open the project.  At that point,
>> it is back to "A".  I'll
>> > deal with this bug but leave the copying/linking behavior as is unless
>> people feel otherwise.  It
>> > confused me but I think I can clarify it in the dialog text.
>> >
>> > -S
>>
>> Hi Seth,
>>
>> I tried that, and I did not noticed your issue.
>> All sheets are OK, and the subsheet A.sch was not modified.
>>
>> --
>> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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 Subsheets

[Andrey Kuznetsov]

Hi Seth,

I thought subsheets didn't have any issues, at least my experience didn't
present any issues, could you please link to the bug you're working on?

Thanks

On Wed, Mar 28, 2018 at 7:34 PM, Seth Hillbrand 
wrote:

> ​Hi All-
>
> I'm working on a bug in renaming sub-sheets.  In testing the fix, I've run
> up against a set of conflicting paradigms for how subsheets are handled.
> I'd like some feedback on how we expect to handle the subsheets.
>
> Either:
> 1) we treat them as actual objects such that renaming the sheet's filename
> renames the file on the computer but keeps the contents unchanged​ or
> ​2) we treat them as links to the objects and renaming the filename​ of
> the subsheet doesn't change the subsheet's file but instead just changes
> which file is referenced.
>
> Right now, we do both depending on whether there is an existing file and
> more than one reference to the subsheet or not.  This is confusing as it is
> difficult to determine when an operation will result in actually
> overwriting an existing file and thereby losing data.
>
> I'm inclined to make all actions (2).  This would allow a subsheet file to
> become unlinked from the project if you change the filename referencing it
> but would not allow overwriting subsheets on disk.
>
> Does anyone feel strongly that (1) is the correct action?
>
> -S
>
>
> ___
> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Proposed roadmap changes

[Andrey Kuznetsov]

Not sure how you would turn this into an effortless feature, but a few
months ago I’ve designed just that, replicated channels using the same
subsheet, on layout I did it once, then copy pasted and manually renamed
each component based on each channel number component.

On Wed, Mar 7, 2018 at 8:42 AM Andy Peters  wrote:

>
> > On Mar 5, 2018, at 10:57 AM, Jon Evans  wrote:
> >
> > Hi all,
> >
> > Since my day job involves a lot of engineering planning/timelines/etc,
> I've had this rolling around in my head...
> > I started brainstorming some proposed changes to the roadmaps.
> >
> > I am using Google drive because that's what is easiest for me to play
> with; I'm happy to send patches against the official roadmaps if get some
> buy-in for this.
> >
> > Feel free to comment (either directly on the doc or by email) with
> thoughts on this.
> >
> >
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> >
> > Basically what I am proposing is to put most of the energy into Eeschema
> for 6.0, with changes to other parts of the software basically being
> "whatever people have time left over for".  Everything else has been bumped
> to 7.0
>
> I’ll add one more to the list, clearly it’s a v7 wish … layout “rooms,”
> like the Altium feature. Consider a multi-channel design where you have to
> replicate a layout several times. It would be nice to define the channel
> in, say, a hierarchical subsheet, and the layout knows that it should
> replicate the work you do for one channel across the others.
>
> I realize that this is a completely non-trivial thing to implement, and
> further I recall some discussion about this but nobody had any real good
> ideas about how to do it.
>
> -a
>
>
>
> ___
> 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
>
-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Jumpy canvas on other platforms?

[Andrey Kuznetsov]

I notice the jerkiness on WIndows!

When you start panning, very slowly, by a little bit, there is a period
when it looks like the view window tries to center itself, so it jumps back
and forth between where it used to be and where the mouse is going, until
it's far enough and it snaps out of it and at the same time the scroll bars
appear.

On Mon, Mar 5, 2018 at 5:54 AM, Wayne Stambaugh 
wrote:

> I'm not seeing this on my windows 7 builds.  The panning after zoom
> extents works smoothly.  I even tried resizing the main frame several
> times but I still didn't notice it.
>
> On 3/4/2018 5:00 PM, Jeff Young wrote:
> > There is actually code in there to make them always on, but there seems
> > to be something defeating it.  I’ll poke around some more.
> >
> >> On 4 Mar 2018, at 21:57, Jon Evans  >> > wrote:
> >>
> >> Ah yes, I can reproduce that on Windows too.  I guess I didn't notice
> >> before because generally the scrollbars are visible (I noticed that
> >> "zoom extents" doesnt *always* result in the scrollbars being hidden,
> >> for whatever reason)
> >> Any reason why we hide the scrollbars?  Seems like it might be simpler
> >> to just always show them...
> >> -Jon
> >>
> >> On Sun, Mar 4, 2018 at 4:52 PM, Bernhard Stegmaier
> >> > wrote:
> >>
> >> Do a “fit to window” and then pan left/right… I use the touchpad.
> >> After “fit to window” there is no scrollbar.
> >> When the scrollbar comes back due to panning, I see almost always
> >> a small shift of the whole view down and then up again.
> >> Sometimes, but not always if you just pan left/right it will make
> >> this small jump downwards every time you cross center, just as if
> >> it would “snap" to middle position.
> >>
> >>
> >>> On 4. Mar 2018, at 21:25, Jon Evans  >>> > wrote:
> >>>
> >>> Maybe I don't really understand what you mean, but I can't see
> >>> any jumpiness on Linux when panning around (with middle-mouse
> drag).
> >>> What do you mean by "it automatically fits to window, so there's
> >>> not really any place to go"?  It does not do any kind of
> >>> auto-fitting except for the zoom-extents on file load on Linux,
> >>> and I don't have my Mac machine handy to compare.
> >>>
> >>> On Sun, Mar 4, 2018 at 3:11 PM, Jeff Young  >>> > wrote:
> >>>
> >>> If I open an eeschema file on OSX and pan around (it
> >>> automatically fits to window, so there’s not really any place
> >>> to go), the screen jumps around a bit.  True also on other
> >>> platforms, or Mac-specific?
> >>>
> >>> Thanks,
> >>> Jeff.
> >>> ___
> >>> 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
> >
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Mac HighDPI performance

[Andrey Kuznetsov]

Of course Wayne, that was my way of expressing concern for delaying a
performance issue and trying to sauce out your feeling of the possible
duration of v6 development.
Do you think there is currently manpower and list of features that requires
1 year plus 6 months delay, or do you think it's more like 2 years best
case and 1 year of delay worst case time of thing?

On Sun, Mar 4, 2018 at 5:03 PM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> When you become the project leader of KiCad, then you can make these
> decisions and live with the consequences of them.  In the mean time, that
> responsibility falls on my shoulders.  We are in a feature freeze for v5
> stable so I'm going to err on the side of caution here.  If we can pick up
> some performance gains without pushing the v5 stable release out, then I'm
> fine with that but if there are any stability issues then we will have to
> live with what we have.  Implementing this at the beginning of v6 and back
> porting it when it's stable is also acceptable.  Hopefully v6 will not take
> 2-3 years.
>
> Wayne
>
> On 03/04/2018 07:00 PM, Andrey Kuznetsov wrote:
>
>> If 6.0 is coming in 1 year, OK, but if it's 2-3 years away then I'd say
>> v5.0 should be stable and not have performance issues, in my mind better to
>> delay v5 up to 1 month at most to fix it rather than let it sit like that
>> for 2-3 years.
>>
>> On Sun, Mar 4, 2018 at 3:39 PM, Jeff Young <j...@rokeby.ie > j...@rokeby.ie>> wrote:
>>
>> As for road-map, I’d suggest that EeschemaGAL + newSymbolFileFormat
>> == 6.0.  Anything else that can ride along is fine, but not
>> definitive.
>>
>> The legacy stuff represents a tax on all development we do.
>>
>> Cheers,
>> Jeff.
>>
>>
>> On 4 Mar 2018, at 23:31, Jeff Young <j...@rokeby.ie
>>> <mailto:j...@rokeby.ie>> wrote:
>>>
>>> Well, I pounded on it a bit more, and it wasn’t really fitting
>>> into “easy” /or/ “straight forward”.  It’ll have to wait.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>> On 4 Mar 2018, at 20:07, Jon Evans <j...@craftyjon.com
>>>> <mailto:j...@craftyjon.com>> wrote:
>>>>
>>>> We should probably make some kind of road map if it doesn't exist
>>>> already, concerning the path to GAL for eeschema and who will be
>>>> doing what. For example, it might make sense to do the SCHEMATIC
>>>> class refactoring you were talking about before or in parallel
>>>> with parts of the porting effort.
>>>>
>>>> I'm up for working on this too, as soon as my connectivity / bus
>>>> stuff has landed.
>>>>
>>>> -Jon
>>>>
>>>> On Sun, Mar 4, 2018, 14:46 Wayne Stambaugh <stambau...@gmail.com
>>>> <mailto:stambau...@gmail.com>> wrote:
>>>>
>>>> I agree.  If it's not an easy straight forward fix, I would
>>>> prefer to
>>>> spend our precious manpower resources on the GAL port as
>>>> well.  I don't
>>>> know when in the v6 cycle any of this will happen but I'm
>>>> guessing it
>>>> will happen fairly early.  Tom or Orson, do either of you
>>>> have any idea
>>>> when this will happen?
>>>>
>>>> Wayne
>>>>
>>>> On 03/04/2018 02:40 PM, Jon Evans wrote:
>>>> > FWIW, I don't find the existing performance to be unusable,
>>>> it's just
>>>> > not up to the standards of PcbNew/GAL.  I don't think it's
>>>> worth any
>>>> > effort beyond easy fixes, we should put that energy into
>>>> the GAL port.
>>>> >
>>>> > -Jon
>>>> >
>>>> > On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier
>>>> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>
>>>> > <mailto:stegma...@sw-systems.de
>>>> <mailto:stegma...@sw-systems.de>>> wrote:
>>>> >
>>>> > I would judge it wrt eeschema GAL conversion.
>>>> > If that starts with v6, I don’t know if it is worth the
>>>> effort.
>>>> > If it is unsure when this will happen, it might be
>>>> worth it.

Re: [Kicad-developers] [PATCH] macOS CFBundleName

[Andrey Kuznetsov]

I'd prefer it actually, since it uses proper capitalization of
abbreviations. But that's just me and aesthetics.

On Sun, Mar 4, 2018 at 4:32 PM, Jeff Young  wrote:

> Anyone care if we go the other way with some of these (ie: rename Eeschema
> window to EESchema, CvPcb to CvPCB, and Pcbnew to PCBNew)?
>
> > On 4 Mar 2018, at 22:43, Bernhard Stegmaier 
> wrote:
> >
> > I guess it just is like that because the Linux binaries are also written
> like that and it has always been like that… :)
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 4. Mar 2018, at 23:37, Michael Kavanagh 
> wrote:
> >>
> >> The attached trivial patch fixes the app menubar items to match the
> >> window titles, as well as when you "Quicklook" an executable, in
> >> activity monitor and probably some other places as well.
> >>
> >> As a side is there any reason why the bundle/symlink names aren't
> >> capitalised/contain underscores instead of spaces? See attached
> >> screenshot.
> >>
> >> Regards,
> >> Michael
> >> <0001-macOS-standardise-CFBundleName-to-application-names.patch> Shot 2018-03-04 at 17.39.07.png>_
> __
> >> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Mac HighDPI performance

[Andrey Kuznetsov]

indow.
>> >>>
>> >>> Even if you fix that (to scroll most of the window and only
>> >>> invalidate
>> >>> the newly-exposed parts), you run into this:
>> >>>
>> >>>voidwxWidgetCocoaImpl::drawRect(void*rect,
>> WXWidgetslf,void*WXUNUSED(_cmd))
>> >>>
>> >>>{
>> >>>
>> >>>//preparingtheupdateregion
>> >>>
>> >>>wxRegionupdateRgn;
>> >>>
>> >>>
>> >>>//sinceaddingmanyrectstoaregionisacostlyprocess,
>> bydefaultusetheboundingrect
>> >>>
>> >>>#if0
>> >>>
>> >>>constNSRect*rects;
>> >>>
>> >>>NSIntegercount;
>> >>>
>> >>>[slfgetRectsBeingDrawn::];
>> >>>
>> >>>for(inti=0;i<count;++i)
>> >>>
>> >>>{
>> >>>
>> >>>updateRgn.Union(wxFromNSRect(slf,rects[i]));
>> >>>
>> >>>}
>> >>>
>> >>>#else
>> >>>
>> >>>    updateRgn.Union(wxFromNSRect(slf,*(NSRect*)rect));
>> >>>
>> >>>#endif
>> >>>
>> >>>
>> >>> …which will /also/ cause the whole window to be repainted if
>> there’s
>> >>> both an invalidated horizontal strip and a vertical one.
>> >>>
>> >>> And the latter turns out to be pretty much guaranteed by this
>> >>> one, which
>> >>> batches repaints:
>> >>>
>> >>>voidwxNonOwnedWindow::Update()
>> >>>
>> >>>{
>> >>>
>> >>>if(clock()-s_lastFlush>CLOCKS_PER_SEC/30)
>> >>>
>> >>>{
>> >>>
>> >>>s_lastFlush=clock();
>> >>>
>> >>>m_nowpeer->Update();
>> >>>
>> >>>}
>> >>>
>> >>>}
>> >>>
>> >>>
>> >>> But even Kicad isn’t blameless.  Once you fix all those there’s
>> >>> still no
>> >>> checking in SCH_SCREEN::Draw() to see if the individual draw items
>> >>> intersect the update region.  (Sure, the actually drawing is
>> >>> clipped in
>> >>> the end, but you still go through a /lot/ of code to get there.)
>> >>>
>> >>> All of these are fixable, and we’ve already crossed the Rubicon of
>> >>> having our own OSX wxWidgets branch.
>> >>>
>> >>> But it’s still a reasonable amount of work, with a non-trivial
>> risk
>> >>> profile.  Should I continue?
>> >>>
>> >>> Cheers,
>> >>> Jeff.
>> >>>
>> >>>
>> >>>
>> >>>> On 4 Mar 2018, at 01:30, Bernhard Stegmaier
>> >>>> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>
>> >>>> <mailto:stegma...@sw-systems.de>> wrote:
>> >>>>
>> >>>> No.
>> >>>>
>> >>>>> On 4. Mar 2018, at 01:51, Andrey Kuznetsov <kandre...@gmail.com
>> >>>>> <mailto:kandre...@gmail.com>
>> >>>>> <mailto:kandre...@gmail.com>> wrote:
>> >>>>>
>> >>>>> Would it be an easy fix to change the text/font such that it
>> >>>>> does not
>> >>>>> affect performance so significantly on MacOS?
>> >>>>>
>> >>>>> On Sat, Mar 3, 2018 at 5:20 AM, Wayne Stambaugh
>> >>>>> <stambau...@gmail.com <mailto:stambau...@gmail.com>
>> >>>>> <mailto:stambau...@gmail.com>> wrote:
>> >>>>>
>> >>>>>On 03/03/2018 07:33 AM, Jeff Young wrote:
>> >>>>>
>> >>>>>Hi Andrey,
>> >>>>>
>> >>>>>I did some profiling and I’d guess that the difference in
>> >>>>>eeschema and pcbnew-legacy performance is down to there
>> >>>

Re: [Kicad-developers] Mac HighDPI performance

[Andrey Kuznetsov]

Thanks, I didn't know that, Open in Low Resolution definitely speeds up
eeschema, I know kicad has this info on the website, however that fact that
you have to go inside the package and set that to low res mode as far as I
remember was not stated!

The docs should be updated to properly show how to enable low res mode,
step by step! Setting the main kicad.app to low res mode is not enough,
eeschema.app inside kicad.app package needs to be set.

It didn't feel like pcbnew got faster, I'll have to try on 5K monitor and I
found some supersampling and anti-aliasing modes that I want to turn on to
check.

Thank you to someone on the dev team I guess for getting rid of the mouse
warp events from right click, however the zoom mouse warp to the center of
the screen is still a major WTF.

Question: Is there something different in the way pcbnew does the zooming
compared to eeschema? My mouse zooming feels weird in escheema, but not in
pcbnew.
I think pcbnew has a linear incremental step and the zooming is crisp,
display changes per mouse wheel click, while eeschema what feels like
rubber banding between wheel clicks, step sizes are not linear thus causing
zooming ooogles. My mouse is a logitech mx master 2s using the ratchet
mode. In pcbnew, the zoom happens every ratchet, while in eeschema the zoom
can happen inbetween ratchets, like I just tilt the wheel and bring it back
but the zoom changed in one direction only, ie I can zoom all the way in
without ratcheting. In pcbnew you cannot do that, and it feels natural.


Bug or not? When I open eeschema and pcbnew from KiCad app, eeschema opens
as a standalone app and shows up in the dock on macOS while pcbnew opens as
another window that's part of kicad app. This caused issues with my logitec
options software for custom mouse button settings because I only programmed
kicad, but not eeschema.

On Thu, Mar 1, 2018 at 8:37 PM, Seth Hillbrand <seth.hillbr...@gmail.com>
wrote:

> Usually, Eeschema, Pcbnew, etc are links into the KiCad package.  If you
> right-click and go to "Show Original", you will get the actual
> application.  Get Info there will allow you to select "Open in Low
> Resolution" for that application.
>
> -S
>
> 2018-03-02 4:00 GMT+00:00 Andrey Kuznetsov <kandre...@gmail.com>:
>
>> Only KiCad app has Open in Low Resolution Mode, and I already had it
>> enabled!
>>
>> On Thu, Mar 1, 2018 at 7:53 PM, Seth Hillbrand <seth.hillbr...@gmail.com>
>> wrote:
>>
>>> Andrey-
>>>
>>> I'm moving this to a new thread so that we don't conflate the OpenMP
>>> discussion with this.
>>>
>>> Can you test running Kicad with the "Open in Low Resolution" mode
>>> enabled?  You can activate this by choosing "Get Info" on the main KiCad
>>> application and checking the option that says "Open in Low Resolution".
>>> You may need to do the same for the other applications (Eeschema, pcbnew,
>>> etc) as well.
>>>
>>> -Seth
>>>
>>> ​
>>> ​
>>> 2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov <kandre...@gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> So for now I've had a chance to test the motherboard project on my
>>>> Retina macbook display.
>>>> eeschema: horrible zoom, feels like elastic band zoom and I have all
>>>> scroll wheel accelerations and similar disabled, zoom response is super
>>>> laggy, cannot work like this, will need to make schematics on windows.
>>>> pcbnew by order of slowness:
>>>> legacy - pretty slow, zoom lag is major, boo boo
>>>> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
>>>> modern (accelerated) - almost cannot feel the lag, very nice, nice zoom
>>>> responsiveness
>>>>
>>>> I'll report tomorrow on 5K LG display.
>>>>
>>> ​
>>>
>>>
>>> ___
>>> 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
>>>
>>>
>>
>>
>> --
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the
>> future [JFK]
>>
>> kandre...@gmail.com
>> Live Long and Prosper,
>> Andrey
>>
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Mac HighDPI performance

[Andrey Kuznetsov]

Only KiCad app has Open in Low Resolution Mode, and I already had it
enabled!

On Thu, Mar 1, 2018 at 7:53 PM, Seth Hillbrand <seth.hillbr...@gmail.com>
wrote:

> Andrey-
>
> I'm moving this to a new thread so that we don't conflate the OpenMP
> discussion with this.
>
> Can you test running Kicad with the "Open in Low Resolution" mode
> enabled?  You can activate this by choosing "Get Info" on the main KiCad
> application and checking the option that says "Open in Low Resolution".
> You may need to do the same for the other applications (Eeschema, pcbnew,
> etc) as well.
>
> -Seth
>
> ​
> ​
> 2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov <kandre...@gmail.com>:
>
>> Hi,
>>
>> So for now I've had a chance to test the motherboard project on my Retina
>> macbook display.
>> eeschema: horrible zoom, feels like elastic band zoom and I have all
>> scroll wheel accelerations and similar disabled, zoom response is super
>> laggy, cannot work like this, will need to make schematics on windows.
>> pcbnew by order of slowness:
>> legacy - pretty slow, zoom lag is major, boo boo
>> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
>> modern (accelerated) - almost cannot feel the lag, very nice, nice zoom
>> responsiveness
>>
>> I'll report tomorrow on 5K LG display.
>>
> ​
>
>
> ___
> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] MacOS + OpenMP

[Andrey Kuznetsov]

Hi,

So for now I've had a chance to test the motherboard project on my Retina
macbook display.
eeschema: horrible zoom, feels like elastic band zoom and I have all scroll
wheel accelerations and similar disabled, zoom response is super laggy,
cannot work like this, will need to make schematics on windows.
pcbnew by order of slowness:
legacy - pretty slow, zoom lag is major, boo boo
modern (fallback) - decent, but the lag can be felt, zoom lag is minor
modern (accelerated) - almost cannot feel the lag, very nice, nice zoom
responsiveness

I'll report tomorrow on 5K LG display.

On Thu, Mar 1, 2018 at 9:06 AM, Bernhard Stegmaier 
wrote:

> When I started with KiCad I had massive problems mixing gcc and clang
> depending on what dependency was built with which compiler (different
> libstdc, ABI, etc.) - even if everything should have been compatible in
> theory.
> So, even if we decide to switch to our own toolchain and OpenMP I wouldn’t
> target that for v5.
>
> For my taste, I would rather stick to a toolchain being as stock as
> possible.
>
> > On 1. Mar 2018, at 18:00, Adam Wolf 
> wrote:
> >
> > I do not think it is feasible to distribute a different libstdc++ with
> > V5 stable for macOS unless there's someone who wants to take that on.
> >
> > Adam
> >
> > On Thu, Mar 1, 2018 at 10:50 AM, Wayne Stambaugh 
> wrote:
> >> Just for clarification I think Tom was commenting that the changes hurt
> >> the zone filling speed.  @Tom, is that what your were commenting on
> earlier?
> >>
> >> On 3/1/2018 10:11 AM, Jeff Young wrote:
> >>> But then the progress reporter won’t work (and you’ve got no way to
> cancel).
> >>>
> >>> Non-pooling parallel threads are sufficient for zone filling, aren’t
> they?
> >>>
> >>>
>  On 1 Mar 2018, at 15:00, Bernhard Stegmaier 
> wrote:
> 
>  For now it would probably be fine to just restore the pragma for the
> for loop optimisation.
>  Mac users are used to work single-threaded, all others would get back
> multithreading here.
> 
> > On 1. Mar 2018, at 15:58, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
> >
> > On 01/03/18 15:43, Jeff Young wrote:
> >> The purpose is it works on Mac.
> >>
> >> But it does appear I misread the std::max( omp_get_num_procs(), 2 )
> part.
> >>
> >
> > Thanks Jeff!
> >
> > Be aware that neither std::thread nor std::async have any concept of
> > thread pooling - we need to look for a suitable library or write or
> own.
> >
> > 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
> 
> >>>
> >>>
> >>> ___
> >>> 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
>
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] MacOS + OpenMP

[Andrey Kuznetsov]

Is there a complicated board design online I could download and test for
comparison between macOS and windows?
Someone people have used before for kicad verification for example.

On Wed, Feb 28, 2018 at 11:40 PM, Bernhard Stegmaier <
stegma...@sw-systems.de> wrote:

> I had a quick look where OpenMP is used.
>
> I found it somewhere in the connectivity/ratsnest code.
> I don’t know of any complaints in that area and even on my old HW I had
> never a bad experience.
>
> And then, 3D-Viewer.
>
> So, in my opinion it is basically only about 3D-Viewer… I don’t know if
> user experience will be that bad without OpenMP.
> IMHO it’s only the Raytracing view, which isn’t intended to be used for
> normal viewing stuff anyway.
>
> If I find some time over the weekend I will also try… but I don’t think it
> will be worth it.
>
>
> Regards,
> Bernhard
>
> > On 1. Mar 2018, at 00:50, Jeff Young  wrote:
> >
> > Or rip it out and use STL?
> >
> >> On 28 Feb 2018, at 23:38, Jon Evans  wrote:
> >>
> >> Hi all,
> >>
> >> Does anyone have a working build setup for getting OpenMP-enabled KiCad
> out of MacOS?
> >> If so, please share how -- I tried for a bit but couldn't get it going
> (I'm not super familiar with the MacOS toolchain yet).
> >>
> >> We should make sure that the 5.0 release is built with OpenMP,
> otherwise our Mac users are going to have a slower user experience.
> >>
> >> -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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] 3D Viewer "Render current view using Raytracing" is ludicrously slow

[Andrey Kuznetsov]

Hi Jon,

I'll test it tomorrow, kicad is downloading painfully slow.
Primarily, last time I tested it, it was because of large resolution
display and zooming/panning, dragging.
I have not noticed slowdown issues on my macbook pro in other programs.
[image: Inline image 1]


On Tue, Feb 27, 2018 at 8:17 PM, Jon Evans <j...@craftyjon.com> wrote:

> Is *everything* slow on your Mac, or just some things?
>
> I have a Mac that I try to test on when I can, although I do my primary
> development on a Linux machine. I have tried to make sure that GerbView is
> as fast on Mac OS as it is on Linux and in my testing, recent versions are
> basically there.
>
> I don't do much schematic work on Mac but I've done some things in pcbnew
> and don't notice much performance issues.
>
> If you can report specific actions or give example files that are much
> slower on Mac than on other platforms, if will be very helpful for
> improving performance.
>
> Re. Andy's email, yes the raytracer is slow, and there's probably room to
> make it faster! I don't think this is a MacOS specific thing.
>
> -Jon
>
>
> On Tue, Feb 27, 2018, 23:09 Andrey Kuznetsov <kandre...@gmail.com> wrote:
>
>> Frankly, everything on MacOS is slow in KiCad from 3D to layout to
>> schematic, panning and zooming is horrendous.
>> It's probably been 2 months since I tried anything on MacOS, and there
>> have been more than a few improvements committed, but I'm not holding my
>> breath. Especially since schematic isn't using OpenGL and will be
>> re-written for v6.
>>
>> I'll try to check the nightlies tomorrow to see how well it works on my
>> 5K display as well as just on the Retina display.
>>
>> On Tue, Feb 27, 2018 at 3:21 PM, Andy Peters <de...@latke.net> wrote:
>>
>>> This is probably way low on the list of priorities …
>>>
>>> On a 2017 MacBook Pro (Retina, touch bar, 16 GB RAM, with the Radeon 555
>>> graphics), the "Render current view using Raytracing" is ludicrously slow,
>>> as in it takes about a minute to render a “simple” design (front panel
>>> thing with LEDs and buttons).
>>>
>>> I admit that I didn’t know what that blue cube in the 3D viewer’s
>>> toolbar was for. I guess it’s really a tesseract.
>>>
>>> Anyway, it re-draws the display and then when you zoom or pan it reverts
>>> back to the original rendering (which is quite fast).
>>>
>>> -a
>>>
>>>
>>>
>>> Application: kicad
>>> Version: (5.0.0-rc2-dev-26-g0d794b2), release build
>>> Libraries:
>>> wxWidgets 3.0.4
>>> libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
>>> Platform: Mac OS X (Darwin 17.4.0 x86_64), 64 bit, Little endian, wxMac
>>> Build Info:
>>> wxWidgets: 3.0.4 (UTF-8,STL containers,compatible with 2.8)
>>> Boost: 1.61.0
>>> Curl: 7.43.0
>>> Compiler: Clang 7.3.0 with C++ ABI 1002
>>>
>>> Build settings:
>>> USE_WX_GRAPHICS_CONTEXT=ON
>>> USE_WX_OVERLAY=ON
>>> KICAD_SCRIPTING=ON
>>> KICAD_SCRIPTING_MODULES=ON
>>> KICAD_SCRIPTING_WXPYTHON=ON
>>> KICAD_SCRIPTING_ACTION_MENU=ON
>>> BUILD_GITHUB_PLUGIN=ON
>>> KICAD_USE_OCE=ON
>>> KICAD_SPICE=ON
>>>
>>>
>>> ___
>>> 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
>>>
>>
>>
>>
>> --
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the
>> future [JFK]
>>
>> kandre...@gmail.com
>> Live Long and Prosper,
>> Andrey
>> ___
>> 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
>>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] 3D Viewer "Render current view using Raytracing" is ludicrously slow

[Andrey Kuznetsov]

Frankly, everything on MacOS is slow in KiCad from 3D to layout to
schematic, panning and zooming is horrendous.
It's probably been 2 months since I tried anything on MacOS, and there have
been more than a few improvements committed, but I'm not holding my breath.
Especially since schematic isn't using OpenGL and will be re-written for v6.

I'll try to check the nightlies tomorrow to see how well it works on my 5K
display as well as just on the Retina display.

On Tue, Feb 27, 2018 at 3:21 PM, Andy Peters  wrote:

> This is probably way low on the list of priorities …
>
> On a 2017 MacBook Pro (Retina, touch bar, 16 GB RAM, with the Radeon 555
> graphics), the "Render current view using Raytracing" is ludicrously slow,
> as in it takes about a minute to render a “simple” design (front panel
> thing with LEDs and buttons).
>
> I admit that I didn’t know what that blue cube in the 3D viewer’s toolbar
> was for. I guess it’s really a tesseract.
>
> Anyway, it re-draws the display and then when you zoom or pan it reverts
> back to the original rendering (which is quite fast).
>
> -a
>
>
>
> Application: kicad
> Version: (5.0.0-rc2-dev-26-g0d794b2), release build
> Libraries:
> wxWidgets 3.0.4
> libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
> Platform: Mac OS X (Darwin 17.4.0 x86_64), 64 bit, Little endian, wxMac
> Build Info:
> wxWidgets: 3.0.4 (UTF-8,STL containers,compatible with 2.8)
> Boost: 1.61.0
> Curl: 7.43.0
> Compiler: Clang 7.3.0 with C++ ABI 1002
>
> Build settings:
> USE_WX_GRAPHICS_CONTEXT=ON
> USE_WX_OVERLAY=ON
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_ACTION_MENU=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_SPICE=ON
>
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Pads front and F.Cu visibility, possible bugs?

[Andrey Kuznetsov]

Yes Wayne, thanks.

JP, it's all your fault, demos shouldn't have proprietary Frenchy layer
names. :D

I think the demos should have proper layer names, I forgot the layer names
could be changed because I almost never go to Layer Setup.
It would be confusing for beginners when looking at demo boards.

On Mon, Feb 26, 2018 at 5:42 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Copper layers can be renamed so I only expect the layer names F.Cu and
> B.Cu when I have not renamed them.  I'm guessing you have one of the
> kicad demo projects open based on the French layer names which JP likes
> to use.
>
> On 2/25/2018 8:59 PM, Andrey Kuznetsov wrote:
> > Not sure if this is the right thread that dealt with Layers tab, but
> > anyone else thinks the first 2 names should say:
> > F.Copper
> > B.Copper
> >
> > instead of:
> > Inline image 1
> >
> > On Sat, Feb 17, 2018 at 3:04 PM, Andrzej Wolski <awolski.ki...@gmail.com
> > <mailto:awolski.ki...@gmail.com>> wrote:
> >
> > There is a simple fix to this problem, patch in attachment. It needs
> > to be applied on top of this patch:
> > https://bugs.launchpad.net/kicad/+bug/1743890
> > <https://bugs.launchpad.net/kicad/+bug/1743890>
> >
> > Witch this patch there is another issue: when all layers (in Layer
> > tab) are hidden, anchors and invisible text are still displayed.
> > I'm not sure what to do about it, maybe they also should be hidden?
> >
> > Cheers,
> > Andrzej
> >
> >
> >
> > On 02/07/2018 04:24 PM, Kristoffer Ödmark wrote:
> >
> > Hey!
> >
> > Another confusion arised when I was speaking to a friend. When
> > disabling the F.Cu layer, the pads are still visible. I can
> > understand the need to be able to disable the pads on the front
> > layer separate from everything else, to check for things under
> > pads etc.
> >
> > What I cannot understand is why the pads are visible if I want
> > to disable the entire front layer in pcbnew, also if one wants
> > transparent layers, one can actually se the compositioning for
> > the front pads and front traces, and allowing them to be
> > different colors also seem a bit confusing actually.
> >
> > I could basically change the front pad colors to look like they
> > belong to the back layer, I know its stupid, but this seems like
> > the kind of thing one would not want to even be possible, except
> > maybe for pranks.
> >
> > TLDR;
> >
> > Possible bugs:
> > 1. pads not affected by layer visibility setting
> > 2. pads and layer compositioning even when same setting
> > 3. pads and corresponding layer color setting
> >
> > Possible solution:
> > 1. Both layer and pads setting must be enabled for pads to
> render.
> > 2. Seems hard, Dont know
> > 3. pads and layer share color setting, not necessarily opacity
> > setting.
> >
> > Comments on these?
> >
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > <https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net
> > <mailto:kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > <https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp
> > <https://help.launchpad.net/ListHelp>
> >
> >
> >
> >
> > --
> > Remember The Past, Live The Present, Change The Future
> > Those who look only to the past or the present are certain to miss the
> > future [JFK]
> >
> > kandre...@gmail.com <mailto:kandre...@gmail.com>
> > Live Long and Prosper,
> > Andrey
> >
> >
> > ___
> > 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Windows Nightlies Installer - Unable to check components for instal

[Andrey Kuznetsov]

OK, what about the help files? :)

I agree, the library installer should be provided, you can call me a
thorough tester but a basic user (otherwise known as complainer ;-P ) and I
don't want to deal with github to get kicad libraries. A 50 year old
hobbyist will give up on kicad in 10 minutes after not being able to figure
out where the components are and that kicad appears baren after not being
able to start designing even a simple circuit without reinventing the wheel.

On Mon, Feb 26, 2018 at 3:39 AM, Simon Richter <simon.rich...@hogyros.de>
wrote:

> Hi,
>
> On 25.02.2018 22:52, Andrey Kuznetsov wrote:
>
> > The unchecked components in the image below cannot be checked.
>
> Yes, these are no longer in the nightly installer, because they are
> 600MB compressed, and most nightly users maintain their libraries
> themselves.
>
>Simon
>
>
> ___
> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] pcbnew: Right Click Context Menu

[Andrey Kuznetsov]

Hi,

Does anyone else think the right context menu in pcbnew should have some
items shelved into submenus?

For example, this looks OK when you click on nothing
[image: Inline image 1]

but if you start using the right click context menu for what it was meant
for, then all those Center, and Zoom *** items are just crowding the menu:
[image: Inline image 2]

I propose the Center and all the Zoom be shelved as submenu items under
"View" item.

-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Pads front and F.Cu visibility, possible bugs?

[Andrey Kuznetsov]

Not sure if this is the right thread that dealt with Layers tab, but anyone
else thinks the first 2 names should say:
F.Copper
B.Copper

instead of:
[image: Inline image 1]

On Sat, Feb 17, 2018 at 3:04 PM, Andrzej Wolski 
wrote:

> There is a simple fix to this problem, patch in attachment. It needs to be
> applied on top of this patch:
> https://bugs.launchpad.net/kicad/+bug/1743890
>
> Witch this patch there is another issue: when all layers (in Layer tab)
> are hidden, anchors and invisible text are still displayed.
> I'm not sure what to do about it, maybe they also should be hidden?
>
> Cheers,
> Andrzej
>
>
>
> On 02/07/2018 04:24 PM, Kristoffer Ödmark wrote:
>
>> Hey!
>>
>> Another confusion arised when I was speaking to a friend. When disabling
>> the F.Cu layer, the pads are still visible. I can understand the need to be
>> able to disable the pads on the front layer separate from everything else,
>> to check for things under pads etc.
>>
>> What I cannot understand is why the pads are visible if I want to disable
>> the entire front layer in pcbnew, also if one wants transparent layers, one
>> can actually se the compositioning for the front pads and front traces, and
>> allowing them to be different colors also seem a bit confusing actually.
>>
>> I could basically change the front pad colors to look like they belong to
>> the back layer, I know its stupid, but this seems like the kind of thing
>> one would not want to even be possible, except maybe for pranks.
>>
>> TLDR;
>>
>> Possible bugs:
>> 1. pads not affected by layer visibility setting
>> 2. pads and layer compositioning even when same setting
>> 3. pads and corresponding layer color setting
>>
>> Possible solution:
>> 1. Both layer and pads setting must be enabled for pads to render.
>> 2. Seems hard, Dont know
>> 3. pads and layer share color setting, not necessarily opacity setting.
>>
>> Comments on these?
>>
>>
>>
>
> ___
> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Windows Nightlies Installer - Unable to check components for instal

[Andrey Kuznetsov]

Hi,

Is this intended behaviour?
Downloaded:
http://downloads.kicad-pcb.org/windows/nightly/kicad-r9594.21f46776c-x86_64.exe

The unchecked components in the image below cannot be checked.
[image: Inline image 1]

-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Stable 5 development.

[Andrey Kuznetsov]

I thought there was also variable renaming, can't remember if it was global
variables or other variables.

On Sun, Feb 25, 2018 at 12:31 AM, jp charras <jp.char...@wanadoo.fr> wrote:

> Le 25/02/2018 à 03:12, Andrey Kuznetsov a écrit :
> > Just curious, a month back there were some emails discussing about major
> variable renames, it was
> > decided to wait until people finished committing major features to avoid
> rebasing every patch.
> >
> > Has this been done?
> >
>
> Are you talking about files renaming?
> If yes, I renamed many files, and for me this is done.
>
>
> --
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Stable 5 development.

[Andrey Kuznetsov]

Just curious, a month back there were some emails discussing about major
variable renames, it was decided to wait until people finished committing
major features to avoid rebasing every patch.

Has this been done?

On Sat, Feb 24, 2018 at 3:30 PM, Wayne Stambaugh 
wrote:

> I quick note to my lead developers (those of you with repo privileges)
> please hold off on making any pushes until I make a decision on the current
> branch situation.  I'm thinking it doesn't make sense to have two identical
> branches all the way up to the stable release.  All this does is make more
> work for me without any tangible benefit.  I think we should continue
> developing version 5 in the development repo until the stable 5 release and
> then branch.  Can anyone think of a reason not to do this?
>
> Cheers,
>
> Wayne
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] [PATCH] Add progress reporting for GerbView file loading

[Andrey Kuznetsov]

Does it make sense to predict whether a loading/progress window is
necessary based on total file size, based on prediction that a certain size
takes X seconds to load?
Or is loading highly dependent on the data/objects being loaded?

On Tue, Feb 20, 2018 at 7:21 PM, Jon Evans  wrote:

> Hi all,
>
> This patch adds the progress reporter dialog to GerbView file loading,
> when loading multiple files and the total load time goes over 1 second.
> I've also done some refactoring to share code between loading multiple
> files via a gerber job file and via the regular open dialog.
>
> -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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] [RFC] Change to object visibility system for usability/clarity

[Andrey Kuznetsov]

Jon, thanks for clarifying the cases. I hadn't thought about Wayne's
suggestion that way, and it does seem to make sense to me more than mine,
however I don't think the Render tab's items should be checked/modified
when Visibility is checked/modified.
For example, if I want to turn off Front Cu layer, and my Front Pads is
checked, then unchecking Front Cu will hide all Front layer copper
including Front Pads, however the checkbox for the Front Pads would remain
checked. It's about choosing which item types to show should their layer be
set to VISIBLE, not about trying to manipulate item types based on which
layer is turned on or off. What if I don't want to show front pads, but
need to toggle Front Cu, it'd be a hassle to uncheck Front Pads everytime
Front Cu is checked.

While you're modifying the Render tab, can you please re-order the items in
the list? Front and Bottom pads of the same item type should stick together
in the list, and perhaps place the most used items at the top.

On Sun, Feb 18, 2018 at 6:08 PM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> That's how I see it.  If I turn off the top copper layer and the
> footprints are linked to the layer then I want to turn off the footprint
> pads on that layer.  The remaining footprint layers would still be
> visible (silk screen, solder, mask, etc.).  Through hole layers may be
> tricking.  I don't think we really have a concept of the top or bottom
> copper of a through hole layer.
>
> On 02/18/2018 09:03 PM, Jon Evans wrote:
> > Those are interesting ideas.  My reading is that Andrey and Wayne are
> > actually proposing two different "linking" modes:
> >
> > Andrey: linking Front and Back (i.e. checking Front pads also checks
> > Back pads)
> > Wayne: linking copper and render (i.e. checking F.Cu also checks Front
> pads)
> >
> > Am I right about your suggestion, Wayne?
> >
> > I think from my personal perspective as a user, I would expect by
> > default Wayne's link to be on and Andrey's to be off.
> > That is, by default if I turn off F.Cu I expect Front Pads to go away
> > too, but there might be edge cases where I want to turn on F.Cu and turn
> > off F.Pads or vice versa.
> >
> > -Jon
> >
> > On Sun, Feb 18, 2018 at 8:59 PM, Andrey Kuznetsov <kandre...@gmail.com
> > <mailto:kandre...@gmail.com>> wrote:
> >
> > Wayne,
> > Yep, that's what I meant, kind of like the Photoshop linked layers.
> >
> > I should have added that the link is only between two of the same
> > checkboxes that are front and bottom. Ie Front/Bottom Pads would
> > have linkage, a different linkage would be between F/B Text, and
> > another for etc...
> >
> > Please don't link multiple text/pads/vias/footprints together. I
> > think linking should only be between Front and Bottom of the same
> > item type. Maybe add a tiny horizontal separator between the pairs
> > of Front and Bottom rows: ie
> > Front Pads
> > Bottom Pads
> > -
> > Front Text
> > Bottom Text
> > -
> > etc
> >
> > On Sun, Feb 18, 2018 at 5:49 PM, Wayne Stambaugh
> > <stambau...@gmail.com <mailto:stambau...@gmail.com>> wrote:
> >
> > I was thinking the same thing but rather than locked, I was
> thinking
> > linked to the layer but the concept is the same.  If they are
> >     linked,
> > when the layer is turned off, so are the footprints on that
> > layer.  When
> > they are unlinked, they are independent similar to the current
> > behavior.
> >  I would default to linked since that is what most users would
> > expect.
> >
> > On 02/18/2018 08:42 PM, Andrey Kuznetsov wrote:
> > > Hi Jon,
> > >
> > > Make sure Andrews' patches are consistent with your commits,
> essentially
> > > don't commit if it'll end up as a hodge podge of code that
> even though
> > > it works is not coherent.
> > >
> > > I can see benefits to having control over showing front copper
> pads but
> > > hiding bottom copper pads, so I would keep them separate.
> > > If it's an annoyance to toggle both front and bottom copper
> checkboxes
> > > for pads, maybe a LOCK is warranted such that in a locked
> position, a
> > > toggle checkbox in either, toggles both checkboxes for
> front/bottom, and
> > > an unlocked state keeps them independent.
>

Re: [Kicad-developers] [RFC] Change to object visibility system for usability/clarity

[Andrey Kuznetsov]

Wayne,
Yep, that's what I meant, kind of like the Photoshop linked layers.

I should have added that the link is only between two of the same
checkboxes that are front and bottom. Ie Front/Bottom Pads would have
linkage, a different linkage would be between F/B Text, and another for
etc...

Please don't link multiple text/pads/vias/footprints together. I think
linking should only be between Front and Bottom of the same item type.
Maybe add a tiny horizontal separator between the pairs of Front and Bottom
rows: ie
Front Pads
Bottom Pads
-
Front Text
Bottom Text
-
etc

On Sun, Feb 18, 2018 at 5:49 PM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> I was thinking the same thing but rather than locked, I was thinking
> linked to the layer but the concept is the same.  If they are  linked,
> when the layer is turned off, so are the footprints on that layer.  When
> they are unlinked, they are independent similar to the current behavior.
>  I would default to linked since that is what most users would expect.
>
> On 02/18/2018 08:42 PM, Andrey Kuznetsov wrote:
> > Hi Jon,
> >
> > Make sure Andrews' patches are consistent with your commits, essentially
> > don't commit if it'll end up as a hodge podge of code that even though
> > it works is not coherent.
> >
> > I can see benefits to having control over showing front copper pads but
> > hiding bottom copper pads, so I would keep them separate.
> > If it's an annoyance to toggle both front and bottom copper checkboxes
> > for pads, maybe a LOCK is warranted such that in a locked position, a
> > toggle checkbox in either, toggles both checkboxes for front/bottom, and
> > an unlocked state keeps them independent.
> >
> > Thanks
> >
> > On Sun, Feb 18, 2018 at 4:37 PM, Jon Evans <j...@craftyjon.com
> > <mailto:j...@craftyjon.com>> wrote:
> >
> > I'm going to go to the user forum with these questions too, but
> > curious what the devs think about this:
> >
> > In my original RFC, I proposed eliminating the different between
> > "front" and "back" in the Render checkboxes.
> > I still think this makes sense for things like text and footprints,
> > but I'm having second thoughts about merging the "Pads Front" and
> > "Pads Back"
> > Right now we have pads set to a different color than other copper on
> > the front and back copper layers.
> > I guess some users probably like this and would get annoyed if we
> > removed the ability for pads to be a special color.
> > Will they get annoyed if we force them to set both the front and the
> > back pads to the same color?
> >
> > (to be honest, I am used to EDA tools that by default treat pads as
> > part of the copper layer and show them in the same color, so I don't
> > care about this feature)
> >
> > -Jon
> >
> > On Sun, Feb 18, 2018 at 7:09 PM, Jon Evans <j...@craftyjon.com
> > <mailto:j...@craftyjon.com>> wrote:
> >
> > Thanks Wayne and Jeff (and yes there are a lot of edge cases
> > here to sort out)
> >
> > Note that Andrzej Wolski already did propose some changes
> > related to this that might be good to merge as a first step.
> > I have only done limited testing on them so far but they do work
> > and resolve some of the problems:
> >
> > https://bugs.launchpad.net/kicad/+bug/1743890/comments/6
> > <https://bugs.launchpad.net/kicad/+bug/1743890/comments/6>
> > https://lists.launchpad.net/kicad-developers/msg34009.html
> > <https://lists.launchpad.net/kicad-developers/msg34009.html>
> >
> > -Jon
> >
> > On Sun, Feb 18, 2018 at 6:53 PM, Jeff Young <j...@rokeby.ie
> > <mailto:j...@rokeby.ie>> wrote:
> >
> > Hi Jon,
> >
> > Sounds good to me too.  A few edge-cases you might want to
> > watch out for:
> >
> > https://bugs.launchpad.net/kicad/+bug/1733894
> > <https://bugs.launchpad.net/kicad/+bug/1733894>
> > https://bugs.launchpad.net/kicad/+bug/1744521
> > <https://bugs.launchpad.net/kicad/+bug/1744521>
> > https://bugs.launchpad.net/kicad/+bug/1744730
> > <https://bugs.launchpad.net/kicad/+bug/1744730>
> >
> > Cheers,
> > Jeff.
> >
> >
> >> On 18 Feb 2018, at 22:36, Wayn

Re: [Kicad-developers] [RFC] Change to object visibility system for usability/clarity

[Andrey Kuznetsov]

Hi Jon,

Make sure Andrews' patches are consistent with your commits, essentially
don't commit if it'll end up as a hodge podge of code that even though it
works is not coherent.

I can see benefits to having control over showing front copper pads but
hiding bottom copper pads, so I would keep them separate.
If it's an annoyance to toggle both front and bottom copper checkboxes for
pads, maybe a LOCK is warranted such that in a locked position, a toggle
checkbox in either, toggles both checkboxes for front/bottom, and an
unlocked state keeps them independent.

Thanks

On Sun, Feb 18, 2018 at 4:37 PM, Jon Evans  wrote:

> I'm going to go to the user forum with these questions too, but curious
> what the devs think about this:
>
> In my original RFC, I proposed eliminating the different between "front"
> and "back" in the Render checkboxes.
> I still think this makes sense for things like text and footprints, but
> I'm having second thoughts about merging the "Pads Front" and "Pads Back"
> Right now we have pads set to a different color than other copper on the
> front and back copper layers.
> I guess some users probably like this and would get annoyed if we removed
> the ability for pads to be a special color.
> Will they get annoyed if we force them to set both the front and the back
> pads to the same color?
>
> (to be honest, I am used to EDA tools that by default treat pads as part
> of the copper layer and show them in the same color, so I don't care about
> this feature)
>
> -Jon
>
> On Sun, Feb 18, 2018 at 7:09 PM, Jon Evans  wrote:
>
>> Thanks Wayne and Jeff (and yes there are a lot of edge cases here to sort
>> out)
>>
>> Note that Andrzej Wolski already did propose some changes related to this
>> that might be good to merge as a first step.
>> I have only done limited testing on them so far but they do work and
>> resolve some of the problems:
>>
>> https://bugs.launchpad.net/kicad/+bug/1743890/comments/6
>> https://lists.launchpad.net/kicad-developers/msg34009.html
>>
>> -Jon
>>
>> On Sun, Feb 18, 2018 at 6:53 PM, Jeff Young  wrote:
>>
>>> Hi Jon,
>>>
>>> Sounds good to me too.  A few edge-cases you might want to watch out for:
>>>
>>> https://bugs.launchpad.net/kicad/+bug/1733894
>>> https://bugs.launchpad.net/kicad/+bug/1744521
>>> https://bugs.launchpad.net/kicad/+bug/1744730
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
>>> On 18 Feb 2018, at 22:36, Wayne Stambaugh  wrote:
>>>
>>> Hey Jon,
>>>
>>> I'm good with all of this.  I would like to get this cleaned up before
>>> the stable release if possible since there are so many complaints and bug
>>> reports about it.
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> On 02/18/2018 03:00 PM, Jon Evans wrote:
>>>
>>> Hi all,
>>> Right now the behavior of the "Layer" and "Render" tabs of the layers
>>> widget are confusing to users, resulting in complaints on the forum and
>>> some bug reports:
>>> https://bugs.launchpad.net/kicad/+bug/1748181
>>> https://bugs.launchpad.net/kicad/+bug/1743890
>>> I could take a crack at fixing this (before or after 5.0 depending on
>>> what the complexity ends up being) but before I write any code I wanted to
>>> propose how I think it should work.
>>> I think the visibility of any object should be the AND of layer
>>> visibility and render visibility.
>>> To get there:
>>> 1) In the Render tab, get rid of the distinction between front/back. For
>>> example "Pads Back" and "Pads Front" becomes just "Pads"
>>> 2) Change the visibility code so that an object is visible if (a) the
>>> associated Render setting is turned on for the type of object, and (b) at
>>> least one of the layers the object is on is enabled in the Layers tab.
>>> 3) (optionally) Rename "Render" to something more friendly like "Items"
>>> or "Item Types" to make it more clear to the user that this is where they
>>> can turn off the display of various types of items as opposed to various
>>> layerse
>>> If this plan is OK, I will start working out the details of how to get
>>> there.  Right now the Render tab is directly controlling the visibility of
>>> certain "GAL Layers" but unfortunately the set of objects that appears on
>>> one GAL layer is not always equal to the set of objects that the user would
>>> expect to turn on and off, as seen by the bug reports.  So, there will have
>>> to be some additional logic created to manage these settings beyond just
>>> turning on and off layers in the GAL.
>>> -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 : 

[Kicad-developers] Command Window for Scripting

[Andrey Kuznetsov]

Hi,

I was wondering if there were ideas to add command window for scripting
inside schematic and pcbnew for v6?

For example, in Allegro you can create functions/aliases that when typed
into command line while inside layout tool would execute an for example
change grid type from 0.1mm to 1mm or turn on a predetermined set of
layers. This is for professionals who automate a lot of their actions to as
few actions as possible while working on large projects and need the
ability to reduce a dozen common steps into one.

What kind of scripting interface would it be?

-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Is eeschema's Symbol Table supposed to be editable?

[Andrey Kuznetsov]

Table editing doing weird things you didn't mean: Sounds like the bug I
reported.

On Fri, Feb 9, 2018 at 11:33 AM, Wayne Stambaugh 
wrote:

> Whew!  You can't blame that one on me.  To be honest, I have not really
> used the new "Symbol Table View" dialog so there could be all kinds bugs
> in there.  I know there was a paste bug reported against it where the
> pasted text was getting entered in the row below the one where the
> cursor was located.  I don't know if this ever got fixed.
>
> On 02/09/2018 02:27 PM, Jeff Young wrote:
> > We’re talking about different dialogs (yes, they have nearly the same
> name).  I’m talking about the one you get when you click the
> spreadsheet-looking icon on the top toolbar….
> >
> > Does that one work on MSW and Linux?
> >
> >
> >> On 9 Feb 2018, at 19:17, Wayne Stambaugh  wrote:
> >>
> >> That's strange because it literally is a cut and paste of the footprint
> >> library table edit dialog with a few minor tweaks for symbol libs.  It
> >> works fine on windows and linux.
> >>
> >> On 02/09/2018 02:13 PM, Jeff Young wrote:
> >>> Footprint library table editor is good.
> >>>
>  On 9 Feb 2018, at 19:09, Wayne Stambaugh 
> wrote:
> 
>  Does this not occur in the footprint library table editor?  I would be
>  surprised because its almost identical code unless I broke something.
> 
>  On 02/09/2018 01:59 PM, Bernhard Stegmaier wrote:
> > Yes, seems as if it is completely broken on macOS.
> > Seems to be fine on other platforms.
> >
> > It did somewhat work a while ago.
> > At least, I was able to change some cells/values when clicking
> multiple times…
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 9. Feb 2018, at 19:13, Jeff Young  wrote:
> >>
> >> There’s a Symbol Table dialog in eeschema (from the "Edit symbol
> fields” button in the top toolbar) with Apply Changes and Revert Changes
> buttons, suggesting that it should be editable.  Yet there are no other
> buttons, and neither right-clicking or double-clicking on the list does
> anything.
> >>
> >> Mac-only issue, or broken for everyone, or just never implemented?
> >> ___
> >> 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
> >>>
> >
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] [Kicad-doc-devs] string change proposal

[Andrey Kuznetsov]

We agree, good job, 24->0 words!
No need to specify something that's already been set system wide.

On Thu, Feb 8, 2018 at 8:06 AM, Andy Peters <de...@latke.net> wrote:

>
> On Feb 8, 2018, at 3:42 AM, Jeff Young <j...@rokeby.ie> wrote:
>
> > … or "Set default text editor and PDF viewer programs to open files from
> KiCad”
>
> +1
>
>
> One could interpret “open files from KiCad” as being “Open files created
> by KiCad.”
>
> The point I was trying to make, and perhaps wasn’t clear on, is that
> applications should never modify operating-system defaults that affect
> other applications. Thus saying “open files from (within) KiCad” is
> unnecessary, as it is understood that this setting affects performing this
> operation from within Kicad only.
>
> I suppose, further, that this whole thing about choosing which PDF viewer
> and which text editor to use is completely unnecessary. Why _wouldn’t_
> KiCad open text files in the OS default text editor? Why _wouldn’t_ you
> want it to open PDF files in the OS default PDF viewer? I set those
> defaults in the OS for a reason, and I expect applications to uses those
> defaults.
>
> -a
>
>
>
>
>
>
> On 8 Feb 2018, at 10:15, Andrey Kuznetsov <kandre...@gmail.com> wrote:
>
> Wow, that sentence is unnecessarily long.
>
> By rephrasing, you can cut that text in half. Also, why is text editor and
> PDF viewer in the same context? Default text editor and default PDF viewer
> do not open the same files, is this a context for a Group where those 2 are
> defined, weird...
>
> Telling the user that he "may define" a"Default Text Editor" is redundant,
> same for favorite, default is better, that's what is seen across many
> programs, you define a default program to open files, you don't define a
> favorite program. "These settings" redundant because you are in a settings
> editor window, duhh.
>
> How about "Set default text editor and PDF viewer programs"?
>
> If you want to be more explicit: "Set default text editor and PDF viewer
> programs for use by KiCad" or "Set default text editor and PDF viewer
> programs to open files from KiCad"
>
> On Wed, Feb 7, 2018 at 8:23 AM, Andy Peters <de...@latke.net> wrote:
>
>>
>>
>> > On Feb 7, 2018, at 5:09 AM, Marco Ciampa <ciam...@libero.it> wrote:
>> >
>> > Hello,
>> > I am not a native english,
>>
>> Your English is better than my Italian!
>>
>> > so I think it is better to ask even for small phrases:
>> >
>> > Here:
>> >
>> > #. type: Plain text
>> > #: kicad.adoc:246
>> > msgid ""
>> > "You may define your favorite text editor and PDF viewer. These
>> settings are "
>> > "used whenever you want to open a text or PDF file."
>> >
>> > I would have written it in a more esplicit way like:
>> >
>> > "You may define your favorite text editor and PDF viewer. These
>> settings are "
>> > "used by KiCad whenever you want to open a text or PDF file from the
>> inside "
>> > "of any of the KiCad tools."
>> >
>> > Comments?
>>
>> In general, I’m a fan of being as explicit and clear as possible. But, in
>> this case, I think the user should be aware that s/he’s setting something
>> from within Kicad, and as such that setting is only relevant when
>> interacting with a Kicad tool.
>>
>> -a
>
>
> ___
> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] [Kicad-doc-devs] string change proposal

[Andrey Kuznetsov]

Thanks Jeff,

That's 35->13 (2.7x) word reduction or 24->8 (3x) reduction for the less
explicit sentence.

Description text shouldn't be longer than 12-18 words, if it is it needs
rephrasing and/or help reference tag.

On Thu, Feb 8, 2018 at 2:42 AM, Jeff Young <j...@rokeby.ie> wrote:

> > … or "Set default text editor and PDF viewer programs to open files from
> KiCad”
>
> +1
>
>
> On 8 Feb 2018, at 10:15, Andrey Kuznetsov <kandre...@gmail.com> wrote:
>
> Wow, that sentence is unnecessarily long.
>
> By rephrasing, you can cut that text in half. Also, why is text editor and
> PDF viewer in the same context? Default text editor and default PDF viewer
> do not open the same files, is this a context for a Group where those 2 are
> defined, weird...
>
> Telling the user that he "may define" a"Default Text Editor" is redundant,
> same for favorite, default is better, that's what is seen across many
> programs, you define a default program to open files, you don't define a
> favorite program. "These settings" redundant because you are in a settings
> editor window, duhh.
>
> How about "Set default text editor and PDF viewer programs"?
>
> If you want to be more explicit: "Set default text editor and PDF viewer
> programs for use by KiCad" or "Set default text editor and PDF viewer
> programs to open files from KiCad"
>
> On Wed, Feb 7, 2018 at 8:23 AM, Andy Peters <de...@latke.net> wrote:
>
>>
>>
>> > On Feb 7, 2018, at 5:09 AM, Marco Ciampa <ciam...@libero.it> wrote:
>> >
>> > Hello,
>> > I am not a native english,
>>
>> Your English is better than my Italian!
>>
>> > so I think it is better to ask even for small phrases:
>> >
>> > Here:
>> >
>> > #. type: Plain text
>> > #: kicad.adoc:246
>> > msgid ""
>> > "You may define your favorite text editor and PDF viewer. These
>> settings are "
>> > "used whenever you want to open a text or PDF file."
>> >
>> > I would have written it in a more esplicit way like:
>> >
>> > "You may define your favorite text editor and PDF viewer. These
>> settings are "
>> > "used by KiCad whenever you want to open a text or PDF file from the
>> inside "
>> > "of any of the KiCad tools."
>> >
>> > Comments?
>>
>> In general, I’m a fan of being as explicit and clear as possible. But, in
>> this case, I think the user should be aware that s/he’s setting something
>> from within Kicad, and as such that setting is only relevant when
>> interacting with a Kicad tool.
>>
>> -a
>> ___
>> 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
>>
>
>
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
> ___
> 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
>
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] [Kicad-doc-devs] string change proposal

[Andrey Kuznetsov]

Wow, that sentence is unnecessarily long.

By rephrasing, you can cut that text in half. Also, why is text editor and
PDF viewer in the same context? Default text editor and default PDF viewer
do not open the same files, is this a context for a Group where those 2 are
defined, weird...

Telling the user that he "may define" a"Default Text Editor" is redundant,
same for favorite, default is better, that's what is seen across many
programs, you define a default program to open files, you don't define a
favorite program. "These settings" redundant because you are in a settings
editor window, duhh.

How about "Set default text editor and PDF viewer programs"?

If you want to be more explicit: "Set default text editor and PDF viewer
programs for use by KiCad" or "Set default text editor and PDF viewer
programs to open files from KiCad"

On Wed, Feb 7, 2018 at 8:23 AM, Andy Peters  wrote:

>
>
> > On Feb 7, 2018, at 5:09 AM, Marco Ciampa  wrote:
> >
> > Hello,
> > I am not a native english,
>
> Your English is better than my Italian!
>
> > so I think it is better to ask even for small phrases:
> >
> > Here:
> >
> > #. type: Plain text
> > #: kicad.adoc:246
> > msgid ""
> > "You may define your favorite text editor and PDF viewer. These settings
> are "
> > "used whenever you want to open a text or PDF file."
> >
> > I would have written it in a more esplicit way like:
> >
> > "You may define your favorite text editor and PDF viewer. These settings
> are "
> > "used by KiCad whenever you want to open a text or PDF file from the
> inside "
> > "of any of the KiCad tools."
> >
> > Comments?
>
> In general, I’m a fan of being as explicit and clear as possible. But, in
> this case, I think the user should be aware that s/he’s setting something
> from within Kicad, and as such that setting is only relevant when
> interacting with a Kicad tool.
>
> -a
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] KiCad talk at FOSDEM

[Andrey Kuznetsov]

KiCad is open source.

Last thing we need is to spend resources on legalize and trademark shit we
give away.

On Mon, Feb 5, 2018 at 6:43 PM, Ouabache Designworks 
wrote:

>
>
> On Mon, Feb 5, 2018 at 2:30 PM, Wayne Stambaugh 
> wrote:
>
>> Thank you everyone for the feedback.  Unfortunately I only have 20
>> minutes for my talk so I have to fit in what I can.  I could easily have
>> filled up a 1 hour talk and still needed more time.  I actually spend most
>> of my time talking about KiCad outside of my presentation.  At 7PM last
>> night I was talking to the LibreSpace[1] project and found out there is a
>> board designed with KiCad orbiting earth.  How awesome is that!  It's more
>> fun for me to see all of the great things users are doing with KiCad.  I
>> think that's more
>>
>>
>>
> Perhaps we need to push for a meeting format that better meets our needs
> rather than try to shoe horn into an existing slot.
>
> My main concern about the donation amount is that at some point kicad will
> be big enough to need a some what more formal
> legal presence. Form a non-profit with a board of directors so you can do
> things like hold trademarks and sue people. We may
> have reached that point already. It is the last thing most developers want
> to deal with but otherwise you become a easy target.
>
> John Eaton
>
>
>
> ___
> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Schematic symbol chooser clarification

[Andrey Kuznetsov]

I think this should be fixed before final v5.0 release!

On Mon, Feb 5, 2018 at 5:22 AM kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> Yeah, that to adds to the confusion. I think maybe coherency should be
> one of the main goal for v6.
>
>
> On 2018-02-05 13:25, Marco Ciampa wrote:
> > On Mon, Feb 05, 2018 at 01:10:08PM +0100, kristoffer Ödmark wrote:
> >> Hey!
> >>
> >> I just spent some time trying to "debug" a library non-issue with a EE
> >> switching from Altium for a test. He had added the libraries correctly,
> and
> >> they showed up. But everytime he tried adding a symbol to the
> schematic, no
> >> symbols was there. We sent pictures back and forth, and indeed the
> libraries
> >> added, but did not show up.
> >>
> >> To make a long hassle short, turns out the shortcut "P" is used to place
> >> symbols in Altium, but to place Power symbols in kicad.
> >> This is not an issue, however, there is no indication at all that the
> symbol
> >> chooser is actually filtered or limited when using the shortcut key.
> >>
> >> I think there could be benefits of adding some kind of visualization to
> the
> >> symbol chooser that the list is limited to only power symbols, maybe
> just
> >> changing the window title to something like "Choose Power Symbol" or the
> >> more general term of adding the filter to the window name. Let me know
> what
> >> you think
> > Also when you place a power symbol, the dialog shows normal symbols in
> > the history list, and it also permits to insert these symbols even if
> > they are not power symbols... that to me seems incoherent...
> >
>
>
> ___
> 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
>
-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] KiCad talk at FOSDEM

[Andrey Kuznetsov]

It actually makes sense for Digikey to encourage development of KiCad since
a lot more people would be encouraged to build gadgets and thus need
components which they'd likely buy from Digikey in the US.

Enable the user to build things, and they'll come buy your inventory of
parts.

On Mon, Feb 5, 2018 at 1:35 PM, Wayne Stambaugh 
wrote:

> I am not at liberty to discuss the amount other than it was the single
> largest donation in KiCad's history.
>
> Cheers,
>
> Wayne
>
>
> On 02/05/2018 11:43 AM, Ouabache Designworks wrote:
>
>> Good talk.
>>
>> Wayne mentioned a significant contribution from Digi-Key, Is this one of
>> those secret contributions or can you tell us how big the check was?
>>
>> John Eaton
>>
>>
>>
>>
>> ___
>> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] KiCad talk at FOSDEM

[Andrey Kuznetsov]

The talk is now up!


Note to Wayne,

You need to present KiCad's new features 3 times and explain each feature
in detail, ie no rushing.
You also need to teach 3 groups of people at different times how to use
KiCad.

I think you'll find a lot more "Note to self" improvements tat you stumbled
into while giving the talk :D

On Sun, Feb 4, 2018 at 9:50 PM, Seth Hillbrand 
wrote:

> Well done Wayne.  Excellent talk and congrats on the DigiKey donation!
>
>
>
>
> 2018-02-04 12:13 GMT-08:00 Piotr Esden-Tempski :
>
>> haha! it is! Well I guess I rewatch the talk from last year first to get
>> ready for the one from this year… to try to reverse the confusion I might
>> have caused this is the link again to the archive where the video should
>> appear eventually: https://video.fosdem.org/2018/K.4.201/
>>
>>
>> On Feb 4, 2018, at 12:08 PM, Nick Østergaard  wrote:
>>
>> Hold on. That looks like the one from last year.
>>
>> Den 4. feb. 2018 9.05 PM skrev "Piotr Esden-Tempski" :
>>
>>> Thank you Wayne! The video seems to have been transcoded already and I
>>> can see it on the event page: https://archive.fosdem.o
>>> rg/2017/schedule/event/kicad_status/
>>>
>>> Now I am off to watch your talk! :D
>>>
>>> Cheers,
>>> Piotr
>>>
>>> On Feb 4, 2018, at 11:45 AM, Wayne Stambaugh 
>>> wrote:
>>>
>>> I just reviewed and approved it so it will get trans-coded to high
>>> quality and uploaded to the FOSDEM videos section as soon as it is
>>> complete.  I'm not sure how long this will take so it may be a day or so.
>>> If I left your favorite feature out, it was not on purpose.  With only 20
>>> minutes, I was really pressed for time.  Once again it was standing room
>>> only and we were likely violating every fire code in Brussels.  I'll fill
>>> everyone in with more information late next week. I've got to decompress
>>> from the whirlwind of activity that comes along with FOSDEM and get caught
>>> up with me email backlog.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 02/03/2018 04:28 PM, Piotr Esden-Tempski wrote:
>>>
>>> I assume that the recordings will eventually appear. I guess you will be
>>> able to find it here: https://video.fosdem.org/2018/K.4.201/ eventually.
>>> I can’t wait to see the talk too, it was in the middle of the night for
>>> me so I will have to wait for the archive video to be published. :D
>>> Cheers,
>>> Piotr
>>>
>>> On Feb 3, 2018, at 7:49 AM, eldar.khayrullin >> mailto:eldar.khayrul...@mail.ru >> wrote:
>>>
>>> Oppps, I missed this one. Are any video records?
>>>
>>>  Исходное сообщение 
>>> От: Maciej Suminski >> mailto:maciej.sumin...@cern.ch >>
>>> Дата: 03.02.18 16:08 (GMT+03:00)
>>> Кому: Kicad Developers >> mailto:kicad-developers@lists.launchpad.net
>>> >>
>>> Тема: [Kicad-developers] KiCad talk at FOSDEM
>>>
>>> Just to let you know: Wayne's talk about KiCad [1] starts at 14:30 CET
>>> (in ~30 minutes).
>>>
>>> Cheers,
>>> Orson
>>>
>>> 1. https://fosdem.org/2018/schedule/event/cad_kicad_v5/
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net <
>>> mailto: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 <
>>> mailto: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
>>>
>>>
>>>
>>> ___
>>> 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 

Re: [Kicad-developers] [RFC] Pin edition coupling description

[Andrey Kuznetsov]

JP,

"Synchronized pin edit mode propagates all pin changes but pin number
change to other units"
is very confusing, either use except or pauses or commas or restructure the
meaning of negatives or specifiers.

Perhaps change to:
"Synchronized pin edit mode propagates all pin changes to other units
except renumbering of pins"
Although I'm still not quite sure of the meaning of the sentence, so maybe
this is wrong.

On Wed, Jan 24, 2018 at 8:07 AM, jp charras  wrote:

> Le 24/01/2018 à 16:33, Wayne Stambaugh a écrit :
> > Orson,
> >
> > Looks fine to me.  I'm not sure how clear the icon will be to users but
> > it makes more sense to me than the current icon.  The wording definitely
> > makes more sense.  Thanks for fixing this.
> >
> > Cheers,
> >
> > Wayne>
> > On 1/24/2018 9:28 AM, Maciej Sumiński wrote:
> >> I attach a patch that hopefully describes the mode a bit clearer. There
> >> is also a new icon to reflect the new logic behind the patch (see the
> >> attached imaged for comparison: left is the old icon, right is the
> >> proposed icon).
> >>
> >> Regards,
> >> Orson
> >>
>
>
> Looks also fine to me.
>
> However, the sentence:
> "Synchronized pin edit mode propagates all pin changes to other units"
> should be something like:
> "Synchronized pin edit mode propagates all pin changes but pin number
> change to other units"
>
> Because pin number is specific to each unit.
>
> >> On 01/23/2018 05:09 PM, jp charras wrote:
> >>> Le 23/01/2018 à 16:55, Maciej Sumiński a écrit :
>  On 01/23/2018 04:35 PM, jp charras wrote:
> > Le 23/01/2018 à 12:18, Maciej Sumiński a écrit :
> >> I am trying to find a better description for pin edition coupling
> in the
> >> symbol library editor (the rightmost button on the top toolbar). My
> >> proposal is in the attached patch, but perhaps one of our native
> English
> >> speakers can come up with a clearer description.
> >>
> >> Cheers,
> >> Orson
> >
> > Yes, this is a good proposal.
> >
> > Unfortunately, it is not yet perfect.
> >
> > For historical reasons, the tool that controls the multiunit pin
> edit mode enables this mode when it
> > is disabled (not activated), and disable the multiunit pin edit mode
> when it is activated.
> > (because a long time ago, multiunit parts with interchangeable units
> were 99% of symbols, and
> > disabling this multiunit pin edit mode (activating the tool) was
> useful for only 1% of symbols )
> >
> > For instance, the sentence is not clear:
> > "Normally enabled for multiunit parts with interchangeable units."
> > If "Normally enabled" is related to the pin edit mode, this is true,
> but the tool is not in
> > activated state
> > If "Normally enabled" is related to the tool, the sentence is wrong.
> >
> > Therefore it is really not easy to give a short and understandable
> explanation in a tooltip.
> > (unless changing the tool action)
> 
>  Good point Jean-Pierre. I think the way forward is to rename the
> button
>  from "Disable synchronized pin edit mode" to "Synchronized pin edit
>  mode", so the button enabled will represent the active state. Removing
>  negations will make the description very clear. We can still keep it
>  enabled by default for multi-unit parts with interchangeable units.
> 
>  Regards,
>  Orson
> >>>
> >>> For me, renaming the button (and slightly changing the icon look to
> avoid mistakes: the main issue
> >>> between versions 4 and 5 and old docs) is the less bad way.
> >>>
> >>> (I don't know a good way)
> >>>
> >>>
> >>
> >>
> >>
> >> ___
> >> 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
> >
>
>
> --
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Update PCB from Schematic dialog issues

[Andrey Kuznetsov]

I remember someone telling me, don't kick a dead horse, well Jeff, don't
drag a dead horse.
:D

On Wed, Jan 24, 2018 at 1:16 AM, Jeff Young <j...@rokeby.ie> wrote:

> Hi Andrey,
>
> Given a blank slate, I’d probably agree with you.
>
> But you’ve gotta give some love to the horse you’re on….
>
> Cheers,
> Jeff.
>
>
> On 24 Jan 2018, at 08:52, Andrey Kuznetsov <kandre...@gmail.com> wrote:
>
> Wayne, that's what you get for using PoS like wxWidgets.
> It's been like that since I looked at it 8 years ago, and it's still shit.
>
> That's why I used Qt in my project, it was polished from the get go, had
> easy to understand framework and had plenty of functions to accomplish
> anything in anyway. Where as wxWidgets was something out of 1990's poorly
> written, badly named, and ugly looking with a ton of bugs.
>
> wxWidgets => something the cat dragged in
> Qt => this is open source? WOW, looks professional...
>
> On Tue, Jan 23, 2018 at 4:58 PM, Wayne Stambaugh <stambau...@gmail.com>
> wrote:
>
>> Hey Bernhard,
>>
>> On 01/23/2018 05:51 PM, Bernhard Stegmaier wrote:
>>
>>> Thanks, Jeff.
>>>
>>> So, this brings up a very general question:
>>> How far do we want to go with patching wxWidgets in our fork?
>>>
>>> Don’t get me wrong… the patch looks sane and I guess it then will look
>>> on macOS like it does on Linux/Windows - for whatever reason (bug,
>>> intended?) it didn’t look like that before.
>>> Opinions?
>>> Wayne?
>>>
>>
>> If this is what we have to do to keep macos a workable solution than so
>> be it.  I guess at some point in the future, later versions of wx will
>> solve these issues but for the time being we can maintain a wx branch that
>> gives our macos users the best experience possible.
>>
>>
>>>  From a pure user perspective I guess it would be more important to have
>>> it look/behave the same on all platforms (as long as it doesn’t break OS
>>> specific GUI stuff).
>>> So, I am not opposed to apply such patches and all that might come in
>>> future...
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> On 23. Jan 2018, at 22:30, Jeff Young <j...@rokeby.ie >>> j...@rokeby.ie>> wrote:
>>>>
>>>> Thanks, Bernhard.  I tried that, but it didn’t help.
>>>>
>>>> I ended up taking out a pretty big hammer: I overrode the
>>>> setFrameOrigin method for radioButtons.  When radio buttons are created in
>>>> a column-oriented radio box, they now get a wxLEFT style.  The
>>>> setFrameOrigin override bangs the x value back to 8 if that flag is set.
>>>>
>>>> Patch in https://bugs.launchpad.net/kicad/+bug/1745026.
>>>>
>>>> Cheers,
>>>> Jeff.
>>>>
>>>>
>>>> On 23 Jan 2018, at 16:24, Bernhard Stegmaier <stegma...@sw-systems.de
>>>>> <mailto:stegma...@sw-systems.de>> wrote:
>>>>>
>>>>> In wxWidgets master there are a couple of alignment fixes like this
>>>>> one:
>>>>> https://github.com/wxWidgets/wxWidgets/commit/5aa66ffd936d00
>>>>> d101f12d6e8305a0d2f6c82cc2#diff-4c33f04f2d98bef24c5f526f6fa79d33
>>>>>
>>>>> I don’t know if some of them fix that problem.
>>>>> My last wxWidgets master build shows the same behaviour but I don’t
>>>>> know for sure if those fixes were already in.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Bernhard
>>>>>
>>>>> On 23. Jan 2018, at 15:40, Jeff Young <j...@rokeby.ie >>>>> j...@rokeby.ie>> wrote:
>>>>>>
>>>>>> Yeah, it’s just most noticeable in Read Netlist, but in fact it’s all
>>>>>> radio buttons in a box sizer:
>>>>>>
>>>>>> 
>>>>>>
>>>>>> On 23 Jan 2018, at 14:35, Jeff Young <j...@rokeby.ie >>>>>> j...@rokeby.ie>> wrote:
>>>>>>>
>>>>>>> Note: I’ve split the dialog issues out into a separate thread.
>>>>>>>
>>>>>>> Hi Wayne,
>>>>>>>
>>>>>>> It still happens.  I have wxFormBuilder running, but none of the
>>>>>>> settings affect the centering.  I suspect it’s just how the wxWidgets 
>>>>>>> team
>>>>>>> implemented it on OSX.
>>

Re: [Kicad-developers] Update PCB from Schematic dialog issues

[Andrey Kuznetsov]

Wayne, that's what you get for using PoS like wxWidgets.
It's been like that since I looked at it 8 years ago, and it's still shit.

That's why I used Qt in my project, it was polished from the get go, had
easy to understand framework and had plenty of functions to accomplish
anything in anyway. Where as wxWidgets was something out of 1990's poorly
written, badly named, and ugly looking with a ton of bugs.

wxWidgets => something the cat dragged in
Qt => this is open source? WOW, looks professional...

On Tue, Jan 23, 2018 at 4:58 PM, Wayne Stambaugh 
wrote:

> Hey Bernhard,
>
> On 01/23/2018 05:51 PM, Bernhard Stegmaier wrote:
>
>> Thanks, Jeff.
>>
>> So, this brings up a very general question:
>> How far do we want to go with patching wxWidgets in our fork?
>>
>> Don’t get me wrong… the patch looks sane and I guess it then will look on
>> macOS like it does on Linux/Windows - for whatever reason (bug, intended?)
>> it didn’t look like that before.
>> Opinions?
>> Wayne?
>>
>
> If this is what we have to do to keep macos a workable solution than so be
> it.  I guess at some point in the future, later versions of wx will solve
> these issues but for the time being we can maintain a wx branch that gives
> our macos users the best experience possible.
>
>
>>  From a pure user perspective I guess it would be more important to have
>> it look/behave the same on all platforms (as long as it doesn’t break OS
>> specific GUI stuff).
>> So, I am not opposed to apply such patches and all that might come in
>> future...
>>
>>
>> Regards,
>> Bernhard
>>
>> On 23. Jan 2018, at 22:30, Jeff Young > j...@rokeby.ie>> wrote:
>>>
>>> Thanks, Bernhard.  I tried that, but it didn’t help.
>>>
>>> I ended up taking out a pretty big hammer: I overrode the setFrameOrigin
>>> method for radioButtons.  When radio buttons are created in a
>>> column-oriented radio box, they now get a wxLEFT style.  The setFrameOrigin
>>> override bangs the x value back to 8 if that flag is set.
>>>
>>> Patch in https://bugs.launchpad.net/kicad/+bug/1745026.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
>>> On 23 Jan 2018, at 16:24, Bernhard Stegmaier > wrote:

 In wxWidgets master there are a couple of alignment fixes like this one:
 https://github.com/wxWidgets/wxWidgets/commit/5aa66ffd936d00
 d101f12d6e8305a0d2f6c82cc2#diff-4c33f04f2d98bef24c5f526f6fa79d33

 I don’t know if some of them fix that problem.
 My last wxWidgets master build shows the same behaviour but I don’t
 know for sure if those fixes were already in.


 Regards,
 Bernhard

 On 23. Jan 2018, at 15:40, Jeff Young > wrote:
>
> Yeah, it’s just most noticeable in Read Netlist, but in fact it’s all
> radio buttons in a box sizer:
>
> 
>
> On 23 Jan 2018, at 14:35, Jeff Young  j...@rokeby.ie>> wrote:
>>
>> Note: I’ve split the dialog issues out into a separate thread.
>>
>> Hi Wayne,
>>
>> It still happens.  I have wxFormBuilder running, but none of the
>> settings affect the centering.  I suspect it’s just how the wxWidgets 
>> team
>> implemented it on OSX.
>>
>> I might light at it again while putting my flame-suit on over Undo. ;)
>>
>> Cheers,
>> Jeff.
>>
>>
>> On 23 Jan 2018, at 14:19, Wayne Stambaugh >> > wrote:
>>>
>>> Jeff,
>>>
>>> Is this still an issue.  This dialog looks fine on windows and linux
>>> so
>>> I have no way of confirming that any changes to the wxformbuilder
>>> settings would fix it.  Any of our macos devs have wxformbuilder on
>>> their system so they can fix this?
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 1/18/2018 1:17 PM, Jeff Young wrote:
>>>
 It’s not center vs. left alignment, but rather that the radio button
 group is centered within the staticTextBox.  Note in particular the
 alignment of the two radio button groups in the left column:



 On 18 Jan 2018, at 17:23, Nick Østergaard  
> > wrote:
>
> What do you mean by centered? I don't see anything centered, I just
> see them left aligned. Looks ok to me unless I am looking at the
> wrong
> thing.
>
> 2018-01-14  0:02 GMT+01:00 Jeff Young
>  >:
>
>   This is a shortcut for eeschema Annotate + eeschema Write Netlist
>   + pcbnew Read Netlist, right?
>
>   Is there a reason the Update PCB from Schematic dialog doesn’t
>   include the “keep/delete” options we have 

Re: [Kicad-developers] eeschema Save

[Andrey Kuznetsov]

You already said the save will save everything, now you want to introduce
differentiating icons/tooltips that will add complexity to the most simple
tasks that will already do the implied function without the need for
clarifying what is sheet and what is hierarchy. No changing tooltips based
on single sheet vs hierarchy.

Now that I understand what you are after.

I suggest:
Save icon with multiple diskettes (multiple will imply it will save
everything, whether it's 1 sheet or hierarchy, the function will save all,
so there's no need for a single diskette)
Tooltip: ii

On Sat, Jan 13, 2018 at 11:57 AM, Jeff Young <j...@rokeby.ie> wrote:

> Just to be clear on the context-specific options: the idea is to make
> hierarchical schematics a progressive disclosure feature.  So a
> less-sophisticated user happy with a one-sheet schematic wouldn’t have to
> deal with tooltips and/or icons relating to hierarchies.
>
> So there would always be a single icon visible at any given time (and a
> single function available), but the icon and/or tooltip might be different
> depending on the context.
>
>
> On 13 Jan 2018, at 19:48, Jeff Young <j...@rokeby.ie> wrote:
>
> The *function* is always the same: save as many sheets as there are.  The
> only question is how to communicate that to the user.
>
> Your reply sounds like a vote for (a)(ii), although you weren’t specific
> about the tooltip side of things.
>
> Cheers,
> Jeff.
>
>
> On 13 Jan 2018, at 19:23, Andrey Kuznetsov <kandre...@gmail.com> wrote:
>
> What is the problem with saving ALL schematics in the project that have
> been edited, whether it's a 1 sheet or heirarchy sheet project?
> Are there times when you only want to save that sheet but not the other
> sheets? If yes, then maybe add 2 save buttons, save and save all, if not
> then just the save all button
>
> I am against using schematic icon with a disk, too much complexity!
>
> You should simply use:
> Disk icon for Save
> and/or
> Multi-Disk icon for Save All
>
> There is no purpose in indicating that you want to save a schematic in a
> schematic application when calling for a Save.
>
> On Sat, Jan 13, 2018 at 3:15 AM, Jeff Young <j...@rokeby.ie> wrote:
>
>> The eeschema Save button’s tooltip reads “save schematic *project*”
>> (emphasis mine).  Because of that, it got the
>> project-with-superimposed-disk in the recent icon update.  I don’t think
>> either of those is optimal.
>>
>> There are 3 distinct concepts:
>>
>> 1) Kicad projects (containing schematics, PCBs, gerbers, etc.)
>> 2) A hierarchy of schematic sheets
>> 3) A single schematic sheet
>>
>> The differentiation between (2) and (3) is a bit confusing because the
>> eeschema window only deals with (2) while we represent schemas in the
>> file-system at (3).
>>
>> But we should make every effort not to conflate (1) with (2).  I think
>> the word “project” should be reserved for use in the context of (1).
>>
>> So I can see 4 options for the eeschema Save option:
>>
>> a) sidestep the issue and go with the arrow-to-disk icon (a la pcbnew)
>> b) use a schematic-with-superimposed-disk icon
>> c) use a stacked-schematic-with-superimposed-disk icon (a la the
>> hierarchical-sheet-tool icon)
>> d) context-sensitive schematic or stacked-schematic icon
>>
>> And a few for the tooltip:
>>
>> i) use “save all schematics in hierarchy”
>> ii) use “save schematic(s)”
>> iii) make it context-sensitive, reading either “save schematic” or “save
>> all schematics in hierarchy”
>>
>> Personally, I think context-sensitivity is appropriate for the tool-tip,
>> but not the icon.  So I’d be inclined to go with (b) or (c) and (iii).
>>
>> As an aside, project files (*.pro) are still using the application icon,
>> rather than the Project icon.  That makes the New Project / New Project
>> from Template / Open Project icons harder to understand.
>>
>> Cheers,
>> Jeff.
>>
>> BTW: I’m happy to help fix up any of these issues….
>>
>> ___
>> 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
>>
>>
>
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
>
>
> ___
> Mai

Re: [Kicad-developers] eeschema Save

[Andrey Kuznetsov]

What is the problem with saving ALL schematics in the project that have
been edited, whether it's a 1 sheet or heirarchy sheet project?
Are there times when you only want to save that sheet but not the other
sheets? If yes, then maybe add 2 save buttons, save and save all, if not
then just the save all button

I am against using schematic icon with a disk, too much complexity!

You should simply use:
Disk icon for Save
and/or
Multi-Disk icon for Save All

There is no purpose in indicating that you want to save a schematic in a
schematic application when calling for a Save.

On Sat, Jan 13, 2018 at 3:15 AM, Jeff Young  wrote:

> The eeschema Save button’s tooltip reads “save schematic *project*”
> (emphasis mine).  Because of that, it got the
> project-with-superimposed-disk in the recent icon update.  I don’t think
> either of those is optimal.
>
> There are 3 distinct concepts:
>
> 1) Kicad projects (containing schematics, PCBs, gerbers, etc.)
> 2) A hierarchy of schematic sheets
> 3) A single schematic sheet
>
> The differentiation between (2) and (3) is a bit confusing because the
> eeschema window only deals with (2) while we represent schemas in the
> file-system at (3).
>
> But we should make every effort not to conflate (1) with (2).  I think the
> word “project” should be reserved for use in the context of (1).
>
> So I can see 4 options for the eeschema Save option:
>
> a) sidestep the issue and go with the arrow-to-disk icon (a la pcbnew)
> b) use a schematic-with-superimposed-disk icon
> c) use a stacked-schematic-with-superimposed-disk icon (a la the
> hierarchical-sheet-tool icon)
> d) context-sensitive schematic or stacked-schematic icon
>
> And a few for the tooltip:
>
> i) use “save all schematics in hierarchy”
> ii) use “save schematic(s)”
> iii) make it context-sensitive, reading either “save schematic” or “save
> all schematics in hierarchy”
>
> Personally, I think context-sensitivity is appropriate for the tool-tip,
> but not the icon.  So I’d be inclined to go with (b) or (c) and (iii).
>
> As an aside, project files (*.pro) are still using the application icon,
> rather than the Project icon.  That makes the New Project / New Project
> from Template / Open Project icons harder to understand.
>
> Cheers,
> Jeff.
>
> BTW: I’m happy to help fix up any of these issues….
>
> ___
> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Libedit and Modedit Icons

[Andrey Kuznetsov]

Awesome, thanks!

Looks good.

On Thu, Jan 11, 2018 at 7:27 PM Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Andrey,
>
> Here's all I can provide currently (at work!)
>
> [image: Inline image 1]
>
> I have sent the entire patch to Wayne and JP privately so the merging is
> now in their capable hands :)
>
> On Fri, Jan 12, 2018 at 2:20 PM, Andrey Kuznetsov <kandre...@gmail.com>
> wrote:
>
>> Also the attached image of the final icon set was discarded, can you
>> please resend the final icon image set?
>>
>> Thank you
>>
>> On Thu, Jan 11, 2018 at 8:35 AM, jp charras <jp.char...@wanadoo.fr>
>> wrote:
>>
>>> Le 11/01/2018 à 08:54, Oliver Walters a écrit :
>>> > Wayne,
>>> >
>>> > I have taken further suggestions and final icon set is shown below:
>>> >
>>> > [image: Inline image 1]
>>> >
>>> > The attached patch incorporates all of the icon changes thus far
>>> > implemented.
>>> >
>>> > Thanks,
>>> > Oliver
>>> >
>>>
>>> Oliver,
>>>
>>> For some unknown reason, your mail was blocked by Launchpad.
>>> And the attached patch was discarded.
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the
>> future [JFK]
>>
>> kandre...@gmail.com
>> Live Long and Prosper,
>> Andrey
>>
>
> --
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Hotkeys Editor

[Andrey Kuznetsov]

If that would be the intended functionality, then I'd suggest "Reset
Selected" instead of "Reset".

On Thu, Jan 11, 2018 at 5:01 AM, yann jautard  wrote:

> what about  keeping four buttons :
>
> *Defaults* that reset all hotkeys *of the current tab* to default
>
> *Reset* that reset *the selected* hotkey only to default
>
> *Cancel* that close the window and undo the current changes
>
> *Save* that close the window and save the current changes
>
>
> With a tooltip when getting the mouse over each button that clearly says
> this.
>
>
>
> On 11/01/2018 13:16, Clemens Koller wrote:
>
>> Hi!
>>
>> On 2018-01-11 02:07, Seth Hillbrand wrote:
>>
>>> I don't recall when this change happened but I'd like any feedback on
>>> whether folks are adverse
>>> to reverting to the 4.0.7 tabbed layout while keeping the "Reset" and
>>> "Defaults" buttons,
>>> that I think are really good additions.
>>>
>> I agree, but I still don't understand why we don't use the huge screen
>> real-estate we have nowadays on our desks and display all of them in one
>> table with i.e. four columns. It would be easy then to check the hotkeys
>> across all tools without changing tabs.
>> The Buttons "Default" might become "Reset all Hotkeys to Kicad's
>> defaults. Are you sure Y/N?"
>> The Buttons "Reset" might become "Reset to previous settings" - but that
>> might simply be the "Cancel" button.
>>
>>
>> The menu entry Help -> List Hotkeys seems redundant to Preferences ->
>> Hotkey Options -> Edit Hotkeys.
>> One of the dialogs might be removed.
>> In the latest-git, the Hotkey '?' doesn't work for me. I get a beep, when
>> I am lucky... usually it is just ignored.
>>
>> In Eeschema, the Help -> List Hotkeys doesn't show the '?'
>> There the Hotkey-Editor can be reached via Preferences -> General Options
>> -> Controls Tab...
>>
>> GUI consistency would improve UX a lot. These are IMO the low-hanging
>> fruits to attract users to use Kicad.
>>
>> Regards,
>>
>> Clemens
>>
>> On 2018-01-11 02:07, Seth Hillbrand wrote:
>>
>>> I feel that there is a usability issue with the current hotkeys editor
>>> that is a regression from the 4.0.7 hotkeys editor.
>>>
>>> I've attached images for both to this message.  The current editor opens
>>> with a tree view that hides the hotkeys below "Common".  Users would be
>>> forgiven for not realizing that there were additional hotkeys specific to
>>> each application -- see current_hotkeys.png
>>>
>>> Previously, the hotkeys were displayed in tabs that were, I think, more
>>> clear -- see prev_hotkeys.png.
>>>
>>> I don't recall when this change happened but I'd like any feedback on
>>> whether folks are adverse to reverting to the 4.0.7 tabbed layout while
>>> keeping the "Reset" and "Defaults" buttons, that I think are really good
>>> additions.
>>>
>>> -S
>>>
>>>
>>> ___
>>> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Libedit and Modedit Icons

[Andrey Kuznetsov]

Also the attached image of the final icon set was discarded, can you please
resend the final icon image set?

Thank you

On Thu, Jan 11, 2018 at 8:35 AM, jp charras  wrote:

> Le 11/01/2018 à 08:54, Oliver Walters a écrit :
> > Wayne,
> >
> > I have taken further suggestions and final icon set is shown below:
> >
> > [image: Inline image 1]
> >
> > The attached patch incorporates all of the icon changes thus far
> > implemented.
> >
> > Thanks,
> > Oliver
> >
>
> Oliver,
>
> For some unknown reason, your mail was blocked by Launchpad.
> And the attached patch was discarded.
>
>
> --
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] desired layer sequence for pcb technical layers

[Andrey Kuznetsov]

Actually, programs like Altium and Allegro allow you to swap the order of
layers, to change visibility of transparent layers.
For example, make back layer have higher priority, and front layer lower
priority, with the back layer setting to 50% transparency, etc.

But I guess this layer manager is going to be in v6?

On Thu, Jan 11, 2018 at 11:19 AM, Jon Evans <j...@craftyjon.com> wrote:

> Yes, in the KiCad codebase, they are called Front and Back, and my
> question is independent of whether or not they should be called Top and
> Bottom :-)
>
> On Thu, Jan 11, 2018 at 2:16 PM, Diego Herranz <
> diegoherr...@diegoherranz.com> wrote:
>
>> Regarding Front vs Top, I see it called Top everywhere else, but back to
>> the original question: +1 for Top/Front first.
>>
>> Thanks,
>> Diego
>>
>> On Thu, Jan 11, 2018 at 5:52 AM, Andrey Kuznetsov <kandre...@gmail.com>
>> wrote:
>>
>>> Why is it Front and Back, as opposed to Top and Bottom?
>>> Front/Top should be first.
>>>
>>> On Wed, Jan 10, 2018 at 8:50 PM, Jon Evans <j...@craftyjon.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Right now, we have conflicting "desired order" for technical layers in
>>>> various places.
>>>>
>>>> The layer widget displays "front first", i.e. F.Paste before B.Paste,
>>>> F.Fab before B.Fab, etc.
>>>>
>>>> Everywhere else in the codebase is "back first".
>>>> This leads to this bug: https://bugs.launchpad.net/kicad/+bug/1673792
>>>> because the properties dialog is using LSET::UIOrder() which uses the
>>>> "preferred" back first ordering.
>>>>
>>>> Which way should we actually have it?  "front first" makes sense to me,
>>>> and that is the precedent set in the most user-visible part (the layer
>>>> manager) but then why in LSET::Technicals() is there a comment saying the
>>>> desired order is "back first"?
>>>>
>>>> -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
>>>>
>>>>
>>>
>>>
>>> --
>>> Remember The Past, Live The Present, Change The Future
>>> Those who look only to the past or the present are certain to miss the
>>> future [JFK]
>>>
>>> kandre...@gmail.com
>>> Live Long and Prosper,
>>> Andrey
>>>
>>> ___
>>> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Hotkeys Editor

[Andrey Kuznetsov]

I wonder if "Undo All" is more appropriate if all the changes during that
session are undone, as opposed to just the last one.

On Thu, Jan 11, 2018 at 12:35 AM, Thomas Kindler 
wrote:

>
> On Thu, January 11, 2018 02:07, Seth Hillbrand wrote:
> > I feel that there is a usability issue with the current hotkeys editor
> > that is a regression from the 4.0.7 hotkeys editor.
> >
> > I've attached images for both to this message.  The current editor opens
> > with a tree view that hides the hotkeys below "Common".  Users would be
> > forgiven for not realizing that there were additional hotkeys specific to
> >  each application -- see current_hotkeys.png
> >
> > Previously, the hotkeys were displayed in tabs that were, I think, more
> > clear -- see prev_hotkeys.png.
> >
> > I don't recall when this change happened but I'd like any feedback on
> > whether folks are adverse to reverting to the 4.0.7 tabbed layout while
> > keeping the "Reset" and "Defaults" buttons, that I think are really good
> > additions.
>
> What's the difference between "Reset" and "Defaults"?
>
> I think "Undo" and "Defaults" would be much better.
>
> --
> Thomas Kindler 
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Libedit and Modedit Icons

[Andrey Kuznetsov]

I agree on Calculator revert, Bitmap revert, keeping the new GBR icon
(looks really nice).

On Wed, Jan 10, 2018 at 7:47 AM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> Practially I would read this as:
>
> Go back to the single calculator icon, instead of the +-= boxes.
> Revert the camera icon to the "a" character, cleanup if wanted but dont
> change concept fundamentally.
>
> Otherwise I went throught the old icons in my current build and checked
> them against the latest email. They are pretty similar, but much more
> polished and coherent, so I think that qualifies as being inside scope.
>
> I like the gerber icon change, but that one, dont know if it is outside
> scope or not.
>
> Wayne did i interpret correctly?
>
>  -Kristoffer
>
>
> On 01/10/2018 03:58 PM, Wayne Stambaugh wrote:
>
>> I see scope creep happening here.  I thought the original goal was to
>> make some minor tweaks to our existing icons not wholesale replacement
>> of the them.  I don't like the camera either.  I'm not a big fan of the
>> calculator icon.  Both of these icons looks completely out of place with
>> our other icons.  Please keep the scope of these changes in check.  If
>> we want to discuss an entirely new icon theme for v6, that's fine at the
>> appropriate time but not for v5.
>>
>> On 1/10/2018 9:42 AM, Jeff Young wrote:
>>
>>> Splendid!
>>>
>>> Although I agree with Kristoffer that the new bitmap2component icon
>>> isn’t much help.  Import/Export is the one area where we’ve kept the
>>> arrows (which I think is fine).  Given that, the pixelated “a” with an
>>> import arrow would be perfect.
>>>
>>> FWIW, this is one area where I disagree with Nick.  I did user interface
>>> design and software architecture for Adobe for 25 years and in my
>>> professional opinion, these icons are a HUGE improvement.
>>>
>>> Cheers,
>>> Jeff
>>>
>>>
>>> On 10 Jan 2018, at 14:28, Oliver Walters
 > wrote:

  Also, would it be too much to ask for getting the arrows, the
  diskette and the folder in the repo with the patch, basically if
  someone wants to create future icons. They could use the same
  arrows for any kind of export, import, save, inspect or view.


 I have created a set of "common icons" for exactly this purpose :)

 On Thu, Jan 11, 2018 at 1:27 AM, Kristoffer Ödmark
 >
 wrote:

  Wow, really nice! Although, the icon for the bitmap2component
  basically looks like a screenshot symbol to me, or something
  related to a webcam.

  The old one isnt as polished, but I think it fits better.

  Also, would it be too much to ask for getting the arrows, the
  diskette and the folder in the repo with the patch, basically if
  someone wants to create future icons. They could use the same
  arrows for any kind of export, import, save, inspect or view.

  Basically to help get a icon theme thing going ;)



   -Kristoffer


  On 01/10/2018 03:13 PM, Oliver Walters wrote:

  Wayne,

  Here is the outcome of removing the save / load arrows and
  replacing with
  standard load / save icons.

  I have also further tweaked the main icons as per suggestions.

  Screenshots here:

  https://imgur.com/a/DzZhZ

  This is about as far as I want to go with this, please let me
  know if there
  are any outstanding issues that prevent me from submitting a
  patch.

  Thanks,
  Oliver

  On Wed, Jan 10, 2018 at 8:09 AM, Oliver Walters <
  oliver.henry.walt...@gmail.com
  > wrote:

  Ok, that's good to hear. I will take another look at the
  Gerber icons and
  otherwise see if anyone can suggest some simple clean
  replacements for the
  arrows. If not, I'll push a patch.

  On Wed, Jan 10, 2018 at 8:05 AM, Wayne Stambaugh
  >
  wrote:

  One good thing about bitmaps is they are low risk
  (other than the
  complaining that will surely ensue) so we can merge
  them just about any
  time.  I don't want to wait too long so our doc images
  can be updated to
  reflect the changes so if we cannot come up with
  better alternatives to
  replace the arrows, I'm OK with leaving them as is 

Re: [Kicad-developers] Libedit and Modedit Icons

[Andrey Kuznetsov]

One more thing about the current lib icon, why are the books/binders of
different height?
Do not use yellow objects on white backgrounds in icon, yellow is almost
always invisible.

On Sun, Jan 7, 2018 at 1:39 PM, Vesa Solonen <vesa.solo...@aalto.fi> wrote:

> Andrey Kuznetsov kirjoitti 07/01/18 klo 22:51:
>
> > The problem I had with the library icon is that there are only 2 books,
> and
> > a ruler, that's what it looks like to me, and the 2 books are stacked
> using
> > a weird tilt angle, usually you'd expect the books to be stacked straight
>
> To me they look perfectly fine bunch of files thrown on a shelf without
> side support. The one that is tilted is just not full yet and has bad
> balance as result (BTW they would fall that way too...). Neat stack
> example [1] and less neat (but wrong tilt direction) [2].
>
> Oh the joys of bikeshedding, but do they really need change for the sake
> of just change? File browser icons are quite a coherent set.
>
> -Vesa
>
>
> [1]
> http://www.ekmansystems.fi/1479-large_default/no-kansio-
> plastimap-a47punainen--120280no.jpg
>
> [2]
> https://www.shutterstock.com/fi/image-vector/documentation-
> folders-icon-flat-style-isolated-486347626
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Libedit and Modedit Icons

[Andrey Kuznetsov]

Hi Wayne,

The problem I had with the library icon is that there are only 2 books, and
a ruler, that's what it looks like to me, and the 2 books are stacked using
a weird tilt angle, usually you'd expect the books to be stacked straight
on the left side, and the book on the right to be tilted into the books on
the left. It's the opposite in the current icon.

Plenty of book icons online to draw inspiration from, or even creative
commons:
https://www.google.com/search?q=library+book+icon go to images

On Sun, Jan 7, 2018 at 12:45 PM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> My project leader hat is getting a workout today.  Here is what I would
> like to see:
>
> Revert the libedit and modedit icons without pencils since we are doing
> away with whole pencil idea.  The original blueprint concept for these
> icons was clever but they ended up looking a bit busy and didn't really
> fit in with the rest of our icons.
>
> Remove the magnifying glass from the appropriate icons since it is in
> the same vein as the pencil.
>
> Use the gerber file file extension (gbr) on the gerbview icon if we must
> use any text.  I'm still not convinced that this is the best solution
> but I can't think of a better idea off the top of my head.
>
> Please consider muting the green of the board editor icon.  From the
> images I've seen the bright green is a bit harsh.  Maybe a slightly
> darker shade of green would be better.  I've looked a hundreds of green
> PCBs in my career and I don't ever remember any of them hurting my eyes.
>
> As for the library icons, I'm fine with those.  If you stack the books
> neatly, would they still look like books?  I'm guessing they wouldn't
> but if someone can come up with an orderly book icon than I'm OK with that.
>
> Cheers,
>
> Wayne
>
>
> On 01/07/2018 01:43 PM, Andrey Kuznetsov wrote:
> > I think GBR might be confusing since Gerber has 2 Rs, why not GRB, see
> > what I mean? I know it's the file extension .gbr, but how many new
> > people will figure it out easily? I think "Gerb" would be much better,
> > besides, the older existing icons use LM2902-N, etc in the icon and
> > that's still readable by me on 1080p with regular DPI, so Gerb would
> > definitely fit.
> >
> > I think 3-4 letters on the icons would definitely help, like Krisoffer
> > suggested.
> >
> > On Sun, Jan 7, 2018 at 1:59 AM, Jeff Young <j...@rokeby.ie
> > <mailto:j...@rokeby.ie>> wrote:
> >
> > +1 to eeschema icon changes
> >
> > +1 to reverting libedit and modedit, but with no pencils
> >
> > +1 to no magnifying glass  (the drill file, net and BOM icons all
> > have three letters on them; I’m sure GBR would fit on the gerber
> icon)
> >
> > I still think we need to change the project icon in the navigation
> > to something similar to the New Project icons (instead of the
> > application icon).
> >
> > Kudos to Oliver for spear-heading this.
> >
> > Cheers,
> > Jeff.
> >
> >
> >> On 7 Jan 2018, at 08:32, Andrey Kuznetsov <kandre...@gmail.com
> >> <mailto:kandre...@gmail.com>> wrote:
> >>
> >> I agree, no pencils, no magnifying glass.
> >>
> >> By the way, anyone else thinks the .lib file icons in the
> >> navigation looks weird? If it's meant to look like a few stacked
> >> books, why are they tilted in weird directions?
> >>
> >> On Sun, Jan 7, 2018 at 12:26 AM, Simon Wells <swel...@gmail.com
> >> <mailto:swel...@gmail.com>> wrote:
> >>
> >> if the modedit/libedit icons are to be reverted then i believe
> >> the pencils should be removed, seeing as they were used to
> >> portray edit i believe but now that pcbnew/eeschema don’t have
> >> them they just seem odd
> >>
> >>> On 7/01/2018, at 2:28 PM, Nick Østergaard <oe.n...@gmail.com
> >>> <mailto:oe.n...@gmail.com>> wrote:
> >>>
> >>> I have been intending to revert the annotate icon in eeschema
> >>> to the old one, which made much more sense to me thatn the
> >>> current one.
> >>>
> >>> 2018-01-07 1:24 GMT+01:00 Oliver Walters
> >>> <oliver.henry.walt...@gmail.com
> >>> <mailto:oliver.henry.walt...@gmail.com>>:
> >>>
> >>> I have attached a patchset which performs the following:
> >>>
> >>>

Re: [Kicad-developers] Via dialog to support

[Andrey Kuznetsov]

Thanks for clarifying.

On Sun, Jan 7, 2018 at 10:47 AM, jp charras <jp.char...@wanadoo.fr> wrote:

> Le 07/01/2018 à 19:34, Andrey Kuznetsov a écrit :
> > Should kicad not impose 2 layer restrictions on blind/buried vias? That
> way users could at least use
> > them, but will have to manually be careful since DRC doesn't support it.
> There could be 2
> > blind/buried vias on top of each other vertically, but on different
> layers and not touching.
> > And have unlimited adjacent layer selection, from<->to.
> >
>
> There are no restriction for blind/buried vias.
> Just the DRC does not test for valid layers pairs, because there are no
> layer stackup manager in
> Pcbnew, and therefore the user cannot define constraints for blind/buried
> vias.
>
>
> --
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Libedit and Modedit Icons

[Andrey Kuznetsov]

I think GBR might be confusing since Gerber has 2 Rs, why not GRB, see what
I mean? I know it's the file extension .gbr, but how many new people will
figure it out easily? I think "Gerb" would be much better, besides, the
older existing icons use LM2902-N, etc in the icon and that's still
readable by me on 1080p with regular DPI, so Gerb would definitely fit.

I think 3-4 letters on the icons would definitely help, like Krisoffer
suggested.

On Sun, Jan 7, 2018 at 1:59 AM, Jeff Young <j...@rokeby.ie> wrote:

> +1 to eeschema icon changes
>
> +1 to reverting libedit and modedit, but with no pencils
>
> +1 to no magnifying glass  (the drill file, net and BOM icons all have
> three letters on them; I’m sure GBR would fit on the gerber icon)
>
> I still think we need to change the project icon in the navigation to
> something similar to the New Project icons (instead of the application
> icon).
>
> Kudos to Oliver for spear-heading this.
>
> Cheers,
> Jeff.
>
>
> On 7 Jan 2018, at 08:32, Andrey Kuznetsov <kandre...@gmail.com> wrote:
>
> I agree, no pencils, no magnifying glass.
>
> By the way, anyone else thinks the .lib file icons in the navigation looks
> weird? If it's meant to look like a few stacked books, why are they tilted
> in weird directions?
>
> On Sun, Jan 7, 2018 at 12:26 AM, Simon Wells <swel...@gmail.com> wrote:
>
>> if the modedit/libedit icons are to be reverted then i believe the
>> pencils should be removed, seeing as they were used to portray edit i
>> believe but now that pcbnew/eeschema don’t have them they just seem odd
>>
>> On 7/01/2018, at 2:28 PM, Nick Østergaard <oe.n...@gmail.com> wrote:
>>
>> I have been intending to revert the annotate icon in eeschema to the old
>> one, which made much more sense to me thatn the current one.
>>
>> 2018-01-07 1:24 GMT+01:00 Oliver Walters <oliver.henry.walt...@gmail.com>
>> :
>>
>>> I have attached a patchset which performs the following:
>>>
>>> 1. Revert libedit icon to previous version
>>> 2. Revert modedit icon to previous version
>>> 3. Updates pcbnew icon to look more like a PCB
>>> 4. Update colors of eeschema icon
>>> 5. Various (almost imperceptible) tweaks to a number of icons to fix
>>> graphic alignment issues
>>>
>>> Here is a screenshot of the updated icons:
>>>
>>>
>>> 
>>>
>>>
>>> 
>>>
>>> On Sun, Jan 7, 2018 at 8:34 AM, Oliver Walters <
>>> oliver.henry.walt...@gmail.com> wrote:
>>>
>>>> On 7 Jan 2018 05:04, "Chris Pavlina" <pavlina.ch...@gmail.com> wrote:
>>>>
>>>> I wish we had something resembling a policy for icons. It seems like
>>>> someone always wants to change them. We had decent icons for these
>>>> _before_, and then someone submitted new ones, and they were accepted
>>>> because... I don't know? Many of the new icons are really ambiguous and
>>>> kind of useless. Shouldn't have been merged.
>>>>
>>>>
>>>> This is why I'm pushing for *a* change and not *my* change, I remember
>>>> how the argument went last time, before they were silently merged.
>>>>
>>>> I also note that there is a lack of consistency between similar icons.
>>>> e.g. there are many icons which incorporate an arrow but the style/shape of
>>>> the arrows varies.
>>>>
>>>> For the record, I like these proposed ones. They bring back the ability
>>>> to recognize them at a glance.
>>>>
>>>> On Sat, Jan 06, 2018 at 05:52:49PM +, kristoffer Ödmark wrote:
>>>> > I would love to see improved icons, I still never get used to them so
>>>> i read
>>>> > the tooltip, newer know which one is pcb and which one is module
>>>> editor.
>>>> >
>>>> > Luckily most of the time I only need to double click the kicad_pcb
>>>> file
>>>> > anyway :)
>>>> >
>>>> >
>>>> > On 2018-01-06 15:08, Nick Østergaard wrote:
>>>> > > 2018-01-06 14:15 GMT+01:00 Jeff Young <j...@rokeby.ie
>>>> > > <mailto:j...@rokeby.ie>>:
>>>> > >
>>>> > > +1
>>>> > >
>>>> > > And I like Oliver’s proposed icons.  I’d suggest two further
>>>> > > changes though:
>>>> > >
>>>> > > 1) The schematic icon (which Oliver didn’t change) shoul

Re: [Kicad-developers] Via dialog to support

[Andrey Kuznetsov]

Should kicad not impose 2 layer restrictions on blind/buried vias? That way
users could at least use them, but will have to manually be careful since
DRC doesn't support it. There could be 2 blind/buried vias on top of each
other vertically, but on different layers and not touching.
And have unlimited adjacent layer selection, from<->to.

If it's limited to 2 layers, users wouldn't be able to properly use
blind/buried vias.

On Sun, Jan 7, 2018 at 6:01 AM, jp charras  wrote:

> Le 06/01/2018 à 22:58, kristoffer Ödmark a écrit :
> > I am implementing it now, just a question, what should be the logic
> behind micro vias? Not very
> > familiar with those.
> >
> > Can they go between any number of layers, or only adjecent ones? I will
> treat them like buried vias
> > currently, so that they can go between any two layers.
>
> Micro vias and buried vias have constraints.
> These constraints are highly dependent on board makers but usually these
> vias cannot go between any
> two layers.
>
> micro vias are in fact laser drilled vias, and the hole is not a cylinder,
> but a cone.
> the max depth (Z dimension) depend on the hole diameter.
> If we restrict laser drilled vias to 2 adjacent layers, it should work in
> any case (although a bit
> restrictive).
> This is one of reasons in Pcbnew microvias are only blind vias restricted
> to adjacent layers.
> More than 2 adjacent layers is certainly possible, but only the board
> house can say that.
> Of course standard blind/buried vias have also limitations, and cannot go
> between any layer pair.
>
> For instance, see
> https://www.eurocircuits.com/blog/blind-and-buried-vias/
> and
> https://www.pcbcart.com/pcb-capability/blind-and-buried-vias.html
> for limitation examples.
>
> And keep in mind limitations depends on the board house that will make
> your board.
>
> Currently, Pcbnew is missing a layer stack manager (coming for V6), and a
> dialog via properties
> cannot safely manage the layers pairs of non through hole vias.
>
> Also keep in mind changing a via setup should be tested by the DRC
> (clearance test) and the ratsnest
> rebuild if layers change (or if the size is smaller).
>
> --
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Libedit and Modedit Icons

[Andrey Kuznetsov]

I agree, no pencils, no magnifying glass.

By the way, anyone else thinks the .lib file icons in the navigation looks
weird? If it's meant to look like a few stacked books, why are they tilted
in weird directions?

On Sun, Jan 7, 2018 at 12:26 AM, Simon Wells  wrote:

> if the modedit/libedit icons are to be reverted then i believe the pencils
> should be removed, seeing as they were used to portray edit i believe but
> now that pcbnew/eeschema don’t have them they just seem odd
>
> On 7/01/2018, at 2:28 PM, Nick Østergaard  wrote:
>
> I have been intending to revert the annotate icon in eeschema to the old
> one, which made much more sense to me thatn the current one.
>
> 2018-01-07 1:24 GMT+01:00 Oliver Walters :
>
>> I have attached a patchset which performs the following:
>>
>> 1. Revert libedit icon to previous version
>> 2. Revert modedit icon to previous version
>> 3. Updates pcbnew icon to look more like a PCB
>> 4. Update colors of eeschema icon
>> 5. Various (almost imperceptible) tweaks to a number of icons to fix
>> graphic alignment issues
>>
>> Here is a screenshot of the updated icons:
>>
>>
>> 
>>
>>
>> 
>>
>> On Sun, Jan 7, 2018 at 8:34 AM, Oliver Walters <
>> oliver.henry.walt...@gmail.com> wrote:
>>
>>> On 7 Jan 2018 05:04, "Chris Pavlina"  wrote:
>>>
>>> I wish we had something resembling a policy for icons. It seems like
>>> someone always wants to change them. We had decent icons for these
>>> _before_, and then someone submitted new ones, and they were accepted
>>> because... I don't know? Many of the new icons are really ambiguous and
>>> kind of useless. Shouldn't have been merged.
>>>
>>>
>>> This is why I'm pushing for *a* change and not *my* change, I remember
>>> how the argument went last time, before they were silently merged.
>>>
>>> I also note that there is a lack of consistency between similar icons.
>>> e.g. there are many icons which incorporate an arrow but the style/shape of
>>> the arrows varies.
>>>
>>> For the record, I like these proposed ones. They bring back the ability
>>> to recognize them at a glance.
>>>
>>> On Sat, Jan 06, 2018 at 05:52:49PM +, kristoffer Ödmark wrote:
>>> > I would love to see improved icons, I still never get used to them so
>>> i read
>>> > the tooltip, newer know which one is pcb and which one is module
>>> editor.
>>> >
>>> > Luckily most of the time I only need to double click the kicad_pcb file
>>> > anyway :)
>>> >
>>> >
>>> > On 2018-01-06 15:08, Nick Østergaard wrote:
>>> > > 2018-01-06 14:15 GMT+01:00 Jeff Young >> > > >:
>>> > >
>>> > > +1
>>> > >
>>> > > And I like Oliver’s proposed icons.  I’d suggest two further
>>> > > changes though:
>>> > >
>>> > > 1) The schematic icon (which Oliver didn’t change) should really
>>> > > use the default colours (dark red symbols, green wires).  Then
>>> > > there’s a stronger tie-in with the libedit icon.
>>> > >
>>> > > 2) I think I’d drop the dimensions from the modedit icon, and
>>> > > change the pad colour to the default (yellow).
>>> > >
>>> > >
>>> > > The default pad color is not yellow, that is only what you see for
>>> THT
>>> > > pads. Default pad color is green for bottom and red for top copper
>>> > >
>>> > >
>>> > > 3) Projects should use the current New Project icon, rather than
>>> > > the application icon.
>>> > >
>>> > >
>>> > > I have considered to submit a patch for this for some time, but I
>>> guess
>>> > > it is an appropiate time to do this with a major version bump.
>>> > >
>>> > >
>>> > > 4) Both the New Project and New Project from Template icons
>>> should
>>> > > get yellow “new” star.
>>> > >
>>> > > 5) New Footprint in modedit also needs the star, and the star on
>>> > > New Symbol in libedit made more prominent.
>>> > >
>>> > > Cheers,
>>> > > Jeff.
>>> > >
>>> > >
>>> > > > On 6 Jan 2018, at 12:30, Oliver Walters
>>> > > > >> > > > > wrote:
>>> > > >
>>> > > > I think there is a need to tweak the libedit and modedit icons,
>>> > > > as identified below:
>>> > > >
>>> > > > 
>>> > > >
>>> > > > 
>>> > > >
>>> > > > 1. The blue 'textured' background is out of place with the
>>> other
>>> > > > icons
>>> > > > 2. They are very cluttered and hard to read
>>> > > > 3. Weirdly specific callout of dimensions and part names (out
>>> of
>>> > > > character with other icons)
>>> > > >
>>> > > > Further, I think that the pcbnew icon could be adjusted
>>> slightly
>>> > > > to make it look a bit more like a PCB
>>> > > >
>>> > > > Even as someone who uses KiCad on a regular basis I find myself
>>> > > > double checking which icon I am about to click on (and still
>>> > > > getting it wrong half of the time).
>>> > > >
>>> > > > 

Re: [Kicad-developers] Libedit and Modedit Icons

[Andrey Kuznetsov]

You can put "Gerb" in the top 1/5th of the icon just fine, and shrink the
black and white sheets a little bit to make it fit.

On Sat, Jan 6, 2018 at 5:08 PM, Chris Pavlina <pavlina.ch...@gmail.com>
wrote:

> On Sun, Jan 07, 2018 at 01:01:08AM +0000, Andrey Kuznetsov wrote:
> > FYI, the 5th and last icons from the left do not convey what they are
> about.
> >
> > Perhaps you could add the word "Gerber" at the top portion of the icon
> and
> > remove that stupid magnifying glass.
>
> I agree, remove the magnifying glass and hand it to me --- I'll need it
> to read the full words you want in the icons...
>
> >
> > The worksheet layout shouldn't have a schematic in gray color in it, why
> is
> > there a schematic in an empty worksheet layout editor? It's not a
> schematic
> > editor...
> > I'm not sure what the best icon would look like to represent a worksheet
> > layout editor.
> >
> > On Sat, Jan 6, 2018 at 4:24 PM, Oliver Walters <
> > oliver.henry.walt...@gmail.com> wrote:
> >
> > > I have attached a patchset which performs the following:
> > >
> > > 1. Revert libedit icon to previous version
> > > 2. Revert modedit icon to previous version
> > > 3. Updates pcbnew icon to look more like a PCB
> > > 4. Update colors of eeschema icon
> > > 5. Various (almost imperceptible) tweaks to a number of icons to fix
> > > graphic alignment issues
> > >
> > > Here is a screenshot of the updated icons:
> > >
> > >
> > > [image: Inline image 2]
> > >
> > >
> > > [image: Inline image 1]
> > >
> > > On Sun, Jan 7, 2018 at 8:34 AM, Oliver Walters <
> > > oliver.henry.walt...@gmail.com> wrote:
> > >
> > >> On 7 Jan 2018 05:04, "Chris Pavlina" <pavlina.ch...@gmail.com> wrote:
> > >>
> > >> I wish we had something resembling a policy for icons. It seems like
> > >> someone always wants to change them. We had decent icons for these
> > >> _before_, and then someone submitted new ones, and they were accepted
> > >> because... I don't know? Many of the new icons are really ambiguous
> and
> > >> kind of useless. Shouldn't have been merged.
> > >>
> > >>
> > >> This is why I'm pushing for *a* change and not *my* change, I remember
> > >> how the argument went last time, before they were silently merged.
> > >>
> > >> I also note that there is a lack of consistency between similar icons.
> > >> e.g. there are many icons which incorporate an arrow but the
> style/shape of
> > >> the arrows varies.
> > >>
> > >> For the record, I like these proposed ones. They bring back the
> ability
> > >> to recognize them at a glance.
> > >>
> > >> On Sat, Jan 06, 2018 at 05:52:49PM +, kristoffer Ödmark wrote:
> > >> > I would love to see improved icons, I still never get used to them
> so i
> > >> read
> > >> > the tooltip, newer know which one is pcb and which one is module
> editor.
> > >> >
> > >> > Luckily most of the time I only need to double click the kicad_pcb
> file
> > >> > anyway :)
> > >> >
> > >> >
> > >> > On 2018-01-06 15:08, Nick Østergaard wrote:
> > >> > > 2018-01-06 14:15 GMT+01:00 Jeff Young <j...@rokeby.ie
> > >> > > <mailto:j...@rokeby.ie>>:
> > >> > >
> > >> > > +1
> > >> > >
> > >> > > And I like Oliver’s proposed icons.  I’d suggest two further
> > >> > > changes though:
> > >> > >
> > >> > > 1) The schematic icon (which Oliver didn’t change) should
> really
> > >> > > use the default colours (dark red symbols, green wires).  Then
> > >> > > there’s a stronger tie-in with the libedit icon.
> > >> > >
> > >> > > 2) I think I’d drop the dimensions from the modedit icon, and
> > >> > > change the pad colour to the default (yellow).
> > >> > >
> > >> > >
> > >> > > The default pad color is not yellow, that is only what you see
> for THT
> > >> > > pads. Default pad color is green for bottom and red for top copper
> > >> > >
> > >> > >
> > >> > > 3) Projects shoul

Re: [Kicad-developers] Libedit and Modedit Icons

[Andrey Kuznetsov]

FYI, the 5th and last icons from the left do not convey what they are about.

Perhaps you could add the word "Gerber" at the top portion of the icon and
remove that stupid magnifying glass.

The worksheet layout shouldn't have a schematic in gray color in it, why is
there a schematic in an empty worksheet layout editor? It's not a schematic
editor...
I'm not sure what the best icon would look like to represent a worksheet
layout editor.

On Sat, Jan 6, 2018 at 4:24 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> I have attached a patchset which performs the following:
>
> 1. Revert libedit icon to previous version
> 2. Revert modedit icon to previous version
> 3. Updates pcbnew icon to look more like a PCB
> 4. Update colors of eeschema icon
> 5. Various (almost imperceptible) tweaks to a number of icons to fix
> graphic alignment issues
>
> Here is a screenshot of the updated icons:
>
>
> [image: Inline image 2]
>
>
> [image: Inline image 1]
>
> On Sun, Jan 7, 2018 at 8:34 AM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> On 7 Jan 2018 05:04, "Chris Pavlina"  wrote:
>>
>> I wish we had something resembling a policy for icons. It seems like
>> someone always wants to change them. We had decent icons for these
>> _before_, and then someone submitted new ones, and they were accepted
>> because... I don't know? Many of the new icons are really ambiguous and
>> kind of useless. Shouldn't have been merged.
>>
>>
>> This is why I'm pushing for *a* change and not *my* change, I remember
>> how the argument went last time, before they were silently merged.
>>
>> I also note that there is a lack of consistency between similar icons.
>> e.g. there are many icons which incorporate an arrow but the style/shape of
>> the arrows varies.
>>
>> For the record, I like these proposed ones. They bring back the ability
>> to recognize them at a glance.
>>
>> On Sat, Jan 06, 2018 at 05:52:49PM +, kristoffer Ödmark wrote:
>> > I would love to see improved icons, I still never get used to them so i
>> read
>> > the tooltip, newer know which one is pcb and which one is module editor.
>> >
>> > Luckily most of the time I only need to double click the kicad_pcb file
>> > anyway :)
>> >
>> >
>> > On 2018-01-06 15:08, Nick Østergaard wrote:
>> > > 2018-01-06 14:15 GMT+01:00 Jeff Young > > > >:
>> > >
>> > > +1
>> > >
>> > > And I like Oliver’s proposed icons.  I’d suggest two further
>> > > changes though:
>> > >
>> > > 1) The schematic icon (which Oliver didn’t change) should really
>> > > use the default colours (dark red symbols, green wires).  Then
>> > > there’s a stronger tie-in with the libedit icon.
>> > >
>> > > 2) I think I’d drop the dimensions from the modedit icon, and
>> > > change the pad colour to the default (yellow).
>> > >
>> > >
>> > > The default pad color is not yellow, that is only what you see for THT
>> > > pads. Default pad color is green for bottom and red for top copper
>> > >
>> > >
>> > > 3) Projects should use the current New Project icon, rather than
>> > > the application icon.
>> > >
>> > >
>> > > I have considered to submit a patch for this for some time, but I
>> guess
>> > > it is an appropiate time to do this with a major version bump.
>> > >
>> > >
>> > > 4) Both the New Project and New Project from Template icons should
>> > > get yellow “new” star.
>> > >
>> > > 5) New Footprint in modedit also needs the star, and the star on
>> > > New Symbol in libedit made more prominent.
>> > >
>> > > Cheers,
>> > > Jeff.
>> > >
>> > >
>> > > > On 6 Jan 2018, at 12:30, Oliver Walters
>> > > > > > > > > wrote:
>> > > >
>> > > > I think there is a need to tweak the libedit and modedit icons,
>> > > > as identified below:
>> > > >
>> > > > 
>> > > >
>> > > > 
>> > > >
>> > > > 1. The blue 'textured' background is out of place with the other
>> > > > icons
>> > > > 2. They are very cluttered and hard to read
>> > > > 3. Weirdly specific callout of dimensions and part names (out of
>> > > > character with other icons)
>> > > >
>> > > > Further, I think that the pcbnew icon could be adjusted slightly
>> > > > to make it look a bit more like a PCB
>> > > >
>> > > > Even as someone who uses KiCad on a regular basis I find myself
>> > > > double checking which icon I am about to click on (and still
>> > > > getting it wrong half of the time).
>> > > >
>> > > > Below is a /**suggestion**/ of some improvements. I am not
>> trying
>> > > > to back my own horse here, I'd be happy for anyone else to
>> > > > suggest a better design for any of these. But I feel that
>> > > > changing these icons would be a good improvement to make before
>> > > > the v5 release. There have been many people complaining 

Re: [Kicad-developers] [PATCH] Wire-bus entry dangling points

[Andrey Kuznetsov]

Anyone else thinks the green wire bus entries should be blue and the wire
bus entry connection with a wire should have a junction?
>From that image, who is to say the wire and wire-entry, both green, do not
connect to the blue line twice, just look at the triangles that have been
made in the 2nd screenshot.

On Fri, Dec 15, 2017 at 10:15 AM, Seth Hillbrand 
wrote:

> The attached patch adjusts how dangling ends are shown for wire-bus
> entries to correct the behavior Nick reported.
>
> Previously, wire-bus entries were shown as dangling if there was a wire or
> a bus at both ends.  This broke in the case of the Coldfire demo where a
> bus was drawn over a wire and there was also an entry point (see attached
> image coldfire-broken.png).
>
> The patch implements the logic that if there is _at least_ a wire and a
> bus at each end, that the entry is considered not dangling. (see attached
> image coldfire-fixed.png)
>
> -Seth
>
>
> ___
> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] [PATCH] Fix artifacts on touchpad scroll (fixes lp:1735669)

[Andrey Kuznetsov]

Merge to get additional testing please. I can't compile source.

On Wed, Dec 6, 2017 at 4:21 PM, Wayne Stambaugh 
wrote:

> Has anyone else had a chance to test this or should I just merge it to
> get additional testing?
>
> On 12/04/2017 07:45 PM, Seth Hillbrand wrote:
> > ​This fixes artifacts remaining on the screen when touchpad scrolling is
> > enabled.
> > https://bugs.launchpad.net/kicad/+bug/1735669
> >
> > The attached patch is tested on MacOS and Linux.  Could someone with a
> > Windows laptop check that the performance of touchpad scrolling is not
> > affected?
> >
> > Thanks!
> > Seth
> >
> >
> > ___
> > 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Zone filling & display speed improvements

[Andrey Kuznetsov]

Stay consistent, no heuristics for formats.
If it's slow on your machine, that doesn't mean it won't be fast on mine,
and you other points about version control make sense.
Do not store things like this, makes it hard on checkin.

On Mon, Dec 4, 2017 at 7:48 PM, Henner Zeller  wrote:

> On 4 December 2017 at 16:41, Tomasz Wlostowski
>  wrote:
> > On 04/12/17 15:43, Henner Zeller wrote:
> >> On 4 December 2017 at 06:31, Tomasz Wlostowski
> >>  wrote:
> >>> On 04/12/17 02:05, Henner Zeller wrote:
>  On 2 December 2017 at 10:11, Henner Zeller  wrote:
> > On 1 December 2017 at 08:12, Tomasz Wlostowski
> >  wrote:
> >> On 29/11/17 16:10, jp charras wrote:
> >>> I am using a few board in Kicad demos: interf_u, video,
> pic_programmer.
> >>>
> >>> Also, filled areas are no shown in OpenGL, but are shown in Cairo
> canvas.
> >>
> >> Hi all,
> >>
> >> The branch [1] contains a set of improvements in the zone filling
> >> algorithm. It's several times faster than in the current master
> branch.
> >>
> >> I'd like to merge it soon and move on to fixing P issues pending
> for
> >> the V5 - I'll greatly appreciate testing and feedback!
> >
> > Hi Tom,
> >
> > I'll compile your branch hopefully later this weekend for testing.
> > If you need another board for testing, I am currently having a board
> > that takes annoying several seconds to fill the zones in head KiCad,
> > which hence might be interesting test case:
> >>>
> >>> Hi Henner,
> >>>
> >>> What OS did you build for?
> >>
> >> This was on Debian testing on a x86_64 machine.
> >> g++ 7.2.0, Cairo: 1.15.8, boost 1.62.0
> >>
> >> -h
> >
> > Hi guys,
> >
> > Now it should work fine - the filling algorithm was not thread safe and
> > apparently wxProgressDialog can't be invoked from non-main thread.
> >
> > Check out the updated branch.
>
> Thanks Tom!
>
> Nice, the [tom-faster-zones-dec01] branch works well and very fast. I
> have not seen any crashes anymore.
>
> There is a leftover method mentioned in pcbnew/class_zone.h:
>   void RemoveInsulatedCopperIslands()
> .. which is not used/implemented so should be removed from the header.
>
> One thing I noticed: since it is sooo fast now, the progress-popup is
> actually quite annoying as it just briefly blinks up and vanishes
> again (at least for the board I was testing it with). Maybe it should
> only show up if the operation is still ongoing after a second and less
> than 50% is done at that time ?
>
> Another thought: if zone filling can be that fast, maybe we should
> only store zone outlines in the *.kicad_pcb file, not the
> (filled_polygon ...) that are now also stored. It is cheap to just
> recreate them when loading the file.
> Backround: This can save a lot of disk space as the filled polygons
> tend to create a lot of points and tend to completely change with tiny
> changes to other elements on the board, such as a moved via. This
> means that version control has to store huge changes every time and it
> is hard to see what actual changes are happening just looking at the
> diff (I like to inspect diffs before checking something in, and this
> makes it hard. Also it makes it hard to git merge kicad-pcbs).
> Downside is, that everyone loading a file has to pay the extra cost to
> create the zones (e.g. gerber generation). Maybe it could be a
> heuristic to not store the filled polygons if recreating it takes less
> than a second or so.
>
> Cheers,
>   Henner.
>
> >
> > Thanks!
> > 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] [PATCH] Reset tool transitions even when already active (Fixes lp:1733224)

[Andrey Kuznetsov]

Possibly also related to this: https://bugs.launchpad.net/kicad/+bug/1678575
The shortcut actions are not properly verified against present state
conditions under which they should be allowed to operate under before the
actions are triggered.

On Sun, Nov 26, 2017 at 5:23 PM, Jon Evans  wrote:

> Tom, you might want to take a look at this one.
>
> I was looking into this bug and noticed some odd behavior and I'm not
> quite sure what the intended behavior is: https://bugs.launchpad.net/
> kicad/+bug/1733224
>
> When EDIT_TOOL::Main() is activated by move hotkey, transitions are reset
> and other edit tool actions can be issued (for example, Rotate).  But you
> can also hit M again, which sends another event to start the Main(), and
> since the tool is already active, transitions are not reset.
>
> The attached patch changes this, and seems to work fine, but I'm not sure
> if there is some reason why it was not done this way.
>
> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] GitHub Plugin (my nemesis)

[Andrey Kuznetsov]

Sorry, I was only talking about wrapping the 3D files which can be 100KB to
10MB large.
The other files are small enough.

On Mon, Oct 2, 2017 at 2:38 AM Simon Küppers <simon.kuepp...@rub.de> wrote:

> I am no expert, but this question is out of the scope of this thread.. For
> downloading, gut applies compression anyway.
>
> I respect the people having slow Internet lines.. However as shown a few
> posts backwards, the whole footprints and symbol library is like 100
> megabytes without the 3d models. If think the benefit of a single repo
> outways the ability to download only a selection of libraries... By a LOT.
>
>
>
> Am 2. Oktober 2017 10:22:10 MESZ schrieb Andrey Kuznetsov <
> kandre...@gmail.com>:
>>
>> Is it possible to keep the 3d models ZIPed or RARed on disk and KiCAD
>> unpacks them on the fly as needed/used during the session/etc?
>>
>> I am seeing 10x reduction in size when I pack the files whether they are
>> 7.5MB or 120KB, both were reduced to 750KB and 10KB respectively.
>> That's a lot of space wasted if we're thinking of the poor designers with
>> limited disk space.
>>
>> On Mon, Oct 2, 2017 at 1:03 AM, Carsten Schoenert <
>> c.schoen...@t-online.de> wrote:
>>
>>> Am 02.10.2017 um 06:14 schrieb David Godfrey:
>>> > Bernhard hit the nail on the head here.
>>> > For normal Users, ALL of the git functionality should be hidden behind
>>> > basic KiCad GUI features.
>>>
>>> A "normal" user doesn't need any git functions. He expects to have a
>>> working solution if he is using KiCad or $whatever software. The tricky
>>> part is on the software developers side, they need to take care about
>>> full functional additional components for the normal users.
>>>
>>> > However, for Users and Librarians that want to manage, add, edit at
>>> > least a basic knowledge of whatever tooling is used behind the scenes
>>> is
>>> > a HARD REQUIREMENT.
>>>
>>> Agreed.
>>> But such things are additional extras on the current situation. I guess
>>> the intent of this whole thread was to improve the current situation on
>>> the library handling inside KiCad. I think this should be focused on
>>> first as this increases the usability on the user side significantly.
>>>
>>> > These days git is probably one of the best documented, and most well
>>> > supported in the greater community.
>>> > That alone makes it a very good choice of backend.
>>> >
>>> > Handling of submodules can be slightly tricky, but a few simple helper
>>> > scripts (for LedgerSMB project we use a Makefile with a few targets
>>> such
>>> > as "submodules" which updates all submodules to the current repo head's
>>> > commit references to them)
>>> Mhh, I never have seen that any body is really happy about git
>>> submodules as they are always problematic. The reasons for this are
>>> already written here in this thread.
>>>
>>> I always look at the Linux kernel development model which is quite
>>> larger and bigger than the KiCad project.
>>> All parts in the development there don't use git submoduls for good
>>> reasons. All people involved always use the full tree. Sorry, I don't
>>> see a real need and gain for using git submoduls. And even if you have
>>> some scripting on top you need to teach the people how to use this. That
>>> is *always* overhead I'd avoid.
>>>
>>> As written here also, a complete git repository about all of the
>>> schematics with a stable and development branch and tagged releases
>>> would be fine and enough. The l10n and documentation part is already
>>> using this model.
>>>
>>> --
>>> Regards
>>> Carsten Schoenert
>>>
>>> ___
>>> 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
>>>
>>
>>
>>
>> --
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the
>> future [JFK]
>>
>> kandre...@gmail.com
>> Live Long and Prosper,
>> Andrey
>>
> ___
> 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
>
-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] GitHub Plugin (my nemesis)

[Andrey Kuznetsov]

Is it possible to keep the 3d models ZIPed or RARed on disk and KiCAD
unpacks them on the fly as needed/used during the session/etc?

I am seeing 10x reduction in size when I pack the files whether they are
7.5MB or 120KB, both were reduced to 750KB and 10KB respectively.
That's a lot of space wasted if we're thinking of the poor designers with
limited disk space.

On Mon, Oct 2, 2017 at 1:03 AM, Carsten Schoenert 
wrote:

> Am 02.10.2017 um 06:14 schrieb David Godfrey:
> > Bernhard hit the nail on the head here.
> > For normal Users, ALL of the git functionality should be hidden behind
> > basic KiCad GUI features.
>
> A "normal" user doesn't need any git functions. He expects to have a
> working solution if he is using KiCad or $whatever software. The tricky
> part is on the software developers side, they need to take care about
> full functional additional components for the normal users.
>
> > However, for Users and Librarians that want to manage, add, edit at
> > least a basic knowledge of whatever tooling is used behind the scenes is
> > a HARD REQUIREMENT.
>
> Agreed.
> But such things are additional extras on the current situation. I guess
> the intent of this whole thread was to improve the current situation on
> the library handling inside KiCad. I think this should be focused on
> first as this increases the usability on the user side significantly.
>
> > These days git is probably one of the best documented, and most well
> > supported in the greater community.
> > That alone makes it a very good choice of backend.
> >
> > Handling of submodules can be slightly tricky, but a few simple helper
> > scripts (for LedgerSMB project we use a Makefile with a few targets such
> > as "submodules" which updates all submodules to the current repo head's
> > commit references to them)
> Mhh, I never have seen that any body is really happy about git
> submodules as they are always problematic. The reasons for this are
> already written here in this thread.
>
> I always look at the Linux kernel development model which is quite
> larger and bigger than the KiCad project.
> All parts in the development there don't use git submoduls for good
> reasons. All people involved always use the full tree. Sorry, I don't
> see a real need and gain for using git submoduls. And even if you have
> some scripting on top you need to teach the people how to use this. That
> is *always* overhead I'd avoid.
>
> As written here also, a complete git repository about all of the
> schematics with a stable and development branch and tagged releases
> would be fine and enough. The l10n and documentation part is already
> using this model.
>
> --
> Regards
> Carsten Schoenert
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] [PATCH] Multilayer keepout zones

[Andrey Kuznetsov]

What's the rationale to limiting this to copper layers only?
Why not have it available for all layers?

It's probably unlikely but if a silkscreen pour is made and a keep out is
required, as I understand it, it would make sense not to limit features
necessarily to select layers.

--
Andrey Kuznetsov
kandre...@gmail.com

On Wed, Sep 27, 2017 at 10:10 AM jp charras <jp.char...@wanadoo.fr> wrote:

> Le 26/09/2017 à 18:20, jp charras a écrit :
> > Le 26/09/2017 à 13:47, Wayne Stambaugh a écrit :
> >> Oliver,
> >>
> >> Thanks for making the changes.
> >>
> >> JP,
> >>
> >> Would you please take a look at this patch set when you get a chance.
> >> You are more familiar with the board zone code than I am so you may find
> >> issues that I may have missed.
> >>
> >> Thanks,
> >>
> >> Wayne
> >>
> >
> > I am currently working on it.
> >
>
>
> Hi Oliver,
>
> I just committed your patch, and fixed a few (minor) issues:
> A cosmetic issue in dialog
> A fix to make multilayer keepout zones creation working in legacy mode.
>
> Thanks for your work.
>
> --
> 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
>
-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] [PATCH] Add background color for subsheets

[Andrey Kuznetsov]

I hope there's an option to remove color as well, after color has been
added.

I can't remember, is text color modifiable? If not, that kind of limits the
background color choices.

On Thu, Sep 14, 2017 at 7:22 AM Wayne Stambaugh 
wrote:

> Oliver,
>
> I just tested this patch and I like it.  I would like you to please set
> the default color to COLOR4D::UNSPECIFIED if possible so that no filling
> occurs unless the user selects a color.  It is rather jarring to
> suddenly have all of the sheets in your schematic turn blue.  It might
> also be nice if you could select COLOR4D::UNSPECIFIED in the standard
> color selector for users who prefer no fill on sheets but that could be
> in a separate patch.
>
> Wayne
>
> On 9/12/2017 5:11 AM, Oliver Walters wrote:
> > This small patch adds a configurable background color for hierarchical
> > sheets.
> >
> > Image: http://i.imgur.com/53zgcy9.png
> >
> > 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
>
-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] KiCad Libraries (again)

[Andrey Kuznetsov]

If possible, would be good to have a single full KLC page with all the
rules combined in addition to the individual chapter pages, hopefully using
the same KLC source without having to maintain 2 version.
This is useful when you want to use the browser find functionality instead
of clicking on chapters or when you want to print out the KLC, which
reminds me there should be a revision and last update date time stamp to
the ruleset somewhere at the top of the page of the full KLC ruleset.

--
Andrey


On Thu, Sep 14, 2017 at 5:01 AM Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Hi everyone,
>
> The conversation of how best to manage and distribute KiCad libraries has
> been raging for a while now.
>
> Users looking to download or contribute to the libraries are currently
> presented with a github landing page and some bland wiki pages (e.g. for
> the KLC information).
>
> I have been working on a new-and-improved website system for the following:
>
> * Clear information about the libraries
> * A place to download the latest libraries
> * Information on what is *in* the libraries
> * Instructions on how to contribute to the libs
> * Better presentation of the KLC
>
> This website will need to be updated periodically to present the latest
> version of the libraries to the users. Also, if users are going to be
> downloading library files then it could potentially use a lot of bandwidth.
> Thirdly, the generated content should be scripted but statically hosted.
>
> The solution? GitHub pages! - https://pages.github.com/ -
>
> These are hosted from your github repository, and for e.g. ours would have
> the URL kicad.github.io - this could be easily redirected from
> kicad-lib.org/library (for example).
>
> GitHub pages use the jekyll toolset to generate static content.
>
> With a small amount of additional Python scripting I have created a
> bare-bones example of what this might look like (locally hosted on my
> laptop for now):
>
> Here are some screenshots! Ignore the colors and simple layout scheme,
> this is currently just a framework.
>
> https://imgur.com/a/0GELG
>
> The main objectives of this project are:
>
> a) Present a more professional landing page for the libraries
> b) Leverage GitHub Pages functionality
> c) Improve KLC
>
> And, eventually:
>
> Provide a standardised way to separate the KiCad libraries from the KiCad
> installer!
>
> Thoughts and comments appreciated!
>
> 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
>
-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] [PATCH] Add support for panning with left and right mouse buttons

[Andrey Kuznetsov]

Sorry,  I was talking about the nightly version.

On Wed, Sep 13, 2017 at 12:24 PM Jon Evans <j...@craftyjon.com> wrote:

> Are you using my gerbview_gal branch and testing with gerbview?  That is
> the only place where this feature is enabled.   If you would like to test
> it outside of that branch, change m_panWithRightButton to true and rebuild.
>
> I don't have a Windows laptop to test with at the moment, but I would
> believe that the behavior of trackpads is different -- this will only work
> if (like Apple trackpads) the trackpad translates a "press with two
> fingers, then drag" as a "right button drag" event.
>
> -Jon
>
> On Wed, Sep 13, 2017 at 1:41 PM, Andrey Kuznetsov <kandre...@gmail.com>
> wrote:
>
>> FYI, Regarding panning with 2 fingers, it does not work on my Lenovo
>> laptop running windows 8.
>> Only zoom works, 2 finger up-down motion.
>>
>> On Wed, Sep 13, 2017 at 6:53 AM, Jon Evans <j...@craftyjon.com> wrote:
>>
>>> Hi Orson and Bernhard,
>>>
>>> 1) If the left-click pan setting is enabled, it does conflict with
>>> left-click dragging (to make a group selection, for example).  I do not
>>> enable left-click pan anywhere by default, I just added it in case there is
>>> a single-function "pan tool" ever desired, like what is available in most
>>> PDF readers.
>>>
>>> 2) If the right-click pan setting is enabled, it only handles drag
>>> events, so in my testing, you can still use the right click menus just fine
>>> (because it is a click without a drag).  I would welcome feedback if anyone
>>> tests this and finds that it causes issues with right-click.
>>>
>>> 3) This setting is currently only enabled in my GerbView GAL branch, so
>>> if you want to test it on master, you will have to just force the default
>>> to enable right-click pan, and then it will also work in pcbnew.
>>>
>>> 4) The reason for this change is that the "touchpad pan" option allows
>>> you to pan with the touchpad but not zoom, since it is using the same
>>> events.  My patch allows (in some tools, when appropriate) four different
>>> actions without leaving the mouse/touchpad:  Left click to select, Right
>>> click for context menu, mouse wheel, and right-drag for pan.  On an Apple
>>> touchpad at least, this lets you both zoom and pan with just gestures.
>>> This new patch is not specific to MacOS though, I have tested it on Linux
>>> as well and with various mice in addition to the Mac touchpad.  On regular
>>> mice with wheel it also allows you to select, zoom, and pan at the same
>>> time.
>>>
>>> Best,
>>> Jon
>>>
>>> On Wed, Sep 13, 2017 at 6:51 AM, Bernhard Stegmaier <
>>> stegma...@sw-systems.de> wrote:
>>>
>>>> Hi,
>>>>
>>>> Did you try (at least for laptops) the existing touchpad panning -
>>>> instead of introducing yet another panning mode?
>>>> The 2-finger panning gestures should meanwhile also be available on
>>>> Windows/Linux?
>>>>
>>>>
>>>> Regards,
>>>> Bernhard
>>>>
>>>> > On 13. Sep 2017, at 11:21, Maciej Suminski <maciej.sumin...@cern.ch>
>>>> wrote:
>>>> >
>>>> > Hi Jon,
>>>> >
>>>> > I apologize for delayed replies, I have very limited time for KiCad
>>>> > development recently.
>>>> >
>>>> > I do not mind adding such setting, but does not it cause issues with
>>>> > right-click menus or left mouse button click actions?
>>>> >
>>>> > Regards,
>>>> > Orson
>>>> >
>>>> > On 09/06/2017 03:31 AM, Jon Evans wrote:
>>>> >> Hi all,
>>>> >>
>>>> >> This patch extends the VIEW_CONTROLS to allow optional panning with
>>>> left or
>>>> >> right buttons in addition to middle.  I plan to make use of this in
>>>> >> GerbView for an easy panning mode that works well on laptops and
>>>> 2-button
>>>> >> mice, and this might also be useful in other applications --
>>>> drag-to-pan
>>>> >> with the right button is a handy thing to enable in editing tools to
>>>> make
>>>> >> them usable when you don't have a middle button.
>>>> >>
>>>> >> -Jon
>>>> >>
>>>>

Re: [Kicad-developers] [PATCH] Add support for panning with left and right mouse buttons

[Andrey Kuznetsov]

FYI, Regarding panning with 2 fingers, it does not work on my Lenovo laptop
running windows 8.
Only zoom works, 2 finger up-down motion.

On Wed, Sep 13, 2017 at 6:53 AM, Jon Evans  wrote:

> Hi Orson and Bernhard,
>
> 1) If the left-click pan setting is enabled, it does conflict with
> left-click dragging (to make a group selection, for example).  I do not
> enable left-click pan anywhere by default, I just added it in case there is
> a single-function "pan tool" ever desired, like what is available in most
> PDF readers.
>
> 2) If the right-click pan setting is enabled, it only handles drag events,
> so in my testing, you can still use the right click menus just fine
> (because it is a click without a drag).  I would welcome feedback if anyone
> tests this and finds that it causes issues with right-click.
>
> 3) This setting is currently only enabled in my GerbView GAL branch, so if
> you want to test it on master, you will have to just force the default to
> enable right-click pan, and then it will also work in pcbnew.
>
> 4) The reason for this change is that the "touchpad pan" option allows you
> to pan with the touchpad but not zoom, since it is using the same events.
> My patch allows (in some tools, when appropriate) four different actions
> without leaving the mouse/touchpad:  Left click to select, Right click for
> context menu, mouse wheel, and right-drag for pan.  On an Apple touchpad at
> least, this lets you both zoom and pan with just gestures.  This new patch
> is not specific to MacOS though, I have tested it on Linux as well and with
> various mice in addition to the Mac touchpad.  On regular mice with wheel
> it also allows you to select, zoom, and pan at the same time.
>
> Best,
> Jon
>
> On Wed, Sep 13, 2017 at 6:51 AM, Bernhard Stegmaier <
> stegma...@sw-systems.de> wrote:
>
>> Hi,
>>
>> Did you try (at least for laptops) the existing touchpad panning -
>> instead of introducing yet another panning mode?
>> The 2-finger panning gestures should meanwhile also be available on
>> Windows/Linux?
>>
>>
>> Regards,
>> Bernhard
>>
>> > On 13. Sep 2017, at 11:21, Maciej Suminski 
>> wrote:
>> >
>> > Hi Jon,
>> >
>> > I apologize for delayed replies, I have very limited time for KiCad
>> > development recently.
>> >
>> > I do not mind adding such setting, but does not it cause issues with
>> > right-click menus or left mouse button click actions?
>> >
>> > Regards,
>> > Orson
>> >
>> > On 09/06/2017 03:31 AM, Jon Evans wrote:
>> >> Hi all,
>> >>
>> >> This patch extends the VIEW_CONTROLS to allow optional panning with
>> left or
>> >> right buttons in addition to middle.  I plan to make use of this in
>> >> GerbView for an easy panning mode that works well on laptops and
>> 2-button
>> >> mice, and this might also be useful in other applications --
>> drag-to-pan
>> >> with the right button is a handy thing to enable in editing tools to
>> make
>> >> them usable when you don't have a middle button.
>> >>
>> >> -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
>>
>
>
> ___
> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] 1: GAL Bug with Window Buttons

[Andrey Kuznetsov]

Same thing here:

Application: kicad
Version: (2017-09-07 revision 90668f9ef)-makepkg, release build
Libraries:
wxWidgets 3.0.3
libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1
librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian,
wxMSW
Build Info:
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.60.0
Curl: 7.54.1
Compiler: GCC 7.1.0 with C++ ABI 1011

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_SPICE=ON


On Wed, Sep 13, 2017 at 3:02 AM, Marcos Chaparro 
wrote:

> I can confirm this on sept 6 nighties.
>
> Regards
>
> On Sep 13, 2017 03:07, "Strontium"  wrote:
>
>> On 13/09/17 13:24, Nick Østergaard wrote:
>>
>>> What version of kicad did he test?
>>>
>> Application: kicad
>> Version: no-vcs-found-8182369~60~ubuntu16.04.1, release build
>> Libraries:
>> wxWidgets 3.0.2
>> libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
>> Platform: Linux 4.4.0-93-generic x86_64, 64 bit, Little endian, wxGTK
>> Build Info:
>> wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
>> Boost: 1.58.0
>> Curl: 7.47.0
>> Compiler: GCC 5.4.0 with C++ ABI 1009
>>
>> Build settings:
>> USE_WX_GRAPHICS_CONTEXT=OFF
>> USE_WX_OVERLAY=OFF
>> KICAD_SCRIPTING=ON
>> KICAD_SCRIPTING_MODULES=ON
>> KICAD_SCRIPTING_WXPYTHON=ON
>> KICAD_SCRIPTING_ACTION_MENU=ON
>> BUILD_GITHUB_PLUGIN=ON
>> KICAD_USE_OCE=ON
>> KICAD_SPICE=ON
>>
>> ___
>> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Drag Tracks Broken?

[Andrey Kuznetsov]

OK, nvm, either it got fixed between 8432 and 8477 releases or it was a
weird windows stated because I haven't rebooted in months.

On Thu, Sep 7, 2017 at 11:15 PM, jp charras <jp.char...@wanadoo.fr> wrote:

> Le 07/09/2017 à 21:53, Andrey Kuznetsov a écrit :
> > I can't seem to drag tracks in cairo or openGL in latest nightly pcbnew,
> dragging only works in legacy.
> >
> > Using Windows.
> >
> > Can someone check please?
> > --
>
> It works for me (using W7)
>
>
> --
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Drag Tracks Broken?

[Andrey Kuznetsov]

I can't seem to drag tracks in cairo or openGL in latest nightly pcbnew,
dragging only works in legacy.

Using Windows.

Can someone check please?
-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] [PATCH] Add support for panning with left and right mouse buttons

[Andrey Kuznetsov]

Thanks Jon, also useful with mice that have shitty middle mouse buttons
that are either hard to press or spin freely willy, or both, that makes it
hard to press the button without zooming in all over the place.

On Tue, Sep 5, 2017 at 6:31 PM, Jon Evans  wrote:

> Hi all,
>
> This patch extends the VIEW_CONTROLS to allow optional panning with left
> or right buttons in addition to middle.  I plan to make use of this in
> GerbView for an easy panning mode that works well on laptops and 2-button
> mice, and this might also be useful in other applications -- drag-to-pan
> with the right button is a handy thing to enable in editing tools to make
> them usable when you don't have a middle button.
>
> -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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] KiCAD with MacOS Barely Usable

[Andrey Kuznetsov]

Well, it's working a bit faster without external display, but still laggy
enough to be an annoyance compared to windows.
Holding the middle button and panning the schematic in circles shows
incredible lag. In windows it's no more than 20 pixels separated from the
mouse cursor, actually hard to notice, and on mac it can be separated by as
much as an entire screen depending on how fast you move the mouse.
If I zoom in back and forth real fast, on windows I get instant display
feedback, on macOS I get a rubber band type effect with the zoom, it keeps
zooming after I stop, not sure it's either the rubber band or lag. Smart on
finger portables like phones, stupid on laptop/desktops.
I have already disabled inertia in my mouse/trackpad and all other sources
of rubber band that I could find online.

It might be an issue with hardware, not sure what to do about it though,
how do you quantify this problem and reliably test it though since it's a
user experience and speed/time issue in order to file a bug.

[image: Inline image 1]

On Tue, Sep 5, 2017 at 9:36 AM, Adam Wolf <adamw...@feelslikeburning.com>
wrote:

> I don't have issues with rendering lag on my Retina display (not in
> low-DPI mode) either, unless my board gets very complicated.
>
> I do not run on an external display.
>
> On Tue, Sep 5, 2017 at 11:16 AM, Jon Evans <j...@craftyjon.com> wrote:
> > I think the Retina display is just one piece of the puzzle re. Mac
> > performance.  I have a Retina display and don't have any issues with
> > rendering lag (and don't run in low-DPI mode either).  So, I suspect that
> > there are some combinations of display + GPU + maybe drivers, library
> > versions, etc? that can cause poor performance.
> >
> > -Jon
> >
> > On Tue, Sep 5, 2017 at 12:12 PM, Andrey Kuznetsov <kandre...@gmail.com>
> > wrote:
> >>
> >> Yes, I did.
> >>
> >> On Tue, Sep 5, 2017 at 9:11 AM Nick Østergaard <oe.n...@gmail.com>
> wrote:
> >>>
> >>> Did you try the tip mentioned on the webpage?
> >>>
> >>> http://kicad-pcb.org/help/known-system-related-issues/#_osx
> >>>
> >>> 2017-09-05 16:32 GMT+02:00 Jon Evans <j...@craftyjon.com>:
> >>>>
> >>>> Hi Andrey,
> >>>>
> >>>> I tried to reproduce this and couldn't.  I'm on 10.12.6, on a 2017
> rMBP
> >>>> with internal display and 2K external display (don't have a 5K, but
> can't
> >>>> see how that would matter).  I also tried with an external mouse and
> didn't
> >>>> see any issue with the scroll wheel.
> >>>>
> >>>> Any other Mac developers have any ideas to help diagnose this?
> >>>> Andrey, it would probably be good to open a bug report so that this
> >>>> doesn't get lost in email.
> >>>>
> >>>> -Jon
> >>>>
> >>>> On Fri, Sep 1, 2017 at 7:58 PM, Andrey Kuznetsov <kandre...@gmail.com
> >
> >>>> wrote:
> >>>>>
> >>>>> Here's an example video.
> >>>>> I move the scroll wheel one at a time at first, and it zooms very
> slow,
> >>>>> notice it jumps from like 7x to 22x in a single scroll.
> >>>>> I tried PCBnew with OpenGL and it has additional problems, it zooms
> >>>>> pretty fast compared to Eeschema but when it stops, there's 50:50
> chance it
> >>>>> will jump 1 zoom level about a second after the zoom stops, which
> throws you
> >>>>> off badly in terms of where you are. It's not my scroll wheel
> behaving
> >>>>> badly, scroll wheel is ratcheted, nothing like this happens on web
> pages,
> >>>>> pdfs, etc.
> >>>>> https://www.dropbox.com/s/rtlzeadfkkf3atn/KiCAD_20170801.mov?dl=0
> >>>>>
> >>>>> On Fri, Sep 1, 2017 at 4:31 PM, Andrey Kuznetsov <
> kandre...@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> I'm using last night's nightly.
> >>>>>>
> >>>>>> Which mac do you have, retina display, external display?
> >>>>>> My schematic operations are super laggy.
> >>>>>>
> >>>>>> To select a few parts, I have to click, wait a few seconds then
> drag,
> >>>>>> if I don't wait and start dragging and release, the parts never get
> >>>>>> selected.
> >>>>>>
> >>>>>> On Fri, Sep 1, 2017 at 4:27 PM, Jon Evans <j...@

Re: [Kicad-developers] KiCAD with MacOS Barely Usable

[Andrey Kuznetsov]

Yes, I did.

On Tue, Sep 5, 2017 at 9:11 AM Nick Østergaard <oe.n...@gmail.com> wrote:

> Did you try the tip mentioned on the webpage?
>
> http://kicad-pcb.org/help/known-system-related-issues/#_osx
>
> 2017-09-05 16:32 GMT+02:00 Jon Evans <j...@craftyjon.com>:
>
>> Hi Andrey,
>>
>> I tried to reproduce this and couldn't.  I'm on 10.12.6, on a 2017 rMBP
>> with internal display and 2K external display (don't have a 5K, but can't
>> see how that would matter).  I also tried with an external mouse and didn't
>> see any issue with the scroll wheel.
>>
>> Any other Mac developers have any ideas to help diagnose this?
>> Andrey, it would probably be good to open a bug report so that this
>> doesn't get lost in email.
>>
>> -Jon
>>
>> On Fri, Sep 1, 2017 at 7:58 PM, Andrey Kuznetsov <kandre...@gmail.com>
>> wrote:
>>
>>> Here's an example video.
>>> I move the scroll wheel one at a time at first, and it zooms very slow,
>>> notice it jumps from like 7x to 22x in a single scroll.
>>> I tried PCBnew with OpenGL and it has additional problems, it zooms
>>> pretty fast compared to Eeschema but when it stops, there's 50:50 chance it
>>> will jump 1 zoom level about a second after the zoom stops, which throws
>>> you off badly in terms of where you are. It's not my scroll wheel behaving
>>> badly, scroll wheel is ratcheted, nothing like this happens on web pages,
>>> pdfs, etc.
>>> https://www.dropbox.com/s/rtlzeadfkkf3atn/KiCAD_20170801.mov?dl=0
>>>
>>> On Fri, Sep 1, 2017 at 4:31 PM, Andrey Kuznetsov <kandre...@gmail.com>
>>> wrote:
>>>
>>>> I'm using last night's nightly.
>>>>
>>>> Which mac do you have, retina display, external display?
>>>> My schematic operations are super laggy.
>>>>
>>>> To select a few parts, I have to click, wait a few seconds then drag,
>>>> if I don't wait and start dragging and release, the parts never get
>>>> selected.
>>>>
>>>> On Fri, Sep 1, 2017 at 4:27 PM, Jon Evans <j...@craftyjon.com> wrote:
>>>>
>>>>> Hi Andrey,
>>>>>
>>>>> Are you running the stable build or the nightlies?
>>>>> I'm also using 10.12 and while there are some issues, it is usable.  I
>>>>> agree the zooming behavior is somewhat strange on Mac right now, but I
>>>>> don't have any issues with lag or the other things you describe (I'm using
>>>>> nightly builds).
>>>>>
>>>>> -Jon
>>>>>
>>>>> On Fri, Sep 1, 2017 at 7:17 PM, Andrey Kuznetsov <kandre...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Previously used KiCAD on Windows, everything worked well, even the
>>>>>> nightlies.
>>>>>> Just started using KiCAD on MAC OSX 10.12.6 on macbook pro 2016 with
>>>>>> 5K display, tried it without external display, no change, tried with low
>>>>>> resolution mode for the program, no change, tried reducing screen
>>>>>> resolution, a little better, but still supper laggy and weird.
>>>>>>
>>>>>> Starting a new project and currently working in Eeschema.
>>>>>>
>>>>>> It takes 0.7s to rotate an LED symbol clockwise 90 degrees,
>>>>>> everything is so laggy.
>>>>>> Selecting parts, half the time doesn't select probably because I
>>>>>> release too soon, the other half, very slow.
>>>>>>
>>>>>> Using the scroll wheel to zoom in and out causes horrendous lags. Not
>>>>>> only that but somehow it ends up zooming to unpredictable levels when 
>>>>>> only
>>>>>> 1 mouse scroll is triggered and inertia disabled, because it keeps 
>>>>>> zooming
>>>>>> and I move the mouse, it ends up zooming not where I was originally
>>>>>> pointing to zoom with 1 scroll wheel trig. For example, sometimes the 
>>>>>> zoom
>>>>>> doesn't stop right away so instead of zooming by 10 or 25% it goes from
>>>>>> 0.6x to 11x, like WTFF. So the zoom completely doesn't work, useless.
>>>>>> Why is it that when I press CMD+scroll wheel it scrolls viewport
>>>>>> horizontally?
>>>>>> I have 2 scroll wheels, horiz and vert, both are sc

Re: [Kicad-developers] KiCAD with MacOS Barely Usable

[Andrey Kuznetsov]

I'm using last night's nightly.

Which mac do you have, retina display, external display?
My schematic operations are super laggy.

To select a few parts, I have to click, wait a few seconds then drag, if I
don't wait and start dragging and release, the parts never get selected.

On Fri, Sep 1, 2017 at 4:27 PM, Jon Evans <j...@craftyjon.com> wrote:

> Hi Andrey,
>
> Are you running the stable build or the nightlies?
> I'm also using 10.12 and while there are some issues, it is usable.  I
> agree the zooming behavior is somewhat strange on Mac right now, but I
> don't have any issues with lag or the other things you describe (I'm using
> nightly builds).
>
> -Jon
>
> On Fri, Sep 1, 2017 at 7:17 PM, Andrey Kuznetsov <kandre...@gmail.com>
> wrote:
>
>> Hi,
>>
>> Previously used KiCAD on Windows, everything worked well, even the
>> nightlies.
>> Just started using KiCAD on MAC OSX 10.12.6 on macbook pro 2016 with 5K
>> display, tried it without external display, no change, tried with low
>> resolution mode for the program, no change, tried reducing screen
>> resolution, a little better, but still supper laggy and weird.
>>
>> Starting a new project and currently working in Eeschema.
>>
>> It takes 0.7s to rotate an LED symbol clockwise 90 degrees, everything is
>> so laggy.
>> Selecting parts, half the time doesn't select probably because I release
>> too soon, the other half, very slow.
>>
>> Using the scroll wheel to zoom in and out causes horrendous lags. Not
>> only that but somehow it ends up zooming to unpredictable levels when only
>> 1 mouse scroll is triggered and inertia disabled, because it keeps zooming
>> and I move the mouse, it ends up zooming not where I was originally
>> pointing to zoom with 1 scroll wheel trig. For example, sometimes the zoom
>> doesn't stop right away so instead of zooming by 10 or 25% it goes from
>> 0.6x to 11x, like WTFF. So the zoom completely doesn't work, useless.
>> Why is it that when I press CMD+scroll wheel it scrolls viewport
>> horizontally?
>> I have 2 scroll wheels, horiz and vert, both are scrolling horizontally.
>>
>> Button tool tips take a very long time to show up, I think 2 seconds,
>> 0.5s -1s should be used, when you're working and need a quick reminder, 2
>> seconds must as well be 10 seconds.
>>
>> Anyone else familiar with things I'm experiencing?
>>
>> Thanks
>>
>> --
>> kandre...@gmail.com
>> Live Long and Prosper,
>> Andrey
>>
>> ___
>> 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
>>
>>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] KiCAD with MacOS Barely Usable

[Andrey Kuznetsov]

Hi,

Previously used KiCAD on Windows, everything worked well, even the
nightlies.
Just started using KiCAD on MAC OSX 10.12.6 on macbook pro 2016 with 5K
display, tried it without external display, no change, tried with low
resolution mode for the program, no change, tried reducing screen
resolution, a little better, but still supper laggy and weird.

Starting a new project and currently working in Eeschema.

It takes 0.7s to rotate an LED symbol clockwise 90 degrees, everything is
so laggy.
Selecting parts, half the time doesn't select probably because I release
too soon, the other half, very slow.

Using the scroll wheel to zoom in and out causes horrendous lags. Not only
that but somehow it ends up zooming to unpredictable levels when only 1
mouse scroll is triggered and inertia disabled, because it keeps zooming
and I move the mouse, it ends up zooming not where I was originally
pointing to zoom with 1 scroll wheel trig. For example, sometimes the zoom
doesn't stop right away so instead of zooming by 10 or 25% it goes from
0.6x to 11x, like WTFF. So the zoom completely doesn't work, useless.
Why is it that when I press CMD+scroll wheel it scrolls viewport
horizontally?
I have 2 scroll wheels, horiz and vert, both are scrolling horizontally.

Button tool tips take a very long time to show up, I think 2 seconds, 0.5s
-1s should be used, when you're working and need a quick reminder, 2
seconds must as well be 10 seconds.

Anyone else familiar with things I'm experiencing?

Thanks

-- 
kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Additional Patch for via properties dialog (2)

[Andrey Kuznetsov]

If you're looking for good DFM manuals, check out protoexpress, otherwise
known as Sierra Circuits.
They're a professional board house in the USA with simple to complex board
design support including high speed interfaces, uvias, etc.


On Tue, Aug 22, 2017 at 2:33 PM, Thomas Langås 
wrote:

> On Tue, Aug 22, 2017 at 9:36 PM, Wayne Stambaugh 
> wrote:
> > I'm not opposed to this change.  However, there are two schools of
> > thought when it comes to board layout: strict layout constraints and no
> > layout constraints.  I tend to lean towards the latter but I've been
> > doing this for 30 years so I am painfully aware of the pitfalls of no
> > layout constraints and have a pretty good idea of what not to do.
> > Should we choose to loosen the layout constraints for blind/buried vias,
> > then we should be prepared for a serious tongue lashing the first time
> > someone violates their board vendor's manufacturing limitations and ends
> > up with a bunch of useless and likely expensive boards.  Maybe at some
> > point in the future we will have a complete constraint system that can
> > cover all possibilities but until then we have to walk that fine line
> > between power users and beginners.
>
>
> Is there a good reason why not to build this by rulesets, and allow
> people to define
> their own rulesets within KiCAD.  You can have a sensible default rule
> that covers
> the 80-90%, and allow the people who know more about this and what they
> need
> just remove the default rule and add their own advanced rules?
>
> Of course, this would imply that without any rules at all, it's just
> willy nilly and
> everything allowed.  But isn't that the way design rules should be?  If
> you want
> to try ice skating down a mountain, it might not be smart, but it's your
> own
> choice  ;-)
>
>
> --
> Thomas
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Move point on pcbnew

[Andrey Kuznetsov]

I was about to explode, but then noticed that if I select the whole
footprint then the MOVE (press M) snaps to the closest point, either center
of footprint or center of pad.

However, if I selected a pad without selecting the footprint and then
pressed M, then it would snap to the center of the footprint, this is
unexpected behaviour. When a pad is selected, I'd expect the move to snap
to the center of that specific pad, not to the whole footprint.
Can someone fix it?

On Mon, May 8, 2017 at 8:01 AM, Carlo Maragno  wrote:

> Ok, could you point out how to achieve the same result on the last version
> of kicad?
>
> I recompiled from master head but I wasn't able do drag a component from a
> pad.
>
>
> Thanks again,
> Carlo
>
> 2017-05-06 14:25 GMT+02:00 Maciej Suminski :
>
>> Oh, now I see what you mean. There is a slight difference between the
>> steps we perform to drag a component by its pad. You select a pad and
>> start to drag it, and I select a whole footprint and drag starting near
>> a pad.
>>
>> Regards,
>> Orson
>>
>> On 05/05/2017 05:36 PM, Carlo Maragno wrote:
>> > Too bad! Here you can find a google drive folder with the two small
>> video.
>> >
>> > Enjoy,
>> > Carlo
>> >
>> > https://drive.google.com/folderview?id=0B-AbX0GoNzEPRjFSY19qQ0JjeFE
>> >
>> > On May 3, 2017 10:15 PM, "Carlo Maragno"  wrote:
>> >
>> >> Hi Guys,
>> >>
>> >> While I was using an old developer version of Kicad (the build date was
>> >> 28-2-2017), in pcbnew the move tool would grab the component from the
>> point
>> >> closer to the cursor when M was pressed. In other word, if the cursor
>> was
>> >> closer to a pad the center of the pad would become the grabbing point.
>> >>
>> >> On the last developer release from the Ubuntu PPA, this behavior
>> >> disappeared. I'm trying to figure out at which point it was deleted
>> but as
>> >> I was quite far away from master head this could be a very long
>> process.
>> >> Now I am at commit #bbaa29, made by Chris Pavlina.
>> >>
>> >> Can someone of the developers point to me at which point this feature
>> was
>> >> removed?
>> >>
>> >> My ultimate goal would be to make a push request in order to get this
>> >> feature added again. So if someone could help that would be great!
>> >>
>> >> Thanks again to all,
>> >> Carlo
>> >>
>> >
>> >
>> >
>> > ___
>> > 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Component table improvements

[Andrey Kuznetsov]

Agree, a csv file option should be available.

Would be nice if there were 2 flavors, grouped and ungrouped.
That's all a general user might want.

Asking a general user to deal with python is unreasonable, and it took me a
while to figure out how the current plug in system works and even longer to
find the right plugin to get grouped results.

On Sun, May 14, 2017 at 12:39 PM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> Well I think these reasons are strange, I think that having a built in way
> of exporting the BoM from the software is reasonable. Since not everyone
> are the same.
>
> The component table is what a user expects to see when wanting to generate
> a BOM. I can assure you that no EE or student expects to be presented with
> a weirdly formatted command-line interface as is the current way.
>
> The current BOM generating is a settings interface more than a BOM export
> tool.
>
> CSV files are also a lot easier to parse than parsing a kicad schematic
> file,
>
> - Kristoffer
>
>
>
> On 05/13/2017 02:46 PM, Strontium wrote:
>
>> I agree with this decision as well but for different reasons.
>>
>> The more I get into small scale self manufacturing, the more I am
>> persuaded by the argument that you want to keep as little BoM information
>> in the Kicad schematic fields as reasonably possible. It becomes a
>> maintenance nightmare, an external BoM tool is what is needed which bridges
>> Kicads schematic information and true BoM part information.  If you are
>> making one or two boards you can store it all inside your schematic, but go
>> to 3 or 4 and you quickly feel like you are crushing rocks re-entering the
>> same information for the same components all over again.  And if you want
>> to change something, then you have to do it for every component you have of
>> that part, in every schematic that uses it. Then you have equivalents,
>> costings, inventory control, supplier information, etc etc. It quickly
>> becomes unmanageable if you try and hold this information in a schematic.
>>
>> If you are trying to generate a CSV or TSV to upload to Mouser for
>> costing, it will be subtly different to what a contract manufacturer will
>> want from you, etc.  Because of this, no two designers will come up with
>> the same scheme to specify this BoM information, it will depend what they
>> want to use it for.
>>
>> Its better to store an abstract or general piece of information in the
>> schematic which can be used by an external BoM tool to generate a true BoM
>> for you, in the format/s you or your manufacturer require.  And if you are
>> going to do that, its just as easy to directly read the schematic files, as
>> it is to read a BoM exported in CSV format.
>>
>> See: https://github.com/KiCad/kicad-library-utils for python code to
>> read a schematic directly.
>>
>> Steven
>>
>> On 13/05/17 02:18, jp charras wrote:
>>
>>> Le 12/05/2017 à 13:55, Oliver Walters a écrit :
>>>
 This feature was IN this branch of code but was vetoed. It was WYSIWYG
 BoM with export to:

 *SV
 XML
 HTML

 Wayne mentioned that KiCad used to have such a BOM export tool but I
 haven't been using KiCad long
 enough to have experienced it.

 If there is real need for such a feature then I leave that to the
 project leads to decide. I have
 the code still, and it could be implemented very easily.

>>> Hi Oliver,
>>>
>>> As Wayne said, we don't like a BOM export tool *written in C++ inside*
>>> the Kicad code.
>>>
>>> Here is the reason:
>>> A few years ago, this code was existing and (as Wayne said) created the
>>> same BOM files (txt, csv...)
>>> as your code.
>>>
>>> What was the result:
>>> Roughly ever month, a bug or request was filled to change something in
>>> BOM files.
>>> I am guessing we cannot find 2 guys who want the same BOM format or
>>> option.
>>>
>>> Therefore, the C++ code inside the Kicad code was dropped, and replaced
>>> by external scripts (Python
>>> or XSL) to transform the XML netlist created by Kicad to an other list
>>> (BOM, but also other netlist
>>> formats).
>>>
>>> *Trust me*, this was a *wise* decision (It was not my decision, but was
>>> a good decision).
>>>
>>> Therefore: if you want to create the BOM you like, write a Python script
>>> to do that from a netlist
>>> (it is easy to run from Eeschema: see the BOM or Netlist generator), but
>>> do not try to merge this
>>> code in Kicad C++ sources: your script will never generate the "right"
>>> BOM.
>>> But a Python script is very easy to modify.
>>>
>>> There are already many BOM generators written in Python.
>>>
>>>
>>>
>>
>> ___
>> 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: 

Re: [Kicad-developers] [FEATURE] Partial selection in pcbnew

[Andrey Kuznetsov]

What's CTRL taken by?
I thought CTRL would be used to toggle grid snapping?

On Mon, May 8, 2017 at 3:39 PM, José Ignacio  wrote:

> Or switching between object and grid snap :)
>
> On Mon, May 8, 2017 at 5:34 PM, Wayne Stambaugh 
> wrote:
>
>> I tend to lean toward Oliver's approach.  Most CAD tools I've used have
>> this type of includes vs intersects selection paradigm.  I don't see the
>> need to tie up the modifier key if we don't have to.  I would prefer
>> that we keep a modifier key open for something like orthogonal move.
>>
>> On 5/8/2017 5:51 PM, Oliver Walters wrote:
>> > I was approaching this from having used mechanical CAD tools where the
>> > direction of selection is the standard approach. Whatever function is
>> > chosen, it will still be required that the users adjust to the new
>> > style, manuals updated, etc.
>> >
>> > Is assigning what is essentially the last remaining modifier key worth
>> > it for this?
>> >
>> > On 8 May 2017 23:55, "Nick Østergaard" > > > wrote:
>> >
>> > 2017-05-08 14:59 GMT+02:00 Maciej Sumiński > > >:
>> > > Hi Oliver,
>> > >
>> > > I took your set of patches for a test drive. I am glad that you
>> > thought
>> > > about the subtractive mode in the selection tool, it really fits
>> > there.
>> > > Regarding different selection modes - I like the idea, but I
>> think the
>> > > two modes should be more distinct, changing the selection
>> direction
>> > > might be not enough.
>> > >
>> >
>> > I personally prefer modifier keys as we are used to in Gimp and
>> > Inkscape.
>> >
>> > > I observed another user trying out the tool and he could not tell
>> how
>> > > does it work, but noticed it is a bit different than the old tool.
>> > >
>> > > Perhaps one of the following would work:
>> > >
>> > > - change the selection box colors so they are easier to tell
>> apart (my
>> > > mate was surprised to find out there were two colors for the
>> > selection box)
>> > >
>> > > - change the mode using a key modifier (I think only Alt is left
>> free)
>> > > or mouse button
>> > >
>> > > - add an option to select the default mode (though I do not really
>> > like
>> > > having too many options to set)
>> > >
>> > > I agree with Tom about the geometry library. IIRC currently it is
>> only
>> > > used by the PNS router, but ultimately we would like to use it in
>> the
>> > > primary model. The library already provides methods to check for
>> > > collisions between basic shapes, yet we still need a few more.
>> > > It would be a pity to drop your code now, so perhaps we could
>> > merge the
>> > > code as is and fix the methods during the model refactor.
>> > >
>> > > Just to let you know, there are a few code formatting violations
>> > (mostly
>> > > not keeping two empty lines between method definitions in .cpp
>> files),
>> > > but as they are infrequent - I can handle them myself.
>> > >
>> > > Regards,
>> > > Orson
>> > >
>> > > On 05/07/2017 02:11 AM, Oliver Walters wrote:
>> > >> Maciej,
>> > >>
>> > >> That was it! Thanks for the hint.
>> > >>
>> > >> #0016 attached, which fixes both issues:
>> > >>
>> > >> a) No more double-selection of module and module-items (pads /
>> > lines / etc)
>> > >> in PCBNEW
>> > >> b) Disable selection of entire module in MODEDIT
>> > >>
>> > >> As far as I can tell this patchset is now working very well.
>> > >>
>> > >> Regards,
>> > >> Oliver
>> > >>
>> > >> On Sat, May 6, 2017 at 10:21 PM, Oliver Walters <
>> > >> oliver.henry.walt...@gmail.com
>> > > wrote:
>> > >>
>> > >>> Maciej,
>> > >>>
>> > >>> Thanks, I'll look into that. If you have a chance to look over
>> > what I've
>> > >>> done, I'd appreciate that :)
>> > >>>
>> > >>> On Sat, May 6, 2017 at 10:17 PM, Maciej Suminski
>> > >
>> > >>> wrote:
>> > >>>
>> >  Hi Oliver,
>> > 
>> >  I have not tested the patches yet, but my gut feeling says that
>> > you miss
>> >  calling SELECTION_TOOL::selectable() to filter out redundant
>> items.
>> > 
>> >  Regards,
>> >  Orson
>> > 
>> >  On 05/06/2017 09:21 AM, Oliver Walters wrote:
>> > > Three further patch files attached:
>> > >
>> > > - Different color select box based on direction
>> > > - Fixed HitTest for EDA_TEXT
>> > > - Control modifier unselects anything in rectangle.
>> > >
>> > > The major piece of feedback I need right now is how to
>> perfect the
>> > 

Re: [Kicad-developers] [FEATURE] Partial selection in pcbnew

[Andrey Kuznetsov]

Actually I'd prefer there to be only 1 selector tool, every program that
I've used that made the distinction of 2 mouse pointers with slightly
different functionality of selection has made it HELL to use.
The act of switching between the two cursors is a PITA, whereas a silent
selector switch based on user motion/action is a more natural and easier to
perform action without requiring brain input, muscle memory and intent are
all that's required.

On Thu, May 4, 2017 at 8:05 AM, Wayne Stambaugh 
wrote:

> On 5/4/2017 10:53 AM, Marco Ciampa wrote:
> > On Thu, May 04, 2017 at 02:36:06PM +0200, Kristoffer Ödmark wrote:
> >> Personally I would like the box select to update selections online while
> >> dragging, this would be very informative. I also think that maybe this
> >> functionality would be better with a modifier button now that I think
> about
> >> it, since sometimes I cannot starta a drag move in one corner due to a
> large
> >> footprint residing there and then getting selected.
> >
> > +1
> >
> > I like the GIMP way:
> >
> >  - CTRL+drag means substract objects from the selecion
> >and appears little minus symbol near the pointer to feedback this
> >
> >  - SHIFT+drag means add objects to the selection
> >and appears little plus symbol near the pointer to feedback this
>
> Custom cursors for inside versus intersect selection could be a good way
> to make the different selection bounding box feature discover-able
> without being too distracting to the user.
>
> >
> >> But the hidden features problem is one that is starting to affect more
> and
> >> more of pcbnew since functionality is added continuosly.
> >
> > agree
> >
> >> I know there is a manual for pcbnew, maybe tools should have some
> shortcut
> >> to go to the relevant section of that manual? Or the tools have a
> shortcut
> >> to go a "tool manual" I have no clue on how to achieve this, but It
> would be
> >> nice.
> >
> > again this would be very handy as it is already present for instance in
> GIMP.
> >
> > We should figure out how to obtain this, at least for HTML... I have some
> > ideas about how it can be obtained but I have to check for those
> > feasibility...
> >
> > Regards,
> >
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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