On Mar 18, 2011, at 4:07 PM, DJ Delorie wrote:
> And your kind of bottom-up design never gets done at all, because of
> impossible-to-meet requirements for unlimited flexibility.
"My kind" of bottom-up design is precisely what Ritchie did when he invented C.
Contrast C with PL/I, the language i
DJ Delorie writes:
>> Still, I do not see a need for outline layers anywhere, except as an
>> attribute on a graphical layer that tells an exporter where to stop
>> drawing.
>
> Hmmm... so you think PCB should let the user place an element in a
> physically impossible location, because it doesn't
DJ Delorie writes:
>> > Except gerbers have special cases for thermals and pads, for example.
>>
>> So there need to be attributes on shapes.
>
> No, the exporters really need to have access to the whole collection
> of shapes that means "pin" so they can do pin-specific things. If the
> export
hi,
Is there any way in gschem (or gattrib) to refactor netnames in a given set of
schematics?
Thnaks,
Levente
--
Levente Kovacs
http://levente.logonex.eu
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/li
On Sat, 2011-03-19 at 00:41 +0100, Stefan Salewski wrote:
>
> LMBD + LMBU over hot pin end: start new net segment
>
I mean:
LMBD + LMBU over hot pin end or existing net end: start new net segment
For starting a new net segment from void area we will have to activate
net mode.
___
> Of course I will support selection with a rectangular bounding
> box. Does your "select-region" mean an arbitrary shaped area?
No, I mean select rectangle.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listi
On Fri, 2011-03-18 at 19:47 -0400, DJ Delorie wrote:
> > > Don't forget about select-region, select-touching,
> > > select-touching-line, etc.
> >
> > I guess that is not too common in schematics?
>
> select-region is *very* common.
>
Of course I will support selection with a rectangular boundi
> > Don't forget about select-region, select-touching,
> > select-touching-line, etc.
>
> I guess that is not too common in schematics?
select-region is *very* common.
select-touching-line would be really handy to select a group of angled
lines, without selecting the non-angled lines they're co
Hi all,
I appreciate the discussion.
There we nearly no objections to my layer concept, just to the
via/footprint/composite.
I have updated the page (http://geda.seul.org/wiki/geda:pcb_layers)
and I hope it not reflects the 'opinion of majority'.
So again. Coments are welcome, the discussion was
On Mar 18, 2011, at 5:39 PM, DJ Delorie wrote:
>
>> It is the exporter's job to understand drilling. For geometry
>> capture, all you need to know is the shape. Modules with no "need to
>> know" should not know.
>
> The autorouter needs to know not to run traces across unplated
> holes...
Whet
On Fri, 2011-03-18 at 19:17 -0400, DJ Delorie wrote:
> > shift-leftclick on object
>
> Don't forget about select-region, select-touching,
> select-touching-line, etc.
>
I guess that is not too common in schematics?
Here is my current draft for my gschem clone:
Peted intended user interface beh
> It is the exporter's job to understand drilling. For geometry
> capture, all you need to know is the shape. Modules with no "need to
> know" should not know.
The autorouter needs to know not to run traces across unplated
holes...
___
geda-user maili
On Mar 18, 2011, at 5:25 PM, DJ Delorie wrote:
> You don't drill through ink. You drill through what the ink is *on*.
> It's a semantic issue. If you want a spot where ink is missing, you
> add an anti-circle there. It's different than a physical hole. It's
> still a circle that removes thing
> Still, I do not see a need for outline layers anywhere, except as an
> attribute on a graphical layer that tells an exporter where to stop
> drawing.
Hmmm... so you think PCB should let the user place an element in a
physically impossible location, because it doesn't care about the
outlines?
DJ Delorie writes:
>> I do not like the concept of composit outlines. Does each layer
>> have its outline? How does it do partial vias?
>
> In the case of flex cables, each layer *does* have its own outline.
> The tool needs to know that vias go only across layers that actually
> exist at that
> Would and an 'outline' layer do for you? We can rename it so 'assembly'
> layer or so.
"assembly" has a specific meaning in CAM - it's a reference drawing,
either to help the CAM engineer understand how your board is
assembled, or to help with assembling the components to it.
On Sat, Mar 19, 2011 at 12:17:36AM +0100, Stephan Boettcher wrote:
> But that's why I argue for hole layers. A hole is a shape on a hole
> layer. The layers attributes define what needs to be drilled.
> Actually, they only define to which layers they electrically conduct.
> That is all the tools n
> > As general as neccessary, but not as general as *possible*.
>
> But we cannot know what is necessary.
Well, we start by asking people who do pcb layouts what they need :-)
"My point exactly. Do customers *want* portable fire?"
> >> On top of that is a memory representation, that introduce
On Mar 18, 2011, at 5:05 PM, DJ Delorie wrote:
>
>> Yes, sadly gEDA is a high productivity toolkit for spaceflight
>> hardware, ASIC design, merging tabular design data with graphical
>> design data, symbolic circuit analysis, and even hydraulics.
>
> No matter what I say, you'll find a way to
DJ Delorie writes:
>> > I expect the plugin mechanism to be the way to write *all* the core
>> > bits, though.
>>
>> The more important it is, that what is below the plugin mechanism is as
>> general as necessary, and since that is difficult to judge up front: as
>> general as possible, without
> shift-leftclick on object
Don't forget about select-region, select-touching,
select-touching-line, etc.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Stefan Salewski wrote:
> Is there a guide how multi-select should work for tools like PCB and
> gschem? I have done a short google search and some test with PCB and
> gschem, but I am not really sure that I fully grab it.
>
> I think we should have these actions:
> Select
leftclick on object or
> Except that we'll argue forever if we can't agree on the words.
I don't care about the words. I care about the ideas, the concepts,
the use-cases. You throw "factored design" around like it's the
solution to everything, but it's a meaningless term without a specific
solution behind it.
Unfor
On Mar 18, 2011, at 5:02 PM, DJ Delorie wrote:
> These are all examples of a need for both a semantic and data
> heirarchy, where parts of your design are grouped together and treated
> as a single object, sometimes replicated, sometimes customized.
Yes. Factored design.
> What
> we call them
> I do not like the concept of composit outlines. Does each layer
> have its outline? How does it do partial vias?
In the case of flex cables, each layer *does* have its own outline.
The tool needs to know that vias go only across layers that actually
exist at that spot.
_
> Yes, sadly gEDA is a high productivity toolkit for spaceflight
> hardware, ASIC design, merging tabular design data with graphical
> design data, symbolic circuit analysis, and even hydraulics.
No matter what I say, you'll find a way to disagree with me.
I *meant* sadly, the results are THE ON
> > Except gerbers have special cases for thermals and pads, for example.
>
> So there need to be attributes on shapes.
No, the exporters really need to have access to the whole collection
of shapes that means "pin" so they can do pin-specific things. If the
exporter doesn't need that high-leve
On Friday 18 March 2011, John Doty wrote:
> Yes, sadly gEDA is a high productivity toolkit for
> spaceflight hardware, ASIC design, merging tabular design
> data with graphical design data, symbolic circuit analysis,
> and even hydraulics.
ROFLMAO
___
John Doty writes:
> On Mar 18, 2011, at 3:31 PM, Stephan Boettcher wrote:
>
>> Except, I see no need to specify any insulating layers here.
>
> "I see no need" is exactly the kind of thinking that produces an
> inflexible, limited tool. I see *every* need to base the description
> on geometry, so
DJ Delorie writes:
>> As someone proposed, it is possible to have different hole size on
>> different layers. So I think the best would be to have special 'hole'
>> object on each layer. And that object will always be in composite
>> container, and all of them will be forcebly aligned to the same
On Mar 18, 2011, at 4:34 PM, DJ Delorie wrote:
>>
>> In your sense, you have no idea what the "space of the possible" is
>> for the integers.
>
> Of course I do. It's aleph null, the set of counting numbers.
That's not the space of the possible, that's only the range of the abstraction.
To k
On Fri, Mar 18, 2011 at 01:18:16PM -0700, Steven Michalske wrote:
> Embedded resistor and capacitors are in holes in the separating layers.
>
> Some separating layers are more like a solder mask and sprayed down
> rather than FR4 and prepreg.
>
> Just because standard FR4 Fabs don't usually use a
> > I expect the plugin mechanism to be the way to write *all* the core
> > bits, though.
>
> The more important it is, that what is below the plugin mechanism is as
> general as necessary, and since that is difficult to judge up front: as
> general as possible, without compromising the final go
On Mar 18, 2011, at 4:34 PM, DJ Delorie wrote:
> The problem with geda is that the lower leves are *so* flexible, that
> there was no semantic consistency, no intrinsic model for the upper
> levels to follow. The results were sadly predictable.
Yes, sadly gEDA is a high productivity toolkit for
DJ Delorie writes:
>> Hide all composites with attribute "type=via". The GUI probably
>> maintains an extra list of those, as well as a list of elements, for
>> performance.
>
> Why the GUI? Why can't the core maintain that list, since a lot of
> things will need it? I care a lot about perform
> The right kind of flexibility is even more important
> to the developers than to the users.
Since you're not a pcb developer, how can you know what the right kind
of flexibility is?
> In your sense, you have no idea what the "space of the possible" is
> for the integers.
Of course I do. It's
> If you mean 'physical layer' by 'composite', than yes. Each of those
> will have it's 'outline' layer.
I meant sub-assemblies.
This is hard to describe because of the near-impossible list of things
we want to support, but...
There are two types of sub-assemblies. First, composite objects whi
DJ Delorie writes:
>> ... I think the tool we have is pretty good already. Very good. Thanks!
>
> The tool we have already is nearly impossible to maintain, though.
>
>> Please do not expect that users write plugins. The tool is already too
>> good as it is to make is worth the effort to learn
On Mar 18, 2011, at 4:07 PM, DJ Delorie wrote:
>
>> That's the kind of "top down" design that produces a tool that meets
>> today's requirements in the minimum amount of time, but produces an
>> inflexible tool limited to those requirements.
>
> And your kind of bottom-up design never gets done
On Fri, Mar 18, 2011 at 05:58:29PM -0400, DJ Delorie wrote:
>
> > As someone proposed, it is possible to have different hole size on
> > different layers. So I think the best would be to have special 'hole'
> > object on each layer. And that object will always be in composite
> > container, and al
On Fri, Mar 18, 2011 at 10:40:02PM +0100, Stephan Boettcher wrote:
> Martin Kupec writes:
>
> > On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote:
> >>
> >> > But if I am doing that (just to extend this silly example too far), I
> >> > would want the DRC checker to ensure that it obeys
> That's the kind of "top down" design that produces a tool that meets
> today's requirements in the minimum amount of time, but produces an
> inflexible tool limited to those requirements.
And your kind of bottom-up design never gets done at all, because of
impossible-to-meet requirements for un
On Mar 18, 2011, at 3:11 PM, DJ Delorie wrote:
>
>> But if I am doing that (just to extend this silly example too far), I
>> would want the DRC checker to ensure that it obeys both the rules for
>> copper _and_ for silk.
>
> Hmmm... DRC is already fab-specific anyway. Maybe DRC should be on
>
On Mar 18, 2011, at 3:31 PM, Stephan Boettcher wrote:
> Except, I see no need to specify any insulating layers here.
"I see no need" is exactly the kind of thinking that produces an inflexible,
limited tool. I see *every* need to base the description on geometry, so that
the tool's limits ar
On Mar 18, 2011, at 3:09 PM, DJ Delorie wrote:
> I feel that the data layer is easiest to implement, but it seems to be
> what we're arguing about the most. I say we should ignore that
> problem for now, until we have a better understanding of what we want
> at the other two layers.
That's the
> As someone proposed, it is possible to have different hole size on
> different layers. So I think the best would be to have special 'hole'
> object on each layer. And that object will always be in composite
> container, and all of them will be forcebly aligned to the same center.
What I suggest
> I do not agree with the term high level here. I agree that there
> may be layers of different types, that require special treatment.
> These are low-level types, like "conductive" for layers that
> electrically connect things, or "holes" for connections between
> layers, and "other" for anythin
On Fri, Mar 18, 2011 at 09:23:20PM +0100, Stephan Boettcher wrote:
> Martin Kupec writes:
> > Actually what I am trying to do, is to have concept so layers don't
> > interract with layers of different type. The composits are a bit
> > problem, because I would need to consider more layers when perf
DJ Delorie writes:
>> I don't want to end up with the current state that some 'specialy
>> named' layers receive special treatment.
>
>>From a practical standpoint, I think it makes sense to have a fast way
> to scan for layers of some high-level type, as well as further typing
> them by name.
Martin Kupec writes:
> On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote:
>>
>> > But if I am doing that (just to extend this silly example too far), I
>> > would want the DRC checker to ensure that it obeys both the rules for
>> > copper _and_ for silk.
>>
>> Hmmm... DRC is already fa
> ... I think the tool we have is pretty good already. Very good. Thanks!
The tool we have already is nearly impossible to maintain, though.
> Please do not expect that users write plugins. The tool is already too
> good as it is to make is worth the effort to learn how to do that.
I expect t
DJ Delorie writes:
>> We are talking about different thinks, I guess.
>
> Probably.
>
>> The tool shall be very focussed on traces, elements, vias.
>
> To be this kind of focused, it needs to have some understanding of
> what a via is. You wouldn't want to invoke the via editor on a trace,
> but
> Hide all composites with attribute "type=via". The GUI probably
> maintains an extra list of those, as well as a list of elements, for
> performance.
Why the GUI? Why can't the core maintain that list, since a lot of
things will need it? I care a lot about performance.
> Exporters can only
On Fri, Mar 18, 2011 at 05:09:09PM -0400, DJ Delorie wrote:
> User level - a via is a connection between layers that I can add,
> remove, edit, and move around.
>
> Tool level - a via is an anonymous (i.e. not part of an element) hole
> between layers electrically connecting copper pads on each la
On Fri, Mar 18, 2011 at 05:19:10PM -0400, DJ Delorie wrote:
>
> > I don't want to end up with the current state that some 'specialy
> > named' layers receive special treatment.
>
> From a practical standpoint, I think it makes sense to have a fast way
> to scan for layers of some high-level type,
On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote:
>
> > But if I am doing that (just to extend this silly example too far), I
> > would want the DRC checker to ensure that it obeys both the rules for
> > copper _and_ for silk.
>
> Hmmm... DRC is already fab-specific anyway. Maybe DRC s
> I don't want to end up with the current state that some 'specialy
> named' layers receive special treatment.
>From a practical standpoint, I think it makes sense to have a fast way
to scan for layers of some high-level type, as well as further typing
them by name.
My original design had an enu
DJ Delorie writes:
>> That is up to the HID to find the composits with attribute
>> "type=via", and present them in a via toll selector.
>
> I disagree with this.
>
> The HID is the Human Interaction Device - how the information is
> presented to the user. GUI, printer, etc.
>
> The HID is the w
On Fri, Mar 18, 2011 at 01:52:38PM -0700, Jared Casper wrote:
> On Fri, Mar 18, 2011 at 1:44 PM, DJ Delorie wrote:
> > At the design/edit level, that layer is a copper layer. Note to John:
>
> > And DRC freaks out because it has two separate incompatible sets of
> > rules to apply to it.
Tha
> But if I am doing that (just to extend this silly example too far), I
> would want the DRC checker to ensure that it obeys both the rules for
> copper _and_ for silk.
Hmmm... DRC is already fab-specific anyway. Maybe DRC should be on
the other side of the CAM job? I.e. make DRC an exporter, s
DJ Delorie writes:
>> But at the core, they work all just the same.
>
> The "core" includes the autorouters, optimizers, DRC, exporters,
> reports, and even simple editing - we have a "hide vias" button. How
> does that work if you no longer have "vias" as an inherent type?
Hide all composites
On Mar 18, 2011, at 1:32 PM, DJ Delorie wrote:
>
>> But at the core, they work all just the same.
>
> The "core" includes the autorouters, optimizers, DRC, exporters,
> reports, and even simple editing - we have a "hide vias" button. How
> does that work if you no longer have "vias" as an
> We are talking about different thinks, I guess.
Probably.
> The tool shall be very focussed on traces, elements, vias.
To be this kind of focused, it needs to have some understanding of
what a via is. You wouldn't want to invoke the via editor on a trace,
but you wouldn't want the "move" opt
On Mar 18, 2011, at 2:55 PM, Stephan Boettcher wrote:
> DJ Delorie writes:
>
>>> Inflexible wired-in behavior
>>
>> ... is MANDATORY if you're going to produce a tool that's usable.
>>
>> That's the difference between a pcb editor and, say, inkscape.
>>
>> Inkscape gives you complete flexibi
On Fri, Mar 18, 2011 at 09:49:08PM +0100, Stephan Boettcher wrote:
> Martin Kupec writes:
> > Ok. We probably don't understand each other, so I will just state my fears.
> >
> > I would like to know about each drawing layer where it belongs to.
> >
> > So when I am performing DRC check, I will kno
DJ Delorie writes:
>> Inflexible wired-in behavior
>
> ... is MANDATORY if you're going to produce a tool that's usable.
>
> That's the difference between a pcb editor and, say, inkscape.
>
> Inkscape gives you complete flexibility, and it's absolutely useless
> as a pcb layout tool.
>
> You seem
On Fri, Mar 18, 2011 at 1:44 PM, DJ Delorie wrote:
>
>> But what if I want a silk layer to just be a copy of a copper layer?
>
> This is a different category of problem - the CAM job. Typically,
> you'd have a file that describes how to map design layers to output
> layers. In that file, you'd s
> You can always tell the board house to use copper minus soldermask as
> silk.
That sounds like fun...
Now I want to make a pcb plugin that copies all copper to the silk
layer, but only where there's soldermask. You get a picture of your
circuit in white-on-green, that actually works :-)
___
Jared Casper writes:
> On Fri, Mar 18, 2011 at 1:23 PM, Martin Kupec wrote:
>> If layers types would be defined by attributes, someone would be able to
>> declare one layer both as conductive and as silk for example. That could
>> cause me a nighmares. That is why I insist on 'typed' layers, not
Martin Kupec writes:
> On Fri, Mar 18, 2011 at 09:00:04PM +0100, Stephan Boettcher wrote:
>> Martin Kupec writes:
>>
>> > On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote:
>> >> The file format need not know about these distictions. Both are
>> >> graphical layers, with differ
> But what if I want a silk layer to just be a copy of a copper layer?
This is a different category of problem - the CAM job. Typically,
you'd have a file that describes how to map design layers to output
layers. In that file, you'd say "this copper layer should be output
as a silk layer also".
On Fri, Mar 18, 2011 at 09:29:04PM +0100, Stephan Boettcher wrote:
> Martin Kupec writes:
>
> > On Fri, Mar 18, 2011 at 01:52:24PM -0600, John Doty wrote:
> >>
> >> On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote:
> >>
> >> > Generaly you are proposing that there should be a special type of
> >
On Fri, Mar 18, 2011 at 1:32 PM, DJ Delorie wrote:
> The "core" includes the autorouters, optimizers, DRC, exporters,
> reports, and even simple editing - we have a "hide vias" button. How
> does that work if you no longer have "vias" as an inherent type?
>
You go through and hide all the compos
Steven Michalske writes:
> On Fri, Mar 18, 2011 at 12:40 PM, Martin Kupec wrote:
>> On Wed, Mar 16, 2011 at 10:36:24AM -0600, John Doty wrote:
>>>
>>> On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote:
>>>
>>> >> Ok. So "via" should be a circle element on "hole" typed layer.
>>> >
>>> > No.
On Fri, Mar 18, 2011 at 01:20:43PM -0700, Steven Michalske wrote:
> On Fri, Mar 18, 2011 at 1:11 PM, Stephan Boettcher
> > The GUI must present footprints, vias, and hierachical sublayouts, both
> > in copy on write and in truly hierachical fashion. But at the core,
> > they work all just the same
> That is up to the HID to find the composits with attribute
> "type=via", and present them in a via toll selector.
I disagree with this.
The HID is the Human Interaction Device - how the information is
presented to the user. GUI, printer, etc.
The HID is the wrong place to be assigning *meani
On Fri, Mar 18, 2011 at 1:23 PM, Martin Kupec wrote:
> If layers types would be defined by attributes, someone would be able to
> declare one layer both as conductive and as silk for example. That could
> cause me a nighmares. That is why I insist on 'typed' layers, not
> 'tagged' layer.
>
> That
> But at the core, they work all just the same.
The "core" includes the autorouters, optimizers, DRC, exporters,
reports, and even simple editing - we have a "hide vias" button. How
does that work if you no longer have "vias" as an inherent type?
PCB has a lot of tools that know a lot about how
Martin Kupec writes:
> On Fri, Mar 18, 2011 at 01:52:24PM -0600, John Doty wrote:
>>
>> On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote:
>>
>> > Generaly you are proposing that there should be a special type of
>> > footpring called 'via' and it should receive extra care.
>>
>> Why single out
On Fri, Mar 18, 2011 at 09:00:04PM +0100, Stephan Boettcher wrote:
> Martin Kupec writes:
>
> > On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote:
> >> The file format need not know about these distictions. Both are
> >> graphical layers, with different attributes. The one has a
> Inflexible wired-in behavior
... is MANDATORY if you're going to produce a tool that's usable.
That's the difference between a pcb editor and, say, inkscape.
Inkscape gives you complete flexibility, and it's absolutely useless
as a pcb layout tool.
You seem to be totally blind to the theory
Martin Kupec writes:
> On Fri, Mar 18, 2011 at 01:44:35PM -0600, John Doty wrote:
>> >> Trying to model things that aren't layers as if they were layers is
>> >> one common mistake in this kind of tool. Equally common is leaving out
>> >> layers: the insulating layers in a PCB are just as importa
On Fri, Mar 18, 2011 at 1:11 PM, Stephan Boettcher
wrote:
> DJ Delorie writes:
>
>>> Why single out "via" and "footprint" when they are merely members of
>>> an open-ended list of possible composite objects?
>>
>> Because a tool that doesn't deal with real-world concepts in a
>> user-friendly way
On Fri, Mar 18, 2011 at 12:40 PM, Martin Kupec wrote:
> On Wed, Mar 16, 2011 at 10:36:24AM -0600, John Doty wrote:
>>
>> On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote:
>>
>> >> Ok. So "via" should be a circle element on "hole" typed layer.
>> >
>> > No. A Via is a composit, consisting of a
On Fri, Mar 18, 2011 at 1:08 PM, DJ Delorie wrote:
>
>> I agree here, that a via and a footprint are essentially the same
>> thing.
>
> Except the user doesn't interact with them the same way.
>
This is a UI representation, not a layer geometry issue.
A via tool that makes the proper composite ob
DJ Delorie writes:
>> Why single out "via" and "footprint" when they are merely members of
>> an open-ended list of possible composite objects?
>
> Because a tool that doesn't deal with real-world concepts in a
> user-friendly way is unusable.
Yes. The real world concepts must exist, in a highe
> I agree here, that a via and a footprint are essentially the same
> thing.
Except the user doesn't interact with them the same way.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
On Fri, Mar 18, 2011 at 12:53 PM, DJ Delorie wrote:
>
>> Why single out "via" and "footprint" when they are merely members of
>> an open-ended list of possible composite objects?
>
> Because a tool that doesn't deal with real-world concepts in a
> user-friendly way is unusable.
>
User friendly is
On Mar 18, 2011, at 1:53 PM, DJ Delorie wrote:
>
>> Why single out "via" and "footprint" when they are merely members of
>> an open-ended list of possible composite objects?
>
> Because a tool that doesn't deal with real-world concepts in a
> user-friendly way is unusable.
>
I completely agre
On Fri, Mar 18, 2011 at 12:52 PM, John Doty wrote:
>
> On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote:
>
>> Generaly you are proposing that there should be a special type of
>> footpring called 'via' and it should receive extra care.
>
> Why single out "via" and "footprint" when they are merely m
On Fri, Mar 18, 2011 at 01:52:24PM -0600, John Doty wrote:
>
> On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote:
>
> > Generaly you are proposing that there should be a special type of
> > footpring called 'via' and it should receive extra care.
>
> Why single out "via" and "footprint" when they
Martin Kupec writes:
> On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote:
>> The file format need not know about these distictions. Both are
>> graphical layers, with different attributes. The one has attributes to
>> tell DRC to flag overlapping components, the other has attrib
On Fri, Mar 18, 2011 at 01:44:35PM -0600, John Doty wrote:
> >> Trying to model things that aren't layers as if they were layers is
> >> one common mistake in this kind of tool. Equally common is leaving out
> >> layers: the insulating layers in a PCB are just as important as the
> >> copper, and h
> Why single out "via" and "footprint" when they are merely members of
> an open-ended list of possible composite objects?
Because a tool that doesn't deal with real-world concepts in a
user-friendly way is unusable.
___
geda-user mailing list
geda-us
On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote:
> Generaly you are proposing that there should be a special type of
> footpring called 'via' and it should receive extra care.
Why single out "via" and "footprint" when they are merely members of an
open-ended list of possible composite objects?
Generaly you are proposing that there should be a special type of
footpring called 'via' and it should receive extra care.
I am ok with that, I just need to figure out how to handle mapping from
footprint layers to layout layers. I don't want concept of 'top',
'inner', 'bottom' layer at all...that
On Mar 16, 2011, at 11:09 AM, Stephan Boettcher wrote:
> John Doty writes:
>>
>> The "layer" concept should be physical, not a metaphysical
>> abstraction. Objects in a layer may contain holes, but a "hole layer"
>> is nonsensical, a toxic conceptual shortcut. An "outline" layer is
>> similarly
On Wed, Mar 16, 2011 at 06:09:25PM +0100, Stephan Boettcher wrote:
> For me, a layer is something that the designer puts shapes on. Shapes
> with atributes, if required. The semantics of these shapes on a given
> layer shall all be the same. Some of these are required for netlisting,
> some are
On Wed, Mar 16, 2011 at 10:36:24AM -0600, John Doty wrote:
>
> On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote:
>
> >> Ok. So "via" should be a circle element on "hole" typed layer.
> >
> > No. A Via is a composit, consisting of a circle on the hole layer, and
> > various circles on copper
On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote:
> The file format need not know about these distictions. Both are
> graphical layers, with different attributes. The one has attributes to
> tell DRC to flag overlapping components, the other has attributes to
> tell some autorout
1 - 100 of 109 matches
Mail list logo
