Re: [Kicad-developers] Launch Pad ???

[Clemens Koller]

Is ist possible to remove the remaining information from launchpad and make it 
clear that we moved?

Clemens

On 04/03/2021 13.44, Wayne Stambaugh wrote:
> All KiCad development and bug tracking has been moved to GitLab.  Only
> the mailing list hosting remains on Launchpad.
> 
> - Wayne
> 
> On 2/19/21 2:23 PM, Christopher Buckley wrote:
>> Are you guys still using launchpad for bug reporting / tracking?
>>
>> Latest bug I've found there is for June 2020...
>>
>> Am searching through the inventory...
>>
>> C
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Code execution context

[Clemens Koller]

Hello, Markus!

I can offer to do some testing / debugging on Arch Linux. (I'm currently on 
boost 1.75.0, but I hope it is not needed as dependency.)
I cannot help with proprietary / closed source drivers.

My SpaceNav was sleeping in my drawer for ages, so the rubber parts became 
sticky as chewing gum! 8-/

$ lsusb
shows:
Bus 007 Device 002: ID 046d:c626 Logitech, Inc. 3Dconnexion Space Navigator 3D 
Mouse

I recommend to have a look into the blender, calligra, freecad, openscad 
integration of spacenav/libspnav.
http://spacenav.sourceforge.net/
(https doesn't seem to work, currently!)

Regards,

Clemens

On 25/02/2021 07.47, Markus Bonk wrote:
> Hi,
> 
>  
> 
> I am currently investigating adding support for 3D input devices to pcbnew. 
> The plan is to use a websocket interface (boost/beast) to communicate with 
> the 3D device. Effectively the communication runs on an extra thread. 
> Somewhere the event code will need to switch to executing on the main thread.
> 
>  
> 
> One way of achieving this on say win32 might be to add functors to a queue 
> post a message to a message window handler in the main thread which empties 
> the queue and invokes the functor.
> 
>  
> 
> Is such a mechanism already in place in KiCAD? What is the KiCAD recommended 
> solution to the issue?
> 
>  
> 
> Thanks
> 
> -Markus
> 
>  
> 
>  
> 
> --
> 
> *Markus Bonk*
> Senior Software Engineer
> 
> Clarita-Bernhard-Str. 18
> 81249 München
> Germany
> 
>   
> markus_b...@3dconnexion.com 
> 
> www.3dconnexion.com 
> 
> Geschäftsführer: Antonio Pascucci
> Sitz der Gesellschaft: München
> Registergericht: München HRB 99232
> 
> This email and any files transmitted with are from 3Dconnexion GmbH. The 
> contents of this email and any attachments are confidential to the intended 
> recipient. They may not be disclosed to or used by or copied in any way by 
> anyone other than the intended recipient. If this email is received in error, 
> please contact 3Dconnexion GmbH by calling +49 89 8974542-0 and then delete 
> it. Please note that neither 3Dconnexion GmbH nor the sender accepts any 
> responsibility for viruses and it is your responsibility to scan or otherwise 
> check this email and any attachments. Any opinion expressed in this email are 
> those of the individual and not necessarily those of 3Dconnexion GmbH.
> 3Dconnexion GmbH processes and stores for commercial purposes your personal 
> data, collected upon your consent, in accordance with its privacy policy 
> available at https://www.3dconnexion.eu/privacy.html 
> , which has been drafted in 
> accordance with Regulation (EU) no. 679/2016 and all applicable local data 
> protection laws and regulations of the countries where the company operates. 
> To revoke your consent or exercise all your rights with regards to personal 
> data, please contact us at priv...@3dconnexion.com 
> .
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Official Docker Image

[Clemens Koller]

Hi, Martin!


On 23/11/2020 20.42, Martin Marmsoler wrote:
> sorry for the late response, I didn't see it. I'm using also Arch, which 
> version of wxwidgets do I need (wxgtk3-dev?).

wxgtk3 might do the trick.
Have a look at the dependencies in Arch's PKGBUILD:
https://github.com/archlinux/svntogit-community/blob/packages/kicad/trunk/PKGBUILD

I had Kicad built for a path in home by bending the MAKE_INSTALL_PREFIX as well 
as the DEFAULT_INSTALL_PATH. Hence, the cmake line might need some updates from 
above PKGBUILD. So, the following is a bit aged:

# git pull stuff...
cd kicad.git
rm -rf build/debug
mkdir -p build/debug
cd build/debug
cmake   \
-DCMAKE_BUILD_TYPE=Debug \
-DCMAKE_INSTALL_PREFIX=~/SW \
-DDEFAULT_INSTALL_PATH=~/SW \
-DKICAD_SCRIPTING=ON \
-DKICAD_SCRIPTING_MODULES=ON \
-DKICAD_SCRIPTING_WXPYTHON=ON \
-DKICAD_SCRIPTING_ACTION_MENU=ON \
-DKICAD_SPICE=ON \
-DKICAD_USE_OCE=ON \
-DBUILD_GITHUB_PLUGIN=ON \
-DUSE_WX_GRAPHICS_CONTEXT=OFF \
-DUSE_WX_OVERLAY=OFF \
../../
make -j8
make install

YMMV.

Clemens

> 
> Cheers,
> 
> Martin
> 
> Am Di., 27. Okt. 2020 um 18:30 Uhr schrieb Clemens Koller  <mailto:c...@embeon.de>>:
> 
> Hi!
> 
> I am working with a version in i.e. ~/SW/bin in parallel to the release 
> on Arch Linux.
> IMO, no docker necessary.
> 
> Clemens
> 
> On 27/10/2020 17.30, Martin Marmsoler wrote:
> > Hi,
> >
> > do there exist an official docker image which can be used for 
> developing? So everything is encapsulated from the host system.
> >
> > Cheers,
> >
> > Martin
> >
> > ___
> > 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>
> >
> 
> ___
> 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>
> 

___
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] Official Docker Image

[Clemens Koller]

Hi!

I am working with a version in i.e. ~/SW/bin in parallel to the release on Arch 
Linux.
IMO, no docker necessary.

Clemens

On 27/10/2020 17.30, Martin Marmsoler wrote:
> Hi,
> 
> do there exist an official docker image which can be used for developing? So 
> everything is encapsulated from the host system.
> 
> Cheers,
> 
> Martin
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Attempting to build kicad-git source on Slackware-current Linux

[Clemens Koller]

Hello, Tom!

I don't know if it's of any help to you. On Arch Linux, I am manually building 
a locally installed test version of kicad.git using the attached script.

Installed packages containing "wx" are currently:
$ pacman -Q -s wx
local/python-wxpython 4.0.7.2-1
Cross-platform GUI toolkit
local/python2-wxpython3 3.0.2.0-3
Classic wxWidgets GUI toolkit for Python
local/wxformbuilder-svn 3.5.2.RC2.r2225-1
Designer, GUI builder, and RAD tool For wxWidgets
local/wxgtk-common 3.0.5.1-1
Common libraries and headers for wxgtk2 and wxgtk3
local/wxgtk2 3.0.5.1-1
GTK+2 implementation of wxWidgets API for GUI
local/wxgtk2.8 2.8.12.1-6
GTK+ implementation of wxWidgets API for GUI
local/wxgtk3 3.0.5.1-1
GTK+3 implementation of wxWidgets API for GUI

You can peek the build instructions for wxgtk* and others in the Arch 
repositories. i.e.:
https://github.com/archlinux/svntogit-packages/blob/packages/wxgtk/trunk/PKGBUILD


Regards,

Clemens

On 08/10/2020 20.28, Tom Crane wrote:
> Thanks for the follow-up.
> 
> I am building both using a slightly modified version of this 
> http://www.slackware.com/~alien/slackbuilds/wxGTK3/build/wxGTK3.SlackBuild 
> script.
> 
> My mods were to remove the '--disable-shared' configure options so the 
> shareable libraries got built and to add an extra subdirectory onto the 
> --libdir pathspecs to ensure against overwriting and other confusion.
> 
> After adjusting the PATH to ensure the correct wx-config version (3 rather 
> than 2) is called I get eg.
> 
> /tmp/SBo/kicad-git/build$ wx-config --libs -L/usr/lib64/gtk3 -pthread 
> -lwx_gtk3u_xrc-3.1 -lwx_gtk3u_html-3.1 -lwx_gtk3u_qa-3.1 -lwx_gtk3u_core-3.1 
> -lwx_baseu_xml-3.1 -lwx_baseu_net-3.1 -lwx_baseu-3.1
> 
> 
> I am guessing this ought to work
> 
> Tom.
> 
> On Thu, 8 Oct 2020, mark.vandoesb...@hetnet.nl wrote:
> 
>> You need to compile wxGTK with gtk3 instead of gtk2 (which is the default
>> in slackbuilds) I use wxGTK3-3.0.5, I don't use the python stuff.
>>
>> Tom Crane  wrote:
>>
>>  I am having no success despite having been able to do this in the past.
>>
>>  Previously I was able to build for gtk2+ with Python2.  Now trying this 
>> fails at runtime with eg. "(eeschema:6730): Gtk-ERROR **: 15:29:43.689: GTK+ 
>> 2.x symbols detected.  Using GTK+ 2.x and GTK+ 3 in the same process is not 
>> supported".  According to 
>> https://forum.kicad.info/t/gtk-2-to-3-issues/24856/2 GTK2 isn't able to be 
>> used any more.
>>
>>  Instead (my preference anyway) I am now trying to build against gtk3+ 
>> and
>>  Python3.
>>
>>  I get this error,
>>
>>  # cmake -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
>> -DKICAD_SCRIPTING_PYTHON3=ON -DKICAD_SCRIPTING_WXPYTHON=ON 
>> -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON -DKICAD_SCRIPTING_ACTION_MENU=ON 
>> -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON ../
>>  -- KiCad install dir: 
>>  -- Enabling warning -Wsuggest-override
>>  -- Enabling warning -Wduplicated-branches
>>  -- Enabling warning -Wduplicated-cond
>>  -- Enabling error for -Wvla
>>  -- Enabling warning -Wimplicit-fallthrough
>>  -- Enabling error for -Wreturn-type
>>  -- Enabling warning -Wshadow
>>  -- Enabling warning -Wsign-compare
>>  -- Enabling warning -Wmissing-field-initializers
>>  -- Enabling warning -Wempty-body
>>  -- Enabling warning -Wreorder
>>  -- Check for installed GLEW -- found
>>  -- Check for installed ZLIB -- found
>>  -- Check for installed Python Interpreter -- found
>>  -- Python module install path: lib64/python3.8/site-packages
>>  -- Found Phoenix 4.1.1a1/gtk3 (wxWidgets 3.1.5)
>>  CMake Error at 
>> /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 
>> (message):
>> Could NOT find wxWidgets: Found unsuitable version "3.1.4", but 
>> required is  at least "3.1.5" (found
>>
>>  
>> -L/usr/lib64/gtk3;-pthread;;;-lwx_gtk3u_gl-3.1;-lwx_gtk3u_aui-3.1;-lwx_gtk3u_html-3.1;-lwx_gtk3u_core-3.1;-lwx_baseu_net-3.1;-lwx_baseu-3.1;-lwx_gtk3u_propgrid-3.1;-lwx_baseu_xml-3.1;-lwx_gtk3u_stc-3.1)
>>  Call Stack (most recent call first):
>> /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:456
>>  (_FPHSA_FAILURE_MESSAGE)
>> CMakeModules/FindwxWidgets.cmake:1014
>>  (find_package_handle_standard_args)
>> CMakeLists.txt:808 (find_package)
>>
>>
>>  -- Configuring incomplete, errors occurred!
>>  See also "/tmp/SBo/kicad-git/build/CMakeFiles/CMakeOutput.log".
>>  See also "/tmp/SBo/kicad-git/build/CMakeFiles/CMakeError.log".
>>
>>
>>  CMakeError.log shows the test compilations failing with these three 
>> errors,
>>  c++: error: unrecognized command line option 
>> '-Winconsistent-missing-override'
>>  c++: error: unrecognized command line option '-Wmismatched-tags'
>>  c++: error: unrecognized command line option 
>> '-Wimplicit-int-float-conversion'
>>
>>  BTW I am using GCC 9.3.0.

[Kicad-developers] Placing real components out of a database instead of: "Automatic assignment of footprint with a database"

[Clemens Koller]

Hello!

This is related to the previous thread: "Automatic assignment of footprint with 
a database"

I would generally prefer assemble real components on a real PCB right from the 
beginning instead of first placing generic components and then assign 
footprints + manufacturers + types + x manually. This seems extra work for each 
component which could possibly be avoided.

So, regarding on the Kicad codebase, I would very likely not recomment to embed 
a full component management / database system, since this might vary from site 
to site and even from project/assembly house to project/house. But it would be 
great to be able to have an interface to grab a component out of a database and 
Kicad grabs all desired / a selection of individual columns out of the database 
as needed.
This might include the actual footprints stored in the database as well.


Regards, Clemens


-
Just FYI - my workflow:

To automate as much as possible, the Library in my PCB Tools (Mentor PADS, 
Kicad, and since a couple of weeks: Eagle *omph*) contain real parts only.

I am maintaining a MariaDB Database with all my different components (2000+) 
containing a lot of information, possibly worth more than a commercial design 
software license.
Let me show you the table structure (below) for your information and discussion 
to hopefully get the big picture of the complexity of component management.

There are still some missing features and advanced usecases:
- Allow some components get replaced with successors in a life-cycle-management 
/ obsoloete-part-management sense - on a per project basis.
- Use unique components+versions and store the used components for all 
manufactured boards in a database.
- For conformal coating: Add columns if a component must not be coated, Add 
columns on a project basis if a component should be coated or not.
- Depending on different assembly houses: Generate footprints with small 
rounded rectancles for reflow processes, or with wider pads for wave-soldering 
and update the PCB atomatically!
- Search for a obsoloete component in selected projects and replace it with a 
different one. Since the new one has an updated footprint, layouts need to be 
updated too in X places!

Here is an  (still incomplete) database schema, I am using for years now - with 
a lot more SQL magic and M4 scripts around it to get it in and out of the 
different design tools:

CREATE TABLE `main` (
`mfg` VARCHAR(45) NULL DEFAULT '' COMMENT 'mfg name' COLLATE 
'utf8_general_ci',
`mfgname` VARCHAR(45) NULL DEFAULT '' COMMENT 'mfg partname' COLLATE 
'utf8_general_ci',
`description` VARCHAR(255) NULL DEFAULT '' COMMENT 'functional 
specification' COLLATE 'utf8_general_ci',
`lycomment` VARCHAR(255) NULL DEFAULT '' COMMENT 'comment regarding 
part usage' COLLATE 'utf8_general_ci',
`partname` VARCHAR(45) NULL DEFAULT '' COMMENT 'KEY: partname_metric' 
COLLATE 'utf8_general_ci',
`partname_old` VARCHAR(45) NULL DEFAULT '' COMMENT 'KEY: 
partname_imperial (obsolete)' COLLATE 'utf8_general_ci',
`caedecal` VARCHAR(45) NULL DEFAULT '' COMMENT 'cae decal name' COLLATE 
'utf8_general_ci',
`pincount` SMALLINT(5) UNSIGNED NULL DEFAULT '0' COMMENT 'no of package 
pins including e-pad, excluding drills',
`value` VARCHAR(20) NULL DEFAULT '' COMMENT 'ATTRIBUTE: primary 
component value in design tool ' COLLATE 'utf8_general_ci',
`pcbdecal` VARCHAR(45) NULL DEFAULT '' COMMENT 'pcb decal name ' 
COLLATE 'utf8_general_ci',
`mfgpkg` VARCHAR(45) NULL DEFAULT '' COMMENT 'mfg package 
specification' COLLATE 'utf8_general_ci',
`mfgpkg_iec` VARCHAR(45) NULL DEFAULT '' COMMENT 'mfg package 
specification IEC' COLLATE 'utf8_general_ci',
`mfgpkg_jeita` VARCHAR(45) NULL DEFAULT '' COMMENT 'mfg package 
specification JEITA' COLLATE 'utf8_general_ci',
`mfgpkg_jedec` VARCHAR(45) NULL DEFAULT '' COMMENT 'mfg package 
specification JEDEC' COLLATE 'utf8_general_ci',
`power` DECIMAL(7,3) UNSIGNED NULL DEFAULT '0.000' COMMENT 'power 
rating',
`voltage` DECIMAL(7,3) UNSIGNED NULL DEFAULT '0.000' COMMENT 'voltage 
rating',
`current` DECIMAL(7,3) UNSIGNED NULL DEFAULT '0.000' COMMENT 'current 
rating',
`temp_min` SMALLINT(5) NULL DEFAULT '0' COMMENT 'min operating 
temperature',
`temp_max` SMALLINT(5) NULL DEFAULT '0' COMMENT 'max operating 
temperature',
`pitch` DECIMAL(7,3) UNSIGNED NULL DEFAULT '0.000' COMMENT 'footprint 
minimum pitch',
`length` DECIMAL(7,3) UNSIGNED NULL DEFAULT '0.000' COMMENT 'length of 
part',
`width` DECIMAL(7,3) UNSIGNED NULL DEFAULT '0.000' COMMENT 'width of 
part',
`height` DECIMAL(7,3) UNSIGNED NULL DEFAULT '0.000' COMMENT 'height of 
part',
`rohs` VARCHAR(10) NULL DEFAULT '' COMMENT 'rohs conformity' COLLATE 
'utf8_general_ci',
`dista` VARCHAR(255) NULL DEFAULT '' COMMENT 'primary distributor' 
COLLATE 'utf8_general_ci',

Re: [Kicad-developers] Auto-generated backup files: are they useful?

[Clemens Koller]

Hello!

On 30/06/2020 18.46, Jon Evans wrote:
> Give this issue a thumbs up: https://gitlab.com/kicad/code/kicad/-/issues/4763

Just some additions to this issue's desired features:

> 1. Capture the entire project state into a single backup archive (.zip file)

...including a timestamp in the .zip's or folder's name (outside of your VCS' 
visibility).

> 2. Configurable (turn the entire feature on or off, and control how many 
> backups to keep
> 3. Store backups in a configurable location (default: a subdirectory of the 
> project, like ./projectname-backups/)
> 4. Automatically save backups at some configurable interval (every N hours or 
> days, maybe) -- NOT every time you save a file

... every minute(s)!
In the case KiCad crashes I can hardly remember the last 10 minutes of work I 
did.
Additionally: It might useful to save on each CreateUndoEntry to be able to 
reconstruct the a crash for debug purposes.

> 5. A feature (in project manager, probably) to restore a project's state from 
> a given backup archive

Thanks,

Clemens



> 
> On Tue, Jun 30, 2020 at 12:21 PM Diego Herranz
>  wrote:
>>
>> This possibility to save the last N backups would be useful. It is what 
>> Altium does more or less and it has proven useful to me in the past. 
>> Especially if you change your mind after 2h working on something which is 
>> not going anywhere :)
>>
>> Thanks,
>> Diego
>>
>> On Tue, 30 Jun 2020 at 15:15, Wayne Stambaugh  wrote:
>>>
>>> Sounds like a great solution to me.
>>>
>>> On 6/30/20 10:12 AM, Jon Evans wrote:
 JP, I agree that true backups are useful.

 Maybe even it is a good idea for KiCad to have a built-in backup function.

 I just don't think the current backup function is actually useful
 because of my first point (backups are overwritten on each save).

 I would propose:

 1) Remove the current backup file generation

 2) Create a spec (in GitLab issue) for a better backup system that:

 - Can be turned on or off
 - Backs up the whole project in a zip file
 - Can keep the last N backups
 - Runs on a schedule, not necessarily every time you click Save.

 Anyone opposed to this?

 -Jon

 On Tue, Jun 30, 2020 at 3:32 AM jp charras  wrote:
>
> Le 30/06/2020 à 00:13, hauptmech a écrit :
>>
>> While I agree that it is not KiCad's job to do archival backups or 
>> version control, I do think that KiCad should preserve the integrity of 
>> users data through a crash. Even better if the work between the last 
>> save and the crash is also preserved and recovered on restart.
>>
>> I have had to use the backup files to recover data in the past. I have 
>> no idea if that recovery was related to something that is now no longer 
>> a possible issue.
>>
>>
>> -Hauptmech
>>
>>
>
> I am also thinking a backup can be useful when something unexpected 
> happens.
>
> Backups, like any security system, bothers you as long as you do not need 
> to use them.
> But you are happy to find them in case of trouble.
>
> I like the way some CAD tools manage backup:
> only one zip archive is created (for instance projectname_backup.zip) and 
> contains all saved files
> (in our case: *.kicad_sch (and sub paths) and .kicad_pcb)
> This is not a full project backup, just main files are saved.
>
> This is not invasive (only one file, or a few .zip if one want to keep 
> last n saved versions)
> and is a security against  unexpected cases.
>
> For me, backups are like a accident insurance: you need them and you hope 
> never use them.
>
> And about VCS use:
>
> Many good electronics guys do not even know what is it, and have never 
> compiled any source code.
> Electronics world and Software world are not exactly the same world.
>
> --
> 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

>>>
>>> ___
>>> 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] Symbols and Pin mapping in v6 - Proposal

[Clemens Koller]

Hello, Tim!

I agree that in the near future, the demand for (I'd call it) "Table Based 
Design Entry" will rise tremendously,
when we reach pincounts in the high hundreds and thousands.

It is a lot of work to draw and maintain complex MCUs/SoCs/FPGAs in some 
schematic when pins can have 8 different functions which might change during 
product development. A current example: i.MX8 [1] with i.e. 625 pins.
So, it might not even be sufficient to be able to import (and export) .CSVs. It 
might be a good idea to prepare for some automatism to be able to update and 
version control pin multiplexing changes!

Regards, Clemens

[1] https://www.nxp.com/docs/en/data-sheet/IMX8MDQLQIEC.pdf

On 15/09/2019 15.29, Tim Hawkins wrote:
> What about shunting the problem aside and have the ability to load a fixed 
> format csv file with the details of the pin map. The file could then be 
> bundled with the project.  Ie define a dynamic component, that has a physical 
> form, but its schematic forms are dynamic, and depend on the contents of the 
> csv (speadsheet),  each row is one physical pin, with bus groups, lables and 
> other elements defined in the ss. 
> 
> On Sun, Sep 15, 2019, 9:18 PM Strontium,  > wrote:
> 
> Hello Ajith,
> 
> I admit i skimmed your proposal, but i think it looks like it has merit, 
> and that work can be done to improve symbols and pin mapping.
> 
> I always struggle with multi use pins like on MCUs.  Its tedious to keep 
> drawing boxes with pins, just to support a layout of pins that suits the 
> pinmuxing your using, and the a decent layout of the schematic.
> 
> I think a complex component like an MCU or FPGA could work like a 
> sub-sheet.  It doesn't have a shape or symbol, per-se.  Its JUST a list of 
> pins.  You then drop one of that component (which is a resizeable box like a 
> sub-sheet), and like a sub-sheet import pins from it and place wherever you 
> want in the box boundary.  Want to break your MCU into functional units, just 
> drop another box with the same reference, import the pins you want into 
> there.  It would be a lot easier to manage, i think.  And would reduce 
> redundancy in part definitions for complex MCUs, and make those parts a lot 
> easier to define in the process.  But I also think its probably a lot of work 
> to do, and I don't know how it would break the file formats. 
> 
> However this would also allow one to choose the mux function/s which 
> could set the appropriate pin attribute for that pin, input/output/open 
> drain, etc.  Making DRC sane again.  The schematic would be neater and would 
> also tell you more about what is intended than:
> 
> I2C2_CLK/SPI1_MISO/ADC3_CH6/CLK_OUT/UART3_TX/UART2_TX/TIMER2_A/SCLK | 10 
> -
> 
> Does.  Which is how a lot of MCU's end up getting defined.  Instead the 
> designer says, this pin is the I2C2_CLK and the pin then looks like this in 
> the schematic:
> 
> I2C2_CLK | 10 -
> 
> doesn't suit layout, right click on pin and change it to the I2C2_CLK on 
> pin 239:
> 
> I2C2_CLK | 239 -
> 
> Don't have to copy the component, move pins around, reimport the changed 
> symbol, etc etc.
> 
> For simple components, like diodes, transistors, buffers, LDOs, opamps, 
> etc etc.  Then a symbolic representation is definitely the way to go.  And 
> your proposal would make that even nicer.  I like the list of pins example 
> you gave for the transistor.  Much clearer from a schematic perspective.
> 
> Steven
> 
> On 12/9/19 11:36 am, Ajith N wrote:
>> Sorry the URL was mangled, here it is:
>>   https://gitel84.github.io/pdfs/kicad_syms_proposal.pdf
>>
>>
>>  On Thu, 12 Sep 2019 12:30:26 +0800  
>>
>> Hi Developers,
>>
>> Requesting your attention to a proposal and discussion in the KiCad 
>> User Forum. The topic is symbols and pin mapping (for v6) as they relate to 
>> the data model.
>>
>> I took up a suggestion (by Rene Poeschl) to detail my proposal with 
>> diagrams, and have prepared some slides, which is at:
>>
>>     https://gitel84.github.io/pdfs/kicad_syms_proposal.pdf (PDF 
>> format)
>>
>> The background references are at the end.
>>
>> (I feared being unable to respond in a timely manner to potential 
>> questions which may arise in the course of discussions in the developers' 
>> list. Therefore, I have chosen to put more detail into the slides wherever 
>> possible. Hopefully that helps. The detail may be excessive for some readers 
>> though. If so please bear with me).
>>
>> I hope KiCad developers find this worth looking at for v6.
>>
>> Thanks for all the great work!
>>
>> P.S.
>> I have been a happy user of KiCad for barely over a year now. KiCad 
>> to me is a very nice and open tool with nice features, has no lock-in, has 
>> an active community of users and is progressing in a good direction.
>>
>>
>>
>>

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Clemens Koller]

Hi!
I think it could be good to see both:
- The actual PCB area of the outline (well, without drills).
- The max-width * max-height which is usually what you have to pay for when you 
get it manufactured.
The second one could be also an interesting task to calculate if you have an 
odd shaped polygonal outline.

Regards,
Clemens


On 29/07/2019 14.43, Alexander Shuklin wrote:
>   Hi! I've been asked to do actually PCB area calculation. Since English is 
> not my first language, maybe I just miss-understood. Do you mean, that area 
> has to be just max width * max height? I never seen that, but there's a 
> message in thread about sometimes you need proper area.
> I utilized kicad outline functions for that.
> 
> 
> Понедельник, 29 июля 2019, 15:35 +03:00 от Mark Roszko 
> :
> 
> Huh, looking at the statistics code, it actually tries and find the more 
> "detailed area" of a board based on any polygonal outline.
> Is there any value in it this way? PCB manufacturing charges are 
> generally per-square area  because ultimately the price is on panel space you 
> are using. 
> 
> On Sat, Jul 27, 2019 at 5:07 AM Diego Herranz 
>  > wrote:
> 
> I've been testing this dialog and I think it is a nice addition. 
> Thanks!
> 
> There seems to be something wrong with the area calculation, though. 
> See image below:
> area.png
> 
> Thanks,
> Diego
> 
> On Tue, 23 Jul 2019 at 11:18, Ian McInerney  > wrote:
> 
> Alexander,
> 
> Instead of declaring the 2 static variables separately, I would 
> suggest creating a struct for the settings then store that as the static 
> variable. For an example of this see the dialog_create_array.cpp file. This 
> way if any new options must be added in the future, they can just be added to 
> the struct very easily.
> 
> -Ian
> 
> On Mon, Jul 22, 2019 at 9:39 PM Alexander Shuklin 
> > 
> wrote:
> 
> Damn ><,
> don't use last patch, please.
> It doesn't count total vias amount. Use this one.
> 
> 
> Понедельник, 22 июля 2019, 22:14 +03:00 от Alexander 
> Shuklin  >:
> 
> Hi,
> thanks for sharing experience, as I never used that 
> translations or wxWidgets before. And I have no idea where else could I get 
> that information. ))
> So, there's the patch with vias information and some tiny 
> improvements.
> 
> 
> Понедельник, 22 июля 2019, 13:34 +03:00 от Ian 
> McInerney  >:
> 
> 
> 
> On Mon, Jul 22, 2019 at 11:03 AM Dino Ghilardi 
>  > wrote:
> 
> Hi Alexander,
> 
> One possible solution for the translation could 
> be put the ":" in a
> different column of the table and right-align the 
> field description text
> (so all the colons will be aligned). A rapid 
> google search shown that in
> French and Vietnamese there should be a space 
> before the colon, while in
> the rest of the world there is not, so having the 
> translation for the
> ":" word seems to make sense. Also another 
> question arises: Is there
> some language in which the colon should be 
> another character before the
> word? (I'm thinking about spanish where the 
> question mark upside-down
> appears before a question...)? ...conclusion: 
> keeping "Height:" and
> "Height" as two different words seem to be the 
> solution that gives
> maximum flexibility to translators.
> 
> 
> This actually doesn't give them as much flexibility. 
> When translations are done, they need to examine the entire string that needs 
> translating, so the ":" character should be included in the string. 
> Separating out the two portions is the equivalent of saying that every 
> lanugage will follow the same compositional rules.
>  
> 
> Another possible solution (probably better then 
> the one above since it
> just removes the problem) is to remove the ":" 
> and have the cell borders
> in a different color, just like the tables in the 
> "board setup" dialog
> (so that you can also take a look at that code to 
> solve also the color
> problem seeing how it was solved there). The 
> advantage of this approach
> is also having a more consistent "look" through 
> all the dialogs.
> 
> 
> 
> P.S. (a little bit off-topic):
>  

Re: [Kicad-developers] A consistent name for the Aux Origin?

[Clemens Koller]

Hello, Jeff!

On 18/05/2019 12.37, Jeff Young wrote:
> We need fewer origins.

I agree.

> I like the name Coordinates Origin, but why do we then need a Grid Origin?  
> And why a setting for the displayed coordinates?  Shouldn’t that always be 
> the Coordinates Origin?

My imagination of the Layout world: I would welcome a "Physical Design Origin" 
or short "Origin". If I place my board edge (or a component or something else) 
at the Origin (0,0) then I would expect that it also gets output at the Gerber 
at (0,0) as well as all other output files.

Additionally, during the layout/placement process, there could be an additional 
"Auxiliary Grid" to aid in the placement of elements by snapping to it.
(Example: Placing thousands of LEDs in a backlight panel.) This grid could be 
an odd spaced cartesian or polar (or other?) coordinate system with a Grid 
Offset relative to the Physical Origin. This Aux Grid settings should also be 
saved to the design but not affect the physical design itself.

The Visible Grid could or should visualize the Aux Grid if it's set. There 
might be cases where more than one Aux Grid/Visible Grid might come in handy.
In the future, when we think about multi PCB designs, there might be more than 
one Physical Design Origin as well as multiple Aux Grids in a project.

---
OT: A different thing is the manufacturing files / output file generation (i.e. 
Gerber) where it might be nice/mandatory to add additional offsets or step & 
repeat parameters (also polar coorrdinates would be great, or a whole transform 
matrix). These settings might also be saved in the design, but used only for 
the corresponding manufacturing output.

Just my five Cents,

Clemens

___
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] Build Docs Page Not Working

[Clemens Koller]

The browser cache gets cleared on every session at my side...
It still works, somehow. But loading the left menu seems to stall (until some 
timeout?) every once in a while on refresh for several seconds.

Regards,

Clemens

On 07/04/2019 17.38, Mark Roszko wrote:
> It's not fixed. The build job is having trouble uploading correctly at the 
> moment.
> If it looks fine atm, it's because of your browser cache.
> 
> On Sun, Apr 7, 2019 at 11:23 AM Clemens Koller  <mailto:c...@embeon.de>> wrote:
> 
> It seems fixed, on firefox 66.0.2, too. It wasn't this morning.
> 
> On 07/04/2019 15.02, Wayne Stambaugh wrote:
> > Has this been fixed?  It looks fine to me in Chrome.
> >
> > On 4/6/19 11:58 PM, Mark Roszko wrote:
> >> Looks like the last docs build broke on upload.
> >>
> >> On Sat, Apr 6, 2019 at 11:57 PM Mark Roszko  <mailto:mark.ros...@gmail.com>
> >> <mailto:mark.ros...@gmail.com <mailto:mark.ros...@gmail.com>>> wrote:
> >>
> >>     >Resource interpreted as Stylesheet but transferred with MIME type
> >>     text/x-asm: "http://docs.kicad-pcb.org/doxygen/doxygen.css;.
> >>
> >>     HM
> >>
> >>
> >>
> >>     On Sat, Apr 6, 2019 at 9:30 PM Christopher Buckley
> >>      <mailto:mallardproducti...@yahoo.com> <mailto:mallardproducti...@yahoo.com 
> <mailto:mallardproducti...@yahoo.com>>>
> >>     wrote:
> >>
> >>         Is it just me using Firefox 66 or is the docs build page really
> >>         messed up???
> >>
> >>         
> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html
> >>
> >>
> >>         ___
> >>         Mailing list: https://launchpad.net/~kicad-developers
> >>         Post to     : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> >>         <mailto:kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>>
> >>         Unsubscribe : https://launchpad.net/~kicad-developers
> >>         More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >>
> >>     --
> >>     Mark
> >>
> >>
> >>
> >> --
> >> Mark
> >>
> >> ___
> >> 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 
> <mailto: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

Re: [Kicad-developers] Build Docs Page Not Working

[Clemens Koller]

It seems fixed, on firefox 66.0.2, too. It wasn't this morning.

On 07/04/2019 15.02, Wayne Stambaugh wrote:
> Has this been fixed?  It looks fine to me in Chrome.
> 
> On 4/6/19 11:58 PM, Mark Roszko wrote:
>> Looks like the last docs build broke on upload.
>>
>> On Sat, Apr 6, 2019 at 11:57 PM Mark Roszko > > wrote:
>>
>> >Resource interpreted as Stylesheet but transferred with MIME type
>> text/x-asm: "http://docs.kicad-pcb.org/doxygen/doxygen.css;.
>>
>> HM
>>
>>
>>
>> On Sat, Apr 6, 2019 at 9:30 PM Christopher Buckley
>> mailto:mallardproducti...@yahoo.com>>
>> wrote:
>>
>> Is it just me using Firefox 66 or is the docs build page really
>> messed up???
>>
>> 
>> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html
>>
>>
>> ___
>> 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
>>
>>
>>
>> -- 
>> 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
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] type-based transparency

[Clemens Koller]

On 18/03/2019 13.28, Seth Hillbrand wrote:
> Am 2019-03-17 20:11, schrieb Jon Evans:
>> Hi all,
>>
>> I want to change the color system in PcbNew so that transparency is
>> tied to object type rather than board layer.  Color would still be set
>> by layer, but transparency would be settable for things like tracks,
>> component pads, zones, etc.
> 
> Hi Jon-
> 
> I like the idea.  I can see that working well for 
> tracks/zones/vias/footprints/etc.
> 
> I would still like to keep the option (maybe as a multiplicative 
> setting) of changing a layer transparency, at least for user layers.  I 
> wouldn't want my GDT marks to automatically have the same transparency 
> as lines in copper layers, for instance.
> 
> -Seth

I second that. Setting transparency by object type as well as layer set by an n 
x m multiplication might be the way to go.
Imagine how to visualize an 8+ layer board with embedded passives instead of 
only a 2 layer board. Additionally, it might become very handy to highlight 
(reduce transparency and/or emphasize brightness and/or saturation) of the 
current routing layer, dynamically updating on each layer change while routing.

Thank you,

Clemens

___
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

[Clemens Koller]

On 09/03/2019 14.27, Rene Pöschl wrote:
> It might help if you could state where on this planet you are. The 
> problem seems to either be location or time dependent.

Germany, Munich.
Regardless of that, the problem is likely not server-side.

Clemens

On 09/03/2019 14.27, Rene Pöschl wrote:
> It might help if you could state where on this planet you are. The 
> problem seems to either be location or time dependent.
> 
> On 09/03/19 14:21, Clemens Koller wrote:
>> I cannot confirm such a slow download.
>> I get 23MBytes/s speed from https://kicad-downloads.s3.cern.ch which is the 
>> max I can get here.
>>
>> Regards,
>>
>> Clemens
>>
>> On 09/03/2019 12.38, Rene Pöschl wrote:
>>> Hi,
>>>
>>>
>>> it seems that some of our users struggle to download nightly builds for
>>> windows from the cern servers right now.
>>>
>>> Is this an expected sideeffect of the server move or is there currently
>>> a problem?
>>>
>>>
>>> The original report was made over here:
>>> https://forum.kicad.info/t/window-nightlies-download-speed/15633/
>>>
>>> Some of the guys report download speeds in the low kB/s range and even
>>> experience total download failures. (It might be noteworthy that all the
>>> guys reporting problems are outside of europe.)
>>>
>>>
>>> ___
>>> 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

Re: [Kicad-developers] Download speeds for nightly builds seem a bit slow to a lot of people over at the forum

[Clemens Koller]

I cannot confirm such a slow download.
I get 23MBytes/s speed from https://kicad-downloads.s3.cern.ch which is the max 
I can get here.

Regards,

Clemens

On 09/03/2019 12.38, Rene Pöschl wrote:
> Hi,
> 
> 
> it seems that some of our users struggle to download nightly builds for 
> windows from the cern servers right now.
> 
> Is this an expected sideeffect of the server move or is there currently 
> a problem?
> 
> 
> The original report was made over here: 
> https://forum.kicad.info/t/window-nightlies-download-speed/15633/
> 
> Some of the guys report download speeds in the low kB/s range and even 
> experience total download failures. (It might be noteworthy that all the 
> guys reporting problems are outside of europe.)
> 
> 
> ___
> 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

[Kicad-developers] OT: Re: Kicad support for Linux on PPC

[Clemens Koller]

Sorry, for getting OT, but...

On 18/02/2019 10.48, Jean-Samuel Reynaud wrote:
> Hi,
> 
> According to the user that push to me that patch (Gianluca Renzi, a user
> of the https://www.powerpc-notebook.org/ project), It's working
> correctly and 3D look to be fast. So I assume that it's correct in term
> of OpenGL configuration...

...the project is using an QorIQ T2080 Communication Processor from NXP 
(formerly Freescale).
These chips are great (well, for networking) and even on the 15years 
longetivity roadmap, but there are rumors that there will be no more new Power 
Architecture CPUs from this corner.

Regards,

Clemens

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

[Clemens Koller]

Hi, Cedric,

I've just tested your instructions. It looks quite good. Some comments are 
below:

On my main Arch Linux (regularly maintained rolling release since 2011), your 
instructions don't work out of the box yet.

Qt Creator chokes a bit on the qmake versions because I am using qt4 and qt5 on 
my system:
"Cannot update Qt version information: /usr/lib/qt/bin/qmake cannot be run."
This can easily be fixed by going to Tools -> Options - Kits -> Qt Versions:
Use Qt 5.12.0 (System) /usr/bin/qmake
xor Qt 5.12.0 (System) /usr/bin/qmake-qt5
not Qt 4.8.7 (System) /usr/bin/qmake-qt4

Side note: Otherwise, if no proper qmake is accessible, Qt Creator asks for the 
ninja build system.
This could optionally be installed with:
# pacman -S ninja
(currently, it's ninja-1.8.2-1)


When I tell Qt Creator to use CMakeLists.txt according to your suggestions:

> file => open file or project => /home/username/kicad/CMakeList.txt => open
> configure project

but first, it gets a bit noisy:

-8<-
Failed to set up kit for Qbs: Could not determine whether Qt is a static build.
Running "/usr/bin/cmake -E server --pipe=/tmp/cmake-.IhGzVk/socket 
--experimental" in /tmp/QtCreator-wuKvat/qtc-cmake-tBiqfBkX.
Starting to parse CMake project, using: 
"-DCMAKE_CXX_COMPILER:STRING=/usr/bin/g++", 
"-DCMAKE_C_COMPILER:STRING=/usr/bin/gcc", "-DCMAKE_PREFIX_PATH:STRING=", 
"-DQT_QMAKE_EXECUTABLE:STRING=".
The C compiler identification is GNU 8.2.1
The CXX compiler identification is GNU 8.2.1
Check for working C compiler: /usr/bin/gcc
Check for working C compiler: /usr/bin/gcc -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Detecting C compile features
Detecting C compile features - done
Check for working CXX compiler: /usr/bin/g++
Check for working CXX compiler: /usr/bin/g++ -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
CMake Error at CMakeLists.txt:89 (install):
  install TARGETS given no RUNTIME DESTINATION for executable target "kicad".


CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

cmake_minimum_required(VERSION 3.13)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP".
This warning is for project developers.  Use -Wno-dev to suppress it.

Configuring incomplete, errors occurred!
See also "/tmp/QtCreator-wuKvat/qtc-cmake-tBiqfBkX/CMakeFiles/CMakeOutput.log".
CMake Project parsing failed.
-8<-

Interestingly, CMakeLists.txt contains the line:
cmake_minimum_required( VERSION 2.8.12 FATAL_ERROR )

So, urgh?
The fun part is, that this issue simply vanished on the next try - after 
closing & opening qtcreator.
I then get a quite promising log of:

-8<-
Running "/usr/bin/cmake -E server --pipe=/tmp/cmake-.eYPdxT/socket 
--experimental" in /tmp/QtCreator-XUOcgJ/qtc-cmake-FzUufvWY.
Starting to parse CMake project, using: 
"-DCMAKE_CXX_COMPILER:STRING=/usr/bin/g++", 
"-DCMAKE_C_COMPILER:STRING=/usr/bin/gcc", "-DCMAKE_PREFIX_PATH:STRING=", 
"-DQT_QMAKE_EXECUTABLE:STRING=".
The C compiler identification is GNU 8.2.1
The CXX compiler identification is GNU 8.2.1
Check for working C compiler: /usr/bin/gcc
Check for working C compiler: /usr/bin/gcc -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Detecting C compile features
Detecting C compile features - done
Check for working CXX compiler: /usr/bin/g++
Check for working CXX compiler: /usr/bin/g++ -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
KiCad install dir: 
Looking for malloc.h
Looking for malloc.h - found
Looking for iso646.h
Looking for iso646.h - found
Looking for stdint.h
Looking for stdint.h - found
Looking for strcasecmp
Looking for strcasecmp - found
Looking for strncasecmp
Looking for strncasecmp - found
Looking for strtok_r
Looking for strtok_r - found
Looking for malloc
Looking for malloc - found
Looking for math.h
Looking for math.h - found
Looking for C++ include cmath
Looking for C++ include cmath - found
Looking for asinh
Looking for asinh - found
Looking for acosh
Looking for acosh - found
Looking for atanh
Looking for atanh - found
Performing Test HAVE_CMATH_ISINF
Performing Test HAVE_CMATH_ISINF - Success
Looking for clock_gettime in rt
Looking for clock_gettime in rt - found
Looking for gettimeofday
Looking for gettimeofday - found
Looking for getc_unlocked
Looking for getc_unlocked - found
Performing Test COMPILER_SUPPORTS_WSUGGEST_OVERRIDE
Performing Test COMPILER_SUPPORTS_WSUGGEST_OVERRIDE - Success
Performing Test COMPILER_SUPPORTS_WVLA
Performing Test COMPILER_SUPPORTS_WVLA - Success
Performing Test COMPILER_SUPPORTS_WSHADOW
Performing Test COMPILER_SUPPORTS_WSHADOW - 

Re: [Kicad-developers] Diff pair button

[Clemens Koller]

Hi!

On 29/08/2018 20.43, Seth Hillbrand wrote:
> Does this mean we should be expressly dis-allowing single-track routing on a 
> differential pair?

My experience tells me, that in complex designs, some differential routers 
reach their limits quite often and get stuck. So, manual single-track routing 
is mandatory, followed by some cleaning up.
(Or: Don't restrict users if they believe to know what they are doing.)

> The current behavior is that differential pair routing is only allowed on the 
> net pairs named as Simon mentioned but we do not automatically use 
> differential pair routing in those cases.

I.e. Mentor PADS can switch from diff pair routing to single track routing 
while routing. But you need to re-start routing if you want to continue diff 
pair routing... :-/

Regards,

Clemens

___
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

[Clemens Koller]

Hi, Andrew!

On 17/08/2018 07.10, Andrew Lutsenko wrote:
> Or are you asking to update docs in the repo?

I suggested to have your sample pluging and icon bundled with your patch, ready 
for git to apply (once committers agree...).

Clemens

On 17/08/2018 07.10, Andrew Lutsenko wrote:
> Hi Clemens,
> 
> See sample plugin attached. Extract it into kicad's share/scripting/plugins 
> folder.
> One of other scanned directories that are documented in kicadplugins.i 
> <https://github.com/KiCad/kicad-source-mirror/blob/6fdc5972f8431b4d5831a32649e67bfe20d05de8/scripting/kicadplugins.i#L180>
>  should work too.
> 
> Or are you asking to update docs in the repo?
> Documentation/development/pcbnew-plugins.md seems like the right place.
> I will update it once committers agree with the path I've chosen to implement 
> this.
> 
> 
> 
> On Thu, Aug 16, 2018 at 4:48 AM Clemens Koller  <mailto:c...@embeon.de>> wrote:
> 
> Hello,  Andrew!
> 
> I am somehow missing the Python example you are giving in your patch.
> Can you add this a simple example to the sources to get a basic/dummy 
> skeleton working right from scratch?
> 
> Regards,
> 
> Clemens
> 
> 
> On 15/08/2018 11.31, 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 <http://self.name> <http://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 
> <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

Re: [Kicad-developers] [PATCH] RFC: toolbar button support for action plugins

[Clemens Koller]

Hello,  Andrew!

I am somehow missing the Python example you are giving in your patch.
Can you add this a simple example to the sources to get a basic/dummy skeleton 
working right from scratch?

Regards,

Clemens


On 15/08/2018 11.31, 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
> 

___
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] bring (back) the autoplacer to GAL

[Clemens Koller]

Hi, Tom!

Did you use git mv to rename the files in your patch 0001-* ?
It seems the rename wasn't done/detected properly and thus, git is loosing the 
change history...

Clemens

On 09/08/2018 16.12, Tomasz Wlostowski wrote:
> Hi all,
> 
> The patch set in the attachment brings back the legacy autoplacement
> tool in a GALified version since many people were asking for it. Now it
> can either place selected set of components or all off-board components
> through Place->Autoplace menu.
> 
> Testing & feedback - as always - is more than welcome :)
> 
> Best,
> 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

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

[Clemens Koller]

Did anybody consider putting the field name templates / alias / mapping things 
into some project or workspace file which can be individually set and loaded 
based on the user's workflow/preference?
I strongly prefer to have any configuration space like "custom" field names not 
in the schematics unless it's actively put there.

Personal note again:
"Distr", "Distr P/N", "Mfgr", "Mfgr P/N", "Specifications" are not what I would 
prefer to place in the libs/schematics/layouts.

Just for information, I have only the mandatory "attibutes" tied into the EDA 
systems as they are needed/created there:
partname, pcbdecal, ref, value, posx, posy, height, rotation, layer 
(top/bottom/inner{n}), smt (Technology SMT/THT), asy (assembled in assembly 
variant(s) x,y), coat (conformal coated), ...
"partname" is an index into a database. refs are usually unique, except in 
multi-pcb projects or multi-channel designs.

All manufacturer / distributor / procurement / warehouse / life-cycle / 
assembly house annotations / whatever information is retrieved from a database 
with a simple (SLQ-) query like:
SELECT partname, mfg, dist, price, stockqty, stockplace, ... FROM schematics, 
database WHERE schematics.partname=database.partname ... 


Divide and conquer,

Clemens

On 2018-05-29 22:06, Jeff Young wrote:
> Field Name Templates is even better as it’s harder to parse wrong.  
> DefaultField Names vs. Default FieldNames suggest different things, while 
> FieldName Templates and Field NameTemplates have pretty much the same 
> connotation.
> 
> I think we need to remove the values for 5.0, though.  Plus, it will fix the 
> “silent” side-effect as a bonus.  Then anything we do in 6.0 can be 
> considered new features.
> 
>> On 29 May 2018, at 20:55, Wayne Stambaugh  wrote:
>>
>> On 5/29/2018 3:16 PM, Jeff Young wrote:
>>> And one more idea: “Default Field Names” would also be a reasonable thing 
>>> to call these (so it’s clear that the /name/ is a default, not the /field/).
>>
>> Would that be "Field Name Templates"?
>>
>>>
 On 29 May 2018, at 19:56, Jeff Young  wrote:

 Another way to fix the side-effect issue:

 1) Go with the seed field model (we can name them "template fields”).
>>
>> This is my preference.  I would stick with the "template" nomenclature.
>> I think "seed" would be tricky to translate although I could be wrong
>> about that.
>>

 2) Don’t allow setting values for template fields.  If you open the Symbol 
 Properties dialog the names will appear in the field list, but without 
 values.  If you want to add a value then the field is now part of your 
 symbol.  No “silent” adding.  
>>
>> I'm OK with have field values as long as they are not added "silently"
>> to the either the schematic or the netlist output.  I recommend that we
>> revert to the previous behavior for the v5 release (at least it is a
>> known in spite of it's flaws) and reset the associated bug report
>> status.  Then make the following changes early in v6 development for a
>> v5 point release:
>>
>> Remove the "silent" add template fields behavior from the symbol
>> properties dialog.
>>
>> Add a button to the symbol properties dialog to add the template fields
>> to the symbol.
>>
>> Add an option in the template field option panel to add the template
>> fields to symbols as they are added to the schematic.
>>
>> Add a menu command and possibly a toolbar button to add the template
>> fields to all symbols in the schematic.
>>
>> Any adding of template fields assumes that any duplicate existing symbol
>> fields will not be overwritten.
>>
>> During v6 development, I would like to see the storage of the template
>> fields moved from the Eeschema config file to the default project file.
>> This would allow users to define project specific template fields.  I
>> could see this being useful for consultants who lay out boards for
>> multiple customers with differing BOM requirements.
>>

 The internal struct name (TEMPLATE_FIELDNAME) suggests this might have 
 been the intention at some point.

 This walks a fine line on the string freeze.  We need to change the dialog 
 to Template Fields, but as they were named that earlier the translation 
 keys might already be in the dictionaries.
>>
>> It's possible the old template strings are still around in the
>> translation files but I suspect not.
>>

> On 29 May 2018, at 19:38, Jeff Young  wrote:
>
> We really must choose a model.  What we have is broken under either model.
>
> If they’re “default” fields, then they need to be there by default.  
> That’s what “default” means.  I understand this isn’t the model you have 
> in mind.
>
> The alternative is “seed” (or “template”) fields.  In this model they 
> must be added by the user.  But that’s NOT what the code does (either 
> before or after the recent change).  If you edit a symbol they are 
> *silently* added (as if they 

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

[Clemens Koller]

Hello!

Please don't add manufacturer/distributor's information / procurement 
informtion which will end up in the schematics as some empty or non-empty 
defaults.
Or add them as invisible/all off by default.

This will spoil version management on schematics level and supports merging 
responsibilities of the design-correctness (choosing parts and manufacturer(s) 
and their part no. to fit, incl. a coice of second source components) with 
responsibilities of the procurement (choosing dists / sourcing partners).

When you want to implement some version management and/or some product 
life-cycle management / obsolescence-management, you will very likely end up in 
a maintenance nightmare in big projects.
It became also more common that manufacturer names and mfg part numbers keep 
changing over the lifetime od a design. See: 
Motorola->Freescale->NXP(->Qualcomm?) chain of aquisitions.

I strongly suggest to split the design data from the manufacturer data from the 
dist/supply chain data.
It is so easy to put some database connectivity in between to link these 
together to stay flexible.

Regards,

Clemens


On 2018-05-29 14:54, Reece R. Pollack wrote:
> On 05/29/18 08:27, Jeff Young wrote:
>> Comments inline:
>>
>>> On 28 May 2018, at 17:28, Reece R. Pollack >> > wrote:
>>>
>>> I believe you owe me 2c. We can discuss 2c in which currency later. :-)
>>>
>>> I have five custom default fields defined:
>>>  - Mfgr
>>>  - Mfgr P/N
>>>  - Dist
>>>  - Dist P/N
>>>  - Specifications
>>
>> None of these have any default values that make any sense, so I assume 
>> they’re all just names with empty values, right?
> 
> Yes, all of these are empty by default, though I typically order from DigiKey 
> so I could have set that one. I added them as "Default Fields" so that all 
> components would have the same fields, and I wouldn't have to depend on 
> adding the field names by hand.
> 
>>
>>>
>>> The first two give the manufacturer's name and part number; the second two 
>>> give the distributor's name and part number; the third is a catch-all for 
>>> specs that are important for ordering but aren't worth cluttering the 
>>> schematic with.
>>>
>>> My biggest issue with the current Default Fields is that I didn't start my 
>>> current project with them, so using the field edit spreadsheet-like thingie 
>>> often results in lots of noise in my commits as the empty default fields 
>>> get added to components.
>>
>> If it’s adding empty default fields then it’s a bug.  It should only add 
>> them if they have non-empty values.
> 
> Then you have a bug. Here's a small excerpt from a Git diff where a lot of 
> components had empty fields added. None of these components were added in 
> this revision; I was simply setting part numbers for /other/ components using 
> the field editor spreadsheet thingie:
> 
> diff --git a/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch 
> b/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch
> index 37482ee..e2aea43 100644
> --- a/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch 
> +++ b/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch 
> @@ -22,6 +22,11 @@ F 0 "U12" H 3900 2215 50   C CNN
>  F 1 "74LVC1T45" H 3900 2124 50   C CNN
>  F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 1850 50  0001 C CNN
>  F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 1850 50  0001 
> C CNN
> +F 4 "" H 0   0   50  0001 C CNN "Distr"
> +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
> +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
> +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
> +F 8 "" H 0   0   50  0001 C CNN "Specifications"
>     1    3900 1850
>     1    0    0    -1 
>  $EndComp
> @@ -33,6 +38,11 @@ F 0 "U13" H 3900 3415 50   C CNN
>  F 1 "74LVC1T45" H 3900 3324 50   C CNN
>  F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 3050 50  0001 C CNN
>  F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 3050 50  0001 
> C CNN
> +F 4 "" H 0   0   50  0001 C CNN "Distr"
> +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
> +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
> +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
> +F 8 "" H 0   0   50  0001 C CNN "Specifications"
>     1    3900 3050
>     1    0    0    -1 
>  $EndComp
> @@ -66,6 +86,11 @@ F 0 "J5" H 7719 1375 50   C CNN
>  F 1 "Conn_01x06" H 7719 1466 50   C CNN
>  F 2 "Connector_PinHeader_2.54mm:PinHeader_1x06_P2.54mm_Vertical" H 7800 1900 
> 50  0001 C CNN
>  F 3 "~" H 7800 1900 50  0001 C CNN
> +F 4 "" H 0   0   50  0001 C CNN "Distr"
> +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
> +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
> +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
> +F 8 "" H 0   0   50  0001 C CNN "Specifications"
>     1    7800 1900
>     1    0    0    -1 
>  $EndComp
> @@ -209,6 +234,7 @@ F 4 "CTS" H 3900 7100 50  0001 C CNN "Mfgr"
>  F 5 "218-4LPST" H 3900 7100 50  0001 C CNN "Mfgr P/N"
>  F 6 "DigiKey" H 3900 7100 50  0001 C CNN 

Re: [Kicad-developers] Name change in 6.0 pad properties

[Clemens Koller]

On 2018-05-23 14:25, Jeff Young wrote:
> I think "Pad clearance" is even better.

Hmm... I think it's still not precise enough. Pad-to-what-clearance?

Pad to Pad, Pad to Solder Mask, Pad to Board Outline, ...?

Regards,

Clemens

> 
>> On 23 May 2018, at 13:03, Wayne Stambaugh  wrote:
>>
>> On 5/23/2018 5:36 AM, Jeff Young wrote:
>>> I’ve always found the name “Net pad clearance” odd in the pad properties 
>>> dialog.
>>>
>>> I’m proposing to change it to “Copper clearance” to better match “Solder 
>>> mask clearance” and “Solder paste clearance”.
>>
>> Perhaps "Pad clearance" would work as well.  Copper doesn't always imply
>> a pad but given that this is the pad properties dialog, I guess you
>> could assume copper implied the pad itself.
>>
>>>
>>> (As a side note I’m also changing “Thermal relief width” to “Thermal relief 
>>> spoke width”, but I assume that’s non-controversial.)
>>
>> This makes sense to me.
>>
>>>
>>> Cheers,
>>> 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

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

[Clemens Koller]

Thank you for your feedback:

On 2018-05-22 17:21, Strontium wrote:
> Hello Everyone,
> 
> I like the patch, and hope it makes it in.
> 
> Clemens,  I don't think anything that is being discussed is in any way 
> going to constrain b) or c).  But I think there is a third group, not just
> 
> 1. Big Manufacturers
> 2. Hobbyist/Student
> 
> but
> 
> 3. Small Scale Professional Manufacturer.

You've put up this list of use-cases/organization sizes. This is off course not 
complete of you just take my two examples and make it 1. and 2.

Regards,

Clemens

___
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] More default fields in schematic

[Clemens Koller]

Hello, everybody!

Just my five cents:
Can we somehow make sure that people understand and consider and Kicad reflects 
the differences in:

a) Unique partname + associated footprint + other arbitrary parameters 
necessary for the board design.

b) One or more qualified components from a manufacturer + a unique manufacturer 
number to be assembled on a).

c) One or more distributors or manufacturers or representatives to get one ore 
more of the b)'s.

In my case, it would be sufficient for Kicad to be able to handle a) only.
b) and c) are neither standardized nor flexible enough to be handled by most 
EDA systems, when there is more than one EDA system in use.
b) and c) is handled i.e. by SAP at one of my manufacturers site and some 
Generators + Tools + MariaDB at my place.

So, there is an n x m matrix of demands for b) and c) which makes IMO no sense 
to code in one EDA system if you look at the big picture how industrial 
electronics design happens nowadays. Off course I am not talking about hobbyist 
or academic use cases.

Regards,

Clemens

On 2018-05-22 14:52, Ben Hest wrote:
> From a Digi-Key KiCad library standpoint, as we're still in beta, I would 
> gladly change the fields to whatever would be decided.  Uniformity for 
> plugins use would definitely be an advantage.
> 
> -Ben 
> 
> On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark 
> > wrote:
> 
> Thanks! This is exactly what i was going for, non-intrusive oppurtunity
> for uniformity!
> 
> I tested the bom2csv plugin, It did not include the empty fields.
> 
> I also tested the bom_csv_sorted_by_ref, it did not include the empty
> values, but it included some values I had not specified, such as
> Manufacturer and Vendor even if they were not provided in the
> schematic.
> 
> - Kristoffer
> 
> On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
> > I think I like this new patch.  It provides the /opportunity/ for
> > uniformity, without getting in the way of those who want to go their
> > own way.
> >
> > Do the BOM generators automatically output all default fields or only
> > those with values?
> >
> > > On 22 May 2018, at 09:22, kristoffer ödmark  > > il.com > wrote:
> > >
> > > Please disregard my previous mail, it got mangled badly somehow, it
> > > did
> > > not look like that in my editor at least.
> > >
> > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
> > > > Eeschema already supports creating default optional fields in the
> > > > configuration settings dialog.  Used correctly, these will give
> > > > you
> > > > the
> > > > same optional field names for every project without having to add
> > > > them
> > > > by hand to each symbol and possibly typing in different field
> > > > names
> > > > by
> > > > accident. 
> > >
> > > Different users will still type in different field names for the
> > > same
> > > things though. What you describe works as long as there is only one
> > > person in the entire projects lifetime, using only one computer.
> > >
> > > > The proposed patch would intermingle the default fields
> > > > with
> > > > existing schematic symbol fields which would break existing BOMs
> > > > which I
> > > > don't think users will appreciate. 
> > >
> > > The proposed patch will only change default settings, existing
> > > users
> > > with a config already in place will not be affected. I realised
> > > that
> > > the fields now accept empty values as well, so existing boms on new
> > > installations will not be affected either. I updated the patch, so
> > > it
> > > will not affect anyone that doesnt use the fields.
> > >
> > > > [...] As I've stated before, I can set 10
> > > > different designers down and I will get 10 different sets of
> > > > default
> > > > field names.  This really seems like me to be a configuration
> > > > issue.
> > >
> > > This is the problems I want to address, because those 10 designers
> > > will
> > > by experience also spell the same field in 10 different ways.
> > > Making
> > > their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc. Let
> > > those 10 designers remove the fields they do not want instead.
> > >
> > > > The only possible solution that I would accept is to move the
> > > > default
> > > > field definitions from the eeschema configuration file into the
> > > > default
> > > > kicad project file.  This way existing projects would not be
> > > > polluted
> > > > with the proposed default fields and users could define their own
> > > > default fields in a custom project file. 
> > >
> > > Default fields does not pollute if they are empty, they 

Re: [Kicad-developers] Netlist file extensions

[Clemens Koller]

Hi!

I was digging quite a lot in Mentor PADS's ASCII stuff in the past. Some lately 
introduced "features" are still undocumented but not too difficult to guess.
If somebody needs some help in testing/debugging in that area, please let me 
know.

Regards,

Clemens

On 2018-04-19 10:54, Marco Ciampa wrote:
> On Thu, Apr 19, 2018 at 10:34:24AM +0200, Clemens Koller wrote:
>> I strongly belief that Mentor PADS 9.x.y...VX.x.y does _not_ rely on the 
>> file extension to work correctly.
>> However it makes loading of the file more simple as file dialogs ask for 
>> ".asc" or ".txt".
>>
>> The header / first lines look important - i.e.:
>>
>> Netlist:
>> !PADS-POWERPCB-V9.0-METRIC! NETLIST FILE FROM PADS LOGIC VVX.1.2
>> *REMARK* P1234-XYZ-2.3.4.sch -- Fri May 06 11:56:49 2017
>> *REMARK*  
> 
> Looks a job for BSD's file/magic/libmagic tools to me ...
> 
> --
> 
> 
> 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

Re: [Kicad-developers] Netlist file extensions

[Clemens Koller]

I strongly belief that Mentor PADS 9.x.y...VX.x.y does _not_ rely on the file 
extension to work correctly.
However it makes loading of the file more simple as file dialogs ask for ".asc" 
or ".txt".

The header / first lines look important - i.e.:

Netlist:
!PADS-POWERPCB-V9.0-METRIC! NETLIST FILE FROM PADS LOGIC VVX.1.2
*REMARK* P1234-XYZ-2.3.4.sch -- Fri May 06 11:56:49 2017
*REMARK*  

*PART*   ITEMS
J1  CON-SAM-FT5-RA-30@CON-SAM-FT5-RA-30
X1  MTG-340-600@MTG-340-600
C1  C-3216M-N/A@C-3216M
C67 C-1005M-103-25V-X7R@C-1005M
...

Schematic:
*PADS-LOGIC-V9.0* DESIGN EXPORT FILE FROM PADS LOGIC VVX.1.2
*SCH*GENERAL PARAMETERS OF THE SCHEMATIC DESIGN"

CUR SHEET12 Current Active Sheet
USERGRID 100100 Design and Label/Text grid settings
...

Layout:
!PADS-POWERPCB-V10.0-BASIC! DESIGN DATABASE ASCII FILE 1.0
*PCB*GENERAL PARAMETERS OF THE PCB DESIGN

UNITS1  2=Inches 1=Metric 0=Mils
USERGRID 15 15  Space between USER grid points
MAXIMUMLAYER 8  Maximum routing layer 
...

Regards,

Clemens

On 2018-04-19 01:27, Wayne Stambaugh wrote:
> If no one can confirm that other EDA applications require a fixed file
> extension to work correctly, I would leave it as is.  If there is any
> requirement later, we can always tweak it as part of a bug fix release.
> 
> Cheers,
> 
> Wayne
> 
> On 04/18/2018 07:06 PM, Jeff Young wrote:
>> If no one else is familiar with this either then we can just go with
>> what we have now.
>>
>> But I thought I’d ping the dev group one more time in case someone does….
>>
>> Cheers,
>> Jeff.
>>
>>
>>> On 26 Mar 2018, at 01:04, Jeff Young >> > wrote:
>>>
>>> The PADS-PCB netlist evidently needs an extension of .asc to be read
>>> correctly[1].
>>>
>>> I implemented a reg-ex which takes the pen-ultimate file extension
>>> from the XSL file and applies it to the output file.  So the script
>>> for the above-mentioned netlist exporter is now:
>>>
>>> netlist_form_pads-pcb.asc.xsl
>>>
>>> Would any of the other XLS scripts benefit from this?  I don’t know
>>> enough about the different formats to know if they have well-known
>>> extensions.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>> [1] https://bugs.launchpad.net/kicad/+bug/1591779
>>> ___
>>> 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

Re: [Kicad-developers] Fwd: Right to use KiCad name / logo

[Clemens Koller]

On 2018-04-16 07:33, Mark Roszko wrote:
>> "No national law applies" could be either difficult or beneficial for KiCad 
>> in the case of an infringement.
> 
> That doesn't prevent CERN's right as an entity to assert trademark claims in 
> any country where they registered as an entity and claimed trademarks via 
> applications.
> The same way me as an American can go register trademarks in Europe. They can 
> do the same. The statement on wiki is more related to other legal 
> jurisdiction issues.
> CERN already holds a few trademarks and they have a legal team as they are 
> quite largeso best to assume they know what they are doing. (Not that one 
> can't ask other lawyers)

Thank you for your clarification.
Propably it's just good to ask their legal team what they suggest in KiCad's 
case.

Clemens

___
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] Able to install KiCad stable and "daily build" in same computer

[Clemens Koller]

I would pretty much vote to use the IMO more common naming scheme for major 
package versions:

kicad (the current one installed from the repository of your choice)
kicad4 (currently: 4.0.7)
kicad5 (currently: 5.0.0-rc2-dev...)
kicad6 (tbd.)

...avoiding the ".v5" i've seen lately.

I believe there is less demand for different minor versions installed next to 
each other, however it would be a nice-to-have.
(So... a user-selectable configuration might help: $ kicad -c projectconfig.cfg)

Regards,

Clemens

On 2018-04-12 09:33, Strontium wrote:
> After considering my patch, what about the following proposal:
> 
> Just change the hard coded string in common.cpp (at around line 243) from:
> 
> cfgpath.AppendDir( wxT( "kicad" ) );
> 
> to
> 
> cfgpath.AppendDir( wxT( "kicad.v5" ) );
> 
> (or some other string)
> 
> Thats it.  Then Kicad Version 5 will have a unique configuration 
> directory that will not conflict with version 4.
> 
> If an end user wants to bring their kicad V4 configuration over to v5, 
> they just copy it themselves.  Otherwise it starts with a brand new 
> blank configuration.  Alternatively packaging might be able to copy it 
> over.  But i don't see any real need to do it for the user at that 
> stage.  Its just a complication.
> 
> Then when the development branch is forked, just rename this again to 
> something like:
> cfgpath.AppendDir( wxT( "kicad.v6dev" ) );
> 
> (or whatever).
> 
> Then an end user can have V4, V5 and a Nightly all on the same machine 
> and configurations won't conflict.
> 
> Anything more exotic can be deferred to V6 development.
> 
> Steven
> 
> 
> 
> 
> On 08/04/18 13:33, Carsten Schoenert wrote:
>> Am 07.04.18 um 17:34 schrieb Strontium:
>>> Attached is a patch for discussion only.
>>>
>>> Its the minimum change I could come up with to implement a unique
>>> version specific config directory.
>>>
>>> Nick mentioned changing XDG_CONFIG_HOME, that will not work on Windows
>>> or Mac.
>>> And on Linux, etc it will change from "~/.config/kicad" to
>>> "~/somethingelse/kicad" which would work, but isn't a very friendly
>>> naming scheme.
>> Changing XDG_CONFIG_HOME itself wouldn't be correct. XDG_CONFIG_HOME is
>> pointing to '$HOME/.config' and XDG_DATA_HOME is referencing to
>> $HOME/.local/share.
>>
>> I'm sure Windows and Mac have similar variables for the folders that
>> should contain the logical same content.
>>
>> The path to the KiCad user config must based on such variables plus the
>> preferred name for the config folder, so like kicad-5 (for KiCad5) and
>> kicad-6 (for future version KiCad6) and kicad-nightly (for devel
>> version). GTK is doing this for a long time.
>>
>>> $ find  ~/.config -type d -name gtk*
>>> /home/carsten/.config/gtk-3.0
>>> /home/carsten/.config/gtk-2.0
>> If KiCad will introduce some version specific user config and data
>> folders (which I appreciate to see) it will be needed to configured by
>> the build environment and not hard-coded in the binaries. The variables
>> can be overwritten with some additional value given while starting the
>> applications.
>>
>> e.g.
>> take the default folders
>> $ kicad
>>
>> override the setting for the default config etc.
>> $ KICAD_XDG_CONFIG_HOME=/my/special/folder kicad
>>
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Fwd: Right to use KiCad name / logo

[Clemens Koller]

Hi!

On 2018-04-11 16:06, jp charras wrote:
> I am fine to register Kicad under CERN.
> (I am not especially interested in having it under my name.)

I am wondering if there might be legal difficulties in the case of trademark 
enforcement procedures, because of some "special" legal state of CERN owning 
the trademark.

The german Wikipedia page says:
Das CERN befindet sich auf schweizerischem und französischem Staatsgebiet; 
daher gilt kein nationales Recht. 
"No national law applies" could be either difficult or beneficial for KiCad in 
the case of an infringement.

A different idea might be to found i.e. a (non-profit) Limited ((gemeinnützige) 
GmbH) and have the Limited holding all the rights.
Several people (developers) can then be a "Gesellschafter" (shareholder or 
partner) of the GmbH.

Maybe it's good to ask a lawyer with focus on international intelectual 
property law for a hint.

Regards,

Clemens

___
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] Able to install KiCad stable and "daily build" in same computer

[Clemens Koller]

Does it make sense to include the major version in the package name as well, 
just to give it a grab handle?

kicad4-4.0.7
kicad5-5.0.0
kicad5-nightly

See qt, gtk, ...

Regards,

Clemens

On 2018-04-06 08:01, Strontium wrote:
> Hi Wayne,
> 
> I agree with you about scope creep, however I do see issues for users.
> 
>  From an end user perspective V5 is a big change. I noticed big changes 
> just from missing nightly updates for 2 months.  There may be an 
> extended period of time when a user will want to run both versions, for 
> many reasons.
> 
> 
> On 06/04/18 01:54, Wayne Stambaugh wrote:
>> We should defer this to v6 unless the fix is simple with little or no
>> risk of introducing new bugs.  I know it would be nice to have but I
>> could say that about a lot of things.  Scope creep will prevent us from
>> ever delivering v5.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 4/5/2018 12:25 PM, Seth Hillbrand wrote:
>>> If we are going to support multiple versions, on the developer side, we
>>> should add a preference versioning to the user configuration directory.
>>> Otherwise, fp-lib-table will being either pointing to v4 or v5
>>> footprints.  Likewise, there are a few preferences that only exist in v5
>>> and will be lost when v4 saves the preference file.
>>>
>>> To avoid cluttering the config directory, we could place the v5
>>> configurations in a v5 sub directory.  Configurations would be
>>> preferentially loaded from the v5 directory with a fall-back to the v4
>>> items if v5 items were not found.  Configurations would only be saved to
>>> the v5 subdir.
> I agree with this, except I think we should ONLY read the V4 config 
> once, when the program detects there is no V5 config sub directory at 
> all.  After the V5 config is made and saved, the V4 config should be 
> ignored, and they should diverge from that point.
> 
> I don't know this code at all, but If no one else is doing it, I can try 
> and look at it over the weekend.  But I wont waste time if the decision 
> is already final.
> 
> If we don't do this can I propose that the V5 packaging make a backup of 
> the V4 config so that end users at least have the option of reverting 
> without their config being lost.
> 
> Steven
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] FYI: New format for Gerber Job file, replacing the old one.

[Clemens Koller]

Meh... sorry for the noise. It's propably too late already... you were talking 
about the fob file (only).

Clemens

On 2018-03-19 22:54, Clemens Koller wrote:
> On 2018-03-19 15:44, jp charras wrote:
>> I committed a change for the Gerber job file created by Pcbnew.
> 
> Commit ID: 2ff74cb
> 
> On 2018-03-19 15:44, jp charras wrote:
>> Gerbview can also real the "old format", but because it is deprecated, I'll 
>> remove the code to read
>> and write this old format (no more existing) in the future.
> 
> Why do you want to remove (more or less, IMO non-conflicting) working code?
> I use Gerbview not only for Gerber files generated by pcbnew.
> 
> Regards,
> 
> Clemens
> 
> On 2018-03-19 15:44, jp charras wrote:
>> I committed a change for the Gerber job file created by Pcbnew.
>>
>> According to the last changes for the .gbrjob file format made by Ucamco, 
>> this file uses now a JSON
>> syntax, and has much more info for board stackup (thickness, dielectric 
>> parameters, colors ...)
>>
>> Therefore Pcbnew generates this file using the latest file format 
>> specification, and Gerbview can
>> read this file to load the full set of Gerber plot files.
>>
>> Gerbview can also real the "old format", but because it is deprecated, I'll 
>> remove the code to read
>> and write this old format (no more existing) in the future.
>>
>> Note also some of the new parameters added to this JSON file format were 
>> added after some
>> suggestions from Kicad users about the old file format, some times ago.
>>
>> Please, test it.
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] FYI: New format for Gerber Job file, replacing the old one.

[Clemens Koller]

On 2018-03-19 15:44, jp charras wrote:
> I committed a change for the Gerber job file created by Pcbnew.

Commit ID: 2ff74cb

On 2018-03-19 15:44, jp charras wrote:
> Gerbview can also real the "old format", but because it is deprecated, I'll 
> remove the code to read
> and write this old format (no more existing) in the future.

Why do you want to remove (more or less, IMO non-conflicting) working code?
I use Gerbview not only for Gerber files generated by pcbnew.

Regards,

Clemens

On 2018-03-19 15:44, jp charras wrote:
> I committed a change for the Gerber job file created by Pcbnew.
> 
> According to the last changes for the .gbrjob file format made by Ucamco, 
> this file uses now a JSON
> syntax, and has much more info for board stackup (thickness, dielectric 
> parameters, colors ...)
> 
> Therefore Pcbnew generates this file using the latest file format 
> specification, and Gerbview can
> read this file to load the full set of Gerber plot files.
> 
> Gerbview can also real the "old format", but because it is deprecated, I'll 
> remove the code to read
> and write this old format (no more existing) in the future.
> 
> Note also some of the new parameters added to this JSON file format were 
> added after some
> suggestions from Kicad users about the old file format, some times ago.
> 
> Please, test it.
> 

___
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] - File format shim for clearance data

[Clemens Koller]

Hi!

On 2018-03-07 13:44, Tomasz Wlostowski wrote:
> I'm not totally opposed to hauptmech's change, I just think it's too
> early to merge it. We should discuss such ideas before writing code. My
> goal for V6 DRC is to be able to define clearance rules for at least:
> - per-net & per-netclass
> - per-layer
> - user-defined board areas.

Add: - for components
Higher priority rules override lower priority ones. Priorities are predefined 
and/or can be changed manually.
That's not extremely complex but it still needs a lot of work and proper 
planning beforehand.

Regards,

Clemens

___
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] GerbView: Severe bug: ASSERT on Startup

[Clemens Koller]

Debug build of SHA1 ID: 5a33f09
KiCad-from-scratch (no configs, etc...)
When I open GerbView, I immediately get:


ASSERT INFO:
./src/gtk/scrolwin.cpp(227): assert "scrolled" failed in DoShowScrollbars(): 
window must be created

BACKTRACE:
[1] wxScrollHelper::DoShowScrollbars(wxScrollbarVisibility, 
wxScrollbarVisibility)
[2] wxEntry(int&, wchar_t**)
[3] __libc_start_main
[4] _start

-8<-

Application: gerbview
Version: (5.0.0-rc2-dev-101-g525270ac2), debug build
Libraries:
wxWidgets 3.0.3
libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
(+libidn2/2.0.4) nghttp2/1.30.0
Platform: Linux 4.15.6-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.66.0
Curl: 7.58.0
Compiler: GCC 7.3.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


Regards,

Clemens

___
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] [deadly serious feature request] Use PNS for components as well as traces using rigid body simulation.

[Clemens Koller]

Hi!

I am wondering how difficult it might get to apply the Push & Shove idea also 
to components including all attached traces and use rigid body simulation of a 
physics engine to get it pushed and shoved around?

Quick & Dirty ideas: KiCad exports as .SVG. Blender imports .SVG.
The rest is easy, as you can see: [Blender Tutorial - Quick Rigid Body Fun] 
https://www.youtube.com/watch?v=nHVYYMG3QVY

Can we put that on the roadmap for V7 ??!  8-)

Regards,

Clemens

___
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] GerbView: ASSERT: wxRound(): argument out of supported range

[Clemens Koller]

On 2018-02-27 23:59, Nick Østergaard wrote:
> Also, you need to add version info.

latest-git as of today / last hour: commit eb94d2f
(with my patch: GerbView: Minor cleanup of Menus + Toolbar for consistency.)
on Arch Linux

Application: kicad
Version: (5.0.0-rc2-dev-30-geb94d2fcd-dirty), debug build
Libraries:
wxWidgets 3.0.3
libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
(+libidn2/2.0.4) nghttp2/1.30.0
Platform: Linux 4.15.5-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.66.0
Curl: 7.58.0
Compiler: GCC 7.3.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


Regards,

Clemens

> 
> 2018-02-27 23:52 GMT+01:00 Jon Evans <j...@craftyjon.com 
> <mailto:j...@craftyjon.com>>:
> 
> It's certainly fine, but if you have time to report them on Launchpad too 
> it makes sure we don't let them slip through the cracks!
> 
> Thanks
> 
> -Jon
> 
> On Tue, Feb 27, 2018 at 5:51 PM, Clemens Koller <c...@embeon.de 
> <mailto:c...@embeon.de>> wrote:
> 
> Hi!
> 
> I hope you don't mind feeding you with more bug reports... ;-)
> 
> In GerbView I open two Gerber files from the gerber_test_files:
> apertures_rotated_and_arcs_in_tracks.gbr and
> test_polygons_with_arcs.gbr
> 
> When I choose Miscellaneous -> List DCodes, I run into the following 
> assertion:
> 
> ASSERT INFO:
> ./include/wx/math.h(151): assert "x > INT_MIN - 0.5 && x < INT_MAX + 
> 0.5" failed in wxRound(): argument out of supported range
> 
> BACKTRACE:
> [1] wxDCImpl::DeviceToLogicalY(int) const
> [2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase 
> const&, wxEvtHandler*, wxEvent&)
> [3] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
> [4] wxEvtHandler::TryHereOnly(wxEvent&)
> [5] wxEvtHandler::DoTryChain(wxEvent&)
> [6] wxEvtHandler::ProcessEvent(wxEvent&)
> [7] wxWindowBase::TryAfter(wxEvent&)
> [8] wxEvtHandler::SafelyProcessEvent(wxEvent&)
> [9] wxMenuBase::SendEvent(int, int)
> [10] g_closure_invoke
> [11] g_signal_emit_valist
> [12] g_signal_emit
> [13] gtk_widget_activate
> [14] gtk_menu_shell_activate_item
> [15] g_closure_invoke
> [16] g_signal_emit_valist
> [17] g_signal_emit
> [18] gtk_propagate_event
> [19] gtk_main_do_event
> [20] g_main_context_dispatch
> [21] g_main_loop_run
> [22] gtk_main
> [23] wxGUIEventLoop::DoRun()
> [24] wxEventLoopBase::Run()
> [25] wxAppConsoleBase::MainLoop()
> [26] wxEntry(int&, wchar_t**)
> [27] __libc_start_main
> [28] _start
> 
> Regards,
> 
> Clemens
> 
> ___
> 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>
> 
> 
> 
> ___
> 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>
> 
> 

___
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] GerbView: BUG: Switching to Sketch Mode doesn't get applied when in Accelerated Toolset

[Clemens Koller]

The last one for today:

GerbView: 
Load any gerber test file.
While in Modern Toolset (Accelerated) I choose Preferences - Options - Sketch 
modes for Flashed items, Lines, Polygons. - OK.
Bug: -> View doesn't get updated to show sketched objects.
When I switch then to another Toolset and again back, the display is correct.

I'll try to feed Launchpad with my bug-reports, when I find the time to do so. 
(I'll keep my reports marked locally, too).

Regards,

Clemens

___
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] GerbView: ASSERT: wxRound(): argument out of supported range

[Clemens Koller]

Hi!

I hope you don't mind feeding you with more bug reports... ;-)

In GerbView I open two Gerber files from the gerber_test_files:
apertures_rotated_and_arcs_in_tracks.gbr and
test_polygons_with_arcs.gbr

When I choose Miscellaneous -> List DCodes, I run into the following assertion:

ASSERT INFO:
./include/wx/math.h(151): assert "x > INT_MIN - 0.5 && x < INT_MAX + 0.5" 
failed in wxRound(): argument out of supported range

BACKTRACE:
[1] wxDCImpl::DeviceToLogicalY(int) const
[2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&)
[3] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[4] wxEvtHandler::TryHereOnly(wxEvent&)
[5] wxEvtHandler::DoTryChain(wxEvent&)
[6] wxEvtHandler::ProcessEvent(wxEvent&)
[7] wxWindowBase::TryAfter(wxEvent&)
[8] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[9] wxMenuBase::SendEvent(int, int)
[10] g_closure_invoke
[11] g_signal_emit_valist
[12] g_signal_emit
[13] gtk_widget_activate
[14] gtk_menu_shell_activate_item
[15] g_closure_invoke
[16] g_signal_emit_valist
[17] g_signal_emit
[18] gtk_propagate_event
[19] gtk_main_do_event
[20] g_main_context_dispatch
[21] g_main_loop_run
[22] gtk_main
[23] wxGUIEventLoop::DoRun()
[24] wxEventLoopBase::Run()
[25] wxAppConsoleBase::MainLoop()
[26] wxEntry(int&, wchar_t**)
[27] __libc_start_main
[28] _start

Regards,

Clemens

___
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] [PATCH] GerbView: Minor cleanup of Menus + Toolbar for consistency.

[Clemens Koller]

replace: File -> File(s) when wxFD_MULTIPLE
replace: Load -> Open
replace: Erase -> Clear
add Excellon / Gerber where it makes sense
re-sort File menu

Regards,

Clemens
>From 058dc2b1eea83876f314eaa338c7193af52fdbb5 Mon Sep 17 00:00:00 2001
From: Clemens Koller <c...@embeon.de>
Date: Tue, 27 Feb 2018 23:30:50 +0100
Subject: GerbView: Minor cleanup of Menus + Toolbar for consistency.

replace: File -> File(s) when wxFD_MULTIPLE
replace: Load -> Open
replace: Erase -> Clear
add Excellon / Gerber where it makes sense
re-sort File menu

diff --git a/gerbview/files.cpp b/gerbview/files.cpp
index 381ade3f5..9bd899e2c 100644
--- a/gerbview/files.cpp
+++ b/gerbview/files.cpp
@@ -197,7 +197,7 @@ bool GERBVIEW_FRAME::LoadGerberFiles( const wxString& aFullFileName )
 currentPath.RemoveLast();
 }
 
-wxFileDialog dlg( this, _( "Open Gerber File" ),
+wxFileDialog dlg( this, _( "Open Gerber File(s)" ),
   currentPath,
   filename.GetFullName(),
   filetypes,
@@ -337,7 +337,7 @@ bool GERBVIEW_FRAME::LoadExcellonFiles( const wxString& aFullFileName )
 else
 currentPath = m_mruPath;
 
-wxFileDialog dlg( this, _( "Open Drill File" ),
+wxFileDialog dlg( this, _( "Open Excellon Drill File(s)" ),
   currentPath, filename.GetFullName(), filetypes,
   wxFD_OPEN | wxFD_FILE_MUST_EXIST | wxFD_MULTIPLE | wxFD_CHANGE_DIR );
 
diff --git a/gerbview/menubar.cpp b/gerbview/menubar.cpp
index 9dae741ab..a3ac0ab0e 100644
--- a/gerbview/menubar.cpp
+++ b/gerbview/menubar.cpp
@@ -59,28 +59,28 @@ void GERBVIEW_FRAME::ReCreateMenuBar()
 // Menu File:
 wxMenu* fileMenu = new wxMenu;
 
-// Load Gerber files
+// Open Gerber file(s)
 AddMenuItem( fileMenu, wxID_FILE,
- _( "Load  File..." ),
- _( "Load a new Gerber file on the current layer. Previous data will be deleted" ),
+ _( "Open  File(s)..." ),
+ _( "Open Gerber file(s) on the current layer. Previous data will be deleted" ),
  KiBitmap( load_gerber_xpm ) );
 
-// Load Excellon drill files
+// Open Excellon drill file(s)
 AddMenuItem( fileMenu, ID_GERBVIEW_LOAD_DRILL_FILE,
- _( "Load  Drill File..." ),
- _( "Load excellon drill file" ),
+ _( "Open  Drill File(s)..." ),
+ _( "Open Excellon drill file(s) on the current layer. Previous data will be deleted" ),
  KiBitmap( gerbview_drill_file_xpm ) );
 
-// Load Gerber job files
+// Open Gerber job files
 AddMenuItem( fileMenu, ID_GERBVIEW_LOAD_JOB_FILE,
- _( "Load Gerber  File..." ),
- _( "Load a Gerber job file, and load gerber files depending on the job" ),
+ _( "Open Gerber  File..." ),
+ _( "Open a Gerber job file, and it's associated gerber files depending on the job" ),
  KiBitmap( gerber_job_file_xpm ) );
 
-// Load Zip archive files
+// Open Zip archive files
 AddMenuItem( fileMenu, ID_GERBVIEW_LOAD_ZIP_ARCHIVE_FILE,
- _( "Load  Archive File..." ),
- _( "Load a zipped archive (Gerber and drill) file" ),
+ _( "Open  Archive File..." ),
+ _( "Open a zipped archive (Gerber and Drill) file" ),
  KiBitmap( zip_xpm ) );
 
 // Recent gerber files
@@ -111,22 +111,8 @@ void GERBVIEW_FRAME::ReCreateMenuBar()
 m_drillFileHistory.UseMenu( openRecentDrlMenu );
 m_drillFileHistory.AddFilesToMenu( );
 AddMenuItem( fileMenu, openRecentDrlMenu, wxID_ANY,
- _( "Open Recent Dri File" ),
- _( "Open a recently opened drill file" ),
- KiBitmap( recent_xpm ) );
-
-// Recent drill files
-static wxMenu* openRecentZipArchiveMenu;
-
-if( openRecentZipArchiveMenu )
-m_zipFileHistory.RemoveMenu( openRecentZipArchiveMenu );
-
-openRecentZipArchiveMenu = new wxMenu();
-m_zipFileHistory.UseMenu( openRecentZipArchiveMenu );
-m_zipFileHistory.AddFilesToMenu( );
-AddMenuItem( fileMenu, openRecentZipArchiveMenu, wxID_ANY,
- _( "Open Recent Zip  File" ),
- _( "Open a recently opened zip archive file" ),
+ _( "Open Recent Excellon Dri File" ),
+ _( "Open a recently opened Excellon drill file" ),
  KiBitmap( recent_xpm ) );
 
 // Recent job files
@@ -139,17 +125,31 @@ void GERBVIEW_FRAME::ReCreateMenuBar()
 m_jobFileHistor

Re: [Kicad-developers] GerbView: KiCad-rc2: Layer filenames mixed up in right tab view.

[Clemens Koller]

I'm exercising GerberView's Load Gerber File more...

The filenames in the Layers tab look consistent now. :-)
When loading more Gerbers, additional files are inserted at the last selected 
Layers position, which makes sense to me.

But there is more odd behaviour: When a Layer (i.e. No. 9) is selected prior 
opening the Load Gerber File... dialog and then cancelled,
the Layer 9 is cleared and shown as Graphic layer 9. Cancle should not do that 
IMO.

Good thing btw.: identical filenames do not cause any mess. :-)

Regards,

Clemens


On 2018-02-27 20:30, Jon Evans wrote:
> Have you tried my patch from last night that re-does the sorting code?
> 
> On Tue, Feb 27, 2018 at 2:29 PM, jp charras  > wrote:
> 
> Le 27/02/2018 à 20:09, jp charras a écrit :
> > Le 27/02/2018 à 15:33, Jon Evans a écrit :
> >> This is so strange.  I just installed the nightly build on a Windows 
> machine just to see if this is
> >> a Windows specific problem, and I still don't see it.
> >>
> >> What I did:
> >>
> >> 1) Start GerbView (in OpenGL mode)
> >> 2) Load one file (using File->Open Gerber File...)
> >> 3) See that file appears on Layer 1
> >> 4) Load another file (without clicking anything in the layer manager)
> >> 5) Second file appears in Layer 2, and all colors and file names are 
> correct.
> >>
> >> Regarding your last point, I think by default the active layer is set 
> to one past the last one
> >> loaded, so if you load files in sequence, they do not overwrite each 
> other, but if you click on a
> >> layer in the layer manager (now there is a triangle indicator next to 
> it) and then load a file, it
> >> will replace the selected layer.
> >>
> >> I would much appreciate if anyone who can reproduce this can do any 
> debugging to see what is going
> >> on, since I can't reproduce it.
> >>
> >> I would expect that:
> >>
> >> 1) in GERBVIEW_FRAME::Read_GERBER_File() the first call to 
> GetActiveLayer() returns one higher than
> >> the last layer you loaded
> >> 2) then a few lines down, GetGbrImage( layers ) returns NULL and a new 
> image is created.
> >>
> >>
> >> -Jon
> >
> > Hi Jon,
> >
> > This was very strange, however I found the culprit:
> > This is in files.cpp the call (added by commit 0c9d11) to
> >     GetImagesList()->SortImagesByZOrder();
> > after loading a file.
> > This call is incorrect (especially when files are not in X2 format) 
> ,and reorder the layers, but
> > without changing the previous color of layers.
> >
> > SortImagesByZOrder() creates unexpected reorder of layers if files are 
> not using X2 format.
> > (perhaps this is a flaw in this function) and cannot be called here.
> >
> > I committed the fix that removes this call.
> >
> 
> However, this fix creates an issue: load from a gerber job file does not 
> sort layers (easy to fix),
> and sorting the layers by the context menu of the layer manager sorts the 
> layers, but colors are not
> updated.
> This is a serious regression.
> Sort layers should update color items, if the layer fo these items has 
> changed.
> You cannot expect X2 files are sorted during loading because the loading 
> order is unknown.
> 
> 
> --
> 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
> 

___
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] GerbView: Move Icon Options - Icons in Menus to Options - User Interface?

[Clemens Koller]

Hi!

UI enhancement:

GerbView:
Preferences - Icon Options - Icons in Menus seem very lonely in that menu 
position.
I suggest moving it right above the Icon scale settings in the Preferences - 
Options - User Interface section.

Regards,

Clemens

___
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] Fabrication Outputs and Plot

[Clemens Koller]

Hi!

On 2018-02-27 01:35, Andy Peters wrote:
>> There is no plan yet but it has been discussed.
> The only downside is that we will have to write our own print handling on 
> windows and I'm guessing macos.
> That's one of the reasons no one has signed up yet because it will be a large 
> undertaking.

It is possible to embed metadata into a PDF document with annotations to show 
i.e. detailed part information on a schematic on MouseOver.
This is propably more difficult to achieve when we just use the OS' brilliant 
printing subsystem to generate PDFs.

(Don't get me wrong: I do not favor complex annotations in PDFs as their 
support is severely limited in a lot of PDF readers.)

Regards,

Clemens


On 2018-02-27 01:35, Andy Peters wrote:
> On Feb 24, 2018, at 1:16 PM, Wayne Stambaugh  > wrote:
>>
>> There is no plan yet but it has been discussed.  The only downside is that 
>> we will have to write our own print handling on windows and I'm guessing 
>> macos.  That's one of the reasons no one has signed up yet because it will 
>> be a large undertaking.
> 
> PDF export is free on macOS (and has been since the very first Mac OS X 
> 10.0). If something brings up the system print dialog, there is a little 
> pulldown menu thingie in the lower-left-hand corner with PDF selected. See 
> image. It is the “printing workflows” selector. Printing means more than 
> “send to printer,” as you can “print” to a PDF or to PostScript, and then the 
> result can be saved to a file, e-mailed, messaged or otherwise shared. Click 
> on it, select “Save as PDF,” and then choose where to save it (along with 
> some other features).
> 
> I use this feature all the time. It’s brilliant.
> 
> 
> 
> 
>>
>> On 02/24/2018 02:02 PM, Jon Evans wrote:
>>> Yes I think that's the plan, just needs someone to sign up to write it :)
>>> On Sat, Feb 24, 2018, 14:00 Andrzej Wolski >>  > wrote:
>>>    Cairo have PDF, SVG and Postscript support. I was once wondering if
>>>    GAL/Cairo could be used for printing.
>>>    Andrzej
>>>    W dniu 2018-02-24 o 19:24, Jon Evans pisze:
    Yeah, there (at least) three different dialogs that all present
    similar things (i.e. a list of layers to include, settings, etc):

    Export->SVG
    Print
    Plot

    The Print code for Export->SVG seems to just use the same SVG
    plotter, so maybe it's just mostly GUI cleanup that is needed.

    The main Print code does need an overhaul to use something other
    than wxDC for graphics generation (and perhaps adding some more
    features to PDF export)

    -Jon

    On Sat, Feb 24, 2018 at 1:16 PM, Jeff Young 
    > wrote:

    Plot SVG and Export SVG are different.  The former goes
    through the Plot code while the later goes through the Print
    code.

    Do we need both?  I haven’t a clue.

    It would be nice to clean this stuff up, if there is in fact a
    clean way to present it.

    Cheers,
    Jeff.


>    On 24 Feb 2018, at 14:54, Jon Evans  
>    > wrote:
>
>    I agree with this! It has always tripped me up when I switch
>    back and forth between kicad and other EDA tools.
>
>    On Feb 24, 2018 9:31 AM, "Diego Herranz"
>     
>    > wrote:
>
>    Hi,
>
>    Now that so much work is happening on re-structuring
>    menus, I've remembered something I have always found
>    weird on pcbnew.
>
>    "Plot", from wihch you can obtain Gerbers is not inside
>    "Fabrication Outputs", but on its own.
>    I find it weird to have the drill option inside
>    "Fabrication Outputs" but not the Gerbers (they are
>    normally needed together and in fact, you can go to
>    "Drill" from "Plot").
>
>    If "Plot" was Gerber only, I would recommend moving it
>    inside "Fabrication Outputs" straight away but because it
>    also exports other formats, it's not so straightforward.
>
>    I think ideally we would have:
>
>    - Fabrication outputs
>  - Gerber...
>  - Drill
>  - ...
>    - Export
>  - STEP
>  - PDF...
>  - Postcript...
>  - DXF...
>  - ...
>
>    And I have 

Re: [Kicad-developers] GerbView: KiCad-rc2: Layer filenames mixed up in right tab view.

[Clemens Koller]

Hello, Jon!

I've tried the Gerber files from the KiCad source tree. The behaviour is also 
erratic and reproducible.
Try to load i.e. .../gerber_test_files/test-* files and then load aperture* 
files and then Ucamco*

It seems that filenames in the Tab View position 1 + 2 are stuck and new 
filenames are shown on position 3++.

Regards,

Clemens


On 2018-02-26 00:33, Jon Evans wrote:
> I'm having trouble reproducing this.  If you try opening some of the example 
> Gerber files in the kicad source tree, do you see the same issue?
> 
> On Sun, Feb 25, 2018 at 6:26 PM, Clemens Koller <c...@embeon.de 
> <mailto:c...@embeon.de>> wrote:
> 
> Hi, Jon!
> 
> The files are newly generated proprietary %FSDAX33Y33*% (without X2 
> attributes AFAICT).
> *
> *
> G04 PADS VX.1.2 Build Number: 698008 generated Gerber (RS-274-X) file*
> G04 PC Version=2.1*
> *
> %IN ".pcb"*%
> *
> %MOMM*%
> *
> %FSDAX33Y33*%
> *
> ...
> 
> I opened from a directory by File - Load Gerber File... - Shift-Clicking 
> on the files in the order I want to load them - Open.
> 
> (I need to click #no of file times to dismiss the warning dialog box 
> because of the proprietary format "%FSDAX33Y33*%", which is annoying, btw.)
> 
> Regards,
> 
> Clemens
> 
> On 2018-02-26 00:18, Jon Evans wrote:
> > Hi Clemens, do these files have Gerber X2 attributes?  What process did 
> you use to load them? (i.e. did you load one at a time; use a Gerber job 
> file, load them all at once, etc)?
> >
> > Thanks,
> > Jon
> >
> > On Sun, Feb 25, 2018 at 6:15 PM, Clemens Koller <c...@embeon.de 
> <mailto:c...@embeon.de> <mailto:c...@embeon.de <mailto:c...@embeon.de>>> 
> wrote:
> >
> >     Hi!
> >
> >     I am not absolutely sure what's going on with the layer names in 
> Gerbview. It seems that the filenames in the right layers tab view are mixed 
> up.
> >
> >     Attached is an image of a 4 layer board where the filenames were 
> selected from copper layer 1 (top) 2 3 4 (bottom) ... etc.
> >     But in the tab view, the filenames get mixed up. The 4th line 
> toggles Layer 4 (bottom, blue) but gerber_solder_mask_bot.pho would look 
> completely different.
> >
> >     Is this a known bug/work in progress?
> >     Is there some mystic ordering applied here?
> >
> >     Regards,
> >
> >     Clemens
> >
> >
> >     ___
> >     Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers> 
> <https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>>
> >     Post to     : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net> 
> <mailto:kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>>
> >     Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers> 
> <https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>>
> >     More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp> <https://help.launchpad.net/ListHelp 
> <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

[Kicad-developers] KiCad-from-scratch: GerbView/pcbnew: Startup-Dialog: Enable Acceleration only enables Modern Toolset (Fallback)

[Clemens Koller]

Hi!

Minor bug / inconsistency:

KFS: On the initial run of GerbView and Pcbnew, the Startup-Dialog to enable 
acceleration is shown. When I click on "Enable Acceleration" and check the 
Preferences, only the Modern Toolset (Fallback) is enabled, but not the Modern 
Toolset (Accelerated).

Regards,

Clemens

___
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] GerbView performance optimizations

[Clemens Koller]

What is the quickest way to git pull your changes when I want to follow you in 
real-time?

git.launchpad.net/kicad ?

On 2018-02-26 00:39, Wayne Stambaugh wrote:
> Patches merged.  Thanks!
> 
> On 02/25/2018 03:14 PM, Jon Evans wrote:
>> These patches improves redraw performance when toggling sketch/filled 
>> draw modes.
>>
>> On Linux at least, the difference is quite noticeable on complicated 
>> Gerber files.
>>
>> -Jon
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GerbView: KiCad-rc2: Layer filenames mixed up in right tab view.

[Clemens Koller]

Hi, Jon!

The files are newly generated proprietary %FSDAX33Y33*% (without X2 attributes 
AFAICT).
*
*
G04 PADS VX.1.2 Build Number: 698008 generated Gerber (RS-274-X) file*
G04 PC Version=2.1*
*
%IN ".pcb"*%
*
%MOMM*%
*
%FSDAX33Y33*%
*
...

I opened from a directory by File - Load Gerber File... - Shift-Clicking on the 
files in the order I want to load them - Open.

(I need to click #no of file times to dismiss the warning dialog box because of 
the proprietary format "%FSDAX33Y33*%", which is annoying, btw.)

Regards,

Clemens

On 2018-02-26 00:18, Jon Evans wrote:
> Hi Clemens, do these files have Gerber X2 attributes?  What process did you 
> use to load them? (i.e. did you load one at a time; use a Gerber job file, 
> load them all at once, etc)?
> 
> Thanks,
> Jon
> 
> On Sun, Feb 25, 2018 at 6:15 PM, Clemens Koller <c...@embeon.de 
> <mailto:c...@embeon.de>> wrote:
> 
> Hi!
> 
> I am not absolutely sure what's going on with the layer names in 
> Gerbview. It seems that the filenames in the right layers tab view are mixed 
> up.
> 
> Attached is an image of a 4 layer board where the filenames were selected 
> from copper layer 1 (top) 2 3 4 (bottom) ... etc.
> But in the tab view, the filenames get mixed up. The 4th line toggles 
> Layer 4 (bottom, blue) but gerber_solder_mask_bot.pho would look completely 
> different.
> 
> Is this a known bug/work in progress?
> Is there some mystic ordering applied here?
> 
> Regards,
> 
> Clemens
> 
> 
> ___
> 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>
> 
> 

___
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] GerbView: KiCad-rc2: Layer filenames mixed up in right tab view.

[Clemens Koller]

Comparison with Gerbv attached... here, the filenames are correct.
(Difference in speed is huge! btw.)

Regards,

Clemens


On 2018-02-26 00:15, Clemens Koller wrote:
> Hi!
> 
> I am not absolutely sure what's going on with the layer names in Gerbview. It 
> seems that the filenames in the right layers tab view are mixed up.
> 
> Attached is an image of a 4 layer board where the filenames were selected 
> from copper layer 1 (top) 2 3 4 (bottom) ... etc.
> But in the tab view, the filenames get mixed up. The 4th line toggles Layer 4 
> (bottom, blue) but gerber_solder_mask_bot.pho would look completely different.
> 
> Is this a known bug/work in progress?
> Is there some mystic ordering applied here?
> 
> Regards,
> 
> Clemens
> 
> 
> 
> ___
> 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

[Kicad-developers] GerbView: KiCad-rc2: Layer filenames mixed up in right tab view.

[Clemens Koller]

Hi!

I am not absolutely sure what's going on with the layer names in Gerbview. It 
seems that the filenames in the right layers tab view are mixed up.

Attached is an image of a 4 layer board where the filenames were selected from 
copper layer 1 (top) 2 3 4 (bottom) ... etc.
But in the tab view, the filenames get mixed up. The 4th line toggles Layer 4 
(bottom, blue) but gerber_solder_mask_bot.pho would look completely different.

Is this a known bug/work in progress?
Is there some mystic ordering applied here?

Regards,

Clemens

___
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] Pcbnew menu bar

[Clemens Koller]

On 2018-02-21 15:08, Jeff Young wrote:
> Yes, but not for 5.0.
> 
> See https://bugs.launchpad.net/kicad/+bug/1748680 (most of the Kicad menu 
> items will be app settings).
> 
> But this reminds me that I should probably add a task to tabularize pcbnew’s 
> preferences like we did with eeschema.

+1 for TreeView (+ Tabs only if necessary).

But before that: PLEASE use the available screen real-estate as much as 
possible! Clicking through a small tabs or dialogs makes it difficult to find 
preferences is IMO wasting time.

Imagine that dual-screen desktops (usually >1920x1080px) are standard in 
CAD/CAE workstations with the trend to add a third screen which can be stuffed 
up with the setup dialogs.

What is the minimum resolution KiCad's dialogs are supposed to fit into?

Regards,

Clemens

___
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-from-scratch: Segfault after unarchiving active project.

[Clemens Koller]

Thank you!

The patch
https://launchpadlibrarian.net/357282373/0003-Rebuild-project-tree-when-unarchiving-into-project-d.patch
fixes the crash! -> Good.

But there seems to be a minor issue left:
After Unarchive Project, the project tree also contains the .pro file as a 
branch. The .pro file disappears after hitting Refresh (or when restarting 
kicad without clearing it's config). Screenshot attached.

Regards,

Clemens

On 2018-02-16 15:22, Jeff Young wrote:
> Hi Clemens,
> 
> If you build your own Kicad, you can try the patch attached to the below bug 
> report.
> 
> Cheers,
> Jeff.
> 
>> On 16 Feb 2018, at 13:00, Jeff Young <j...@rokeby.ie 
>> <mailto:j...@rokeby.ie>> wrote:
>>
>> Thanks, Clemens.  I can reproduce this easily.
>>
>> Logged as: https://bugs.launchpad.net/kicad/+bug/1749955
>>
>> Cheers,
>> Jeff.
>>
>>
>>> On 16 Feb 2018, at 12:14, Clemens Koller <c...@embeon.de 
>>> <mailto:c...@embeon.de>> wrote:
>>>
>>> Attaching debug information of GDB session:
>>>
>>> -8<-
>>> [...]
>>> [New Thread 0x7fffe6711700 (LWP 24139)]
>>> [Thread 0x7fffe6711700 (LWP 24139) exited]
>>> SetProjectFullName: old:'' 
>>> new:'/home/admin/share/project/kicad/project/test9/test9.pro'
>>> 13:10:42: Debug: FileWatcherReset: watched paths:
>>> 13:10:42: Debug:  /home/admin/share/project/kicad/project/test9/
>>>
>>> [Thread 0x7fffe6f12700 (LWP 24135) exited]
>>> [New Thread 0x7fffe6f12700 (LWP 24149)]
>>> [New Thread 0x7fffe6711700 (LWP 24150)]
>>> [New Thread 0x7fffd5c56700 (LWP 24151)]
>>> [Thread 0x7fffe6f12700 (LWP 24149) exited]
>>> [Thread 0x7fffe6711700 (LWP 24150) exited]
>>> [New Thread 0x7fffe6711700 (LWP 24152)]
>>> [Thread 0x7fffd5c56700 (LWP 24151) exited]
>>>
>>> Thread 1 "kicad" received signal SIGSEGV, Segmentation fault.
>>> 0x555fc6da in TREEPROJECT_ITEM::GetType (this=0x0) at 
>>> /home/admin/share/project/kicad/kicad-dev/kicad.git/kicad/treeproject_item.h:56
>>> 56TreeFileType GetType() const    { return m_Type; }
>>> (gdb) bt
>>> #0  0x555fc6da in TREEPROJECT_ITEM::GetType() const (this=0x0) at 
>>> /home/admin/share/project/kicad/kicad-dev/kicad.git/kicad/treeproject_item.h:56
>>> #1  0x555ffbfb in TREEPROJECTFILES::OnCompareItems(wxTreeItemId 
>>> const&, wxTreeItemId const&) (this=0x55abd1d0, item1=..., item2=...)
>>>    at 
>>> /home/admin/share/project/kicad/kicad-dev/kicad.git/kicad/treeprojectfiles.cpp:95
>>> #2  0x76f1830d in  () at /usr/lib/libwx_gtk2u_core-3.0.so.0
>>> #3  0x735a07a6 in msort_with_tmp.part () at /usr/lib/libc.so.6
>>> #4  0x735a09f6 in qsort_r () at /usr/lib/libc.so.6
>>> #5  0x76f17386 in wxGenericTreeCtrl::SortChildren(wxTreeItemId 
>>> const&) () at /usr/lib/libwx_gtk2u_core-3.0.so.0
>>> #6  0x555faa28 in 
>>> TREE_PROJECT_FRAME::OnFileSystemEvent(wxFileSystemWatcherEvent&) 
>>> (this=0x55a21c60, event=...)
>>>    at 
>>> /home/admin/share/project/kicad/kicad-dev/kicad.git/kicad/tree_project_frame.cpp:995
>>> #7  0x76575d4e in 
>>> wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
>>> wxEvtHandler*, wxEvent&) () at /usr/lib/libwx_baseu-3.0.so.0
>>> #8  0x7657616b in wxEvtHandler::SearchDynamicEventTable(wxEvent&) 
>>> () at /usr/lib/libwx_baseu-3.0.so.0
>>> #9  0x76576200 in wxEvtHandler::TryHereOnly(wxEvent&) () at 
>>> /usr/lib/libwx_baseu-3.0.so.0
>>> #10 0x765762b4 in wxEvtHandler::ProcessEventLocally(wxEvent&) () at 
>>> /usr/lib/libwx_baseu-3.0.so.0
>>> #11 0x76576316 in wxEvtHandler::ProcessEvent(wxEvent&) () at 
>>> /usr/lib/libwx_baseu-3.0.so.0
>>> #12 0x7656dd6e in  () at /usr/lib/libwx_baseu-3.0.so.0
>>> #13 0x76573802 in  () at /usr/lib/libwx_baseu-3.0.so.0
>>> #14 0x7657435c in  () at /usr/lib/libwx_baseu-3.0.so.0
>>> #15 0x76569665 in  () at /usr/lib/libwx_baseu-3.0.so.0
>>> #16 0x76cbe03d in  () at /usr/lib/libwx_gtk2u_core-3.0.so.0
>>> #17 0x71fa7ca6 in g_main_context_dispatch () at 
>>> /usr/lib/libglib-2.0.so.0
>>> #18 0x71fa8081 in  () at /usr/lib/libglib-2.0.so.0
>>> #19 0x71fa83b2 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
>>> #20 0x73058df3 in gtk_main () at /usr/lib/libgtk-

Re: [Kicad-developers] Kicad-from-scratch: Segfault after unarchiving active project.

[Clemens Koller]

Attaching debug information of GDB session:

-8<-
[...]
[New Thread 0x7fffe6711700 (LWP 24139)]
[Thread 0x7fffe6711700 (LWP 24139) exited]
SetProjectFullName: old:'' 
new:'/home/admin/share/project/kicad/project/test9/test9.pro'
13:10:42: Debug: FileWatcherReset: watched paths:
13:10:42: Debug:  /home/admin/share/project/kicad/project/test9/

[Thread 0x7fffe6f12700 (LWP 24135) exited]
[New Thread 0x7fffe6f12700 (LWP 24149)]
[New Thread 0x7fffe6711700 (LWP 24150)]
[New Thread 0x7fffd5c56700 (LWP 24151)]
[Thread 0x7fffe6f12700 (LWP 24149) exited]
[Thread 0x7fffe6711700 (LWP 24150) exited]
[New Thread 0x7fffe6711700 (LWP 24152)]
[Thread 0x7fffd5c56700 (LWP 24151) exited]

Thread 1 "kicad" received signal SIGSEGV, Segmentation fault.
0x555fc6da in TREEPROJECT_ITEM::GetType (this=0x0) at 
/home/admin/share/project/kicad/kicad-dev/kicad.git/kicad/treeproject_item.h:56
56  TreeFileType GetType() const{ return m_Type; }
(gdb) bt
#0  0x555fc6da in TREEPROJECT_ITEM::GetType() const (this=0x0) at 
/home/admin/share/project/kicad/kicad-dev/kicad.git/kicad/treeproject_item.h:56
#1  0x555ffbfb in TREEPROJECTFILES::OnCompareItems(wxTreeItemId const&, 
wxTreeItemId const&) (this=0x55abd1d0, item1=..., item2=...)
at 
/home/admin/share/project/kicad/kicad-dev/kicad.git/kicad/treeprojectfiles.cpp:95
#2  0x76f1830d in  () at /usr/lib/libwx_gtk2u_core-3.0.so.0
#3  0x735a07a6 in msort_with_tmp.part () at /usr/lib/libc.so.6
#4  0x735a09f6 in qsort_r () at /usr/lib/libc.so.6
#5  0x76f17386 in wxGenericTreeCtrl::SortChildren(wxTreeItemId const&) 
() at /usr/lib/libwx_gtk2u_core-3.0.so.0
#6  0x555faa28 in 
TREE_PROJECT_FRAME::OnFileSystemEvent(wxFileSystemWatcherEvent&) 
(this=0x55a21c60, event=...)
at 
/home/admin/share/project/kicad/kicad-dev/kicad.git/kicad/tree_project_frame.cpp:995
#7  0x76575d4e in 
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&) () at /usr/lib/libwx_baseu-3.0.so.0
#8  0x7657616b in wxEvtHandler::SearchDynamicEventTable(wxEvent&) () at 
/usr/lib/libwx_baseu-3.0.so.0
#9  0x76576200 in wxEvtHandler::TryHereOnly(wxEvent&) () at 
/usr/lib/libwx_baseu-3.0.so.0
#10 0x765762b4 in wxEvtHandler::ProcessEventLocally(wxEvent&) () at 
/usr/lib/libwx_baseu-3.0.so.0
#11 0x76576316 in wxEvtHandler::ProcessEvent(wxEvent&) () at 
/usr/lib/libwx_baseu-3.0.so.0
#12 0x7656dd6e in  () at /usr/lib/libwx_baseu-3.0.so.0
#13 0x76573802 in  () at /usr/lib/libwx_baseu-3.0.so.0
#14 0x7657435c in  () at /usr/lib/libwx_baseu-3.0.so.0
#15 0x76569665 in  () at /usr/lib/libwx_baseu-3.0.so.0
#16 0x76cbe03d in  () at /usr/lib/libwx_gtk2u_core-3.0.so.0
#17 0x71fa7ca6 in g_main_context_dispatch () at 
/usr/lib/libglib-2.0.so.0
#18 0x71fa8081 in  () at /usr/lib/libglib-2.0.so.0
#19 0x71fa83b2 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#20 0x73058df3 in gtk_main () at /usr/lib/libgtk-x11-2.0.so.0
#21 0x76cbc866 in wxGUIEventLoop::DoRun() () at 
/usr/lib/libwx_gtk2u_core-3.0.so.0
#22 0x7642b784 in wxEventLoopBase::Run() () at 
/usr/lib/libwx_baseu-3.0.so.0
#23 0x763f2247 in wxAppConsoleBase::MainLoop() () at 
/usr/lib/libwx_baseu-3.0.so.0
#24 0x555e003f in APP_KICAD::OnRun() (this=0x55988100) at 
/home/admin/share/project/kicad/kicad-dev/kicad.git/kicad/kicad.cpp:233
#25 0x7647f578 in wxEntry(int&, wchar_t**) () at 
/usr/lib/libwx_baseu-3.0.so.0
#26 0x555deab5 in main(int, char**) (argc=1, argv=0x7fffe458) at 
/home/admin/share/project/kicad/kicad-dev/kicad.git/kicad/kicad.cpp:265
-8<-

I hope it's useful.

Regards,

Clemens

On 2018-02-16 12:51, Clemens Koller wrote:
> Some more KiCad-from-scratch testing on Arch Linux:
> 
> Setup:
> KiCad Version: (2018-02-16 revision 3c9a5b096)-master, release build
> There is an previously archived project in some working directory 
> .../test9/test9.zip next to the project files test9.pro
> (as well as an empty schematics and layout, ...)
> 
> How to reproduce:
> - KiCad: Open Project -> ...test9/test9.pro.
> - Filemanager: delete all files of the project except the previously archived 
> test9/test9.zip
> - KiCad: When KiCad comes to front, the project tree gets reduced to 
> test9.pro (some refresh on focus? ok, cool).
> - KiCad: When hitting Refresh, the project tree shows an additional "Empty 
> project" branch below test9.pro (different refresh?, well, ok).
> - KiCad: File -> Unarchive Project -> select test9.zip -> Open -> Target 
> Directory -> test9 (keep current) -> Open -> Crash :-(
> 
> 
> [13603.796230] kicad[14646]: segfault at 10 ip 5647994c4655 sp 
> 7ffc39fea080 e

[Kicad-developers] Kicad-from-scratch: Segfault after unarchiving active project.

[Clemens Koller]

Some more KiCad-from-scratch testing on Arch Linux:

Setup:
KiCad Version: (2018-02-16 revision 3c9a5b096)-master, release build
There is an previously archived project in some working directory 
.../test9/test9.zip next to the project files test9.pro
(as well as an empty schematics and layout, ...)

How to reproduce:
- KiCad: Open Project -> ...test9/test9.pro.
- Filemanager: delete all files of the project except the previously archived 
test9/test9.zip
- KiCad: When KiCad comes to front, the project tree gets reduced to test9.pro 
(some refresh on focus? ok, cool).
- KiCad: When hitting Refresh, the project tree shows an additional "Empty 
project" branch below test9.pro (different refresh?, well, ok).
- KiCad: File -> Unarchive Project -> select test9.zip -> Open -> Target 
Directory -> test9 (keep current) -> Open -> Crash :-(


[13603.796230] kicad[14646]: segfault at 10 ip 5647994c4655 sp 
7ffc39fea080 error 4 in kicad[56479942b000+16e000]

Is there a bug report filed already?
More debug information needed? (debug build just up)

Regards,

Clemens





___
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-from-scratch: View->Refresh with empty project functional?

[Clemens Koller]

Hi!

Whenever KiCad is started from scratch [1], in the menu View->Refresh [Ctrl-R] 
is not greyed out (same with toolbar icon).
Is there anything which can be refreshed at that point?

Regards,

Clemens

[1] KiCad-from-scratch:
rm -r ~/.config/kicad
rm -r ~/.cache/kicad


___
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] Git tags for 5.x.x-rc1 yet?

[Clemens Koller]

Thanks! Will wait. :-)

On 2018-02-16 12:07, Maciej Sumiński wrote:
> Hi Clemens,
> 
> RC1 is not released/tagged yet, Wayne plans to do it this weekend [1].
> 
> Regards,
> Orson
> 
> 1. https://lists.launchpad.net/kicad-developers/msg33890.html
> 
> On 02/16/2018 12:04 PM, Clemens Koller wrote:
>> Hi, There!
>>
>> I am wondering if I am following the right git repository on 
>> github/launchpad to do testing for V5 as there is no 5.0.0-rc1 or -testing 
>> tag.
>> Do you, Wayne(?) keep the V5 stuff in your private repo or are they just not 
>> out there, yet?
>>
>> $ git remote show origin
>> * remote origin
>>   Fetch URL: https://git.launchpad.net/kicad
>>   Push  URL: https://git.launchpad.net/kicad
>>   HEAD branch: master
>>   Remote branches:
>> 4.0tracked
>> master tracked
>>   Local branch configured for 'git pull':
>> master merges with remote master
>>   Local ref configured for 'git push':
>> master pushes to master (up to date)
>>
>> $ git tag
>> 4.0.0
>> 4.0.0-rc1
>> 4.0.0-rc2
>> 4.0.1
>> 4.0.2
>> 4.0.3
>> 4.0.4
>> 4.0.5
>> 4.0.6
>> 4.0.7
>> April-2010-release
>> baseline
>> copy-of-subversion-repo
>> original_code
>> patch_baseline
>> pre-kiway
>> review
>>
>> $ git branch -a
>> * master
>>   remotes/origin/4.0
>>   remotes/origin/HEAD -> origin/master
>>   remotes/origin/master
>>
>> Regards,
>>
>> Clemens
>>
>> ___
>> 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

[Kicad-developers] Git tags for 5.x.x-rc1 yet?

[Clemens Koller]

Hi, There!

I am wondering if I am following the right git repository on github/launchpad 
to do testing for V5 as there is no 5.0.0-rc1 or -testing tag.
Do you, Wayne(?) keep the V5 stuff in your private repo or are they just not 
out there, yet?

$ git remote show origin
* remote origin
  Fetch URL: https://git.launchpad.net/kicad
  Push  URL: https://git.launchpad.net/kicad
  HEAD branch: master
  Remote branches:
4.0tracked
master tracked
  Local branch configured for 'git pull':
master merges with remote master
  Local ref configured for 'git push':
master pushes to master (up to date)

$ git tag
4.0.0
4.0.0-rc1
4.0.0-rc2
4.0.1
4.0.2
4.0.3
4.0.4
4.0.5
4.0.6
4.0.7
April-2010-release
baseline
copy-of-subversion-repo
original_code
patch_baseline
pre-kiway
review

$ git branch -a
* master
  remotes/origin/4.0
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

Regards,

Clemens

___
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] Build broken against glm 0.9.8.4

[Clemens Koller]

Hi, Nick!

Note: There is also a glm 0.9.8.5 out (and glm 0.9.9)... maybe this issue got 
fixed already.

see: https://github.com/g-truc/glm/releases

Regards,

Clemens


On 2018-02-07 12:37, Nick Østergaard wrote:
> Hi
> 
> Just a heads up.
> 
> I think e0f7958dbdab89f38bacc6a567e21b38a0926aee broke the build on fedora26 
> and fedora 27 which uses glm 0.9.8.4. Caused by fix in 
> https://bugs.launchpad.net/kicad/+bug/1746546.
> 
> /usr/include/glm/detail/type_vec4_simd.inl:156:11: error: 'struct 
> glm::tvec4' has no member named 'data'
> /usr/include/glm/detail/type_vec4_simd.inl:156:11: error: 'struct 
> glm::tvec4' has no member named 'data'
>     Result.data = _mm_mul_ps(a.data, _mm_rcp_ps(b.data));
>     Result.data = _mm_mul_ps(a.data, _mm_rcp_ps(b.data));
>            ^~~~
>            ^~~~
> 
> https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/711229/
> 
> Nick
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GUI garbage...? (Solution)

[Clemens Koller]

Hi!

Simple solution: There is an wxpython-gtk2 in AUR. Use this instead of 
wxpython, as wxpython-gtk2 is linked against gtk2... blahblubb easy.

I am still wondering what's wrong with wxpython linking against gtk3 and why 
only KiCad seems to put it's foot in it?!
Can somebody explain more details about this wxDC stuff?

Regards,

Clemens

On 2018-02-03 18:25, Nick Østergaard wrote:
> Den 3. feb. 2018 1.27 PM skrev "Clemens Koller" <c...@embeon.de 
> <mailto:c...@embeon.de>>:
> 
> Hi, Nick!
> 
> On 2018-02-03 01:02, Nick Østergaard wrote:
> > are you sure you didn't rebuild wxpython with gtk2?
> 
> I cannot tell right out of the box if the KiCad build picks wxpython or 
> wxpython2.8.
> Note, that I am installing KiCad-git into ~/SW and not into my system and 
> run it with:
> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/SW/lib 
> PYTHONPATH=~/SW/lib/python2.7/site-packages/ ./kicad
> This might make is special.
> 
> 
> No, this is safe.
> 
> 
> There are AFAICT no tweaks on the host. I'm installing the packages from 
> the official repositories and from AUR as is.
> 
> Details, how they are built can be found i.e. at:
> https://www.archlinux.org/packages/community/x86_64/wxpython/ 
> <https://www.archlinux.org/packages/community/x86_64/wxpython/>
> 
> 
> I know, I use arch myself.
> 
> 
> Note the separate wxgtk2.8 and a wxpython2.8. They are built from AUR 
> (the arch linux user repository) as you can see here:
> https://aur.archlinux.org/packages/wxgtk2.8/ 
> <https://aur.archlinux.org/packages/wxgtk2.8/>
> https://aur.archlinux.org/packages/wxpython2.8/ 
> <https://aur.archlinux.org/packages/wxpython2.8/>
> 
> 2.8 refers to the wx version, not the gtk version. I think kicad requires wx 
> 3.0, but I don't remember this exactly.
> 
> 
> Below, some ldd and lsof outputs...
> 
> Regards,
> 
> Clemens
> 
> $ ldd ./kicad
>         linux-vdso.so.1 (0x7ffca1178000)
>         libwx_gtk2u_gl-3.0.so.0 => /usr/lib/libwx_gtk2u_gl-3.0.so 
> <http://libwx_gtk2u_gl-3.0.so>.0 (0x7f5b1f41e000)
>         libwx_gtk2u_aui-3.0.so.0 => /usr/lib/libwx_gtk2u_aui-3.0.so.0 
> (0x7f5b1f18b000)
>         libwx_gtk2u_adv-3.0.so.0 => /usr/lib/libwx_gtk2u_adv-3.0.so.0 
> (0x7f5b1edb7000)
>         libwx_gtk2u_html-3.0.so.0 => /usr/lib/libwx_gtk2u_html-3.0.so.0 
> (0x7f5b1eae7000)
>         libwx_gtk2u_core-3.0.so.0 => /usr/lib/libwx_gtk2u_core-3.0.so.0 
> (0x7f5b1e2bd000)
>         libwx_baseu_net-3.0.so.0 => /usr/lib/libwx_baseu_net-3.0.so.0 
> (0x7f5b1e079000)
>         libwx_baseu-3.0.so.0 => /usr/lib/libwx_baseu-3.0.so.0 
> (0x7f5b1dbe3000)
>         libwx_baseu_xml-3.0.so.0 => /usr/lib/libwx_baseu_xml-3.0.so.0 
> (0x7f5b1d9d3000)
>         libwx_gtk2u_stc-3.0.so.0 => /usr/lib/libwx_gtk2u_stc-3.0.so.0 
> (0x7f5b1d595000)
>         libGLEW.so.2.1 => /usr/lib/libGLEW.so.2.1 (0x7f5b1d2ed000)
>         libcairo.so.2 => /usr/lib/libcairo.so.2 (0x7f5b1cfcb000)
>         libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x7f5b1cd23000)
>         libGL.so.1 => /usr/lib/libGL.so.1 (0x7f5b1ca98000)
>         libGLU.so.1 => /usr/lib/libGLU.so.1 (0x7f5b1c818000)
>         libcurl.so.4 => /usr/lib/libcurl.so.4 (0x7f5b1c59b000)
>         libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x7f5b1c331000)
>         libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x7f5b1beb4000)
>         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f5b1bb2d000)
>         libm.so.6 => /usr/lib/libm.so.6 (0x7f5b1b7e1000)
>         libgomp.so.1 => /usr/lib/libgomp.so.1 (0x7f5b1b5b3000)
>         libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f5b1b39c000)
>         libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f5b1b17e000)
>         libc.so.6 => /usr/lib/libc.so.6 (0x7f5b1adc7000)
>         libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 
> (0x7f5b1a78a000)
>         libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 
> (0x7f5b1a4d6000)
>         libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 
> (0x7f5b1a281000)
>         libX11.so.6 => /usr/lib/libX11.so.6 (0x7f5b19f42000)
>         libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so 
> <http://libgdk_pixbuf-2.0.so>.0 (0x7f5b19d1e000)
>         libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 
> (0x7f5b19acf000)
>         libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x7f5b197ba000)

Re: [Kicad-developers] GUI garbage...?

[Clemens Koller]

Okay...

Reason found:
wxpython 3.0.2.0-7 on Arch Linux was updated on 2018-01-28 (last week) and 
built against wxgtk3 again.
Before (3.0.2.0-6) it was built against wxgtk2...

See:
https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/wxpython=3f1f64acdcd28ca7789e03ecc2b1b0f79e8bf6d1

The change-note says:
"Rebuild with wxgtk3 again, kicad is no longer a blocker"

Regards,

Clemens

On 2018-02-03 14:56, Clemens Koller wrote:
> Ouch... after a rebuild from latest I am now running into the GUI garbage as 
> well!
> 
> I had to change my LD_LIBRARY_PATH from:
> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/SW/lib
> to
> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/SW/lib64
> as well to be able to find libkicad_3dsg.so.2.0.0.
> 
> What's going on here?
> 
> Regards,
> 
> Clemens
> 
> On 2018-02-03 13:39, Iñigo wrote:
>> Hi,
>>
>> Very same behavior here, on Manjaro with KiCad from AUR.
>>
>> If I close the Pcbnew windows KiCad closes completely.
>>
>>
>> On 03/02/18 13:26, Clemens Koller wrote:
>>> Hi, Nick!
>>>
>>> On 2018-02-03 01:02, Nick Østergaard wrote:
>>>> are you sure you didn't rebuild wxpython with gtk2?
>>> I cannot tell right out of the box if the KiCad build picks wxpython or 
>>> wxpython2.8.
>>> Note, that I am installing KiCad-git into ~/SW and not into my system and 
>>> run it with:
>>> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/SW/lib 
>>> PYTHONPATH=~/SW/lib/python2.7/site-packages/ ./kicad
>>> This might make is special.
>>>
>>> There are AFAICT no tweaks on the host. I'm installing the packages from 
>>> the official repositories and from AUR as is.
>>>
>>> Details, how they are built can be found i.e. at:
>>> https://www.archlinux.org/packages/community/x86_64/wxpython/
>>>
>>> Note the separate wxgtk2.8 and a wxpython2.8. They are built from AUR (the 
>>> arch linux user repository) as you can see here:
>>> https://aur.archlinux.org/packages/wxgtk2.8/
>>> https://aur.archlinux.org/packages/wxpython2.8/
>>>
>>> Below, some ldd and lsof outputs...
>>>
>>> Regards,
>>>
>>> Clemens
>>>
>>> $ ldd ./kicad
>>> linux-vdso.so.1 (0x7ffca1178000)
>>> libwx_gtk2u_gl-3.0.so.0 => /usr/lib/libwx_gtk2u_gl-3.0.so.0 
>>> (0x7f5b1f41e000)
>>> libwx_gtk2u_aui-3.0.so.0 => /usr/lib/libwx_gtk2u_aui-3.0.so.0 
>>> (0x7f5b1f18b000)
>>> libwx_gtk2u_adv-3.0.so.0 => /usr/lib/libwx_gtk2u_adv-3.0.so.0 
>>> (0x7f5b1edb7000)
>>> libwx_gtk2u_html-3.0.so.0 => /usr/lib/libwx_gtk2u_html-3.0.so.0 
>>> (0x7f5b1eae7000)
>>> libwx_gtk2u_core-3.0.so.0 => /usr/lib/libwx_gtk2u_core-3.0.so.0 
>>> (0x7f5b1e2bd000)
>>> libwx_baseu_net-3.0.so.0 => /usr/lib/libwx_baseu_net-3.0.so.0 
>>> (0x7f5b1e079000)
>>> libwx_baseu-3.0.so.0 => /usr/lib/libwx_baseu-3.0.so.0 
>>> (0x7f5b1dbe3000)
>>> libwx_baseu_xml-3.0.so.0 => /usr/lib/libwx_baseu_xml-3.0.so.0 
>>> (0x7f5b1d9d3000)
>>> libwx_gtk2u_stc-3.0.so.0 => /usr/lib/libwx_gtk2u_stc-3.0.so.0 
>>> (0x7f5b1d595000)
>>> libGLEW.so.2.1 => /usr/lib/libGLEW.so.2.1 (0x7f5b1d2ed000)
>>> libcairo.so.2 => /usr/lib/libcairo.so.2 (0x7f5b1cfcb000)
>>> libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x7f5b1cd23000)
>>> libGL.so.1 => /usr/lib/libGL.so.1 (0x7f5b1ca98000)
>>> libGLU.so.1 => /usr/lib/libGLU.so.1 (0x7f5b1c818000)
>>> libcurl.so.4 => /usr/lib/libcurl.so.4 (0x7f5b1c59b000)
>>> libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x7f5b1c331000)
>>> libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x7f5b1beb4000)
>>> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f5b1bb2d000)
>>> libm.so.6 => /usr/lib/libm.so.6 (0x7f5b1b7e1000)
>>> libgomp.so.1 => /usr/lib/libgomp.so.1 (0x7f5b1b5b3000)
>>> libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f5b1b39c000)
>>> libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f5b1b17e000)
>>> libc.so.6 => /usr/lib/libc.so.6 (0x7f5b1adc7000)
>>> libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x7f5b1a78a000)
>>> libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x7f5b1a4d6000)
>>> libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x7f5b1a281000)
>>> libX11.so.6 => /usr/lib/libX11.so.6 (0x00

Re: [Kicad-developers] GUI garbage...?

[Clemens Koller]

   1849 admin  mem   REG   8,3353512  170250 
/var/cache/fontconfig/491f45a0a771fef1c10b9b647a97fb82-le64.cache-7
kicad   1849 admin  mem   REG   8,33 6368  170256 
/var/cache/fontconfig/6ba42aef58711b5caaf10d690066-le64.cache-7
kicad   1849 admin  mem   REG   8,3319936  170255 
/var/cache/fontconfig/e83f37fcf327f1deda509da0f6605954-le64.cache-7
kicad   1849 admin  mem   REG   8,3317536  170254 
/var/cache/fontconfig/d62e99ef547d1d24cdb1bd22ec1a2976-le64.cache-7
kicad   1849 admin  mem   REG   8,33   146128  164117 
/var/cache/fontconfig/f349e9996a5320f6dd491cedd2b1f964-le64.cache-7



On 2018-02-03 01:02, Nick Østergaard wrote:
> are you sure you didn't rebuild wxpython with gtk2?
> 
> Den 3. feb. 2018 00.55 skrev "Clemens Koller" <c...@embeon.de 
> <mailto:c...@embeon.de>>:
> 
> Hi, Chris!
> 
> I don't run into the issues on Arch Linux. No special tweaks. Installed 
> packages are i.e.:
> 
> $ pacman -Q | grep "wx"
> wxformbuilder-svn 3.5.2.RC2.r2225-1
> wxgtk-common 3.0.3.1-11
> wxgtk2 3.0.3.1-11
> wxgtk2.8 2.8.12.1-6
> wxgtk3 3.0.3.1-11
> wxpython 3.0.2.0-7
> wxpython2.8 2.8.12.1-3
> 
> 
> About KiCad:
> Application: kicad
> Version: (2018-01-22 revision c702646c2)-master, release build
> Libraries:
>     wxWidgets 3.0.3
>     libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
> (+libidn2/2.0.4) nghttp2/1.29.0
> Platform: Linux 4.14.15-1-ARCH x86_64, 64 bit, Little endian, wxGTK
> Build Info:
>     wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
>     Boost: 1.66.0
>     Curl: 7.57.0
>     Compiler: GCC 7.2.1 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
> 
> Greets,
> Clemens
> 
> 
> On 2018-02-02 23:54, Chris Pavlina wrote:
> > Okay, I can confirm this works, looks like they did switch wxpython from
> > gtk2 to gtk3. Really annoying, given gtk2 and gtk3 are different
> > packages libraries that use them ought to be too...
> >
> > Sorry for the noise, guess my distro is to blame.
> >
> >
> > On Fri, Feb 02, 2018 at 11:55:46PM +0200, Janis Skujenieks wrote:
> >> I don't know exactly, but in forum post he resolved by downgrading 
> wxpython
> >> to 3.0.2.0-6.
> >> 
> https://forum.kicad.info/t/arch-linux-problem-with-wxpython-3-0-2-0-7-reverting-to-3-0-2-0-6-works-fine-kicad-nightly/9493
>  
> <https://forum.kicad.info/t/arch-linux-problem-with-wxpython-3-0-2-0-7-reverting-to-3-0-2-0-6-works-fine-kicad-nightly/9493>
> >>
> >> I haven't had time to upgrade my system.
> >>
> >>
> >> On Fri, Feb 2, 2018 at 11:45 PM, Chris Pavlina 
> <pavlina.ch...@gmail.com <mailto:pavlina.ch...@gmail.com>>
> >> wrote:
> >>
> >>> I'm confused - nickoe comments on that bug to rebuild with gtk2, but
> >>> both the version info posted in the bug report and my own system
> >>> indicate gtk2...
> >>>
> >>> On Fri, Feb 02, 2018 at 11:32:58PM +0200, Janis Skujenieks wrote:
> >>>> I think you may have this problem
> >>>> https://bugs.launchpad.net/kicad/+bug/1746753 
> <https://bugs.launchpad.net/kicad/+bug/1746753>
> >>>>
> >>>> On Fri, Feb 2, 2018 at 11:00 PM, Chris Pavlina 
> <pavlina.ch...@gmail.com <mailto:pavlina.ch...@gmail.com>>
> >>>> wrote:
> >>>>
> >>>>> Mostly empty toolbars, one missing toolbar, and a completely black,
> >>>>> blank schematic.
> >>>>>
> >>>>> Arch Linux
> >>>>> gtk2 2.24.32-1
> >>>>> wxgtk2 3.0.3.1-11
> >>>>>
> >>>>> On Fri, Feb 02, 2018 at 03:53:03PM -0500, Kevin Cozens wrote:
> >>>>>> On 2018-02-02 03:24 PM, Chris Pavlina wrote:
> >>>>>>> https://misc.c4757p.com/kicad-is-very-broken.png 
> <https://misc.c4757p.com/kicad-is-very-broken.png>
> >>>>>>>
> >>>>>>&g

Re: [Kicad-developers] GUI garbage...?

[Clemens Koller]

Hi, Chris!

I don't run into the issues on Arch Linux. No special tweaks. Installed 
packages are i.e.:

$ pacman -Q | grep "wx"
wxformbuilder-svn 3.5.2.RC2.r2225-1
wxgtk-common 3.0.3.1-11
wxgtk2 3.0.3.1-11
wxgtk2.8 2.8.12.1-6
wxgtk3 3.0.3.1-11
wxpython 3.0.2.0-7
wxpython2.8 2.8.12.1-3


About KiCad:
Application: kicad
Version: (2018-01-22 revision c702646c2)-master, release build
Libraries:
wxWidgets 3.0.3
libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
(+libidn2/2.0.4) nghttp2/1.29.0
Platform: Linux 4.14.15-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.66.0
Curl: 7.57.0
Compiler: GCC 7.2.1 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

Greets,
Clemens


On 2018-02-02 23:54, Chris Pavlina wrote:
> Okay, I can confirm this works, looks like they did switch wxpython from
> gtk2 to gtk3. Really annoying, given gtk2 and gtk3 are different
> packages libraries that use them ought to be too...
> 
> Sorry for the noise, guess my distro is to blame.
> 
> 
> On Fri, Feb 02, 2018 at 11:55:46PM +0200, Janis Skujenieks wrote:
>> I don't know exactly, but in forum post he resolved by downgrading wxpython
>> to 3.0.2.0-6.
>> https://forum.kicad.info/t/arch-linux-problem-with-wxpython-3-0-2-0-7-reverting-to-3-0-2-0-6-works-fine-kicad-nightly/9493
>>
>> I haven't had time to upgrade my system.
>>
>>
>> On Fri, Feb 2, 2018 at 11:45 PM, Chris Pavlina 
>> wrote:
>>
>>> I'm confused - nickoe comments on that bug to rebuild with gtk2, but
>>> both the version info posted in the bug report and my own system
>>> indicate gtk2...
>>>
>>> On Fri, Feb 02, 2018 at 11:32:58PM +0200, Janis Skujenieks wrote:
 I think you may have this problem
 https://bugs.launchpad.net/kicad/+bug/1746753

 On Fri, Feb 2, 2018 at 11:00 PM, Chris Pavlina 
 wrote:

> Mostly empty toolbars, one missing toolbar, and a completely black,
> blank schematic.
>
> Arch Linux
> gtk2 2.24.32-1
> wxgtk2 3.0.3.1-11
>
> On Fri, Feb 02, 2018 at 03:53:03PM -0500, Kevin Cozens wrote:
>> On 2018-02-02 03:24 PM, Chris Pavlina wrote:
>>> https://misc.c4757p.com/kicad-is-very-broken.png
>>>
>>> Anyone have any idea what could possibly cause this...?
>>
>> What are we supposed to see in that image? Which operating system are
> you using?
>>
>> --
>> Cheers!
>>
>> Kevin.
>>
>> http://www.ve3syb.ca/   |"Nerds make the shiny things that
> distract
>> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why
> we're
>> | powerful!"
>> #include  | --Chris Hardwick
>>
>> ___
>> 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

[Kicad-developers] OT: Re: Dealing with multifunction pins (Symbol)

[Clemens Koller]

Hi, Augusto!

On 2018-02-02 14:11, Augusto Fraga Giachero wrote:
> Yes, this idea would only work for small and medium sized ICs, but would 
> be nice to not depend on external tools besides Kicad and its symbol 
> libraries to do it.

I fully agree with you. External tools are off course optional. They might be 
also proprietary (i.e. tools from chip vendors). But the interfaces are IMO not 
optional. I was trying to emphasize that interfaces to other tools need to be 
bi-directional and automated and customizable with glue-logic.

> Anyway, a tabled based entry might be a good solution.

I believe it's mandatory for big designs. The importance of the visual 
graphical representation as we know it as schematics might become less 
important, then.

> I'm glad to see that this issue is a concern among Kicad devs.

I am not really a KiCad developer, but I am building from source, trying to 
understand some internals, and testing stuff. Mid-term, I am looking forward to 
integrate KiCad in my "Design-Flow". I would like to migrate my designs and 
libraries to/from my proprietary tool (+ self written lib-generators + 
database).

Regards,

Clemens

> 
> Thanks,
> Augusto Fraga Giachero.
> 
> On 30-01-2018 21:37, Clemens Koller wrote:
>> Hello, Augusto!
>>
>> Your ideas regarding multiplexed I/Os are good, but might only be sufficient 
>> for small to medium-complex CPUs/FPGAs/modules/circuits. If you follow the 
>> latest developments, you will notice that there are even bigger things 
>> coming up and it will get more and more difficult to visually represent the 
>> huge amount of varying I/Os and to solve dependencies and restraints. So, in 
>> the long term, I suggest to have a look at some even more flexible methods 
>> as i.e. (database-) tabled based design entry.
>>
>> This means that a design tool (here KiCad) IMO needs to polish it's 
>> interfaces to the outside world to import/export pin lists and netlists on 
>> request.
>> Some tools can work with lists/.CSVs, but seem to lack automation 
>> (forward/backward annotation). I am working a lot with databases and use my 
>> own glue (sql-scripts) to import/export generated pin lists to/from the 
>> Pin-Multiplexing software and to/from the design. Version managment is also 
>> mandatory.
>>
>> You might have a look at i.e. the Altera Pin Planner, Xilinx IO Planning or 
>> the Pins Tool from NXP to get an idea where we are heading to:
>> https://www.nxp.com/pages/pins-tool-for-i.mx-application-processors:PINS-TOOL-IMX
>>
>> Regards,
>>
>> Clemens
>>
>>
>>
>> On 2018-01-30 16:01, Augusto Fraga Giachero wrote:
>>> Hi,
>>>
>>> I've been designing schematics with some stm32 parts using the standard
>>> Kicad libraries, and a lot of these microcontrollers has 10+ functions
>>> multiplexed in each I/O pin. In the standard library the symbols
>>> displays all possible configurations available to each pin, I understand
>>> the motivation of this choice (not having to refer to the datasheet
>>> every time you want choose an I/O for some specific functionality), but
>>> this results in very large symbols occupying the page.
>>>
>>> I've come with a idea (which probably isn't new) to deal with this problem:
>>> * You can select what functions you will use from a list for each pin
>>> and only that will be displayed in the schematic;
>>> * You can then resize the symbol accordingly directly in the schematic;
>>> * While this wouldn't require any modification to the library symbol
>>> file format as the description string of each pin already carries all
>>> the necessary information, the .sch file format would probably be
>>> changed and would not have backwards compatibility.
>>>
>>> This may not be easy to implement as with the way eeschema handles
>>> symbols today and the issues I've cited above, I would like hear about
>>> your suggestions.
>>>
>>> Thanks,
>>> Augusto Fraga Giachero.
>>>
>>>
>>> ___
>>> 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

Re: [Kicad-developers] Dealing with multifunction pins (Symbol)

[Clemens Koller]

Hello, Augusto!

Your ideas regarding multiplexed I/Os are good, but might only be sufficient 
for small to medium-complex CPUs/FPGAs/modules/circuits. If you follow the 
latest developments, you will notice that there are even bigger things coming 
up and it will get more and more difficult to visually represent the huge 
amount of varying I/Os and to solve dependencies and restraints. So, in the 
long term, I suggest to have a look at some even more flexible methods as i.e. 
(database-) tabled based design entry.

This means that a design tool (here KiCad) IMO needs to polish it's interfaces 
to the outside world to import/export pin lists and netlists on request.
Some tools can work with lists/.CSVs, but seem to lack automation 
(forward/backward annotation). I am working a lot with databases and use my own 
glue (sql-scripts) to import/export generated pin lists to/from the 
Pin-Multiplexing software and to/from the design. Version managment is also 
mandatory.

You might have a look at i.e. the Altera Pin Planner, Xilinx IO Planning or the 
Pins Tool from NXP to get an idea where we are heading to:
https://www.nxp.com/pages/pins-tool-for-i.mx-application-processors:PINS-TOOL-IMX

Regards,

Clemens



On 2018-01-30 16:01, Augusto Fraga Giachero wrote:
> Hi,
> 
> I've been designing schematics with some stm32 parts using the standard 
> Kicad libraries, and a lot of these microcontrollers has 10+ functions 
> multiplexed in each I/O pin. In the standard library the symbols 
> displays all possible configurations available to each pin, I understand 
> the motivation of this choice (not having to refer to the datasheet 
> every time you want choose an I/O for some specific functionality), but 
> this results in very large symbols occupying the page.
> 
> I've come with a idea (which probably isn't new) to deal with this problem:
> * You can select what functions you will use from a list for each pin 
> and only that will be displayed in the schematic;
> * You can then resize the symbol accordingly directly in the schematic;
> * While this wouldn't require any modification to the library symbol 
> file format as the description string of each pin already carries all 
> the necessary information, the .sch file format would probably be 
> changed and would not have backwards compatibility.
> 
> This may not be easy to implement as with the way eeschema handles 
> symbols today and the issues I've cited above, I would like hear about 
> your suggestions.
> 
> Thanks,
> Augusto Fraga Giachero.
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Libedit and Modedit Icons

[Clemens Koller]

On 2018-01-11 11:06, Jörg Hermann wrote:
> After all of Olivers work and the amount of time discussed here, I strongly 
> vote for accepting the changes, as they are a huge improvement.
> I agree on keeping the “old” pixelated a and PCB calculator, if that helps 
> accepting the remaining changes.

I fully agree here. The improvements are IMO really huge.
And I would suggest that Oliver just takes care of the remaining icons for the 
Bitmap converter/vectorizer as well as the PCB calculator for V5.

Regards,

Clemens

___
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 from scratch: pcbnew: cannot use ~/ for home directory for KISYS3DMOD path?

[Clemens Koller]

Hi, Joerg!

On 2018-01-09 18:49, Jörg Hermann wrote:
> Is this behaviour somehow related to 
> https://bugs.launchpad.net/kicad/+bug/1677545

Maybe... remotely.
KISYS3DMOD's default path, as well as it's handling, seems to be off a bit.

My question is: Is Kicad supposed to work with ~/... in general or - for some 
very good reason - needs the expanded (absolute) /home//... ?
If ~/... is an acceptable pathname, then there is a bug to hunt in the latest 
git.

In other words: Where is the code where file + pathnames are abstracted to make 
it work across all platforms in this case?
kicad.git/common/env_paths.cpp ?

Regards,

Clemens


> 
>> On 9. Jan 2018, at 15:38, Nick Østergaard <oe.n...@gmail.com 
>> <mailto:oe.n...@gmail.com>> wrote:
>>
>> If you really want to start from scratch then you may also want to remove 
>> the ~/.cache/kicad  (or there about, I am not on linux right now). But it is 
>> not as important, it only contains the scene graph model cache. (Or what 
>> ever it is really called)
>>
>> 2018-01-09 14:55 GMT+01:00 Clemens Koller <c...@embeon.de 
>> <mailto:c...@embeon.de>>:
>>
>> Hi!
>>
>> I am testing latest-git on Linux, collecting some UX issues when 
>> starting Kicad from scratch (*):
>>
>> On a new installation, I cannot execute 3D Shape Downloader out of the 
>> box. KISYS3DMOD points to ~/SW/share/kicad/modules/packages3d after 
>> installation to ~/SW/share/kicad/bin.
>>
>> This folder doesn't exist yet at this point, but could be created by 
>> Kicad.
>> (The behaviour is still the same even when 
>> ~/SW/share/kicad/modules/packages3d was created in advance.)
>>
>> The 3D Shape Downloader then tells me:
>> "It's not possible to write in the selected directory. Please choose 
>> anothe one."
>>
>> When I press "Default 3D Path", I would expect that it resets the path 
>> to a default working one,
>> but an message tells me that "KISYS3DMOD path not defined , or not 
>> existing".
>>
>> Anyway it's possible to hit the Next-> button just to realize than after 
>> an hour of downloading, the download is going to fail -> Duh!
>> When I replace the ~/ with /home/admin/ everything seems to work.
>> Is there a reason that the ~ cannot be used from within Kicad?
>>
>> Regards,
>>
>> Clemens
>>
>> (*) Kicad rebuilt from src and started from scratch after rm 
>> ~/.config/kicad
>>
>>
>> ---
>> Application: kicad
>> Version: (2018-01-08 <tel:%282018-01-08> revision 0e9c8a423)-master, 
>> release build
>> Libraries:
>>     wxWidgets 3.0.3
>>     libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 
>> libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
>> Platform: Linux 4.14.12-1-ARCH x86_64, 64 bit, Little endian, wxGTK
>> Build Info:
>>     wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 
>> 2.24
>>     Boost: 1.66.0
>>     Curl: 7.57.0
>>     Compiler: GCC 7.2.1 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
> 
> 
> 
> ___
> 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

[Kicad-developers] Kicad from scratch: pcbnew: cannot use ~/ for home directory for KISYS3DMOD path?

[Clemens Koller]

Hi!

I am testing latest-git on Linux, collecting some UX issues when starting Kicad 
from scratch (*):

On a new installation, I cannot execute 3D Shape Downloader out of the box. 
KISYS3DMOD points to ~/SW/share/kicad/modules/packages3d after installation to 
~/SW/share/kicad/bin.

This folder doesn't exist yet at this point, but could be created by Kicad.
(The behaviour is still the same even when ~/SW/share/kicad/modules/packages3d 
was created in advance.)

The 3D Shape Downloader then tells me:
"It's not possible to write in the selected directory. Please choose anothe 
one."

When I press "Default 3D Path", I would expect that it resets the path to a 
default working one,
but an message tells me that "KISYS3DMOD path not defined , or not existing".

Anyway it's possible to hit the Next-> button just to realize than after an 
hour of downloading, the download is going to fail -> Duh!
When I replace the ~/ with /home/admin/ everything seems to work.
Is there a reason that the ~ cannot be used from within Kicad?

Regards,

Clemens

(*) Kicad rebuilt from src and started from scratch after rm ~/.config/kicad


---
Application: kicad
Version: (2018-01-08 revision 0e9c8a423)-master, release build
Libraries:
wxWidgets 3.0.3
libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
(+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
Platform: Linux 4.14.12-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.66.0
Curl: 7.57.0
Compiler: GCC 7.2.1 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


___
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] pcbnew: Zoom to fit board on screen broken

[Clemens Koller]

Sorry, my mistake:

It happens in Modern (Fallback) mode only. Legacy mode is okay! (The new 
names...)

Regards,

Clemens

On 2018-01-09 12:25, Clemens Koller wrote:
> Hi, Jon!
> 
> Its erratic in Legacy mode only, after starting with an empty project. Once 
> there were components placed and deleted, the behaviour vanishes, IIRC.
> 
> Regards,
> 
> Clemens
> 
> 
> On 2018-01-09 05:31, Jon Evans wrote:
>> Can't reproduce this on my Linux system.  I even tried removing my config 
>> file and still the zoom to fit button works on the first try and I don't see 
>> any strange zoom behavior.
>>
>> On Mon, Jan 8, 2018 at 9:05 PM, Clemens Koller <c...@embeon.de 
>> <mailto:c...@embeon.de>> wrote:
>>
>> Hi!
>>
>> The Zoom Button to fit board on screen seems to be broken. It does a fit 
>> board only on second click and then it's still not centered nicely in the 
>> drawing area.
>>
>> This might be related to: https://bugs.launchpad.net/kicad/+bug/1672868 
>> <https://bugs.launchpad.net/kicad/+bug/1672868>
>>
>> Steps to reproduce:
>> - Restart Kicad from scratch (rm ~/.config/kicad)
>> - start pcbnew
>> - play around with zoom buttons.
>>
>> Regards,
>>
>> Clemens
>>
>> ---
>> Application: kicad
>> Version: (2018-01-08 revision 0e9c8a423)-master, release build
>> Libraries:
>>     wxWidgets 3.0.3
>>     libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 
>> libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
>> Platform: Linux 4.14.12-1-ARCH x86_64, 64 bit, Little endian, wxGTK
>> Build Info:
>>     wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 
>> 2.24
>>     Boost: 1.66.0
>>     Curl: 7.57.0
>>     Compiler: GCC 7.2.1 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
>>
>> ---
>>
>> ___
>> 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>
>>
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew: Zoom to fit board on screen broken

[Clemens Koller]

Hi, Jon!

Its erratic in Legacy mode only, after starting with an empty project. Once 
there were components placed and deleted, the behaviour vanishes, IIRC.

Regards,

Clemens


On 2018-01-09 05:31, Jon Evans wrote:
> Can't reproduce this on my Linux system.  I even tried removing my config 
> file and still the zoom to fit button works on the first try and I don't see 
> any strange zoom behavior.
> 
> On Mon, Jan 8, 2018 at 9:05 PM, Clemens Koller <c...@embeon.de 
> <mailto:c...@embeon.de>> wrote:
> 
> Hi!
> 
> The Zoom Button to fit board on screen seems to be broken. It does a fit 
> board only on second click and then it's still not centered nicely in the 
> drawing area.
> 
> This might be related to: https://bugs.launchpad.net/kicad/+bug/1672868 
> <https://bugs.launchpad.net/kicad/+bug/1672868>
> 
> Steps to reproduce:
> - Restart Kicad from scratch (rm ~/.config/kicad)
> - start pcbnew
> - play around with zoom buttons.
> 
> Regards,
> 
> Clemens
> 
> ---
> Application: kicad
> Version: (2018-01-08 revision 0e9c8a423)-master, release build
> Libraries:
>     wxWidgets 3.0.3
>     libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
> (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
> Platform: Linux 4.14.12-1-ARCH x86_64, 64 bit, Little endian, wxGTK
> Build Info:
>     wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
>     Boost: 1.66.0
>     Curl: 7.57.0
>     Compiler: GCC 7.2.1 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
> 
> ---
> 
> ___
> 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>
> 
> 

___
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: Zoom to fit board on screen broken

[Clemens Koller]

Hi!

The Zoom Button to fit board on screen seems to be broken. It does a fit board 
only on second click and then it's still not centered nicely in the drawing 
area.

This might be related to: https://bugs.launchpad.net/kicad/+bug/1672868

Steps to reproduce:
- Restart Kicad from scratch (rm ~/.config/kicad)
- start pcbnew
- play around with zoom buttons.

Regards,

Clemens

---
Application: kicad
Version: (2018-01-08 revision 0e9c8a423)-master, release build
Libraries:
wxWidgets 3.0.3
libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
(+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
Platform: Linux 4.14.12-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.66.0
Curl: 7.57.0
Compiler: GCC 7.2.1 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

---

___
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] Default Canvas for v5

[Clemens Koller]

On 2017-12-31 03:53, Jon Evans wrote:
> I know this would be work for someone to do and maybe I'd offer to do it if 
> the project leaders approve...
> What about a one-time pop-up when first installing a release 5.0 that appears 
> if the config says the user was using legacy canvas, telling them about how 
> to switch and that they should check it out?
> 
> -Jon

+1
An initial start-up dialog to setup the "users default" after a first install 
or after a "reset Kicad to defaults, as I messed something up I don't remember" 
seems very helpful to me. If OpenGL might still crash in rare cases, warn the 
user in advance and explain, how he can safely step back from using OpenGL in 
case it doesn't work and how to file a bug report...

Regards,

Clemens

___
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] Eeschema bus upgrades and new connectivity algorithm

[Clemens Koller]

On 2017-12-15 11:01, Marco Ciampa wrote:
> On Fri, Dec 15, 2017 at 10:54:01AM +0100, Clemens Koller wrote:
> 
>> I was also considering the ellipsis '...' but in classical ASCII, they
>> are three characters wide, that's why I ended up with .., + or * to keep
>> it short.
> 
> ... and the problem with 3 chars is?

It takes more space in the schematics.

>> But since we arrived in Unicode, this can be solved by using the
>> horizontal ellipsis single character: U+2026 '…' or in our case the
>> midline horizontal ellipsis U+22EF '⋯'.
> 
> Please do _not_ use Unicode for this -please-

What are the issues you expect?
Since these symbols are only used on display, I would not mind using them.


Regards,

Clemens

___
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] Eeschema bus upgrades and new connectivity algorithm

[Clemens Koller]

Hello!

On 2017-12-14 14:08, Marco Ciampa wrote:
>> But when you add aliases I run into troubles to keep things separate/clear:
>> {RAM} appears to me as an unnamed bus containing the net RAM. WTF is that?
>> MEMORY{RAM} appears as a bus named MEMORY containing the single net RAM.
>> I would expect to access that net via MEMORY.RAM - Oops.
>>
>> I am definitely irritated by a net MEMORY.OE pulled out of an bus named 
>> MEMORY{RAM}. 8-(
>> It's impossible to distinguish bus aliases from nets of a bus.
> 
> Apart from the _very_ unpolite expression, I agree here.

Off-Topic: Okay, this really puzzles me. There was really no intention to 
offend somebody personally.
I just used WTF and Oops (talking in monologue) to emphasize that the syntax or 
representation seems inconsistent or confusing to me.
I might also have used a confused smiley like "@:-{" to express that. I am 
really sorry if these phrases are considered very unpolite.
English is not my native language. In case I missed the point here in general, 
maybe somebody could give me feedback off-list.


>> Idea: It might be nice to virtually allow folding/unfolding of the net
>> collection contained in a bus, i.e. by showing MEMORY{*} or MEMORY{..} or
>> MEMORY{+}, whereas the '*' or '..' or '+' is shown in a different colour.
>> If that's still to long, I would not mind renaming the bus to MEM{..} or
>> even M{..}.
> 
> The idea that Clemens is describing here (IIUIC) is that what you really
> nead is _not_ a bus alias (although is a good idea anyway...) but a more
> compact equivalent syntax for a BUS name.

To be more clear, what I've tried to express:
... a more compact representation of a bunch of nets of a bus.
 
A bus name could simply be renamed (locally/per sheet or globally), if it 
appears too long - instead of having an alias defined.
But the possibility to use aliases (for nets and/or busses) is a nice-to-have 
feature.

> Once you have defined bus names like MEMORY{something} and MEMORY.OE for
> the single bus entity, you should be able to write something for just the
> bus name like MEMORY{+} or MEMORY{*} or MEMORY{..} (may I add my 2 cents
> here? Why not MEMORY{...} tree dots to distinguish it from the vector
> syntax?) instead of have to specify always all the bus elements in the
> bus name.
> So you should have on the bus name just this label MEMORY{...} (three
> dots ... I like it!) as a bus description and MEMORY.OE and such as
> connections outputting from the bus.

I was also considering the ellipsis '...' but in classical ASCII, they are 
three characters wide, that's why I ended up with .., + or * to keep it short.
But since we arrived in Unicode, this can be solved by using the horizontal 
ellipsis single character: U+2026 '…' or in our case the midline horizontal 
ellipsis U+22EF '⋯'.

Regards,

Clemens

___
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] Eeschema bus upgrades and new connectivity algorithm

[Clemens Koller]

Hello, Orson!

On 2017-12-14 13:12, Maciej Suminski wrote:
>> But when you add aliases I run into troubles to keep things separate/clear:
>> {RAM} appears to me as an unnamed bus containing the net RAM. WTF is that?
> 
> I accept you might not like it, but this comment is not really respectful.

I am sorry if my words were too harsh. I just tried to emphasize that {RAM} 
appears confusing to me.
There is no intention to discredit Jons work.

>> Idea: It might be nice to virtually allow folding/unfolding of the net 
>> collection contained in a bus, i.e. by showing MEMORY{*} or MEMORY{..} or 
>> MEMORY{+}, whereas the '*' or '..' or '+' is shown in a different colour. If 
>> that's still to long, I would not mind renaming the bus to MEM{..} or even 
>> M{..}.
>> A simple mouseover M{..} could pop-up to show all nets and arrays the bus 
>> contains.
> 
> I do not fully get the idea. MEMORY in this case stands for a bus
> instance, so you can have several buses of the same type without
> shorting them together. How does */../+ relate to that?

A (Kicad generic) symbol as '*' or '..' or '+' might simply help to visualize 
that an object (here: the bus) contains more elements (here: net names and net 
arrays) as shown.

Regards,

Clemens

___
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] Eeschema bus upgrades and new connectivity algorithm

[Clemens Koller]

Hello, Jon!

Thank you for your work! I just watched your video and want to give you some 
feedback:

I would prefer not to use the term "Bus Vector". A bus is simply a list (or a 
collection) of arbitrarily named nets. A bus group would be - in my 
understanding - a group of (different) busses.

I like your syntax to represent the list (or collection) {} as well as an array 
of nets [].
You first had a bus containing arbitrary nets: MEMORY{A{7..0] D[15..0] OE WE} 
and you refer to single nets as i.e. MEMORY.A3 or MEMORY.OE - fine.

But when you add aliases I run into troubles to keep things separate/clear:
{RAM} appears to me as an unnamed bus containing the net RAM. WTF is that?

MEMORY{RAM} appears as a bus named MEMORY containing the single net RAM.
I would expect to access that net via MEMORY.RAM - Oops.

I am definitely irritated by a net MEMORY.OE pulled out of an bus named 
MEMORY{RAM}. 8-(
It's impossible to distinguish bus aliases from nets of a bus.

Idea: It might be nice to virtually allow folding/unfolding of the net 
collection contained in a bus, i.e. by showing MEMORY{*} or MEMORY{..} or 
MEMORY{+}, whereas the '*' or '..' or '+' is shown in a different colour. If 
that's still to long, I would not mind renaming the bus to MEM{..} or even 
M{..}.
A simple mouseover M{..} could pop-up to show all nets and arrays the bus 
contains.

Side note: For big designs, table-based design entry (as well as design entry 
by importing tons of generated connections) seems to get more and more 
important. It might be wise to consider how busses (and collections of 
) are represented there as well.

Just my five cents,

Clemens

On 2017-12-14 05:15, Jon Evans wrote:
> Hi all,
> 
> As some of you know, I've been working on some new features for Eeschema that 
> expand the capabilities of buses.
> These features are not yet complete, but I wanted to share my progress to get 
> early feedback.
> 
> Since there are a number of things, I have made a ~4 minute demo video, in 
> which I walk through them and discuss:
> 
> https://youtu.be/z6x0xiKgDIc
> 
> In case you don't want to watch the video, here are the new features:
> 
>   * The existing style of bus is now referred to as a Bus Vector (for 
> example: "A[7..0]")
>   * New concept: Bus Groups, for adding arbitrary nets to a bus
>   o Defined in a list, separated by spaces, enclosed in curly braces. For 
> example: "{DP DM}"
>   o Can contain bus vectors as well as plain nets, for example "{A[7..0] 
> D[7..0] OE WE}"
>   o Can have an optional name in front, like "MEMORY{A[7..0] D[7..0]}"
>   o If you add a name, the resulting nets will have the name prefixed on 
> the front, like "MEMORY.A7"
>   * New concept: Bus Aliases
>   o You can use aliases to define shortcuts for bus groups.
>   o For example, you could create an alias called "USB" that refers to 
> the nets "DP" and "DM"
>   o Then, you can define a bus group as "{USB}" which will contain both 
> of those nets.
>   o You can also add a label, like "USB1{USB}" which will result in nets 
> "USB1.DP" and "USB1.DM "
>   o Bus Aliases are editable through a new dialog, and saved with the 
> schematic file.
>   * New tool: Bus Unfolding
>   o Right click on a bus, and you can easily break out any of its members 
> into a bus entry, label, and wire.
>   o You place the label (and set the bus entry orientation) with the 
> first click, and then can continue wiring.
> 
> In order to support this work, I am also working on a new connectivity 
> algorithm for Eeschema.
> This algorithm stores the resulting connectivity information with the 
> graphical objects on the schematic, meaning that it's quite easy to look up 
> what net any particular object is part of.  The new algorithm is also 
> significantly (i.e. an order of magnitude) faster at generating connectivity 
> than the current netlisting algorithm in my testing so far.  It will support 
> partial updates of the connectivity when editing the schematic, so the net 
> information will always be in sync when adding/removing/editing items in the 
> schematic.
> 
> The combination of a faster algorithm and caching of the connectivity results 
> in dramatic speedups when working with large designs.
> For example, Chris' motherboard project (which is a great benchmark, by the 
> way!) takes several seconds to highlight nets in the current master branch, 
> and with my changes, you can highlight any net instantaneously.
> 
> Although it is not yet far enough along to demonstrate this, I plan to use 
> this new connectivity algorithm to generate netlists for export, and replace 
> the existing algorithm entirely.
> 
> You can check out the code in my branch here, but be warned that it is not 
> yet complete, so I am not yet proposing that anyone do exhaustive testing of 
> it and report bugs (because I already know about many of the bugs you will 
> find :-)
> 
> 

Re: [Kicad-developers] Simulator towards 5.0

[Clemens Koller]

Hi!

FYI: Your patch also touches OPENGL_GAL::BitmapText()...

Regards,
Clemens

On 2017-12-07 09:27, Maciej Sumiński wrote:
> The attached patch lists options that have "KICAD" in their name when
> calling CMake:
> 
> -- Build configuration:
> -- KICAD_BIN=bin
> -- KICAD_BRANCH_NAME=
> -- KICAD_DATA=share/kicad
> -- KICAD_DEMOS=share/kicad/demos
> -- KICAD_DOCS=share/doc/kicad
> -- KICAD_INSTALL_DEMOS=ON
> -- KICAD_LIB=lib64
> -- KICAD_PLUGINS=lib64/kicad/plugins
> -- KICAD_SCRIPTING=OFF
> -- KICAD_SCRIPTING_ACTION_MENU=OFF
> -- KICAD_SCRIPTING_MODULES=OFF
> -- KICAD_SCRIPTING_WXPYTHON=OFF
> -- KICAD_SPICE=OFF
> -- KICAD_TEMPLATE=share/kicad/template
> -- KICAD_USER_CONFIG_DIR=/home/orson
> -- KICAD_USER_PLUGIN=lib64/kicad/plugins
> -- KICAD_USE_OCE=OFF
> -- KICAD_VERSION_EXTRA=
> 
> Perhaps that would be sufficient to inform the user about the flags he
> may change.

___
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] Python: time_t needs mapping; tentative patch

[Clemens Koller]

Hmmm... time_t is supposed to be a signed integer, actually...

On 2017-11-28 13:25, Clemens Koller wrote:
> Hi!
> 
> On 2017-11-28 10:10, Henner Zeller wrote:
>>>>> IIRC the timestamp is just an unique ID of the item in Kicad, right?
>>>>> It's never propagated to the system time, so 64-bits IMHO 64-bits should
>>>>> be safe everywhere.
> 
> Fine, as long as there is an agreement that Kicad's uint64_t timestamp is 
> holding the number of seconds (not counting leap seconds) since 00:00, Jan 1 
> 1970 UTC, corresponding to POSIX time - on all platforms?
> 
> As of the time of writing this on my 64bit Arch Linux, this:
> - 8< -
> #include 
> #include 
> #include 
> int main(void) {
>   time_t timestamp;
>   time();
>   printf("time_t [PRIu64]: %" PRIu64 "\n", timestamp);
>   printf("time_t [PRIx64]: %" PRIx64 "\n", timestamp);
>   printf("sizeof(time_t): %d\n", sizeof(time_t));
>   return 0;
> }
> - 8< -
> 
> delivers:
> 
> - 8< -
> time_t [PRIu64]: 1511871892
> time_t [PRIx64]: 5a1d5594
> sizeof(time_t): 8
> - 8< -
> 
> Correct?
> 
> Regards,
> 
> Clemens
> 
> On 2017-11-28 10:10, Henner Zeller wrote:
>>>>> IIRC the timestamp is just an unique ID of the item in Kicad, right?
>>>>> It's never propagated to the system time, so 64-bits IMHO 64-bits should
>>>>> be safe everywhere.
>>>>>
>>>>> Tom
>>>>
>>>> Yes it is a unique ID only.
>>>> It is converted to a date in footprint editor (legacy mode) to show the 
>>>> last edition date to the user.
>>>> This is easy to convert a uint64_t to show this message.
>>>
>>> I suppose the most elegant solution would be to change time_t in KiCad
>>> source code to uint64_t. This leaves no ambiguity and should be easy to
>>> handle with swig.
>>
>> This sounds good to me, in particular as it reflects more the use of
>> what this is (a unique ID instead of a timestamp).
>>
>> -h
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Python: time_t needs mapping; tentative patch

[Clemens Koller]

Hi!

On 2017-11-28 10:10, Henner Zeller wrote:
 IIRC the timestamp is just an unique ID of the item in Kicad, right?
 It's never propagated to the system time, so 64-bits IMHO 64-bits should
 be safe everywhere.

Fine, as long as there is an agreement that Kicad's uint64_t timestamp is 
holding the number of seconds (not counting leap seconds) since 00:00, Jan 1 
1970 UTC, corresponding to POSIX time - on all platforms?

As of the time of writing this on my 64bit Arch Linux, this:
- 8< -
#include 
#include 
#include 
int main(void) {
time_t timestamp;
time();
printf("time_t [PRIu64]: %" PRIu64 "\n", timestamp);
printf("time_t [PRIx64]: %" PRIx64 "\n", timestamp);
printf("sizeof(time_t): %d\n", sizeof(time_t));
return 0;
}
- 8< -

delivers:

- 8< -
time_t [PRIu64]: 1511871892
time_t [PRIx64]: 5a1d5594
sizeof(time_t): 8
- 8< -

Correct?

Regards,

Clemens

On 2017-11-28 10:10, Henner Zeller wrote:
 IIRC the timestamp is just an unique ID of the item in Kicad, right?
 It's never propagated to the system time, so 64-bits IMHO 64-bits should
 be safe everywhere.

 Tom
>>>
>>> Yes it is a unique ID only.
>>> It is converted to a date in footprint editor (legacy mode) to show the 
>>> last edition date to the user.
>>> This is easy to convert a uint64_t to show this message.
>>
>> I suppose the most elegant solution would be to change time_t in KiCad
>> source code to uint64_t. This leaves no ambiguity and should be easy to
>> handle with swig.
> 
> This sounds good to me, in particular as it reflects more the use of
> what this is (a unique ID instead of a timestamp).
> 
> -h
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Recent eeschema change

[Clemens Koller]

Hi!

On 2017-11-23 09:53, Julius Schmidt wrote:
> It definitely modifies files, as is obvious from the code.
>  for( SCH_SCREEN* screen = schematic.GetFirst(); screen; screen = 
> schematic.GetNext() )
>  SaveEEFile( screen, false, CREATE_BACKUP_FILE );
> 
> is called before the dialog box appears.
> Moving that into the case where the remap button is actually pressed would 
> solve the problem.
> It'd also be nice if the remap dialog clearly stated "this will modify the 
> files on disk".

Users usually expect that *nothing* will modify their (design-)files on disk 
until some "save" or "commit" button is pressed.

Regards,

Clemens




___
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] pcbnew internals refactoring for testing

[Clemens Koller]

Hi, Simon!

On 2017-11-02 17:20, Simon Richter wrote:
> [1] http://kiwi.hogyros.de:8080/job/windows-kicad-msys2-patch/15/console

from [1]:

[...]
17:08:24 error: git apply: bad git-diff - inconsistent old filename on line 305
17:08:24 + RES=128
17:08:24 + echo ' Patch exit: 128'
17:08:24  Patch exit: 128
[...]

Is it okay to ignore that error?

Regards,

Clemens

On 2017-11-02 17:20, Simon Richter wrote:
> Hi Tom,
> 
> On 01.11.2017 23:58, Tomasz Wlostowski wrote:
> 
>> Here's a patch set [1] that refactors some internal PCBnew stuff (mostly
>> GAL & tool framework related), focusing on testability. The goal is to
>> be able to use the BOARD class, GAL view and tools without the
>> GUI-related code for the purpose of developing automated tests and
>> easier development of new tools, which could be then tested outside
>> pcbnew environment.
> 
> Cool, that's a huge step forward!
> 
>> Let me know what you think about these patches (test builds will be
>> greatly appreciated!). I would like to merge them as soon as possible to
>> avoid tedious rebasing.
> 
> I've tried an msys2 build[1], and the qa project failed due to a missing
> config.h. Did you forget to check it in, or is there a dependency
> missing (I've built with -j40)?
> 
>Simon
> 
> [1] http://kiwi.hogyros.de:8080/job/windows-kicad-msys2-patch/15/console
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] latest GerbView doesn't display test file

[Clemens Koller]

Hi!

On 2017-09-28 18:17, jp charras wrote:
> Le 28/09/2017 à 17:58, Jon Evans a écrit :
>> Perhaps another route is to improve the messaging given to the user in these 
>> cases, so that it's
>> easy for them to correct the file / report an issue to their tool vendor?
> 
> Yes.
> 
> In fact, %FSD is already supported by Gerbview because (a long time ago) I 
> found Gerber files in
> decimal format (not documented, because %FSD was never a official Gerber 
> format statement).
> 
> This is the reason no error was reported: coordinates were read as floating 
> numbers (in mm) and valid.
> 

There are several Gerber files out there in the world with an %FSD... not only 
created by PADS. It seems they don't get displayed correctly now in general.

Interestingly, there is the "D" as Format Specifier already in the rs247x.cpp 
line 308 but it seems to be
handled correctly. This is not how it's supposed to be, I believe. Simply 
replacing the D with an L makes it somehow work (some restrictions may apply, 
investigating further).

So, even if some proprietary software is crap it won't help the user much if 
they cannot find a workaround or if they don't even get a hint that something 
was going wrong.

I'll loot into the details behind the "D" Specifier, when I find some time to 
do so...

Regards,

Clemens

___
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] latest GerbView doesn't display test file

[Clemens Koller]

On 2017-09-26 13:38, jp charras wrote:
> The Gerber file is broken:
> the line:
> %FSDAX33Y33*%
> 
> is incorrect

Thank you!

Since I cannot do anything about this proprietary non compliant EDA tool, would 
it be possible to support these wrong but obvious lines anyway (maybe after 
showing a warning) - so would you accept a patch to support the %FSD gerber 
code?

Regards,

Clemens


On 2017-09-26 13:38, jp charras wrote:
> Le 26/09/2017 à 12:42, Clemens Koller a écrit :
>> Hi!
>>
>> I just tested the latest (HEAD -2h) GerbView with GAL support to see if it 
>> gets usable with big designs, but it seems that
>> it has issues to read the file properly. Gerbv just works(TM).
>>
>> Attached is a very basic file which is supposed to show milling contours + 
>> some markers.
>> Is this lack of compatibility a known issue or should I open a new bug 
>> report?
>>
>> Regards,
>>
>> Clemens
> 
> The Gerber file is broken:
> the line:
> %FSDAX33Y33*%
> 
> is incorrect: the %FSD format does not exist (It is even flagged invalid : 
> see the latest Gerber
> file format spec).
> 
> only %FSL or %FST exists.
> 
> This is a a known issue in some non Gerber compliant EDA tools.
> 

___
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

[Clemens Koller]

I was thinking about documentation layers used to illustrate areas for 
conformal coatings... keepouts around connectors and sensors might help to make 
things clear.

Regards,

Clemens

On 2017-09-27 19:22, Andrey Kuznetsov wrote:
> 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  > 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
> 

___
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] latest GerbView doesn't display test file

[Clemens Koller]

Hi!

I just tested the latest (HEAD -2h) GerbView with GAL support to see if it gets 
usable with big designs, but it seems that
it has issues to read the file properly. Gerbv just works(TM).

Attached is a very basic file which is supposed to show milling contours + some 
markers.
Is this lack of compatibility a known issue or should I open a new bug report?

Regards,

Clemens



*
*
G04 PADS VX.1.2 Build Number: 698008 generated Gerber (RS-274-X) file*
G04 PC Version=2.1*
*
%IN "Test.pcb"*%
*
%MOMM*%
*
%FSDAX33Y33*%
*
*
*
*
G04 PC Standard Apertures*
*
*
G04 Thermal Relief Aperture macro.*
%AMTER*
1,1,$1,0,0*
1,0,$1-$2,0,0*
21,0,$3,$4,0,0,45*
21,0,$3,$4,0,0,135*
%
*
*
G04 Annular Aperture macro.*
%AMANN*
1,1,$1,0,0*
1,0,$2,0,0*
%
*
*
G04 Odd Aperture macro.*
%AMODD*
1,1,$1,0,0*
1,0,$1-0.005,0,0*
%
*
*
G04 PC Custom Aperture Macros*
*
*
*
*
*
*
G04 PC Aperture Table*
*
%ADD010C,0.02*%
%ADD039C,0.1*%
*
*
*
*
G04 PC Circuitry*
G04 Layer Name Test.pcb - circuitry*
%LPD*%
*
*
G04 PC Custom Flashes*
G04 Layer Name Test.pcb - flashes*
%LPD*%
*
*
G04 PC Circuitry*
G04 Layer Name Test.pcb - circuitry*
%LPD*%
*
G54D10*
G54D39*
G01X02Y019500D02*
Y020500D01*
X019500Y02D02*
X020500D01*
X12Y093100D02*
Y094100D01*
X119500Y093600D02*
X120500D01*
X12Y019500D02*
Y020500D01*
X119500Y02D02*
X120500D01*
X02Y019500D02*
Y091800D01*
X023000*
X025000Y093800*
Y094300*
X114000Y019300D02*
Y025800D01*
X116000Y027800*
X12*
Y085800*
X116000*
X114000Y087800*
Y094300*
X019500Y093600D02*
X020500D01*
X02Y093100D02*
Y094100D01*
X00Y00D02*
M02*
___
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] Live zone filling

[Clemens Koller]

On 2017-09-19 15:59, Jon Evans wrote:
> What I want to investigate first is how difficult it would be to subdivide a 
> zone into chunks that can be generated independently.  If this is done, than 
> the chunks can be done one after the other in a single-threaded world, or 
> split up between threads if threading is possible.  But, the key advantage is 
> that if you drag a track, you can just mark the chunks that are near the 
> action as dirty, and not need to regenerate the entire zone.

Splitting the zones up in chunks sounds preferrable. Regenerating whole zone 
might not scale well with bigger designs.
Instead of marking chunks as dirty + regen after dragging the track, it might 
be an idea to regenerate/recalculate them on the fly/in realtime in another 
thread... :-)

Regards,

Clemens



> 
> -Jon
> 
> On Tue, Sep 19, 2017 at 9:56 AM, Wayne Stambaugh <stambau...@gmail.com 
> <mailto:stambau...@gmail.com>> wrote:
> 
> On 9/19/2017 9:53 AM, Simon Küppers wrote:
> > I agree with JP, however I see a chance for KiCad, where this feature
> > might work better than in other EDA packages.
> > I think the only way to get this feature to perform well is to use all
> > available processor cores.
> > Maybe it is enough to distribute all the zones to the processor cores.
> > However i do not know if the KiCad sources allow this kind of
> > multithreading.
> 
> Multi-threading inside context switching.  That could be interesting!
> 
> >
> > Best Regards
> >
> >
> > Am 2017-09-19 15:26, schrieb Jon Evans:
> >> Yes, I used Xpedition in a past life and one of my missions is to
> >> bring some of its cool features to KiCad :-)
> >>
> >> JP, I will do some tests on more complex boards and look in to
> >> possible solutions.
> >> I think this is quite a big challenge but want to take it on, because
> >> I think some of the underlying work needed will also be very useful
> >> for other things (like live DRC checking, autorouting, etc)
> >>
> >> -Jon
> >>
> >>> On Tue, Sep 19, 2017 at 8:35 AM, Clemens Koller <c...@embeon.de 
> <mailto:c...@embeon.de>>
> >>> wrote:
> >>>
> >>>> Hello, Jon!
> >>>>
> >>>> Just for Reference: That's how Mentor Expedition is exposing
> >>>> dynamic plane generation:
> >>>> https://www.youtube.com/watch?v=n6TskayF1Oc 
> <https://www.youtube.com/watch?v=n6TskayF1Oc> [1]
> >>>>
> >>>> I would be glad to test these things in Kicad...
> >>>>
> >>>> Regards,
> >>>>
> >>>> Clemens
> >>>>
> >>>> On 2017-09-19 02:18, Jon Evans wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> I've been wanting to take a look at live zone filling, as it's a
> >>>> really useful feature that some professional EDA tools have.  If
> >>>> zones refill in real time as you move things around, it's easy to
> >>>> make sure you leave enough space for your fill to succeed.
> >>>>>
> >>>>> I made a quick patch to pcbnew showing this after an interactive
> >>>> trace move (see attached gif)
> >>>>> For this board and my computer, refilling is fast enough that
> >>>> this isn't a problem (I disabled the pop up window showing a
> >>>> progress bar for the "refill all zones" command).
> >>>>>
> >>>>> Can anyone point me to (or send me) some really complicated
> >>>> KiCad designs in terms of zone fills?  Do people have designs that
> >>>> take a while to fill even on recent computers?
> >>>>>
> >>>>> If I proposed this as a patch, I'd make it an option (disabled
> >>>> by default) in case it slows down old computers, but I think if
> >>>> zone filling for moderately complex boards still takes a while
> >>>> even on fast modern computers, we should look at optimizing it so
> >>>> that we can achieve real-time filling on modern computers.
> >>>>>
> >>>>> Thanks,
> >>>>> Jon
> >>>>>
> >>>>>
> >>>>
> >>>>> __

Re: [Kicad-developers] small typo - please fix

[Clemens Koller]

On 2017-09-16 21:12, Marco Ciampa wrote:
> +   moveDownButton->SetToolTip( _("Move the selected optional fields down 
> one position down") );

- down?
lower?

> +   moveDownButton->SetToolTip( _("Move the selected optional fields one 
> position down.") );

And we put colons after full sentences, propably.

Clemens

___
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] should we change control in 3d-viewer

[Clemens Koller]

Hi!

I would be glad to test a branch with SpaceNavigator + Trackpad + 
KBD+Mouse-Support as well - and even all three of the devices at the same time. 
I can, however, build and test on Linux only. Win7 exists only virtualized.

Regards,

Clemens


On 2017-09-13 17:04, Jon Evans wrote:
> Jost posted about working on Space Navigator support back in May -- curious 
> if that is going anywhere?
> 
> -Jon
> 
> On Wed, Sep 13, 2017 at 10:57 AM, Kevin Cozens  > wrote:
> 
> On 2017-08-28 09:54 AM, Mário Luzeiro wrote:
> 
> Hi liyoubdu,
> you are free to develop new ways of browsing the 3D board and submit 
> a patch.
> 
> 
> A wish list item for me would be to be able to use a Space Navigator to 
> manipulate the view of the PCB in the 3D viewer.
> 
> -- 
> Cheers!
> 
> Kevin.
> 
> http://www.ve3syb.ca/           |"Nerds make the shiny things that 
> distract
> Owner of Elecraft K2 #2172      | the mouth-breathers, and that's why 
> we're
>                                 | powerful!"
> #include  |             --Chris Hardwick
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to     : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Concept Idea for schematic page management

[Clemens Koller]

Hello, Bastian!

I like your ideas as well.
But this Widget could contain much more information that I would call it i.e. 
"Design Explorer".
You can have your schematics in a tree view covering the hierarchical schematic 
pages as you suggest.
But then you could also browse your design by Components, by Netnames, by 
Footprints, by Designrules, etc...

And - in the long term view - when people get more into table-based design 
entry for 200++ pins components (which you won't type and manage by hand...) we 
could also have links to "externally defined components" to be 
managed/accessed/imported/exported from this "design explorer".

Regards,

Clemens


On 2017-09-07 12:06, Michael Kavanagh wrote:
> Hi Bastian,
> 
> I like this idea. The ability to leave the widget open and have it remain on 
> top whilst interacting with the schematic will be useful as well.
> 
> Another CAD package I have used has two items under each sheet/block, 
> labelled "Symbols" and "Nets", where double clicking on it would bring up the 
> edit dialog. This might be a useful feature to implement for large designs if 
> its not too much extra work.
> 
> Cheers,
> Michael
> 
> On 7 September 2017 at 10:29, Bastian Neumannn  > wrote:
> 
> Hi,
> 
> I ususlly work with schematics of around 5 to 15 pages. A3 sized that is. 
> Using A4 for schematics that easily bloats up to 30 pages.
> 
> For those schematics I am not using KiCad since they are in a 
> professional environment.
> 
> Given the situation that I am currently working on a big design in KiCad 
> that reaches up to 40 pages A3 it is a little bit cumbersome to keep track of 
> subsheets.
> 
> I propose to add more functionality to the hirarchy browser.
> 
> 1. Make the widget dockable so I can easily jump between subsheets
> 2. Have empty sheets that do not have to be placed on the schematic for 
> stuff like:
>   - Table of contents
>   - Block diagramms
>   - Change History & Reviews
>   - Additional Information
> 3. Have the ability to change the order of the sheets. Since I might add 
> one later on and don't want it to be at the end of the list
> 
> Here is an inclomplete mock up of what a big schematic for a mainboard 
> could look like.
> Inline-Bild 1
> 
> I am looking for more ideas on what to change. I think some of the 
> changes will have a big impact so we better talk about a concept beforehand.
> 
> Cheers,
> Basti
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to     : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] minor icon improvements

[Clemens Koller]

Hi!

On 2017-08-29 10:04, Fabrizio Tappero wrote:
> I changed the patch accordingly and resubmitted here. Just as reference, this 
> is what I came up with:
> -    Run Gerbview
> +   View GERBER

I suggest to use "Gerber" intead of "GERBER" in general. "Gerber" is not an 
abbreviation.

Regards,

Clemens

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

[Clemens Koller]

Hi!

Maybe, some of these HDI Design Guides + documents are useful:

http://www.we-online.com/web/de/index.php/download/media/04_leiterplatte/2011_2/relaunch/produkte_5/microvia_hdi/141030_DesignGuide_HDI_1_1.pdf
Page 8 gives quite a good overview of what's possible - at least!

http://www.ilfa.de/wp-content/uploads/2016/09/ILFA-Designregeln-Multilayer.pdf
http://www.ilfa.de/wp-content/uploads/2016/09/ILFA-Designregeln-Starrflex.pdf

Some rules for Via-in-Pad or Via on top of Via on some layers, but not others 
might become a bit tricky.
Vias clearances can depend on the used drill diameter as well.
So there might not be a one clearance size fits all sizes in some designs.

Regards,

Clemens



On 2017-08-22 14:05, Bastian Neumannn wrote:
> Hi
> 
>> Ultimately is it useful to design a board, if you cannot make it?
> 
> Right now I can fabricate boards, I can not design. That is also not a good 
> solution.
> 
> via constraints are tricky bussiness as they are very specific to the 
> manufacturer.
> 
>> PS:
>> The current "tracks and vias editor" dialog is (for me) a not finished work:
>> It does not make any DRC test after editing, and this is *really annoying*.
> 
> This is what I am working on at the moment. To have a propper mask where one 
> can input constraints for vias.
> 
> At the moment you can only define some layers. There is much more work to do. 
> Like staggered/stacked µvias
> 
> Inline-Bild 2
> 
> Based on this dialog I plan on having more layer masks to only show layers 
> described here.
> 
> Cheers
> 
> 2017-08-22 13:00 GMT+02:00 jp charras  >:
> 
> Le 22/08/2017 à 12:10, Simon Küppers a écrit :
> > I second this. Working in a Research Institute I can assure you, that 
> very often there are circuit
> > boards with "interesting" stackups and via configurations... These 
> boards are not produced by
> > quick-turn factories like eurocircuits but companies such as ILFA or 
> Optiprint.
> >
> > It would be unwise to cut out those users from KiCad.
> 
> I dont't remember I said we should restrict vias to eurocircuits 
> constraints.
> 
> Moreover "very often there are circuit boards with "interesting" stackups 
> and via configurations"
> lead me to think there are constraints, unless I missed something.
> (if there are "via configurations", there are constraints)
> 
> I don't think eurocircuits is at quick-turn factory (although I have 
> myself any experience about
> blind/buried vias) but I think blind/buried vias can have constraints, 
> because I saw constraints in
> board houses.
> 
> Ultimately is it useful to design a board, if you cannot make it?
> 
> In fact, Pcbnew is really lacking a board stackup editor, to define not 
> only the stackup layers, but
> some other parameters (via parameters, copper thickness, dielectric 
> thickness and type, and a few
> other parameters).
> 
> This board stackup definition is needed not only for vias, but also for 
> impedance controlled boards.
> 
> PS:
> The current "tracks and vias editor" dialog is (for me) a not finished 
> work:
> It does not make any DRC test after editing, and this is *really 
> annoying*.
> 
> 
> >
> >
> > Am 2017-08-22 09:57, schrieb hauptmech:
> >> On 22/08/17 18:25, jp charras wrote:
> >>> Le 22/08/2017 à 05:55, hauptmech a écrit :
>  Manufacturing techniques vary between manufacturers and continuously 
> evolve. Why would kicad limit
>  itself to what eurocircuits can do? They have optimized their 
> process for quick turn prototyping
>  and
>  while they document their process nicely, they are probably not a 
> good reference for what can be
>  done.
> 
>  On 21/08/17 05:44, jp charras wrote:
> > Before working on blind and buried vias dialog, please have a look 
> at:
> > https://www.eurocircuits.com/blog/Blind-and-buried-vias 
> 
> >>> Currently there is no control in Kicad.
> >>>
> >>> Sure, but it looks like there are some constraints on blind/buried 
> vias (microvias are blind/buried
> >>> vias) depending on board houses.
> >>>
> >>> So it could be worth to be able to control these constraints inside 
> Kicad (at least to have a
> >>> minimal control).
> >>>
> >>> We currently have a DRC which detects too small clearances and track 
> widths:
> >>> this is most of time due to manufacturing constraints which 
> continuously evolve.
> >>>
> >> I don't think I have enough understanding of the proposal to have an
> >> opinion. I just want to caution against creating unnecessary
> >> limitations in kicad. It really depends on the board house. I used to
> >> work for one and there were quite a few atypical techniques used for
> >> customer specific projects (many kept 

Re: [Kicad-developers] [PATCH] simplied right click menu icons

[Clemens Koller]

Hi!

If we want to avoid clockwise (CW) and counterclockwise (CCW) I suggest to add 
a sign to the rotation, which should be trivial to translate:

Mathematics/complex plane stuff tells that:
CCW = positive rotation =  rotate + = rot+
CW = negative rotation = rotate - = rot-

In german we can use "rotieren +" und "rotieren -".

Regards,

Clemens


On 2017-07-18 19:34, jp charras wrote:
> Le 18/07/2017 à 19:14, "Jörg Hermann" a écrit :
>> Translation of Clockwise and Counterclockwise are long texts in many 
>> languages:
>> Uhrzeigersinn and Gegenuhrzeigersinn in german for example.
>>  
>> If the icon depicts (dynamically) the sense of rotation, the text can be 
>> short as "Rotate" - which
>> is short in many languages.
>> Just an idea?
>>  
>> Jörg Hermann
>>  
> 
> I agree icons should show the rotation.
> 
> However Rotate Clockwise (or Counter Clockwise ) is still needed (just 
> "Rotate" is not acceptable)
> because icons are not always displayed:
> - On OSX by default (although they can be shown, this is an option in Kicad, 
> now)
> - On Linux, some WM do not display icons in menus.
> 
> Besides, English language is know for its short words and sentences.
> Translations are using most of time longer words and sentences, and this is 
> sometimes an issue in menus.
> We (translators) have to live with that.
> 

___
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] No models in 3d-viewer.

[Clemens Koller]

Hi!

Do you see any chance to use git-bisect to find the patch triggering your 
problem?

Regards,

Clemens


On 2017-07-02 18:46, Kristoffer Ödmark wrote:
> Hello!
> 
> Maybe my 3d-models are not due to the GPU or drivers, but I do have a 
> strange error that I believe is. Since from what I gather I am the only 
> one who has it :)
> 
> If I use the openGl mode. It gets superslow using pcbnew. I mean slow as 
> in changing the topmost layer or starting a new track takes around 6 
> seconds. So much time that I can manually go into GDB and get a 
> stacktrace that looks like this, very easily reproduced:
> 
> #0  0x73697c47 in ioctl () at /usr/lib/libc.so.6
> #1  0x7fffd5710988 in drmIoctl () at /usr/lib/libdrm.so.2
> #2  0x7fffd3eb4459 in amdgpu_cs_query_fence_status () at 
> /usr/lib/libdrm_amdgpu.so.1
> #3  0x7fffd50566de in  () at /usr/lib/xorg/modules/dri/radeonsi_dri.so
> #4  0x7fffd50557e8 in  () at /usr/lib/xorg/modules/dri/radeonsi_dri.so
> #5  0x7fffd5055cec in  () at /usr/lib/xorg/modules/dri/radeonsi_dri.so
> #6  0x7fffd507cc45 in  () at /usr/lib/xorg/modules/dri/radeonsi_dri.so
> #7  0x7fffd4b08d74 in  () at /usr/lib/xorg/modules/dri/radeonsi_dri.so
> #8  0x7fffd49831d4 in  () at /usr/lib/xorg/modules/dri/radeonsi_dri.so
> #9  0x7fffd4983aca in  () at /usr/lib/xorg/modules/dri/radeonsi_dri.so
> #10 0x7fffd7582e6e in KIGFX::CACHED_CONTAINER::Map() 
> (this=0x4fdf0d0) at 
> /home/krille/projects/kicad/common/gal/opengl/cached_container.cpp:234
> #11 0x7fffd7571903 in KIGFX::VERTEX_MANAGER::Map() (this=0x4fded80) 
> at /home/krille/projects/kicad/common/gal/opengl/vertex_manager.cpp:54
> #12 0x7fffd7560f5f in KIGFX::OPENGL_GAL::BeginUpdate() 
> (this=0x39f0c70) at 
> /home/krille/projects/kicad/common/gal/opengl/opengl_gal.cpp:389
> #13 0x7fffd74b7729 in KIGFX::VIEW::ChangeLayerDepth(int, int) 
> (this=0x33407d0, aLayer=109, aDepth=8) at 
> /home/krille/projects/kicad/common/view/view.cpp:730
> #14 0x7fffd74b7bd6 in KIGFX::VIEW::UpdateAllLayersOrder() 
> (this=0x33407d0) at /home/krille/projects/kicad/common/view/view.cpp:821
> #15 0x7fffd70a0d98 in PCB_DRAW_PANEL_GAL::SetTopLayer(PCB_LAYER_ID) 
> (this=0x209d850, aLayer=F_Cu) at 
> /home/krille/projects/kicad/pcbnew/pcb_draw_panel_gal.cpp:278
> #16 0x7fffd70a095c in 
> PCB_DRAW_PANEL_GAL::SetHighContrastLayer(PCB_LAYER_ID) (this=0x209d850, 
> aLayer=F_Cu) at 
> /home/krille/projects/kicad/pcbnew/pcb_draw_panel_gal.cpp:185
> #17 0x7fffd70a21b2 in PCB_DRAW_PANEL_GAL::SetHighContrastLayer(int) 
> (this=0x209d850, aLayer=0) at 
> /home/krille/projects/kicad/pcbnew/pcb_draw_panel_gal.h:72
> #18 0x7fffd6e38073 in PCB_EDIT_FRAME::SetActiveLayer(PCB_LAYER_ID) 
> (this=0x2049af0, aLayer=F_Cu) at 
> /home/krille/projects/kicad/pcbnew/pcbframe.cpp:896
> #19 0x7fffd6e5dbfd in PCB_LAYER_WIDGET::OnLayerSelect(int) 
> (this=0x35563b0, aLayer=0) at 
> /home/krille/projects/kicad/pcbnew/class_pcb_layer_widget.cpp:471
> #20 0x7fffd704d7a9 in LAYER_WIDGET::OnLeftDownLayers(wxMouseEvent&) 
> (this=0x35563b0, event=...) at 
> /home/krille/projects/kicad/pcbnew/layer_widget.cpp:122
> #21 0x765685be in 
> wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
> wxEvtHandler*, wxEvent&) () at /usr/lib/libwx_baseu-3.0.so.0
> #22 0x765689ca in 
> wxEvtHandler::SearchDynamicEventTable(wxEvent&) () at 
> /usr/lib/libwx_baseu-3.0.so.0
> #23 0x76568a5f in wxEvtHandler::TryHereOnly(wxEvent&) () at 
> /usr/lib/libwx_baseu-3.0.so.0
> #24 0x76568b13 in wxEvtHandler::ProcessEventLocally(wxEvent&) () 
> at /usr/lib/libwx_baseu-3.0.so.0
> #25 0x76568b75 in wxEvtHandler::ProcessEvent(wxEvent&) () at 
> /usr/lib/libwx_baseu-3.0.so.0
> #26 0x765688d7 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () 
> at /usr/lib/libwx_baseu-3.0.so.0
> #27 0x76cdf47d in  () at /usr/lib/libwx_gtk2u_core-3.0.so.0
> #28 0x730a37ac in  () at /usr/lib/libgtk-x11-2.0.so.0
> #29 0x72a7aead in g_closure_invoke () at 
> /usr/lib/libgobject-2.0.so.0
> #30 0x72a8d4ee in  () at /usr/lib/libgobject-2.0.so.0
> #31 0x72a9566f in g_signal_emit_valist () at 
> /usr/lib/libgobject-2.0.so.0
> #32 0x72a966ef in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
> #33 0x731bb8cc in  () at /usr/lib/libgtk-x11-2.0.so.0
> #34 0x730a1f74 in gtk_propagate_event () at 
> /usr/lib/libgtk-x11-2.0.so.0
> #35 0x730a232b in gtk_main_do_event () at 
> /usr/lib/libgtk-x11-2.0.so.0
> #36 0x72d1946c in  () at /usr/lib/libgdk-x11-2.0.so.0
> #37 0x71fefa47 in g_main_context_dispatch () at 
> /usr/lib/libglib-2.0.so.0
> #38 0x71fefc78 in  () at /usr/lib/libglib-2.0.so.0
> #39 0x71feff92 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
> #40 0x730a13a7 in gtk_main () at /usr/lib/libgtk-x11-2.0.so.0
> #41 0x76cbe865 in wxGUIEventLoop::DoRun() () at 
> 

Re: [Kicad-developers] 3D Mouse (Spacenavigator) support

[Clemens Koller]

Hello, Jost!

I would be glad to test Kicad with 3D Mouse support, too.
(An Wacom Intuos Pro pen tablet is also laying around.)

Maybe it's wise to talk to the devs of spacenav and check their sparse mailing 
list at http://spacenav.sourceforge.net
how i.e. axis mapping will be abstracted across applications.
It doesn't seem appealing to me that each application on Linux will have to 
implement it's own 3D Mouse configuration.
On Linux, we have at least Blender, FreeCAD, Calligra using the libspnav stuff.
libspnav was initially targeted to be cross-platform, but the current status 
seems unknown regarding that.
There are other applications which might be worth to checkout: OpenSceneGraph, 
GoogleEarth and Ogre.

Some issues to consider:
- Seemless switching in between FreeCad and Kicad (and all the other 3D Mouse 
apps) should / need to be possible.
(I was reading lots about user level driver vs. system driver issues.)
- WGOIS and VRPN might be worth to check out?

Some more links:
http://janoc.rd-h.com/archives/74
https://github.com/vrpn/vrpn/wiki/Troubleshooting-VRPN
https://groups.google.com/forum/#!topic/liquid-galaxy/ThdQ-g4B5g8
https://sourceforge.net/p/wgois/patches/30/
https://sourceforge.net/p/wgois/patches/34/

We are adding more and more features even some "professional" 10kEUR+ software 
doesn't support!
(Or they say it's all there, but the implementation is just crap.)
Great!

Regards,

Clemens

On 2017-05-17 12:26, mrkenhoff wrote:
> Hi all,
> 
> thanks for your feedback.
>> If you can meet these requirements, I see no reason why we would not
>> include the spacenavigator mouse support.
> I think there shouldn't be any problem meeting these requirements. Thanks 
> Wayne!
>> As far as libspnav goes, look through the source, it's actually pretty 
>> simple. I'm not sure how blender is doing it, or whether this is a good 
>> idea, but the device handling is actually pretty thinly veiled around 
>> evdev.
> After I looked at the source I found out that Blender uses a different 
> approach for each OS:
> 
>   * Windows: RawInput (Low level HID API)
>   * Linux: Uses spnav library
>   * OSX: Dynamically links to the original 3Dconnexion driver
> 
> In my opinion the cleanest solution for KiCad would be to connect to the low 
> level HID API of each OS and do not use any spacenav specific driver at all. 
> That way there are no additional dependencies and the implementations for all 
> three operating systems share a great ammount of code.
> As Dan noted, the libsnav "driver" (actually a deamon, to be more precise) is 
> quite simple. It will serve as a good inspiration.
> 
> Jost
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bugs in hotkey assignments - cannot differentiate NumPad hotkeys.

[Clemens Koller]

I just created a new bugreport for Issue 1: 
https://bugs.launchpad.net/kicad/+bug/1686432

Issue 2 might be related to: https://bugs.launchpad.net/kicad/+bug/1562617

Regards,

Clemens

On 2017-04-26 16:44, Chris Pavlina wrote:
> Shouldn't matter, numpad keys are traditionally treated separately for
> hotkey use.
> 
> Clemens, can you link me to the bug report? I've been absent from
> development for a while, but I'll be back soon and this is code I've
> worked on a lot. I'll assign it to myself and fix it when I get a
> chance.
> 
> 
> On Fri, Apr 21, 2017 at 02:27:48PM +1200, Simon Wells wrote:
>> probably a stupid question but was your numlock on or off?
>>
>> On 21 April 2017 at 12:13, Clemens Koller <c...@embeon.de> wrote:
>>> Hi!
>>>
>>> On 2017-04-20 16:56, Maciej Sumiński wrote:
>>>> We would really appreciate if bug reports were kept on the bug tracker.
>>>> I am afraid this report will be lost after a few days of mailing list
>>>> traffic, unless someone fixes the problem right now.
>>>
>>> No worries. Is it okay to extend the current report or should I open 
>>> another one?
>>> Additionally, I would be glad to get some feedback if there is already 
>>> someone working on this issue or if it won't get fixed at all in eeschema 
>>> for some other general redesign reasons.
>>>
>>> It would also be okay to point me to some code to get my hands dirty on my 
>>> own if it makes sense in this case. MMMV.
>>>
>>> Regards,
>>>
>>> Clemens
>>>
>>>
>>> On 2017-04-20 16:56, Maciej Sumiński wrote:
>>>> Hi Clemens,
>>>>
>>>> We would really appreciate if bug reports were kept on the bug tracker.
>>>> I am afraid this report will be lost after a few days of mailing list
>>>> traffic, unless someone fixes the problem right now.
>>>>
>>>> Regards,
>>>> Orson
>>>>
>>>> On 04/19/2017 10:49 PM, Clemens Koller wrote:
>>>>> Hi, there!
>>>>>
>>>>> I am starting a new, clean EESchema - latest git of today.
>>>>> The default Hotkeys are Zoom In = F1, Zoom Out = F2, etc...
>>>>>
>>>>> Issue 1:
>>>>> I was planning to change the Zoom In/Out hotkeys in Preferences - 
>>>>> Schematic Editor Options - Controls to use
>>>>> Zoom In = NumPad + and Zoom Out = NumPad -
>>>>>
>>>>> The issue is, that the Set Hotkey dialog actually recognizes the NumPad 
>>>>> +/- keystroke and closes, but it doesn't accepted the Hotkey assignments. 
>>>>> F1 and F2 still stays as before without further notice.
>>>>>
>>>>> Using the non-NumPad + and - keys seem to work, but they might be used in 
>>>>> a different way later on as these are just different keys.
>>>>> So, why doesn't Kicad recognize the NumPad Keys, why doesn't Kicad 
>>>>> regognize different keys as such?
>>>>>
>>>>>
>>>>> Issue 2:
>>>>> The Tooltips of the Zoom buttons don't get updated with the newly 
>>>>> assigned keys. The still show F1 and F2 for the zooming whereas + and - 
>>>>> was assigned.
>>>>> Can we fix that?
>>>>>
>>>>>
>>>>> This might be related to: https://bugs.launchpad.net/kicad/+bug/1562617
>>>>>
>>>>> Regards,
>>>>>
>>>>> Clemens
>>>>>
>>>>>
>>>>> Version information:
>>>>> Application: kicad
>>>>> Version: (2017-04-19 revision 1366cf6ac)-master, release build
>>>>> Libraries: wxWidgets 3.0.2
>>>>>libcurl/7.53.1 OpenSSL/1.0.2k zlib/1.2.11 libpsl/0.17.0 
>>>>> (+libicu/58.2) libssh2/1.8.0
>>>>> Platform: Linux 4.10.10-1-ARCH x86_64, 64 bit, Little endian, wxGTK
>>>>> - Build Info -
>>>>> wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
>>>>> Boost: 1.63.0
>>>>> Curl: 7.53.1
>>>>> KiCad - Compiler: GCC 6.3.1 with C++ ABI 1010
>>>>> Settings: USE_WX_GRAPHICS_CONTEXT=OFF
>>>>>   USE_WX_OVERLAY=OFF
>>>>>   KICAD_SCRIPTING=ON
>>>>>   KICAD_SCRIPTING_MODULES=ON
>>>>>   KICAD_SCRIPTING_WXPYTHON=ON
>>>>>   KICAD_SCR

Re: [Kicad-developers] Bugs in hotkey assignments - cannot differentiate NumPad hotkeys.

[Clemens Koller]

Hi!

On 2017-04-20 16:56, Maciej Sumiński wrote:
> We would really appreciate if bug reports were kept on the bug tracker.
> I am afraid this report will be lost after a few days of mailing list
> traffic, unless someone fixes the problem right now.

No worries. Is it okay to extend the current report or should I open another 
one?
Additionally, I would be glad to get some feedback if there is already someone 
working on this issue or if it won't get fixed at all in eeschema for some 
other general redesign reasons.

It would also be okay to point me to some code to get my hands dirty on my own 
if it makes sense in this case. MMMV.

Regards,

Clemens


On 2017-04-20 16:56, Maciej Sumiński wrote:
> Hi Clemens,
> 
> We would really appreciate if bug reports were kept on the bug tracker.
> I am afraid this report will be lost after a few days of mailing list
> traffic, unless someone fixes the problem right now.
> 
> Regards,
> Orson
> 
> On 04/19/2017 10:49 PM, Clemens Koller wrote:
>> Hi, there!
>>
>> I am starting a new, clean EESchema - latest git of today.
>> The default Hotkeys are Zoom In = F1, Zoom Out = F2, etc...
>>
>> Issue 1:
>> I was planning to change the Zoom In/Out hotkeys in Preferences - Schematic 
>> Editor Options - Controls to use
>> Zoom In = NumPad + and Zoom Out = NumPad -
>>
>> The issue is, that the Set Hotkey dialog actually recognizes the NumPad +/- 
>> keystroke and closes, but it doesn't accepted the Hotkey assignments. F1 and 
>> F2 still stays as before without further notice.
>>
>> Using the non-NumPad + and - keys seem to work, but they might be used in a 
>> different way later on as these are just different keys.
>> So, why doesn't Kicad recognize the NumPad Keys, why doesn't Kicad regognize 
>> different keys as such?
>>
>>
>> Issue 2:
>> The Tooltips of the Zoom buttons don't get updated with the newly assigned 
>> keys. The still show F1 and F2 for the zooming whereas + and - was assigned.
>> Can we fix that?
>>
>>
>> This might be related to: https://bugs.launchpad.net/kicad/+bug/1562617
>>
>> Regards,
>>
>> Clemens
>>
>>
>> Version information:
>> Application: kicad
>> Version: (2017-04-19 revision 1366cf6ac)-master, release build
>> Libraries: wxWidgets 3.0.2
>>libcurl/7.53.1 OpenSSL/1.0.2k zlib/1.2.11 libpsl/0.17.0 
>> (+libicu/58.2) libssh2/1.8.0
>> Platform: Linux 4.10.10-1-ARCH x86_64, 64 bit, Little endian, wxGTK
>> - Build Info -
>> wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
>> Boost: 1.63.0
>> Curl: 7.53.1
>> KiCad - Compiler: GCC 6.3.1 with C++ ABI 1010
>> 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=OFF
>>   BUILD_GITHUB_PLUGIN=ON
>>   KICAD_USE_OCE=OFF
>>
>>
>>
>>
>> ___
>> 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

[Kicad-developers] Bugs in hotkey assignments - cannot differentiate NumPad hotkeys.

[Clemens Koller]

Hi, there!

I am starting a new, clean EESchema - latest git of today.
The default Hotkeys are Zoom In = F1, Zoom Out = F2, etc...

Issue 1:
I was planning to change the Zoom In/Out hotkeys in Preferences - Schematic 
Editor Options - Controls to use
Zoom In = NumPad + and Zoom Out = NumPad -

The issue is, that the Set Hotkey dialog actually recognizes the NumPad +/- 
keystroke and closes, but it doesn't accepted the Hotkey assignments. F1 and F2 
still stays as before without further notice.

Using the non-NumPad + and - keys seem to work, but they might be used in a 
different way later on as these are just different keys.
So, why doesn't Kicad recognize the NumPad Keys, why doesn't Kicad regognize 
different keys as such?


Issue 2:
The Tooltips of the Zoom buttons don't get updated with the newly assigned 
keys. The still show F1 and F2 for the zooming whereas + and - was assigned.
Can we fix that?


This might be related to: https://bugs.launchpad.net/kicad/+bug/1562617

Regards,

Clemens


Version information:
Application: kicad
Version: (2017-04-19 revision 1366cf6ac)-master, release build
Libraries: wxWidgets 3.0.2
   libcurl/7.53.1 OpenSSL/1.0.2k zlib/1.2.11 libpsl/0.17.0 
(+libicu/58.2) libssh2/1.8.0
Platform: Linux 4.10.10-1-ARCH x86_64, 64 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.63.0
Curl: 7.53.1
KiCad - Compiler: GCC 6.3.1 with C++ ABI 1010
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=OFF
  BUILD_GITHUB_PLUGIN=ON
  KICAD_USE_OCE=OFF




___
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 2/2] Remove redundant statement in WRL2BASE::ReadNode

[Clemens Koller]

Hi!

These lines scream for some comments in the source...
I wouldn't get it, too.

Regards,

Clemens

On 2017-04-13 14:03, Wayne Stambaugh wrote:
> Cirilo,
> 
> Thanks for the info.  The second call to ReadName() does look a bit odd
> so I can understand Konrad's confusion.
> 
> Cheers,
> 
> Wayne
> 
> On 4/12/2017 6:12 PM, Cirilo Bernardo wrote:
>> Do not accept this patch, it will break the parser. The statement
>> which was removed is not redundant.
>>
>> - Cirilo
>>
>> On Wed, Apr 12, 2017 at 8:01 PM, Konrad Beckmann
>>  wrote:
>>> ---
>>>  plugins/3d/vrml/v2/vrml2_base.cpp | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>>
>>> ___
>>> 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

Re: [Kicad-developers] Bug 1677282 fix feedback.

[Clemens Koller]

Hi!

#3 ++
Simply because it's the most transparent and informative way to solve the issue.
Maybe it's wise additionally to recommend saving the file to a different 
filename because it could matter...

#5 could be to have #4 saving to a different filename or creating a backup of 
the old one automatically to take care about VCS users ... but then people 
might wonder WTF is going on when new files pop up.

I believe that putting out clear and comprehensive information of what's going 
on is the way to go. That way you delegate the responsibility to the user but 
still assist to decide which options are suitable and best.

Regards,

Clemens


On 2017-03-30 19:33, Wayne Stambaugh wrote:
> I have found and fixed the bug in this bug report:
> 
> https://bugs.launchpad.net/kicad/+bug/1677282
> 
> This bug creates invalid schematic files which sets the component unit
> flag to 0 and breaks the netlist generator.  The fix itself is simple.
> What is not simple is what to do about the invalid schematic files that
> have already been created.  I added code to schematic parser to fix this
> but this creates a dilemma.  Technically the schematic is modified which
> begs the question, what to do next.  None of the following choices are
> particularly appealing:
> 
> 1) Do nothing and leave the file in an invalid status until the next
> time the user saves the schematic.  This is probably the most convenient
> but what about broken schematics being used by versions of kicad prior
> to this fix?
> 
> 2) Set the schematic modified status which will trigger a save warning
> when eeschema is closed even if the user hasn't made any changes.  We
> already do this with SCH_SCREEN::SchematicCleanUp() that gets called
> lots of places outside of schematic editing.  The problem with this is
> that the user has no idea why they are getting a save warning when they
> didn't actually change anything.
> 
> 3) Set the schematic modified status and inform the user that there was
> an error in their schematic file that was repaired on load and requires
> saving.  This is the most informative for the user but reeks of nagware.
> 
> 4) Silently save the corrected schematic with no user interaction.  This
> will undoubtedly make VCS users unhappy.
> 
> As much as I hate nagware, I like unexpected save warnings when I
> haven't changed anything even less so I'm leaning towards option 3.  Any
> feedback would be appreciated.
> 
> Thanks,
> 
> 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

Re: [Kicad-developers] [PATCH] CW/CCW rotation in GAL

[Clemens Koller]

Hello, Jon!

On 2017-03-30 11:07, John Beard wrote:
> Hi,
> When CW/CCW rotation was added in GAL (7045ed92f), the tool actions
> didn't correct for the internal represention of angles, so CW/CCW were
> reversed. This patch fixes that. I failed to notice the comment "//
> TODO rotate CCW" was wrong. On the other hand, it seems only one
> person actually noticed since Feb 4th :-p, including myself.
> 
> Now, eeschema standard rotate (R) is CW, but legacy Pcbnew "Rotate+"
> (also R) is CCW.
> 
> I have not changed the hotkey assignment for the GAL actions, so it
> now matches eeschema, not legacy mode. I think that CW-default is the
> better default?

I would strongly prefer to use the mathematically positive rotation (CCW) by 
default.

R -> CCW (Rotate +)andShift-R -> CW (Rotate -)

Simply because it's what the majority of applications use...

Regards,

Clemens

___
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] UI improvements

[Clemens Koller]

Hi, Chris!

On 2017-03-23 11:24, Chris Pavlina wrote:
> On Thu, Mar 23, 2017 at 10:27:55AM +0100, Clemens Koller wrote:
>> Hello, Chris!
>>
>> On 2017-03-23 00:12, Chris Pavlina wrote:
>>> On Wed, Mar 22, 2017 at 11:53:40PM +0100, Clemens Koller wrote:
>>>> The timestamp is not human readable. It seems strange to me to dump it as 
>>>> hex-number on the UI. (WTF!?)
>>>
>>> I'm struggling to think of a use for this. Maybe for power users, to
>>> jump quickly to the component in the raw sch file by searching for it -
>>> but why not just search for the reference?
>>>
>>> I wonder how many people would complain if I took that out.
>>
>> I'd complain. 8-)
>> Because the timestamp is a valuable information (until we have proper 
>> version control in situ).
>> But: NOT in hex form. 
> 
> Really? How do you use it?

I can see when I generated/modified the component the last time in the lib and
compare it to the version/date/timestamp of the library generator.
Different designs might have different versions in use...
Some designs will get updated during a redesign, some won't.
Having a timestamp is a short-cut to comparing the lib with a diff-tool.

Regards,

Clemens

___
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