[Kicad-developers] Moving field-texts with connecting line to component; potential patch
Hi, While moving a field text (REFERENCE, VALUE and such) in the schematic, it is possible to loose the visual sight to which component it belonged to, in particular in tight spaces (which is typically the time when you need to start moving labels around). At least once I swapped the visual designators with different components .. creating a mess. So while moving such a label, I think it would be good if there was a visual indicator to which component that label belongs to -- a simple line would do. This would only be drawn while moving is in progress; see attached image how this could look like. I have prepared a patch that does that (the image is done with this patch): https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels As the way to draw differs for not-moving vs. moving (there is an additional line), the very first draw operation with XOR doesn't make sense, as the line hasn't been there before. Likewise the opposite when stopping moving. So here I keep a little state in the SCH_FIELD component that keeps track if the _last_ draw operation was seeing IsMoving(). I haven't found if there is a better way within the framework to better get informed about these transitions. If so, please point me how to implement that more elegantly. And as usual, here the patch download link: https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels.diff cheers, -henner attachment: suggested-move-field-operation.png___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Moving field-texts with connecting line to component; potential patch
Le 07/02/2014 09:22, Henner Zeller a écrit : Hi, While moving a field text (REFERENCE, VALUE and such) in the schematic, it is possible to loose the visual sight to which component it belonged to, in particular in tight spaces (which is typically the time when you need to start moving labels around). At least once I swapped the visual designators with different components .. creating a mess. So while moving such a label, I think it would be good if there was a visual indicator to which component that label belongs to -- a simple line would do. This would only be drawn while moving is in progress; see attached image how this could look like. I have prepared a patch that does that (the image is done with this patch): https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels As the way to draw differs for not-moving vs. moving (there is an additional line), the very first draw operation with XOR doesn't make sense, as the line hasn't been there before. Likewise the opposite when stopping moving. So here I keep a little state in the SCH_FIELD component that keeps track if the _last_ draw operation was seeing IsMoving(). I haven't found if there is a better way within the framework to better get informed about these transitions. If so, please point me how to implement that more elegantly. And as usual, here the patch download link: https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels.diff cheers, -henner Good idea. This feature was existing in Pcbnew, but not in Eeschema. May I ask you to have a look to our coding style policy (see Documentation/coding_style_policy.pdf) before submitting a patch. Thanks for your interest in Kicad. -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Patch: CvPcb - bring footprint window to front when it is buried
On 5 February 2014 17:18, Henner Zeller h.zel...@acm.org wrote: Hi, I usually have a lot of windows stacked on my desktop, which often obscures the 'footprint window' in CvPcb. Pressing the 'view selected footprint' brings the window up the _first_ time, but when it is already there, it stays buried - which is frustrating. So I created the following patch, that works well in Linux and does exactly how it should behave: bringing the window second in the stack of windows on the screen. The focus still stays on CvPcb, but the window is brought as much to the top as possible. I don't know if there is a special function in wxWidgets to achieve that, but the proposed method in the patch works fine. There is a slight chance that this might create a flicker-experience in some other OSes window managers, so please give suggestions how this could be worked around there, if it turns out to be a problem. View patch: https://github.com/hzeller/kicad/compare/master...make-existing-footprint-window-visible Download: https://github.com/hzeller/kicad/compare/master...make-existing-footprint-window-visible.diff Thanks, -henner Hi Henner, Thanks for the patch. I'll get round to testing it tonight. If it doesn't cause problems (I'm sure it won't) then I'll commit it for you. However, please note the coding style policy ( http://www.kicad-pcb.org/display/DEV/Getting+Started ) as we don't use this- to refer to class members, simply omit this- and refer to class members directly. Best Regards, Brian. ___ Mailing list: https://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] Moving field-texts with connecting line to component; potential patch
On 7 February 2014 10:31, jp charras jp.char...@wanadoo.fr wrote: Le 07/02/2014 09:22, Henner Zeller a écrit : Hi, While moving a field text (REFERENCE, VALUE and such) in the schematic, it is possible to loose the visual sight to which component it belonged to, in particular in tight spaces (which is typically the time when you need to start moving labels around). At least once I swapped the visual designators with different components .. creating a mess. So while moving such a label, I think it would be good if there was a visual indicator to which component that label belongs to -- a simple line would do. This would only be drawn while moving is in progress; see attached image how this could look like. I have prepared a patch that does that (the image is done with this patch): https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels As the way to draw differs for not-moving vs. moving (there is an additional line), the very first draw operation with XOR doesn't make sense, as the line hasn't been there before. Likewise the opposite when stopping moving. So here I keep a little state in the SCH_FIELD component that keeps track if the _last_ draw operation was seeing IsMoving(). I haven't found if there is a better way within the framework to better get informed about these transitions. If so, please point me how to implement that more elegantly. And as usual, here the patch download link: https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels.diff cheers, -henner Good idea. This feature was existing in Pcbnew, but not in Eeschema. May I ask you to have a look to our coding style policy (see Documentation/coding_style_policy.pdf) before submitting a patch. Thanks for your interest in Kicad. This is a great feature, thanks for your interest Henner! Best Regards, Brian. ___ Mailing list: https://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] Has something changed in the track drag code?
Recently I noticed (sporadic) crashes when using the
drag-track-keep-slope function. SIGSEG and SIGILL. The nasty stuff.
I trapped a core dump of an occurrance. gdb says:
Program terminated with signal SIGILL, Illegal instruction.
#0 0x046bef42 in ?? ()
(gdb) bt
#0 0x046bef42 in ?? ()
#1 0x006ed801 in PCB_EDIT_FRAME::Start_DragTrackSegmentAndKeepSlope
(this=0x2c42d60, track=0x3716520, DC=0x7c225f30) at
/home/lomarcan/cvswork/kicad-bzr/pcbnew/move_or_drag_track.cpp:726
#2 0x006a4a71 in PCB_EDIT_FRAME::Process_Special_Functions (
this=0x2c42d60, event=...) at
/home/lomarcan/cvswork/kicad-bzr/pcbnew/edit.cpp:1134
The statements seems to be
if( ( track-end == NULL ) || ( track-end-Type() == PCB_TRACE_T) )
TrackToEndPoint = track-GetTrace( GetBoard()-m_Track, NULL, FLG_END );
I fear a corruption of track-end... scavenging the core gives for
track-end:
$6 = {BOARD_ITEM = {EDA_ITEM = {KIGFX::VIEW_ITEM = {
_vptr.VIEW_ITEM = 0x459c9ef, m_view = 0x45dae60, m_visible = 232,
m_groups = 0x0, m_groupsSize = 0, m_layers = {std::_Base_bitset2ul
= {
_M_w = {0, 0}}, No data fields}}, m_StructType = EOT, m_Status =
0,
Pnext = 0x4747ea8, Pback = 0x0, m_List = 0x0, m_Parent = 0x0,
m_TimeStamp = 1391772801, m_forceVisible = false, m_Flags = 0,
m_Image = 0x60008}, m_Layer = -64853952, static ZeroOffset = {x = 0,
y = 0}},
m_TracksConnected = {std::_Vector_baseTRACK*, std::allocatorTRACK* = {
_M_impl = {std::allocatorTRACK* = {__gnu_cxx::new_allocatorTRACK*
= {No data fields}, No data fields}, _M_start = 0xf232afd8, _M_finish =
0x45cb3e8,
_M_end_of_storage = 0x0}}, No data fields},
m_PadsConnected = {std::_Vector_baseD_PAD*, std::allocatorD_PAD* = {
_M_impl = {std::allocatorD_PAD* = {__gnu_cxx::new_allocatorD_PAD*
= {No data fields}, No data fields}, _M_start = 0x0, _M_finish = 0x0,
_M_end_of_storage = 0x0}}, No data fields}, m_NetCode = 0, m_Subnet =
0,
m_ZoneSubnet = 56674392}
The object itself doesn't seem too broken to do a misjump on the vtbl...
however the m_StructType at EOT seems suspicious.
I have no idea of what is happened... suggestions? In the meanwhile I'll try to
reproduce it live.
--
Lorenzo Marcantonio
Logos Srl
___
Mailing list: https://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: new KiCad icons
Thanks Lorenzo, I will slowly modifying a little some of the icons and consider your suggestions. I will however try to keep the present look otherwise the doc guys will kill me. With icons, as for many things, 20 people will produce 20 different looks. I will do my best to include your suggestions. Regards Fabrizio On Fri, Feb 7, 2014 at 8:50 AM, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: On Thu, Feb 06, 2014 at 05:31:12PM +0100, Marco Serantoni wrote: Fabrizio, Nice set, they looks much cleaver than older ones. ^^^ cleaner, I think... Agree with that, the color scheme is more consistent. *Personal* comments follow. In eeschema: - The show hidden pins maybe is not very clear... maybe something like a pin drawn (like the Add Pin) in dashed style would be better? - In the annotate icon I'd have left the U? marking. Even better something like U? - U1 - The backannotate icon seems more a 'go to pcb' icon. Maybe something like the cvpcb icon in reverse? like [package icon]-[schematic icon] - I don't like at all the new NET/BOM icons :P for the BOM maybe a dotted list, for the netlist even something like a real net... (we have a ladybug for the DRC, so...). Or something like the autorouting mode or the ratnest icon in pcbnew - Still no idea of why we keep the copy/cut since only paste is done that way:D - Place graphic lines: why the handles at the ends and not simply a dashed segment? - Load component/update component: why the arrow up/down and not left/right as in all other icons? In cvpcb: - Not an icon issue, but I noticed this; the configuration icon calls up the old legacy library configurator. The menu item calls up the new fptable configurator. I think that would be very confusing. In pcbnew: - In the show vias mode bigger via and smaller tracks:P the sketching effect now is barely visible. For consistency I'd keep the track width in the via display and track display like that in the zone fill icons. There is still the issue (but I think thats a wxwidget one) of the selection border for the active button nearly invisible... -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://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] Release note
There is a new release [lp:~cern-kicad/kicad/selection_tool] available for testing with some improvements to the tools: - undo/redo for all operations you can do in the GAL canvas - highlighted ratsnest for currently modified items (also for the PNS router) - for those who have strong habits - you can edit items in the same way as with the default canvas (hover over an item and select an operation), for people willing to try another approach - you may select items and then modify them (using hotkeys or right-click context menu) I would like to thank Carl Poirier for speeding up the ratsnest algorithm for multicore CPUs - good job! Also, for those who have not checked the selection_tool branch before, there are some other changes to experience: https://lists.launchpad.net/kicad-developers/msg11907.html As usual - I would be very grateful for some testing, before I propose the branch for merging. This time it is particularly important to me, as there are some changes to KiCad's core. This means that I really need to be sure that there is nothing broken. Now you should be able to carry out most editing steps in a more comfortable way than before. The next step is drawing tools. Please let me know what else you miss in the GAL canvas. Regards, Orson ___ Mailing list: https://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] Release note
On 2/7/2014 5:29 AM, Maciej Sumiński wrote: There is a new release [lp:~cern-kicad/kicad/selection_tool] available for testing with some improvements to the tools: - undo/redo for all operations you can do in the GAL canvas - highlighted ratsnest for currently modified items (also for the PNS router) - for those who have strong habits - you can edit items in the same way as with the default canvas (hover over an item and select an operation), for people willing to try another approach - you may select items and then modify them (using hotkeys or right-click context menu) I would like to thank Carl Poirier for speeding up the ratsnest algorithm for multicore CPUs - good job! Also, for those who have not checked the selection_tool branch before, there are some other changes to experience: https://lists.launchpad.net/kicad-developers/msg11907.html As usual - I would be very grateful for some testing, before I propose the branch for merging. This time it is particularly important to me, as there are some changes to KiCad's core. This means that I really need to be sure that there is nothing broken. Now you should be able to carry out most editing steps in a more comfortable way than before. The next step is drawing tools. Please let me know what else you miss in the GAL canvas. Regards, Orson Orson, I've already tested it and I cannot find any issues with it. I do have one minor (hopefully) request. Right clicking an object does not bring up the context menu like the legacy canvas. You first have to select the object and then right click to get the context menu. Making this change should give you 100% coverage of object editing even if all of the hot keys are not yet implemented. I will also mimic the legacy canvas behavior which users are familiar with. 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
Re: [Kicad-developers] Moving field-texts with connecting line to component; potential patch
I like the way it works. But when using it on a component with a filled rectangle the line keeps appearing as an artifact. This does not happen with non filled rectangles. Se attached image. 2014-02-07 Brian Sidebotham brian.sidebot...@gmail.com: On 7 February 2014 10:31, jp charras jp.char...@wanadoo.fr wrote: Le 07/02/2014 09:22, Henner Zeller a écrit : Hi, While moving a field text (REFERENCE, VALUE and such) in the schematic, it is possible to loose the visual sight to which component it belonged to, in particular in tight spaces (which is typically the time when you need to start moving labels around). At least once I swapped the visual designators with different components .. creating a mess. So while moving such a label, I think it would be good if there was a visual indicator to which component that label belongs to -- a simple line would do. This would only be drawn while moving is in progress; see attached image how this could look like. I have prepared a patch that does that (the image is done with this patch): https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels As the way to draw differs for not-moving vs. moving (there is an additional line), the very first draw operation with XOR doesn't make sense, as the line hasn't been there before. Likewise the opposite when stopping moving. So here I keep a little state in the SCH_FIELD component that keeps track if the _last_ draw operation was seeing IsMoving(). I haven't found if there is a better way within the framework to better get informed about these transitions. If so, please point me how to implement that more elegantly. And as usual, here the patch download link: https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels.diff cheers, -henner Good idea. This feature was existing in Pcbnew, but not in Eeschema. May I ask you to have a look to our coding style policy (see Documentation/coding_style_policy.pdf) before submitting a patch. Thanks for your interest in Kicad. This is a great feature, thanks for your interest Henner! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp attachment: artifact.png___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] General suckitude of wx lock files
Got tired of all the lockfiles in the home directory, tried to look at the issue. Sadly is (almost) everything in wxWidgets. It doesn't even catch SIGTERM so a shutdown or ^C or whatever else don't cleanup them. Solution: ripped out the lockfile logic from my branch :P Question: do we really need them? IIRC they were only for coordinating the eeschema/pcbnew IPC (and it's a confirmation only). Data files are only read/written in a single go, not kept open as a db. Since locks are in the home it doesn't even guard over NFS (or other file sharing mechanism). The worst? You overwrite modification you did in another instance. We could eventually warn for this comparing filestamps (vim does it that way). Now I'm working happier:D did I miss some fatal flaw? -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://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] Build failed in Jenkins: kicad-qa #37
See http://ci.kicad-pcb.org/job/kicad-qa/37/changes Changes: [Marco Serantoni] [MacOSX] Automating building for OSX with KICAD_SCRIPTING, see Documentation/compiling/mac-osx.txt -- Started by an SCM change Building in workspace http://ci.kicad-pcb.org/job/kicad-qa/ws/ $ bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ info result: bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ returned 0. Command output: 4669 brian.sidebot...@gmail.com-20140207183841-0u6hq7o8mu8sxkqw stderr: [kicad-qa] $ bzr pull --overwrite lp:kicad You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. See bzr help launchpad-login. http://bazaar.launchpad.net/~kicad-product-committers/kicad/product is permanently redirected to http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. See bzr help launchpad-login. +N CMakeModules/download_pcre.cmake +N CMakeModules/download_swig.cmake +N CMakeModules/download_wxpython.cmake M CMakeLists.txt M Documentation/compiling/mac-osx.txt M pcbnew/CMakeLists.txt M pcbnew/pcbnew.cpp M scripts/osx_fixbundle.sh All changes applied successfully. Now on revision 4670. [kicad-qa] $ bzr revert $ bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ info result: bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ returned 0. Command output: 4670 marco.serant...@gmail.com-20140207185354-8asr0xog2snr4twc stderr: [kicad-qa] $ bzr log -v -r revid:brian.sidebot...@gmail.com-20140207183841-0u6hq7o8mu8sxkqw..revid:marco.serant...@gmail.com-20140207185354-8asr0xog2snr4twc --long --show-ids Getting local revision... $ bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ info result: bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ returned 0. Command output: 4670 marco.serant...@gmail.com-20140207185354-8asr0xog2snr4twc stderr: RevisionState revno:4670 revid:marco.serant...@gmail.com-20140207185354-8asr0xog2snr4twc [kicad-qa] $ /bin/sh -xe /tmp/hudson4678954738694123698.sh + OPTS=' -DCMAKE_BUILD_TYPE=Release -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON' + '[' -d build ']' + cd build + /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Release -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON -- Check for installed OpenGL -- found -- Found Glew: /usr/lib64/libGLEW.so -- Check for installed GLEW -- found -- Check for installed Cairo -- found -- Check for installed wxWidgets -- found -- Check for installed Python Interpreter -- found -- Python module install path: /usr/lib/python2.6/site-packages -- Bazaar version control system version found. -- Kicad Bazaar build version: (2014-02-07 BZR 4670) -- Configuring done -- Generating done -- Build files have been written to: http://ci.kicad-pcb.org/job/kicad-qa/ws/build + make -j4 _pcbnew [ 1%] [ 1%] Built target boost Generating headers containing GLSL source code Headers are up-to-date [ 1%] [ 3%] Built target shader_headers [ 3%] Built target lib_dxf Built target avhttp [ 53%] Built target bitmaps [ 55%] Built target gal [ 56%] Built target polygon [ 56%] Built target 3d-viewer [ 58%] Built target pnsrouter [ 58%] Built target github_plugin [ 60%] Built target pcad2kicadpcb [ 66%] Built target pcbcommon Scanning dependencies of target common [ 66%] Building CXX object common/CMakeFiles/common.dir/build_version.cpp.o Linking CXX static library libcommon.a [ 76%] Built target common Scanning dependencies of target _pcbnew [ 76%] Building CXX object pcbnew/CMakeFiles/_pcbnew.dir/pcbnew.cpp.o http://ci.kicad-pcb.org/job/kicad-qa/ws/pcbnew/pcbnew.cpp: In member function ‘virtual bool EDA_APP::OnInit()’: http://ci.kicad-pcb.org/job/kicad-qa/ws/pcbnew/pcbnew.cpp:163: error: cannot convert ‘const char*’ to ‘const wxChar*’ for argument ‘1’ to ‘wxChar* wxGetenv(const wxChar*)’ http://ci.kicad-pcb.org/job/kicad-qa/ws/pcbnew/pcbnew.cpp:170: error: cannot convert ‘const char*’ to ‘const wxChar*’ for argument ‘1’ to ‘wxChar* wxGetenv(const wxChar*)’ http://ci.kicad-pcb.org/job/kicad-qa/ws/pcbnew/pcbnew.cpp:170: error: cannot convert ‘const char*’ to ‘const wxChar*’ for argument ‘1’ to ‘wxChar* wxGetenv(const wxChar*)’ http://ci.kicad-pcb.org/job/kicad-qa/ws/pcbnew/pcbnew.cpp:170: error: call of overloaded ‘wxString(const char [1])’ is ambiguous /usr/include/wx-2.8/wx/string.h:722: note: candidates are: wxString::wxString(const wxWCharBuffer) near match /usr/include/wx-2.8/wx/string.h:692: note: wxString::wxString(wxChar, size_t) near match /usr/include/wx-2.8/wx/string.h:690: note: wxString::wxString(const wxString) near match /usr/include/wx-2.8/wx/string.h:682: note:
[Kicad-developers] Users view on latest release
Hello All Hope I'm not upsetting the apple cart but thought I give a view on how a dumb user see's the latest releases. Thanks to all of your help I'm not able to regularly build the latest cutting edge releases. I have noted a few things with this version. Firstly trying to create a project is impossible, kicad just crashes either on creating or opening, I have to create it with the old stable release. Secondly in eeschema I used to be able to place parts by just typing the parts name like r for a resistor, now this produces a results box with the whole library in it so i have to go and find it manually, I used to just click on the place part icon, click on the page, type r and hit enter and bingo, same applies for c ect and capapol brings up a search result with just one result so why not place it anyway. Thirdly, I can't progress beyond the schematic capture! I have no idea how the new pcb libraries work and can't even assign pcb footprints to the schematic, I have tried reading the manual but being a dumb user it makes no sense at all and seems to explain principles rather than what to do about it. I search for the file that should hold the path to the libraries brings up so many files I have no idea which one to use. I realize this is a pre-release version but if it goes out like this many won't be able to use it I cannot work out how to point the program at the libraries location. I hope that is of some help to you in understanding how the current release looks from a users point of view. Kind regards Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Release note
On 02/07/2014 01:52 PM, Wayne Stambaugh wrote: On 2/7/2014 5:29 AM, Maciej Sumiński wrote: There is a new release [lp:~cern-kicad/kicad/selection_tool] available for testing with some improvements to the tools: - undo/redo for all operations you can do in the GAL canvas - highlighted ratsnest for currently modified items (also for the PNS router) - for those who have strong habits - you can edit items in the same way as with the default canvas (hover over an item and select an operation), for people willing to try another approach - you may select items and then modify them (using hotkeys or right-click context menu) I would like to thank Carl Poirier for speeding up the ratsnest algorithm for multicore CPUs - good job! Also, for those who have not checked the selection_tool branch before, there are some other changes to experience: https://lists.launchpad.net/kicad-developers/msg11907.html As usual - I would be very grateful for some testing, before I propose the branch for merging. This time it is particularly important to me, as there are some changes to KiCad's core. This means that I really need to be sure that there is nothing broken. Now you should be able to carry out most editing steps in a more comfortable way than before. The next step is drawing tools. Please let me know what else you miss in the GAL canvas. Regards, Orson Orson, I've already tested it and I cannot find any issues with it. I do have one minor (hopefully) request. Right clicking an object does not bring up the context menu like the legacy canvas. You first have to select the object and then right click to get the context menu. Making this change should give you 100% coverage of object editing even if all of the hot keys are not yet implemented. I will also mimic the legacy canvas behavior which users are familiar with. Thanks, Wayne Hi Wayne, Thank you for testing. The idea sounds good, it is already commited in the branch - it did not require many changes. Regards, Orson ___ Mailing list: https://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] Moving field-texts with connecting line to component; potential patch
Hi Henner,
The way I did it in the Piglet hierarchical drawing editor[1] was to put
a function in each primitive that is responsible for drawing rubberband
representations of the primitive. The drawing function gets fed a
sequence of transformed mouse coordinates by a callback in the
eventloop.
So for my line drawing primitive, when my parser decides something needs
to be moved, I set a callback with the event loop with:
`rubber_set_callback(draw_line);
draw_line(double x, double y, int count) is my callback function
and is different for each primitive. It is always called with
the current x,y mouse coordinates and a count. The count starts
at zero and increments for every new coordinate.
After the parser is done with the rubber band drawing and has accepted
the pick, it calls
rubber_clear_callback();
to clear the callback. After receiving rubber_clear_callback(),
the event loop sends one final call to draw_line, this time with
a count of -1.
The draw_line function in geom_line.c looks like this:
void draw_line(double x2, double y2, int count) {
...
if (count == 0) { /* first call */
jump(bb, D_RUBBER); /* draw new shape */
do_line(dbdeflist, bb, D_RUBBER);
} else if (count 0) { /* intermediate calls */
jump(bb, D_RUBBER); /* erase old shape */
do_line(dbdeflist, bb, D_RUBBER);
jump(bb, D_RUBBER); /* draw new shape */
coord_swap_last(CP, x2, y2); /* update new coords */
do_line(dbdeflist, bb, D_RUBBER);
} else {/* last call, cleanup */
jump(bb, D_RUBBER); /* erase old shape */
do_line(dbdeflist, bb, D_RUBBER);
}
/* save old values */
x1old=x1;
y1old=yy1;
x2old=x2;
y2old=y2;
jump(bb, D_RUBBER);
}
The jump() starts a new disconnected segment and turns the drawing
engine to XOR mode (D_RUBBER). Then I just call the main line drawing
routine with the current list of coords.
The key thing is that the XWIN event loop calls the draw_line routine
through the callback with an integer count argument. On the first time
we just do an XOR. The second and subsequent times, we remember our old
position and unwrite it with an XOR before drawing the new coordinate.
Finally, after the event loop gets a rubber_clear_callback(), the last
call has count=-1. This causees the last drawing to be erased and no
new one to be made.
Every primitive has its own specific callback for rubber band drawing.
For instance, I represent hierarchical sub-cells by just a bounding box
so that I don't have to render all the details.
I found that having a centralized callback from the event loop that
simply sends back the mouse coordinates to the rubber band drawing
routine simplified my code and gave me a standard way to handle the XOR
cleanup problem.
Here's the callback hook from the xwin.c event loop.
while (XCheckMaskEvent(dpy, all, xe)) { /* pending X Event */
switch (xe.type) {
case MotionNotify:
...
if (xold != x || yold != y) {
if (xwin_display_state() == D_ON) {
rubber_draw(x, y);
}
xold=x;
yold=y;
}
...
Here's the code for rubber.c
/* *
this set of routines manages the rubber band drawing function for
interactive point selection. The rubber band shapes are drawn with an
xor function such that drawing a line twice will erase it. We need to
ensure that the first shape drawn after rubber_set_callback() gets
erased before the second shape is drawn, and so on, until the last call
is made by rubber_clear_callback().
rubber_set_callback();
First call (x1,y1,0):
draw x1, y1
Second call (x2,y2,1)
draw x1, y1 # erase last shape
draw x2, y2 # drawn new shape
(N-1)th call (x(n-1),y(n-1), n-1)
draw x(n-2), y(n-2) # erase last shape
draw x(n-1), y(n-1) # draw new shape
rubber_clear_callback();
Last call (xn, yn, -1)
draw x(n-1), y(n-1) # erase last shape
# and DONT draw new shape
The callback function manages this behavior by the count variable passed
in the third argument. When count==0, it only draws the specified
shape. When count=0 it always undraws the old shape prior to drawing
the new shape. When count=0 it will undraw the old shape, and NOT draw
a new shape. rubber_clear_callback() is responsible for making the last
call with count=-1.
* */
#include stdio.h
#include rubber.h
typedef int Function ();
static int count=0;
Function * rubber_callback = NULL;
void rubber_set_callback(func)
Function
Re: [Kicad-developers] Release note
On 2/7/2014 2:52 PM, Maciej Sumiński wrote: On 02/07/2014 01:52 PM, Wayne Stambaugh wrote: On 2/7/2014 5:29 AM, Maciej Sumiński wrote: There is a new release [lp:~cern-kicad/kicad/selection_tool] available for testing with some improvements to the tools: - undo/redo for all operations you can do in the GAL canvas - highlighted ratsnest for currently modified items (also for the PNS router) - for those who have strong habits - you can edit items in the same way as with the default canvas (hover over an item and select an operation), for people willing to try another approach - you may select items and then modify them (using hotkeys or right-click context menu) I would like to thank Carl Poirier for speeding up the ratsnest algorithm for multicore CPUs - good job! Also, for those who have not checked the selection_tool branch before, there are some other changes to experience: https://lists.launchpad.net/kicad-developers/msg11907.html As usual - I would be very grateful for some testing, before I propose the branch for merging. This time it is particularly important to me, as there are some changes to KiCad's core. This means that I really need to be sure that there is nothing broken. Now you should be able to carry out most editing steps in a more comfortable way than before. The next step is drawing tools. Please let me know what else you miss in the GAL canvas. Regards, Orson Orson, I've already tested it and I cannot find any issues with it. I do have one minor (hopefully) request. Right clicking an object does not bring up the context menu like the legacy canvas. You first have to select the object and then right click to get the context menu. Making this change should give you 100% coverage of object editing even if all of the hot keys are not yet implemented. I will also mimic the legacy canvas behavior which users are familiar with. Thanks, Wayne Hi Wayne, Thank you for testing. The idea sounds good, it is already commited in the branch - it did not require many changes. Regards, Orson Hey Orson, Hopefully I can get the testing done over the weekend. If it looks good, I will commit the changes to the product branch. Keep up the good work! Cheers, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Patch: CvPcb - bring footprint window to front when it is buried
On 7 February 2014 02:37, Brian Sidebotham brian.sidebot...@gmail.com wrote: On 5 February 2014 17:18, Henner Zeller h.zel...@acm.org wrote: Hi, I usually have a lot of windows stacked on my desktop, which often obscures the 'footprint window' in CvPcb. Pressing the 'view selected footprint' brings the window up the _first_ time, but when it is already there, it stays buried - which is frustrating. So I created the following patch, that works well in Linux and does exactly how it should behave: bringing the window second in the stack of windows on the screen. The focus still stays on CvPcb, but the window is brought as much to the top as possible. I don't know if there is a special function in wxWidgets to achieve that, but the proposed method in the patch works fine. There is a slight chance that this might create a flicker-experience in some other OSes window managers, so please give suggestions how this could be worked around there, if it turns out to be a problem. View patch: https://github.com/hzeller/kicad/compare/master...make-existing-footprint-window-visible Download: https://github.com/hzeller/kicad/compare/master...make-existing-footprint-window-visible.diff Thanks, -henner Hi Henner, Thanks for the patch. I'll get round to testing it tonight. If it doesn't cause problems (I'm sure it won't) then I'll commit it for you. thanks! However, please note the coding style policy ( http://www.kicad-pcb.org/display/DEV/Getting+Started ) as we don't use this- to refer to class members, simply omit this- and refer to class members directly. I'll have a closer look at the style policy over the weekend. Updated the patch now to not contain this- for the local member. -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
Re: [Kicad-developers] Patch: CvPcb - bring footprint window to front when it is buried
On 7 February 2014 16:17, Henner Zeller h.zel...@acm.org wrote: On 7 February 2014 02:37, Brian Sidebotham brian.sidebot...@gmail.com wrote: On 5 February 2014 17:18, Henner Zeller h.zel...@acm.org wrote: Hi, I usually have a lot of windows stacked on my desktop, which often obscures the 'footprint window' in CvPcb. Pressing the 'view selected footprint' brings the window up the _first_ time, but when it is already there, it stays buried - which is frustrating. So I created the following patch, that works well in Linux and does exactly how it should behave: bringing the window second in the stack of windows on the screen. The focus still stays on CvPcb, but the window is brought as much to the top as possible. I don't know if there is a special function in wxWidgets to achieve that, but the proposed method in the patch works fine. There is a slight chance that this might create a flicker-experience in some other OSes window managers, so please give suggestions how this could be worked around there, if it turns out to be a problem. View patch: https://github.com/hzeller/kicad/compare/master...make-existing-footprint-window-visible Download: https://github.com/hzeller/kicad/compare/master...make-existing-footprint-window-visible.diff Thanks, -henner Hi Henner, Thanks for the patch. I'll get round to testing it tonight. If it doesn't cause problems (I'm sure it won't) then I'll commit it for you. thanks! Hi Henner, Committed in BZR4669 with very slight changes to the comments only. Thanks! Best Regards, Brian. ___ Mailing list: https://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] Jenkins build is back to normal : kicad-qa #38
See http://ci.kicad-pcb.org/job/kicad-qa/38/changes ___ Mailing list: https://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] Recent dependencies break builds.
Please use find_package() first and then if you need to download the dependency source and build the dependency. Some developers (me) prefer to build project dependencies outside of KiCad source. That way when I do a make clean, I don't have to rebuild all of the dependencies as well. The only exception to this is to patch a bug that effects KiCad like we have to do with Boost. If it's a build fix only patch, always use find_package() first. I believe this was added to resolve OSX build issues. If this is an OSX only issue, please qualify this with a platform check so as not to break building on other platforms. 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
Re: [Kicad-developers] Users view on latest release
Dear Simon, Interesting email. Please do not assume that many people will have your problem only because you have a problem. Have you looked a the txt tutorial in help menu? Have you looked at the video tutorials in the official kicad website? Let us know how you go, personally, i am a little interested? Also, let us know how you would expect kicad to help you. Good luck mate Fabrizio On 07/02/2014 8:13 PM, Simon Turner si...@simonsphotography.org.uk wrote: Hello All Hope I'm not upsetting the apple cart but thought I give a view on how a dumb user see's the latest releases. Thanks to all of your help I'm not able to regularly build the latest cutting edge releases. I have noted a few things with this version. Firstly trying to create a project is impossible, kicad just crashes either on creating or opening, I have to create it with the old stable release. Secondly in eeschema I used to be able to place parts by just typing the parts name like r for a resistor, now this produces a results box with the whole library in it so i have to go and find it manually, I used to just click on the place part icon, click on the page, type r and hit enter and bingo, same applies for c ect and capapol brings up a search result with just one result so why not place it anyway. Thirdly, I can't progress beyond the schematic capture! I have no idea how the new pcb libraries work and can't even assign pcb footprints to the schematic, I have tried reading the manual but being a dumb user it makes no sense at all and seems to explain principles rather than what to do about it. I search for the file that should hold the path to the libraries brings up so many files I have no idea which one to use. I realize this is a pre-release version but if it goes out like this many won't be able to use it I cannot work out how to point the program at the libraries location. I hope that is of some help to you in understanding how the current release looks from a users point of view. Kind regards Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] General suckitude of wx lock files
On 7 February 2014 10:42, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: Got tired of all the lockfiles in the home directory, tried to look at the issue. Sadly is (almost) everything in wxWidgets. FYI, I found the same thing and filed a patch with the wxWidgets people a couple of days ago. Looks like they just applied it: http://trac.wxwidgets.org/ticket/15944 .. however, this probably will only make it into the 3.x version, so might take some time until it will generally be available. It doesn't even catch SIGTERM so a shutdown or ^C or whatever else don't cleanup them. I think we should have signal handlers that deletes the singleton instance to clean up the mess^H^H^H^HLockfile Solution: ripped out the lockfile logic from my branch :P Question: do we really need them? IIRC they were only for coordinating the eeschema/pcbnew IPC (and it's a confirmation only). Data files are only read/written in a single go, not kept open as a db. Since locks are in the home it doesn't even guard over NFS (or other file sharing mechanism). The worst? You overwrite modification you did in another instance. We could eventually warn for this comparing filestamps (vim does it that way). I think we should switch to some IPC mechanism (e.g. something over a UNIX domain socket in Unix) to transfer some basic information between programs. E.g. would send an event to CvPcb to fetch a new netist etc. Might be worth considering. -h Now I'm working happier:D did I miss some fatal flaw? -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://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] Ooops. wxpython build failure
. . . checking for CAIRO... yes checking for cairo_push_group... yes checking for GST... configure: WARNING: GStreamer 0.10 not available, falling back to 0.8 checking for GST... configure: WARNING: GStreamer 0.8/0.10 not available. configure: error: GStreamer not available Error running configure ERROR: failed building wxWidgets Traceback (most recent call last): File wxPython/build-wxpython.py, line 378, in module File /home//kicad/build/kicad.bzr/.downloads-by-cmake/libwxpython/src/libwxpython/build/tools/build-wxwidgets.py, line 364, in main Error running configure) File /home/bzr help/kicad/build/kicad.bzr/.downloads-by-cmake/libwxpython/src/libwxpython/build/tools/build-wxwidgets.py, line 80, in exitIfError raise builder.BuildError(msg) BuildError make[2]: *** [.downloads-by-cmake/libwxpython/libwxpython-configure] Error 1 make[1]: *** [CMakeFiles/libwxpython.dir/all] Error 2 make: *** [all] Error 2 But, of course, I do have gstreamer, lots of gstreamer packages, contrary to cmake configure. # rpm -qa | grep gstreamer . . . gstreamer-devel-0.10.36-3.fc19.x86_64 gstreamer-0.10.36-3.fc19.x86_64 . . . Lots of other gstreamer packages . I suppose I should have been satisfied with head from a few days ago. bash-4.2$ bzr version-info revision-id: miguelan...@ajo.es-20140208000229-fl29wmjfd7xqx9ey date: 2014-02-08 01:02:29 +0100 build-date: 2014-02-07 21:22:17 -0600 revno: 4675 branch-nick: product If somebody could steer me to teaching cmake about yum platforms as well as apt this or that. everything else in the head built fine. ___ Mailing list: https://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 dependencies break builds.
Broken here too. On Feb 7, 2014 2:59 PM, Wayne Stambaugh stambau...@verizon.net wrote: Please use find_package() first and then if you need to download the dependency source and build the dependency. Some developers (me) prefer to build project dependencies outside of KiCad source. That way when I do a make clean, I don't have to rebuild all of the dependencies as well. The only exception to this is to patch a bug that effects KiCad like we have to do with Boost. If it's a build fix only patch, always use find_package() first. I believe this was added to resolve OSX build issues. If this is an OSX only issue, please qualify this with a platform check so as not to break building on other platforms. 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] Ooops. wxpython build failure
On 02/07/2014 09:30 PM, inkblotter wrote: . . . checking for CAIRO... yes checking for cairo_push_group... yes checking for GST... configure: WARNING: GStreamer 0.10 not available, falling back to 0.8 checking for GST... configure: WARNING: GStreamer 0.8/0.10 not available. configure: error: GStreamer not available Error running configure ERROR: failed building wxWidgets Traceback (most recent call last): File wxPython/build-wxpython.py, line 378, in module File /home//kicad/build/kicad.bzr/.downloads-by-cmake/libwxpython/src/libwxpython/build/tools/build-wxwidgets.py, line 364, in main Error running configure) File /home/bzr help/kicad/build/kicad.bzr/.downloads-by-cmake/libwxpython/src/libwxpython/build/tools/build-wxwidgets.py, line 80, in exitIfError raise builder.BuildError(msg) BuildError make[2]: *** [.downloads-by-cmake/libwxpython/libwxpython-configure] Error 1 make[1]: *** [CMakeFiles/libwxpython.dir/all] Error 2 make: *** [all] Error 2 But, of course, I do have gstreamer, lots of gstreamer packages, contrary to cmake configure. # rpm -qa | grep gstreamer . . . gstreamer-devel-0.10.36-3.fc19.x86_64 gstreamer-0.10.36-3.fc19.x86_64 . . . Lots of other gstreamer packages . I suppose I should have been satisfied with head from a few days ago. bash-4.2$ bzr version-info revision-id: miguelan...@ajo.es-20140208000229-fl29wmjfd7xqx9ey date: 2014-02-08 01:02:29 +0100 build-date: 2014-02-07 21:22:17 -0600 revno: 4675 branch-nick: product If somebody could steer me to teaching cmake about yum platforms as well as apt this or that. everything else in the head built fine. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp Here's another point of light. I tracked down where cmake unpacked wxWidgets 3.0 and built it entirely and installed it without a whisper of problems. I still can't build head because even though I built wxWidgets myself, cmake doesn't seem to be able to do the same for some reason. It would be better if boost and wxWidgets were built outside the tree and merely checked for by cmake. I wouldn't have any problem building either. ___ Mailing list: https://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: don't hardcode wxPython path
The recent addition of CMakeModules/download_wxpython.cmake has resulted in
build failures. The main cause is the fact the --prefix option passed to
the configure script of wxPython is hardcoded to /Users/marco/
Development/product/libwxpython_root. The attached patch replaces that with
the appropriate CMake variable, ${LIBWXPYTHON_ROOT}. This fixes the build
for me.
The additional system dependencies for this also need to be documented. On
Ubuntu 13.04, I needed to install the libgstreamer-plugins-base0.10-dev
package to get a pkg-config file so the wxPython build could find the
system install of gstreamer; this is a required dependency for the build to
succeed.
To the limited extent of my testing, KiCad had been compiling fine with the
system copies of wxPython and swig. Is there now a need for this to be
built locally in all cases, or can it be dependent on the OS or some other
set of conditions?
Regards,
Blair
=== modified file 'CMakeModules/download_wxpython.cmake'
--- CMakeModules/download_wxpython.cmake 2014-02-07 22:00:19 +
+++ CMakeModules/download_wxpython.cmake 2014-02-08 05:12:38 +
@@ -74,7 +74,7 @@
UPDATE_COMMAND ${CMAKE_COMMAND} -E remove_directory ${LIBWXPYTHON_ROOT}
COMMAND ${LIBWXPYTHON_EXEC} wxPython/build-wxpython.py --clean
-CONFIGURE_COMMAND ${LIBWXPYTHON_EXEC} wxPython/build-wxpython.py --prefix=/Users/marco/Development/product/libwxpython_root --unicode --install ${LIBWXPYTHON_OPTS}
+CONFIGURE_COMMAND ${LIBWXPYTHON_EXEC} wxPython/build-wxpython.py --prefix=${LIBWXPYTHON_ROOT} --unicode --install ${LIBWXPYTHON_OPTS}
#BINARY_DIR ${PREFIX}
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
