Re: gEDA-user: Color silk layers in pcb

2010-09-07 Thread Ineiev
On 9/6/10, Peter Clifton pc...@cam.ac.uk wrote:
...
 confusing non-copper with skip-drc is
 probably a bad idea.
...

Thank you, your suggestion is really reasonable.

I renamed the attribute to PCB::non-copper
and corrected the variable name and comments accordingly;
probably it does not make the patch perfect,
but I have no better idea at the moment.

Regards,
Ineiev
From 5ec7e281f01fa09b041537e4f4eb8237cda1cc9c Mon Sep 17 00:00:00 2001
From: Ineiev ine...@users.berlios.de
Date: Tue, 7 Sep 2010 10:30:44 +0400
Subject: [PATCH] recognize PCB::non-copper layer attribute

layers with `PCB::non-copper' attribute are excluded
from DRC (both copper- and silkscreen-specific) and connection lookup
---
 src/action.c |2 +-
 src/action.h |2 ++
 src/find.c   |   23 +--
 src/global.h |2 ++
 4 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/src/action.c b/src/action.c
index 32e294c..2936080 100644
--- a/src/action.c
+++ b/src/action.c
@@ -6957,7 +6957,7 @@ find_element_by_refdes (char *refdes)
   return NULL;
 }
 
-static AttributeType *
+AttributeType *
 lookup_attr (AttributeListTypePtr list, const char *name)
 {
   int i;
diff --git a/src/action.h b/src/action.h
index ee116e8..7b64e05 100644
--- a/src/action.h
+++ b/src/action.h
@@ -46,4 +46,6 @@ void warpNoWhere (void);
 /* In gui-misc.c */
 bool ActionGetLocation (char *);
 void ActionGetXY (char *);
+AttributeType * lookup_attr (AttributeListTypePtr list, const char *name);
+
 #endif
diff --git a/src/find.c b/src/find.c
index 593be70..17f042f 100644
--- a/src/find.c
+++ b/src/find.c
@@ -81,6 +81,7 @@
 
 #include global.h
 
+#include action.h
 #include crosshair.h
 #include data.h
 #include draw.h
@@ -826,6 +827,8 @@ LookupLOConnectionsToPVList (bool AndRats)
   /* now all lines, arcs and polygons of the several layers */
   for (layer = 0; layer  max_layer; layer++)
 {
+	  if (LAYER_PTR (layer)-non_copper)
+	continue;
   info.layer = layer;
   /* add touching lines */
   if (setjmp (info.env) == 0)
@@ -1173,6 +1176,8 @@ LookupPVConnectionsToLOList (bool AndRats)
   /* loop over all layers */
   for (layer = 0; layer  max_layer; layer++)
 {
+  if (LAYER_PTR (layer)-non_copper)
+	continue;
   /* do nothing if there are no PV's */
   if (TotalP + TotalV == 0)
 {
@@ -2900,6 +2905,18 @@ ListsEmpty (bool AndRats)
   return (empty);
 }
 
+static void
+reassign_non_copper_flags (void)
+{
+  int layer;
+
+  for (layer = 0; layer  max_layer; layer++)
+{
+  LayerTypePtr l = LAYER_PTR (layer);
+  l-non_copper = lookup_attr ((l-Attributes), PCB::non-copper) != NULL;
+}
+}
+
 /* ---
  * loops till no more connections are found 
  */
@@ -2907,6 +2924,7 @@ static bool
 DoIt (bool AndRats, bool AndDraw)
 {
   bool new = false;
+  reassign_non_copper_flags ();
   do
 {
   /* lookup connections; these are the steps (2) to (4)
@@ -3349,6 +3367,7 @@ LookupConnection (LocationType X, LocationType Y, bool AndDraw,
 
   /* check if there are any pins or pads at that position */
 
+  reassign_non_copper_flags ();
 
   type
 = SearchObjectByLocation (LOOKUP_FIRST, ptr1, ptr2, ptr3, X, Y, Range);
@@ -3365,8 +3384,8 @@ LookupConnection (LocationType X, LocationType Y, bool AndDraw,
   int laynum = GetLayerNumber (PCB-Data,
(LayerTypePtr) ptr1);
 
-  /* don't mess with silk objects! */
-  if (laynum = max_layer)
+  /* don't mess with silk and other non-conducting objects! */
+  if (laynum = max_layer || ((LayerTypePtr)ptr1)-non_copper)
 return;
 }
 }
diff --git a/src/global.h b/src/global.h
index bb78abc..bb82b79 100644
--- a/src/global.h
+++ b/src/global.h
@@ -301,6 +301,8 @@ typedef struct			/* holds information about one layer */
   char *Color,			/* color */
*SelectedColor;
   AttributeListType Attributes;
+  int non_copper; /* whether to ignore the layer when looking up connections
+		 and checking against copper-specific design rules */
 }
 LayerType, *LayerTypePtr;
 
-- 
1.6.0.4



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Photo mode to the rescue...

2010-09-07 Thread Vanessa Ezekowitz
On Mon, 6 Sep 2010 22:18:18 -0400
DJ Delorie d...@delorie.com wrote:

  How about this: Let footprints contain a file name of an macro image
  from the top. Then, the photo mode could use the image to render a 
  populated board. ;-)
 
 I thought of that, but you need to be able to correctly align the
 photo with the rotated/positioned element footprint.

I like this idea actually.  One way it might work is to take a page from photo 
panorama software - use the idea of control points [1].  If I could code, I'd 
implement it as a separate utility, if not as part of of PCB.  Here is how I 
would do it (lots of rambling from a dreamer follows :-) )...

Step 1:  Create the footprint and save it in the usual way - either with a text 
editor, some kind of script or tool, or using PCB.

Step 2: Launch the control point editor.  The first thing it would do before 
spawning the actual editor window is to pop up a dialog to let you choose the 
footprint file and image file to be loaded, with Forward and Cancel 
buttons.  Next to the image selector should be an option to rotate the image 
90/180/270 degrees before loading.  Once those are set, Forward should bring 
the user to the editor window, which I could see being divided into four parts:

* Upper left:  the footprint as it would be rendered with PCB's photo 
exporter, with the image overlaid on top of it and slightly translucent.  A 
slider bar to the left of this part of the window would control the opacity of 
the overlaid image.

* Upper Right:  the footprint as seen in the user's normal PCB environment.  If 
any control points have been set, their marks would be displayed as + symbols 
or something similar.

* Lower Right:  the original image, with corresponding control point marks 
displayed, if any.

Footprints and images should default to centered and scaled-to-fit each of 
their respective sections (unless the footprint already has control points, in 
which case the image in the upper left should be scaled and positioned 
accordingly).  All three sections should respond to the user's normal mouse and 
keyboard settings for pan and zoom thereafter.  I'm not sure how this will mesh 
with the processing that is to be done on the overlay image in the upper left - 
maybe pre-render the image according to the control points, and display that.

* Lower left:  The current list of control points followed by buttons marked 
something like Show/Hide #, Delete, Accept, Preview,  and Save.

Step 3:  Add and edit new control points.  The user should be able to click in 
either of the two right hand sections to set a mark in each.  Any click in 
either section should move the mark in that section to the new spot.  A 
click-and-drag should also be possible.  Click back and forth between the two 
sections as needed, until both marks are just right.  Click Accept to add 
these two marks to the list of control points at the lower left.

If at any point the user sets a new mark in only one of the two right-hand 
sections, and then tries to click and drag on an older mark in either section, 
the new mark should be discarded, and the older mark should be moved per the 
user's request.

If the user has set new marks in *both* sections, the new marks should both be 
automatically added to the control point list, and the older mark should be 
moved per the user's request.

The user should be able to click and drag to move either of the two 
corresponding older marks back and forth as needed, and should click Accept 
to commit the changes.  If they don't, their next click other than a 
click-and-drag of these two older marks should cause the changes to be thrown 
out, and a new mark to be set .

When the user is editing an older mark, the corresponding control point should 
be highlighted in the list (and brought into view if it is scrolled off).  When 
the user clicks on a control point in the list, the corresponding marks on the 
right should be highlighted (but without discarding any new marks that may be 
in progress).  If the user was editing an older mark and they click a different 
control point in the list, the change they were making should be discarded.

Depending on the amount of distortion in the image, create maybe 8 to 12 
control points around the periphery of the component.  More is better, to a 
point, but at any rate one needs to account for (ideally small variations in) 
scale, position, rotation, perspective, and lens distortion (e.g. fisheye).

Step 4:  Click the Preview button to refresh the footprint/image overlay 
using the current list of control points.  If it needs to be tweaked, to back 
to Step 3.  The Delete button would remove whatever control point is 
highlighted in the list.  If the image overlay looks good, click Save to 
overwrite the footprint that was loaded, with the new control points (and the 
rotation flag set in the load files dialog).  At this point, I guess just 
exit the program.


[1] For those here who don't work with photo 

Re: gEDA-user: PCB format wishlist

2010-09-07 Thread Kovacs Levente
On Mon, 6 Sep 2010 16:32:10 -0400
DJ Delorie d...@delorie.com wrote:

 Arcs can be simulated with many short lines, so the only primitive we
 need are lines.  Of course, if line is a two-point polygon, then the
 only primitive we need is polygons.

So, your pcb file would contain nothing but polygons. This would make it
unparsable with external scripts and humans.
 
 A point is just a line that starts and ends at the same coordinates.

I don't like this.

-- 
Kovacs Levente leventel...@gmail.com
Voice: +36705071002




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Photo mode to the rescue...

2010-09-07 Thread John Luciani
On Mon, Sep 6, 2010 at 10:09 PM, Eric Brombaugh ebrombau...@cox.net wrote:

 Whenever I post pix from photo mode I always get questions about what tool I
 used to do them. Surprising that none of the big pro tools out there provide
 that.  Who says OSS apps always follow the lead of the proprietary SW world?

I have heard the same positive comments from a number of people too.

Being able to get a quality rendering of the PCB from the command line
is extremely convenient.

(* jcl *)


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: PCB format wishlist

2010-09-07 Thread John Doty

On Sep 6, 2010, at 8:31 PM, Rick Collins wrote:

 I have often thought that I would prefer to write an HDL that works like 
 Forth.

I believe Chuck Moore (the inventor of Forth) beat you to it.

http://www.colorforth.com/vlsi.html

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



Re: gEDA-user: Color silk layers in pcb

2010-09-07 Thread Peter Clifton
On Tue, 2010-09-07 at 06:56 +, Ineiev wrote:
 On 9/6/10, Peter Clifton pc...@cam.ac.uk wrote:
 ...
  confusing non-copper with skip-drc is
  probably a bad idea.
 ...
 
 Thank you, your suggestion is really reasonable.
 
 I renamed the attribute to PCB::non-copper
 and corrected the variable name and comments accordingly;
 probably it does not make the patch perfect,
 but I have no better idea at the moment.

DJ, Dan, ...

Shall we / I push this? I think it looks good overall.

I might have put the attribute string PCB::non-copper in a #define
somewhere, but if the string is canonical, I guess it doesn't hurt to
place it explicitly in the code.

I'm slightly weary of the lack of immediate synchronisation between the
attribute being present and the (LayerType*)-non_copper flag, but I can
live with it ;) This means that the -non_copper flag is only known to
be valid after a call to 
reassign_non_copper_flags(), which is a static function only available
inside find.c. This effectively means the flag is ONLY useful inside
find.c at the moment.


I've was (a while back) working on a hook based attribute change
notification system for gschem, and perhaps in future, similar might be
applied to map attribute changes to other data-structure flags
immediately.

OR.. we could eventually optimise the attribute lookup code to be
really fast, so as to avoid the need to keep a separate flag in the
layer data-structure. (Assuming lookup_attrib is too slow to use at
the moment??)


For a future patch:

It would be nice to move some the attribute lookup helper function out
of action.c, if attributes are to form a bigger role in PCB's future,
perhaps more functions will be created, and can live away from the
already bloated (and seemingly unrelated) action.c

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: PCB format wishlist

2010-09-07 Thread DJ Delorie

 I think (hope) DJ was being sarcastic

I was.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Color silk layers in pcb

2010-09-07 Thread DJ Delorie

 I might have put the attribute string PCB::non-copper in a #define
 somewhere, but if the string is canonical, I guess it doesn't hurt to
 place it explicitly in the code.

Perhaps we should tell DRC about all sorts of attributes?  Then we can
do layer-specific ones.  I'd want to use DRC::* at that point though.
And we'd need a GUI to edit them nicely.  Migration to/from the old
DRC() format needs to be considered.

Maybe it's time for me to find time to put in the layer types change,
which would cover this need anyway (copper vs non-copper at least).
After Oct 16th though, no sooner.

 OR.. we could eventually optimise the attribute lookup code to be
 really fast, so as to avoid the need to keep a separate flag in the
 layer data-structure. (Assuming lookup_attrib is too slow to use at
 the moment??)

Lookups are slow but we can cache both the lookup and the conversion
if we need to.  A hash of structs with multiple types (string, int,
float) for each attribute would do.

 It would be nice to move some the attribute lookup helper function out
 of action.c, if attributes are to form a bigger role in PCB's future,
 perhaps more functions will be created, and can live away from the
 already bloated (and seemingly unrelated) action.c

Core attribute lookups are in misc.c

But yeah, the code's getting messy.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread DJ Delorie

 Shall we / I push this? I think it looks good overall.

I desparately need to push out a release to get the LF work
published in order to close it out.  Maybe I'll do a 1.99za release
just to accomplish those goals, then we can cram in all the new
functionality we can for the 4.0 release.  Let's focus on critical bug
fixes for a few days and get that out, then talk about what 4.0
means.


My 4.0 short list is:

* More route styles.  Four is *way* too few for me.

* Real layer types.  Silks, keepouts, docs at least.  Maybe anti-draw
  or paste.

* Some GUI cleanups.  Lesstif could use an optional sidebar, for example.

My longer list includes:

* Other GUI cleanups.  Gtk upgraded to best practices.  Importer config.

* New layout templates and wizards. (instead of defaulting to 4x4 8-layer)

* import/wizard plugins (as well as exports)

* DRC cleanups/rewrite

* CAM engine?  (i.e. ability to say draw outline on top soldermask via 
script/config)

* Ability to layer exporters (i.e. thindraw as a HID)

* New file format we've been discussing.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Photo mode to the rescue...

2010-09-07 Thread Kai-Martin Knaak
DJ Delorie wrote:

 
 How about this: Let footprints contain a file name of an macro image
 from the top. Then, the photo mode could use the image to render a 
 populated board. ;-)
 
 I thought of that, but you need to be able to correctly align the
 photo with the rotated/positioned element footprint.

PCB knows about the rotation of a footprint and the position of its 
origin/handle. So it needs the coordinates of point in the photo that 
corresponds to the origin. In addition, a scaling information may be 
required. All of this additional information would fit nicely in the 
package concept I am about to propose...


 BTW, shadows can be rendered with a little image-magick: 
 
 That kind of logic should be in the PNG exporter...

True. 
But it was way easier for me to search the web for convert utility options.

---)kaimartin(---
-- 
Kai-Martin Knaak  tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik  fax: +49-511-762-2211 
Welfengarten 1, 30167 Hannover   http://www.iqo.uni-hannover.de
GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: PCB format wishlist

2010-09-07 Thread John Griessen

On 09/05/2010 10:21 AM, Bert Timmerman wrote:

On 09/04/2010 10:19 PM, Andrew Poelstra wrote:

I have one more suggestion: the facility to create recursive PCBs.



Recursive PCBs could work the same way as the footprint
re-use: a node could contain a reference to a parent node;
the parent node could be a single element or itself a
reference to a collection of elements.


+1

I can  think of a group of {traces, vias, elements, silk text or lines} to
be linked in from an external file or to be embedded.

The analogy of embedded/unembedded symbols in gschem comes to mind.


Me too.

And what if the gschem, pcb file formats were somehow unified.  Might allow
easier searching through project data.  Might enable cell-based design like
larger circuits, (chips), are done...

John G


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread Windell H. Oskay

On Sep 7, 2010, at 9:01 AM, DJ Delorie wrote:
 
 * Real layer types.  Silks, keepouts, docs at least.  Maybe anti-draw
  or paste.

How about mask keepout layers?  I have to manually merge gerbers to get my 
negative-tone unmasked regions now.  This would be *huge*.



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread DJ Delorie

Noted.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread John Griessen

On 09/07/2010 11:01 AM, DJ Delorie wrote:


My 4.0 short list is:

* More route styles.  Four is *way* too few for me.

Yep.


* Real layer types.  Silks, keepouts, docs at least.  Maybe anti-draw
   or paste.


A layer that is insulator would be good for printed conductive traces,
printed resistors that use insulator printed between.

So you can specify with more than just a note to the fabber, define them
as a layer with DRC's and tell them to fab additively like silk screen.
It could be done with the simple addition of silkscreen2 layer
with same properties as silk.  Insulator might need some minor  DRC
differences from silk, but allowing a little overlap of
pads is all I can think of so far.


John


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread Link

On 07/09/10 18:01, DJ Delorie wrote:



Shall we / I push this? I think it looks good overall.


I desparately need to push out a release to get the LF work
published in order to close it out.  Maybe I'll do a 1.99za release
just to accomplish those goals, then we can cram in all the new
functionality we can for the 4.0 release.  Let's focus on critical bug
fixes for a few days and get that out, then talk about what 4.0
means.


My 4.0 short list is:

* More route styles.  Four is *way* too few for me.

* Real layer types.  Silks, keepouts, docs at least.  Maybe anti-draw
   or paste.

* Some GUI cleanups.  Lesstif could use an optional sidebar, for example.

My longer list includes:

* Other GUI cleanups.  Gtk upgraded to best practices.  Importer config.

* New layout templates and wizards. (instead of defaulting to 4x4 8-layer)

* import/wizard plugins (as well as exports)

* DRC cleanups/rewrite

* CAM engine?  (i.e. ability to say draw outline on top soldermask via 
script/config)

* Ability to layer exporters (i.e. thindraw as a HID)

* New file format we've been discussing.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Some things I regard as quite important:

* Variable-angle arcs. 90 degrees is extremely limiting. gschem does 
this right.


* Filled circles, sans kludge. :)

* Having all shapes that are supported for traces supported for 
footprint copper (arcs, polygons, circles, etcetera).


* Unification of shortcuts in gschem and PCB, or at least an easy option 
for PCB to mimic gschem's shortcuts.


* Better support for free-rotated components: assert that pads at funky 
angles are rendered correctly, fix autorouter for components at weird 
angles (the latest git version has a tendency to either ignore the route 
command or to segfault, depending on the specifics), add rotation to the 
ctrl-R report, etcetera.


* Ability to copy a footprint's name from the library dialogue (so it 
can be pasted into gschem's attribute list).


* Ability to edit netlist in-situ (possibly by drawing on the rat lines 
layer) - e.g, when you want to add a heatsink soldered to ground, it 
will always show up as shorted until the netlist is edited to 
incorporate it.


* Last but not least, blind and buried vias. It's big, reasonably 
important, and has been on people's wish lists for years.



And the category nice to have but mostly unnecessary:

* Trace impedance calculator, with automatic adjustment capability (fill 
in thickness, stray capacitance and desired impedance, and the width is 
adjusted to satisfy the conditions).


* Integrated footprint lookup and fetch from gedasymbols.org.


Might be a bit much and a bit difficult, but at least for me, it would 
promote PCB from very good to absolutely awesome. ;)



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread John Griessen

On 09/07/2010 04:49 PM, Link wrote:


Some things I regard as quite important:

* Variable-angle arcs. 90 degrees is extremely limiting. gschem does
this right.

* Filled circles, sans kludge. :)

If you think in terms of gerber output history, everything's a kludge, so I'd 
lower this priority...


* Having all shapes that are supported for traces supported for
footprint copper (arcs, polygons, circles, etcetera).

This can be filed under subcells.   People are thinking about it, but it's not 
easily done right.



* Unification of shortcuts in gschem and PCB, or at least an easy option
for PCB to mimic gschem's shortcuts.


There is an easy way to mimic gschem's shortcuts.  Send me some tip money and 
I'll write it sooner.
And since I know how to do it and can write, maybe the result will be that pcb 
ships with it default.



* Better support for free-rotated components: assert that pads at funky
angles are rendered correctly, fix autorouter for components at weird
angles (the latest git version has a tendency to either ignore the route
command or to segfault, depending on the specifics), add rotation to the
ctrl-R report, etcetera.


Hey! sounds like you're getting more mileage than me with autorouting.
I'll swap you write ups instead of begging for tip money...but page for page,
paragraph for paragraph, published for all the world to see.



* Ability to copy a footprint's name from the library dialogue (so it
can be pasted into gschem's attribute list).


Sounds nice -- could come from DJ upgrading GTK functionality.



* Ability to edit netlist in-situ (possibly by drawing on the rat lines
layer) - e.g, when you want to add a heatsink soldered to ground, it
will always show up as shorted until the netlist is edited to
incorporate it.


Umm... that sounds so easy to work around you'll have to code it yourself...



* Last but not least, blind and buried vias. It's big, reasonably
important, and has been on people's wish lists for years.


Sure.


And the category nice to have but mostly unnecessary:


More code-it-yourself...


John


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread DJ Delorie

 Sounds nice -- could come from DJ upgrading GTK functionality.

I was hoping someone else would do the GTK stuff :-)


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread John Griessen

On 09/07/2010 06:24 PM, DJ Delorie wrote:



Sounds nice -- could come from DJ upgrading GTK functionality.


I was hoping someone else would do the GTK stuff :-)


Oh, I suppose I could, I just need more economic stability first.

John


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread Andrew Poelstra
On Tue, Sep 07, 2010 at 07:24:38PM -0400, DJ Delorie wrote:
 
  Sounds nice -- could come from DJ upgrading GTK functionality.
 
 I was hoping someone else would do the GTK stuff :-)


I'm working on cleaning up the Gtk code - well, refactoring gui-top-window.c,
anyway. Hopefully I'll be able to get things into a top-down sorta structure
that can be easily mapped to C++.

The hard part is untangling the Gtk code from the HID action-passing code.

Plus, I don't have a clear understanding of what mapped and allocated
and realized mean in Gtk terms. Does anyone know of a good overview of
Gtk+?


Andrew



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread Steven Michalske

On Sep 7, 2010, at 2:49 PM, Link wrote:

 * Trace impedance calculator, with automatic adjustment capability (fill in 
 thickness, stray capacitance and desired impedance, and the width is adjusted 
 to satisfy the conditions).

To get this it would be nice to have stackup information with the layers,  4 
layer board with 1oz copper on the outside and .5oz on the inside.  etc.



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread Mark Rages
On Tue, Sep 7, 2010 at 4:49 PM, Link l...@penguindevelopment.org wrote:

 Some things I regard as quite important:

 * Variable-angle arcs. 90 degrees is extremely limiting. gschem does this
 right.


Yes! Yes!  Not all designs are rectilinear.

 * Having all shapes that are supported for traces supported for footprint
 copper (arcs, polygons, circles, etcetera).

A shape I've often wanted on a pad is circle with the sides cut off.
This is slightly different than an oval.  Something like Inkscape's
boolean operations would be excellent.

 * Unification of shortcuts in gschem and PCB, or at least an easy option for
 PCB to mimic gschem's shortcuts.

Yes.  Better yet, support the modern-standard shortcuts first.  ctrl-z
for undo, etc.

 * Better support for free-rotated components: assert that pads at funky
 angles are rendered correctly, fix autorouter for components at weird angles
 (the latest git version has a tendency to either ignore the route command or
 to segfault, depending on the specifics), add rotation to the ctrl-R report,
 etcetera.

How about text at not-90 degree angles?  Or support for rotated square
pads (I know, the file format doesn't support those two.)

 * Ability to copy a footprint's name from the library dialogue (so it can be
 pasted into gschem's attribute list).

What a sad feature request.  But PCBgschem is such a power bag of
tools that selecting from a dropdown in gschem would be way too
limiting, amirite John D?

 * Ability to edit netlist in-situ (possibly by drawing on the rat lines
 layer) - e.g, when you want to add a heatsink soldered to ground, it will
 always show up as shorted until the netlist is edited to incorporate it.

A desirable feature, but drawing on rat lines seems less useful to me
than just popping a text editor and editing the netlist directly.


 * Last but not least, blind and buried vias. It's big, reasonably important,
 and has been on people's wish lists for years.

Yes!

I have some more feature requests for PCB.

Editing on the grid has got to go!  Counting grid points is the worst
possible way to enter positional information into a computer.

- Make every field in object reports editable.

- Allow direct entry of offsets and absolute positions when editing.

- Add offset and trim feature à la 2D CAD programs.

- Add point to tangent and tangent to tangent line drawing feature
à la 2D CAD programs.

Also, trim polygons against outline layer.  Fix polygons in general.

PCB's editing is just weak sauce.  My latest design, I edited in qcad
entirely, and just imported to PCB as a last step before making
Gerbers.   This was only possible because the design was very simple
with just a handful of nets.   I've since purchased a license for
Altium, which has its own kind of badness, but at least it lets me
type in numbers.

Regards,
Mark
markra...@gmail
-- 
Mark Rages, Engineer
Midwest Telecine LLC
markra...@midwesttelecine.com


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread DJ Delorie

 To get this it would be nice to have stackup information with the
 layers, 4 layer board with 1oz copper on the outside and .5oz on the
 inside.  etc.

I think we decided at some point in the past that the layer *group*
order would be our stackup order, but more information needs to be
added to make it complete.  Attributes, probably.  And a GUI option to
make it all user-friendly so they're less likely to do the wrong thing
with it and complain when it doesn't work.

Or we could redesign how we store layer groups, so that we have
information for what goes *between* the layers as well.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread Ethan Swint

On 09/07/2010 08:28 PM, Mark Rages wrote:

* Ability to edit netlist in-situ (possibly by drawing on the rat lines
layer) - e.g, when you want to add a heatsink soldered to ground, it will
always show up as shorted until the netlist is edited to incorporate it.
 

A desirable feature, but drawing on rat lines seems less useful to me
than just popping a text editor and editing the netlist directly.
   
Too true - but it can cause quite a fuss when you reload the file in the 
wrong window.  How about having PCB (and gEDA, too, FTM) scan the file's 
timestamp periodically and alert the user when the file has been 
overwritten?




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread timecop
   Surely in 2010 there is a portable non-polling way to get file update
   notification?

   On 8 Sep 2010 09:46, Ethan Swint [1]eswint.r...@verizon.net wrote:
On 09/07/2010 08:28 PM, Mark Rages wrote:
* Ability to edit netlist in-situ (possibly by drawing on the rat
   lines
layer) - e.g, when you want to add a heatsink soldered to ground,
   it will
always show up as shorted until the netlist is edited to
   incorporate it.
   
A desirable feature, but drawing on rat lines seems less useful to
   me
than just popping a text editor and editing the netlist directly.
   
Too true - but it can cause quite a fuss when you reload the file in
   the
wrong window. How about having PCB (and gEDA, too, FTM) scan the
   file's
timestamp periodically and alert the user when the file has been
overwritten?
   
   
   
___
geda-user mailing list
[2]geda-u...@moria.seul.org
[3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

References

   1. mailto:eswint.r...@verizon.net
   2. mailto:geda-user@moria.seul.org
   3. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread DJ Delorie

 Surely in 2010 there is a portable non-polling way to get file update
 notification?

More than one, I think...

But any design that requires you to edit files behind pcb's back, is bad.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread John Doty

On Sep 7, 2010, at 6:50 PM, DJ Delorie wrote:

 But any design that requires you to edit files behind pcb's back, is bad.

You're not thinking flexible toolkit. You're thinking inflexible integrated 
tool.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread Ethan Swint

On 09/07/2010 08:50 PM, DJ Delorie wrote:

Surely in 2010 there is a portable non-polling way to get file update
notification?
 

More than one, I think...

But any design that requires you to edit files behind pcb's back, is bad.
   
I text-edit PCB files on every single board I do... arcs are the most 
blatant example.  Other things I do where it's easier to text edit 
rather than to look up/create a command in PCB:
*connect vias to polygons as a workaround for not being able to 
associate polys with a net, i.e. I search  replace  'found' for 
'thermal(1x,2x),found'.

*change multiple trace segments to a desired numerical width
*change clearances on multiple pins/pads to a desired numerical value
*change the min size of via holes or soldermask openings 
(tented/cleared) when I've forgotten to change the defaults to my 
projects requirements at the start
*create/modify footprints where a given numerical value is desired 
(concurrently performing sanity-check in PCB)



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread gene glick

DJ Delorie wrote:

Shall we / I push this? I think it looks good overall.



off the top of my head . . .

A) slots in planes (may be already in the process?)
B) square/rectangular holes (e.g. mounting tabs)


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread John Doty

On Sep 7, 2010, at 7:21 PM, DJ Delorie wrote:

 
 You're not thinking flexible toolkit. You're thinking inflexible 
 integrated tool.
 
 I'm thinking two things shouldn't edit the same file at the same time
 
 I don't care what you do when pcb isn't running, but when it is...

The trouble with GUI tools is that they don't just do one thing and get out of 
the way.  Therefore, a GUI tool has special responsibilities, including 
watching the file it's editing.

 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
 

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread DJ Delorie

 The trouble with GUI tools is that they don't just do one thing and
 get out of the way.  Therefore, a GUI tool has special
 responsibilities, including watching the file it's editing.

What?  I don't know of any guis that do that.  The best I've seen is
the file seems to have changed since the last load... are you sure
you want me to overwrite it?

Editing *anything* with two editors (any kind of editors) at the same
time IS BAD, unless both are explicitly designed to work together that
way.

And why is a gui special this way?  I could argue that emacs and vi
also have special responsibilities to watch the file they're
editing.  Hey - that W changed on disk, should I reload?

You're talking about a magic three-way merge feature in every editor.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread John Doty

On Sep 7, 2010, at 7:24 PM, DJ Delorie wrote:

 
 I do stuff like that too, but it's still bad.  Way too easy to lose
 work by saving one set of changes over another.

But having the GUI tool on alert helps.

 
 Now, if we had an edit the raw pcb file menu option that LOCKED the
 file so that you couldn't corrupt your data and lose work, that would
 be safer.  Or maybe PCB needs to follow the bog-standard this file is
 being edited locking semaphores whenever the pcb is unsaved.

Locks tend to cause more problems than they solve. Ever use RCS?

 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
 

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread John Doty

On Sep 7, 2010, at 7:31 PM, DJ Delorie wrote:

 What?  I don't know of any guis that do that.  The best I've seen is
 the file seems to have changed since the last load... are you sure
 you want me to overwrite it?

Nedit, for example, watches and pops up a dialog box that says: file has 
been modified by another program. Reload? with the appropriate buttons. Not a 
perfect mechanism, but a useful and practical one.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread DJ Delorie

 But having the GUI tool on alert helps.

Warning: it's too late to avoid losing your work!

 Locks tend to cause more problems than they solve. Ever use RCS?

Yes.  It kept me from stomping on my co-workers changes, many times.
Every source control system I know has some sort of mechanism for
dealing with this issue, either through locks or a manual three-way
merge.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread DJ Delorie

 Nedit, for example, watches and pops up a dialog box that says:
 file has been modified by another program. Reload? with the
 appropriate buttons. Not a perfect mechanism, but a useful and
 practical one.

And if you've just spent the last hour editing the file, you're
screwed.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: next PCB release - 1.99za vs 4.0

2010-09-07 Thread John Doty

On Sep 7, 2010, at 7:38 PM, DJ Delorie wrote:

 
 But having the GUI tool on alert helps.
 
 Warning: it's too late to avoid losing your work!
 
 Locks tend to cause more problems than they solve. Ever use RCS?
 
 Yes.  It kept me from stomping on my co-workers changes, many times.
 Every source control system I know has some sort of mechanism for
 dealing with this issue, either through locks or a manual three-way
 merge.

The merge works better, although it's not a logically rigorous mechanism. But 
back in the bad old RCS days, my group constantly had to break locks to get 
anything done. So in practice, locking is less rigorous.

 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
 

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user