On 11/29/13 10:58, Maciej Sumiński wrote: > On 11/28/2013 09:58 PM, mj wrote: >> On 11/28/13 13:10, Martijn Kuipers wrote: >>> >>> On Nov 28, 2013, at 12:07 PM, Lorenzo Marcantonio >>> <[email protected]> wrote: >>> >>>> On Thu, Nov 28, 2013 at 10:56:42AM +0100, Maciej Sumiński wrote: >>>> >>>>> I am particularly interested in the main developers' view about >>>>> points: >>>>> - Cut/copy/paste >>>> >>>> Never felt a need for copy/paste on a board... YMMV of course (perhaps >>>> for modular I/O stages or such?) >>> >>> I can see it be fun to be able to Cut & Paste from one board to another. >>> For instance, copy the switching power supply part as a whole. >> Cut&Paste would be nice :). But I guess it'll be used to repeat parts of >> an schematic which should be solved in an more elegant way - treat board >> layouts as parts. Sure, you'll need some special part in eeschema to >> denote a track as connection to "the other board". > > I am not sure if I got it right - are you talking about "subschematics" > or schematics blocks (have a look at demos/complex_hierarchy.sch that is > delivered with KiCad source code)? And then, in case you have multiple > blocks using the same pattern in schematics (e.g. a few ADCs with > filters) to duplicate parts layout on the board? What do you call the one in demos/complex_hierarchy? It's reusing the same schematic twice with differnent annotations (done this before, saves quite some time doing a switch matrix - but with hierarchy labels). Guess if it's using hierarchy labels, it's a subschematic in your terminology?
>> Sounds confusing to make no difference between parts and layouts? >> Parts and boards only differ in in the fact that an board can may have >> more layers compared to a part (and no tracks in parts - why?). Layers >> are all the same - besides we can only use the outer copper layers... >> If we go a bit deeper, the microwave tool (create line of specific >> length) already puts an module into the boards layout - but it'll >> discard all information about the length of the track - which was the >> curial part about the created segment... >> Besides this, the statements inside the module it created, are quite >> close to the information about tracks, only missing the net and >> timestamp. Imho we've got some redundant elements here (fp_line vs. >> segment). >> But if we use normal tracks to make such modules, how do we keep the >> user from deforming those tracks? Add some special joints to mark some >> "super-segment", between those joints, it should be impossible to edit >> the single segments, only move them as whole (like the microwave part >> before). > > Is it called 'rooms' in the Altium's nomenclature? (For non-Altium > people: http://www.youtube.com/watch?v=dYgvRCrVeOI / > http://wiki.altium.com/pages/viewpage.action?pageId=22872356). Yes that's the feature I had in mind :) (Zones was wrong). >> Like said above, the difference between the parts and boards is not that >> big. If we would place the "add pad" button in pcbnew (and an field for >> partname), we could ditch the complete module editor (which you can only >> reach by starting pcbnew....). > > Ditching the module editor may be not such a good idea, you still need > an editor for preparing footprints. And still it does not solve the > problem of backannotation. Given it's possible to use boards as parts and add pads pcbnew, it should replace the module editor - or am I still missing some important parts? But yes, the backannotation is still a problem, but if one would give me a choice, I would choose the "boards as footprints" feature first. >> Stuff like "Zones" for multichannel layouts (terms from Altium) would be >> nearly implemented that way, you would only need the option to select a >> complete board as footprint for an entire subsheet (or create a symbol >> for the board and don't use the whole schematic as subsheet). >> Goind this way, one would not end with, say 16 times, the same layout >> which he has to edit if something was wrong - just re-import the >> "footprint" (aka layout) and you are done. >> >> Maybe I'm wrong with my view about the current situation in kicad, in >> this case I would like to know why :). >> Cya, >> imp > > The idea itself is great, but needs some more consideration regarding > the implementation. Indeed :). Bye, imp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
