Re: gEDA-user: New line-snapping feature for PCB - please try it!
I find I spend a lot of time moving lines over to the next grid point, during the later stages of layout (like today, doing DRC on a board, or nudging traces apart to make room for another one). When the grid is smaller than the lines, this is nearly impossible - you have to click to grab the point, press shift, move the point, release shift, grab the next point, etc. In this case, 10 mil lines on a 6.25 mil grid. Moving lines over a grid point is similar, especially moving a diagonal in a Z-bend. The only time I'd want to snap to an off-grid line when I move that line's endpoint, is if I'm extending a line - usually a stub connecting a metric part's pin to a ground plane, on an inch grid. But orthogonal moves mode is supposed to handle that. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Warp pointer nonesense
On Mon, 2011-07-25 at 01:15 +0200, Kai-Martin Knaak wrote: > Peter Clifton wrote on the other list where mere users are not allowed to > post: > My objection: I use regularily this feature to locate nets. It would be > a regression if it were removed without a replacement. Yes, it is less > than perfect now. A better way to achieve the same goal would be: > > 1) center the canvas on the feature to be warped to > 2) move the cursor right on top of the feature > 3) adjust zoom so that the diameter of the feature is about a tenth of > the canvas. > 4) make the main window of PCB active > > Do all this when explicitely asked for with a click on a warp-button. Try the patch on geda-dev, see how that works as a first cut. > PS: Please let users have a say, when it comes to GUI behavior. > That is, discuss such topics in geda.user, not in geda devel. Alternatively, ask Ales nicely, subscribe to geda-dev and discuss there. There are a huge number of users on _this_ list who don't want to get bogged down in details of an ongoing development discussion. -- 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) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New line-snapping feature for PCB - please try it!
On Sun, 2011-07-24 at 20:09 -0400, DJ Delorie wrote: > Also - it seems to snap to the lines you're moving, when you move an > intersection. Not sure if that makes sense. I think that makes sense.. I'll probably have to fix that. Having said that.. does it help you shorten an off-grid line without changing its angle? -- 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) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Warp pointer nonesense
Peter Clifton wrote on the other list where mere users are not allowed to post: > If no-one has any objection, I will remove the code which warps the > mouse pointer when selecting nets in the netlist window. My objection: I use regularily this feature to locate nets. It would be a regression if it were removed without a replacement. Yes, it is less than perfect now. A better way to achieve the same goal would be: 1) center the canvas on the feature to be warped to 2) move the cursor right on top of the feature 3) adjust zoom so that the diameter of the feature is about a tenth of the canvas. 4) make the main window of PCB active Do all this when explicitely asked for with a click on a warp-button. > The end goal is to abstract away the flipping / rotating of the board > into the rendering code. This should make it easier to reconcile board > flipping in the 3D view code, for example. Since 3D view is nice-to-have and provide pretty pictures but no much core funktionality, it should not be a reason for regression in other areas. ---<)kaimartin(>--- PS: Please let users have a say, when it comes to GUI behavior. That is, discuss such topics in geda.user, not in geda devel. -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 not happy with moderation of geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New line-snapping feature for PCB - please try it!
Also - it seems to snap to the lines you're moving, when you move an intersection. Not sure if that makes sense. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New line-snapping feature for PCB - please try it!
On Sun, 2011-07-24 at 20:23 +0200, Kai-Martin Knaak wrote: > Peter Clifton wrote: > > > Try it and you will see ;) > > > Now, that I tried a bit more, I see room for improvement :-) > Currently the cross hair snaps to lines on all layers. It should perhaps be a "stronger" snap on the layer you are on perhaps. Placing vias is layer agnostic of course, and I can imagine cases where I want to line a track up against one on a different layer _before_ placing the via. Perhaps a corner case though.. I'll leave it to others to experiment with the heuristic.. I've got other patches to cook at the moment. -- 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) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New line-snapping feature for PCB - please try it!
Peter Clifton wrote: > Try it and you will see ;) Now, that I tried a bit more, I see room for improvement :-) Currently the cross hair snaps to lines on all layers. In most cases this is not appropriate. It should look to lines on the current layer, only. This is a general problem with snappin in PCB. See my other more elaborate comment in this thread. Bonus points to make this behavior configurable. Because sometimes inter layer snapping is really useful. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 not happy with moderation of geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New line-snapping feature for PCB - please try it!
Peter Clifton wrote: > Basically, when you're over the line, the snap code picks the nearest > grid point to where your mouse pointer is, then casts out from it in > vertical, horizontal and both 45 degree angles in between, until it hits > the line your mouse pointer is over. Ok, so the cursor slides over the current line and tries to stay close to gridpoints in terms of 45°/90° metrik. Just recompiled and gave it a test run. Very nice! I like it. Side-note: I keep patching src/hid/common/hidnogui.c every time I clone the git repo. The application falsely assumes an error if invalidate_lr is called without a running GUI. This prevents action scripts from the command line do useful work like flip the board for back side printing. It also prevents me from distributing my command line printing scripts to students and collegues. Any chance that this gets fixed? ---<)kaiamrtin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 not happy with moderation of geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB: Documentation for command-line options (unit-changes)
Am 25.07.2011 08:03, schrieb Andrew Poelstra: (...) As for units, there shouldn't really be a default unit. If no unit is given, we will probably go with cmils for the sake of backward compatibility. But we support giving units like --via-thickness 3mm (no space) and that is what should be done. Thanks, I will add this to the documentation. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB: Documentation for command-line options (unit-changes)
> We should use the CLAMP() macro to force min/max values rather > than ignoring out-of-range values, in my opinion. I think each such case should be an opportunity to see if we shouldn't have limits there at all. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB: Documentation for command-line options (unit-changes)
On Sun, Jul 24, 2011 at 10:00:08PM +0200, Felix Ruoff wrote: > Hello everybody, > > I am actually working on Kai-Martins patch for the command-ine > options he suggested in > > http://thread.gmane.org/gmane.comp.cad.geda.user/29944/focus=30083 > > Its from April 2010, so there is some work to be done to fit it to the > present code-base. While doing this, I got two questions: > - What is the actual unit for size-options like '--via-thickness', > '--line-thickness'? Is the unit for this setting still 1/100 mil? Or is it > possible to give this option with an unit like '--via-thickness 3 mm'? I have > in mind, that there were some changes during the last weeks, but I didn't > figure out the actual situation. > - I realised that the default-value for '--via-thickness' is > MIL_TO_COORD(60), (line 487 of main.c) but in line 616 it will be set to > MIL_TO_COORD(40) if the given value is over or under a given limit. Is the > difference in this sizes done on purpose? > I don't think this size difference should be there. It sounds like the default was changed at some point and whoever did it forgot to change the "out of range" value. We should use the CLAMP() macro to force min/max values rather than ignoring out-of-range values, in my opinion. As for units, there shouldn't really be a default unit. If no unit is given, we will probably go with cmils for the sake of backward compatibility. But we support giving units like --via-thickness 3mm (no space) and that is what should be done. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB: Documentation for command-line options (unit-changes)
Hello everybody, I am actually working on Kai-Martins patch for the command-ine options he suggested in http://thread.gmane.org/gmane.comp.cad.geda.user/29944/focus=30083 Its from April 2010, so there is some work to be done to fit it to the present code-base. While doing this, I got two questions: - What is the actual unit for size-options like '--via-thickness', '--line-thickness'? Is the unit for this setting still 1/100 mil? Or is it possible to give this option with an unit like '--via-thickness 3 mm'? I have in mind, that there were some changes during the last weeks, but I didn't figure out the actual situation. - I realised that the default-value for '--via-thickness' is MIL_TO_COORD(60), (line 487 of main.c) but in line 616 it will be set to MIL_TO_COORD(40) if the given value is over or under a given limit. Is the difference in this sizes done on purpose? Kind regards, Felix ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Recap of remaining metric-conversion work
On Sun, Jul 24, 2011 at 05:15:15PM +0100, Peter Clifton wrote: > On Sun, 2011-07-24 at 18:37 -0700, Andrew Poelstra wrote: > > > I have pushed my first commit. Rebasing my work causes merge > > failures in three files (action.c, crosshair.c, fontmode.c). > > Probably mostly just some fixes I made for compiler warnings. I am > plodding away at refactoring the event coordinate conversion for the GTK > HID though, and that could potentially conflict a bit. > > I'm trying to use the new types where applicable though - so I hope > resolving the conflicts should just be a matter of checking whether I > did anything stupid with my changes. > Looks good. Nearly all the conflicts were my changing LocationType to Coord where you changed the variables themselves. I did make one "real" change, though: I moved crosshair_sq_dist() to SquareDistance() in misc.c, to be with the Distance() function. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Recap of remaining metric-conversion work
On Sun, 2011-07-24 at 18:37 -0700, Andrew Poelstra wrote: > I have pushed my first commit. Rebasing my work causes merge > failures in three files (action.c, crosshair.c, fontmode.c). Probably mostly just some fixes I made for compiler warnings. I am plodding away at refactoring the event coordinate conversion for the GTK HID though, and that could potentially conflict a bit. I'm trying to use the new types where applicable though - so I hope resolving the conflicts should just be a matter of checking whether I did anything stupid with my changes. Best wishes, -- 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) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Recap of remaining metric-conversion work
On Sun, Jul 24, 2011 at 11:43:31AM +0100, Peter Clifton wrote: > On Sun, 2011-07-24 at 08:33 -0700, Andrew Poelstra wrote: > > > This causes no regressions, though if you are playing with grids > > you may need commit #2 below, which does cause regressions. > > I've not been working with the grid really - just the > "FitCrosshairIntoGrid" function in crosshair.c. > > (Incidentally - this doesn't really do what it says in the function > name.. evaluating GRIDFIT_X and GRIDFIT_Y on the mouse pointer position > is only a tiny aspect of what it does, the rest involves snapping to > various different kinds of objects. > I have pushed my first commit. Rebasing my work causes merge failures in three files (action.c, crosshair.c, fontmode.c). I'll let you know if there's anything serious. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New line-snapping feature for PCB - please try it!
On Sun, Jul 24, 2011 at 11:31:52AM +0100, Peter Clifton wrote: > On Sun, 2011-07-24 at 01:37 +0200, Kai-Martin Knaak wrote: > > Peter Clifton wrote: > > > > > adding a feature for snapping to off-grid points along the body of a > > > track. > > > > Sounds good, but I don't quite understand the details. Where exactly > > are these points? > > Try it and you will see ;) > > Basically, when you're over the line, the snap code picks the nearest > grid point to where your mouse pointer is, then casts out from it in > vertical, horizontal and both 45 degree angles in between, until it hits > the line your mouse pointer is over. > > Any of the intersections between the cast lines and the line you're over > will snap - the closest to your mouse pointer is choesen. > My first impression is that I like it. Now I can draw certain lines on very fine grids and not have to worry when working on coarser ones. The old behavior was very frustrating. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Recap of remaining metric-conversion work
On Sun, 2011-07-24 at 08:33 -0700, Andrew Poelstra wrote:
> This causes no regressions, though if you are playing with grids
> you may need commit #2 below, which does cause regressions.
I've not been working with the grid really - just the
"FitCrosshairIntoGrid" function in crosshair.c.
(Incidentally - this doesn't really do what it says in the function
name.. evaluating GRIDFIT_X and GRIDFIT_Y on the mouse pointer position
is only a tiny aspect of what it does, the rest involves snapping to
various different kinds of objects.
> The Gtk GUI uses _("mm") and _("mil") in its current code. I
> did not want to change this, so I internationalized all the units.
Yuck - never mind. We could change it to not translate, but since you've
gone to the trouble of making it work, I don't see why we should.
--
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)
signature.asc
Description: This is a digitally signed message part
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New line-snapping feature for PCB - please try it!
On Sun, 2011-07-24 at 01:37 +0200, Kai-Martin Knaak wrote: > Peter Clifton wrote: > > > adding a feature for snapping to off-grid points along the body of a > > track. > > Sounds good, but I don't quite understand the details. Where exactly > are these points? Try it and you will see ;) Basically, when you're over the line, the snap code picks the nearest grid point to where your mouse pointer is, then casts out from it in vertical, horizontal and both 45 degree angles in between, until it hits the line your mouse pointer is over. Any of the intersections between the cast lines and the line you're over will snap - the closest to your mouse pointer is choesen. From the commit message: commit 9e33678b20433f571c54009c704e75d114a3ea10 Author: Peter Clifton Date: Sat Jul 23 20:47:47 2011 +0100 crosshair.c: Snap to points along off-grid lines when drawing tracks This should greatly easy making tidy layouts where some lines have (perhaps by necessity) ended up off-grid. This patch adds code to snap onto the center of a line. It finds the nearest grid point to the cursor, then will allow snapping at the intersections between the line in question and the lines of an imaginary X and + centered on the nearest grid-point to the cursor. This allows neat drawing of horizontal, vertical and 45 degree lines which will land correctly on the existing line. signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
