Re: gEDA-user: essential library -- plaese comment.
2011/8/31 DJ Delorie d...@delorie.com: Note that the links give you the *wrong* symbol though. The link doesn't match the visible text. Oh, I am sorry. I just tried to say the links are wrong, that is they don't point to appropriate footprints. -- VZh ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New gtk menu system
Andrew Poelstra wrote: One close thing I could do is set the hover-selection property, which would actually select the item the mouse is on. This would be a nightmare, I imagine, for people who bat their mice haphazardly to the left to get their cursor out of the way. You mean, mouse-over triggers the same events like left-mouse-click? This would indeed be a nightmare. Another, more sensible thing I can do is to change the rendering of the color swatch when the mouse is on the row. Can you think of a good highlighted cue that only affects the swatch? How about a change to the frame? For example, make it thicker and GTK highlight color. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 increasingly unhappy 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 gtk menu system
Two more issues: * A left-mouse-click on the square toggles the visibility of the whole layer group on the canvas. But it toggles only the visual state of this layer, not the state of the squares that correspond to the other layers in the group. As a result, the state of the squaere is not necessarily in unison with the visibility of the layers on the canvas. * Load of a colour theme does not immediately update the colours. The layers in the layout receive the new colours only, after their visibilty is toggled. The squares in the layer selector only receive the new colours after restart of the application. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 increasingly unhappy 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: essential library -- please comment.
DJ Delorie wrote: Note that the links give you the *wrong* symbol though. The link doesn't match the visible text. Ah! I totally missed that. It chould be correct now (including all the other links Vladimir found on my main page -- Thanks for checking, again). These copy-paste errors tend to stay unnoticed for years because I don't use the gedasymbols HTML-page myself. Lesson to be learned: This kind of page really should be created from the actual library by a script. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 increasingly unhappy 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: revert vs reload
On Tue, 2011-08-30 at 01:46 +0200, Kai-Martin Knaak wrote: With a number of recommended work-flows PCB and gschem do not return to the last saved state. Instead, they update to the current state of the source file. The gsch2pcb work-flow relies on the ability to change the *.pcb file in the back of PCB. Contrary to the meaning of the word revert the revert action does not go back but forward. When the files that evince or gedit have open are changed, they pop up a bar across the top of the window with a reload button in it. Perhaps this is a solution that would fit in better. Cheers, Rob 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 gtk menu system
On Tue, 30 Aug 2011 14:22:28 -0700 Andrew Poelstra as...@sfu.ca wrote: On Tue, Aug 30, 2011 at 06:51:10PM +0200, Kai-Martin Knaak wrote: Some glitches: I don't see any visual feedback which item the mouse cursor currently refers to. Gnome user expectation seems to be, that the item should be highlighted with background changing to focus color. Much the same way that the items in a menu highlight on mouse-over. Currently, I get focus color only after I clicked a layer. Here is some visual feedback. It brightens the swatches when the mouse is over the row, a little bit. Let me know what you think of it. I didn't try it yet, but will it work for layers with the following colors: - white layers (e.g., silk) or black layers? - layers with colors like red, green, blue, yellow, cyan, etc. where all of R,G,B are either 0.0 or 1.0 (normalized scale)? A more general solution, and one that won't affect the accurate representation of the layer color by the swatch, is to draw a 1 or 2 pixel wide border around the swatch when the mouse hovers over that layer button. Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gpcb-menu.res
On Tue, 30 Aug 2011 12:01:00 -0700 Andrew Poelstra as...@sfu.ca wrote: Fixed in git head. Thanks! Maybe I can see why the automatic layer (group) change doesn't work. Can you give me any clue where it is located in the code? Thank you Levente -- 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: gpcb-menu.res
On Wed, Aug 31, 2011 at 02:00:37PM +0200, Kovacs Levente wrote: On Tue, 30 Aug 2011 12:01:00 -0700 Andrew Poelstra as...@sfu.ca wrote: Fixed in git head. Thanks! Maybe I can see why the automatic layer (group) change doesn't work. Can you give me any clue where it is located in the code? In the toggle callback, I call ChangeGroupVisibility, which changes the core state, but there is no function that resyncs the selector state with the core state. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Do whatever you want. Do what you think is important. Everybody is an individual. --Ron Paul ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: essential library -- plaese comment.
?? wrote: Oh, I am sorry. I just tried to say the links are wrong, that is they don't point to appropriate footprints. If I didn't introduce new errors, they should be fine now. Thanks again for checking! Any comments on the symbols themselves? ---)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 - not happy with moderation of geda-user mailinglist ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New gtk menu system
Colin D Bennett wrote: A more general solution, and one that won't affect the accurate representation of the layer color by the swatch, is to draw a 1 or 2 pixel wide border around the swatch when the mouse hovers over that layer button. +1 and use gtk selection color for the frame. Or alternatively, draw the frame in layer color. This would increase the size of the square. ---)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 - not happy with moderation of geda-user mailinglist ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gedasymbols.org down?
On Wed, Aug 31, 2011 at 10:56:27AM -0400, DJ Delorie wrote: Just FYI, turns out the place that hosts my secondary DNS was *also* out for the hurricane. Not much I can do about that - my paranoia only goes so far ;-) I could host sec dns for the site in central Europe if that helps. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New gtk menu system
On Wed, Aug 31, 2011 at 01:12:13AM +0200, Kai-Martin Knaak wrote: Two more issues: * A left-mouse-click on the square toggles the visibility of the whole layer group on the canvas. But it toggles only the visual state of this layer, not the state of the squares that correspond to the other layers in the group. As a result, the state of the squaere is not necessarily in unison with the visibility of the layers on the canvas. * Load of a colour theme does not immediately update the colours. The layers in the layout receive the new colours only, after their visibilty is toggled. The squares in the layer selector only receive the new colours after restart of the application. Both fixed in git head. I also explicily sync the layer selector to pcb's internal state in the LayersChanged() action handler, so they should not be able to get out of sync anymore. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Do whatever you want. Do what you think is important. Everybody is an individual. --Ron Paul ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New gtk menu system
On Tue, Aug 30, 2011 at 03:47:33PM -0700, Colin D Bennett wrote: On Tue, 30 Aug 2011 14:22:28 -0700 Andrew Poelstra as...@sfu.ca wrote: Here is some visual feedback. It brightens the swatches when the mouse is over the row, a little bit. Let me know what you think of it. I didn't try it yet, but will it work for layers with the following colors: - white layers (e.g., silk) or black layers? - layers with colors like red, green, blue, yellow, cyan, etc. where all of R,G,B are either 0.0 or 1.0 (normalized scale)? White layers, no. Everything else, yes. A more general solution, and one that won't affect the accurate representation of the layer color by the swatch, is to draw a 1 or 2 pixel wide border around the swatch when the mouse hovers over that layer button. I tried this at home. It seemed to draw too much attention to the swatch, and indicate toggle me! rather than prelight. IMHO, if we do anything to indicate prelighting, it should be (at least) as subtle as my color change. And I am not entirely sold that we should be doing anything. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Do whatever you want. Do what you think is important. Everybody is an individual. --Ron Paul ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: essential library -- plaese comment.
On Wed, Aug 31, 2011 at 03:08:08PM +0200, Kai-Martin Knaak wrote: ?? wrote: Oh, I am sorry. I just tried to say the links are wrong, that is they don't point to appropriate footprints. If I didn't introduce new errors, they should be fine now. Thanks again for checking! Any comments on the symbols themselves? The symbols are nice, but there are special state standards in Russia about what should they look like. I like an idea to have the footprints attribute. It also would be nice to have a GUI way to pick one of its items to be used as the footprint attribute. Viel Erfolg! -- VZh ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: How to find which specific part of a PCB is shorted?
I am getting these messages: Warning! Net 3V3plus is shorted to net GND Warning! Net GND is shorted to net 3V3plus The 3.3V bus is used all over the board. How can I locate specifically which part is shorted? It must be something I placed recently, but I do not have an undo buffer as I closed the program down before I noticed this. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: How to find which specific part of a PCB is shorted?
On 08/31/2011 04:57 PM, Thomas Oldbury wrote: The 3.3V bus is used all over the board. How can I locate specifically which part is shorted? Divide and conquer...delete some trace segments or reroute 2 pieces where one long one is and see what changes... It must be something I placed recently, but I do not have an undo buffer as I closed the program down before I noticed this. I've used the highlighting to find problems. You know there is a wrong connection to 3.3V bus, so highlight that trace and see what all is connected to it. The intersection of the non-power traces that are highlighted and the power bus is where the problem is. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New gtk menu system
On Wed, 2011-08-31 at 01:12 +0200, Kai-Martin Knaak wrote: Two more issues: * A left-mouse-click on the square toggles the visibility of the whole layer group on the canvas. But it toggles only the visual state of this layer, not the state of the squares that correspond to the other layers in the group. As a result, the state of the squaere is not necessarily in unison with the visibility of the layers on the canvas. If this is the case, it would seem that the selector's data model may reside in the wrong place. A quick skim of the new code suggests that the click action is directly updating the row, where it (arguably) should be poking PCB's core (using an API such as ChangeGroupVisibility) then reading back the changed states. While it probably doesn't, PCB could quite merrily change the layer on / off status from (say), an action in the core, or a plugin we have no control of. Unfortunately, we don't yet have a way to keep track of this happening in the GUI, but perhaps we should grow one. Whilst the definitive source of the underlying data is in PCB's core, the widget ought ideally to be working from that. Since PCB doesn't do signals on changed data, we might have to improve the HID API a little here. The graphics API work I'm doing could remove part of the the need to have the layer on / off status in the core (for rendering at least), but the autorouter(s) use it to determine which layers to route on, and various other bits of code (including object selection) seem to care. Perhaps the easier option would be to contractually ban the core from assigning layer visibilities. That would mean banning or moving some of the misc.c APIs which touch that. 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: New gtk menu system
While it probably doesn't, PCB could quite merrily change the layer on / off status from (say), an action in the core, or a plugin we have or DRC, which does that, at least temporarily. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: revert vs reload
On Wed, 2011-08-31 at 11:08 +0100, Rob Spanton wrote: On Tue, 2011-08-30 at 01:46 +0200, Kai-Martin Knaak wrote: With a number of recommended work-flows PCB and gschem do not return to the last saved state. Instead, they update to the current state of the source file. The gsch2pcb work-flow relies on the ability to change the *.pcb file in the back of PCB. Contrary to the meaning of the word revert the revert action does not go back but forward. When the files that evince or gedit have open are changed, they pop up a bar across the top of the window with a reload button in it. Perhaps this is a solution that would fit in better. Would be nice to have. Perhaps file a feature-request on http://launchpad.net/pcb/+bugs We would probably need the g_file_monitor_file API in GLib/GIO. This is present (I think), since GLib 2.18. This corresponds to approximately GTK 2.16 and onwards. (From a quick scan of the git repository, GTK 2.16 requires at least GLIB 2.19.7). Regards, -- 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: revert vs reload
We would probably need the g_file_monitor_file API in GLib/GIO. Given the nature of PCB, I'd suggest tying it to the changed flag of the loaded PCB - so if you haven't edited it yet, you see reload but if you have unsaved changes, you see revert. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gpcb-menu.res
On Wed, 2011-08-31 at 14:00 +0200, Kovacs Levente wrote:
On Tue, 30 Aug 2011 12:01:00 -0700
Andrew Poelstra as...@sfu.ca wrote:
Fixed in git head.
Thanks! Maybe I can see why the automatic layer (group) change doesn't work.
Can you give me any clue where it is located in the code?
src/hid/gtkhid-main.c, SwapSides (...)
Approx line 1408:
if ((active_group == comp_groupcomp_on!solder_on) ||
(active_group == solder_group solder_on !comp_on))
{
bool new_comp_vis = Settings.ShowSolderSide active_group == comp_group;
ChangeGroupVisibility (PCB-LayerGroups.Entries[comp_group][0],
new_comp_vis, new_comp_vis);
ChangeGroupVisibility (PCB-LayerGroups.Entries[solder_group][0],
!new_comp_vis, !new_comp_vis);
}
The failure is probably in picking the correct groups..
at the top of that function:
int active_group = GetLayerGroupNumberByNumber (LayerStack[0]);
-- Probably ok
int comp_group = GetLayerGroupNumberByNumber (component_silk_layer);
-- Probably ok
int solder_group = GetLayerGroupNumberByNumber (solder_silk_layer);
-- Probably ok
bool comp_on = LAYER_PTR (PCB-LayerGroups.Entries[comp_group][0])-On;
-- PROBABLY BAD
bool solder_on = LAYER_PTR (PCB-LayerGroups.Entries[solder_group][0])-On;
-- PROBABLY BAD
IIRC, there is no guarantee that the 0'th index in the group is the one
we should be testing here. The (PCB+GL) rendering code tests group
on/off-ness like this:
int idx = group; /* idx is a group number here */
if (idx = 0 idx max_group)
{
int n = PCB-LayerGroups.Number[group];
for (idx = 0; idx n-1; idx ++)
{ /* idx is a group entry index here */
int ni = PCB-LayerGroups.Entries[group][idx]; /* ni is a layer
number */
if (ni = 0 ni max_copper_layer + 2
PCB-Data-Layer[ni].On)
break;
}
idx = PCB-LayerGroups.Entries[group][idx]; /* idx is now a layer
number! */
}
if (idx = 0 idx max_copper_layer + 2)
{
group_visible = PCB-Data-Layer[idx].On;
... /* idx is a layer number in this section */
}
else if (idx 0)
... /* idx is a magic group number, created with SL() macros */
What that is doing, is looking for a copper (or silk) layer in the
appropriate group (which gets its number set in idx, then testing if
that layer is on.
Note that the for-loop stops one-short, as the value left in idx can be
one greater than the termination criteria of the for loop (which IS the
last in the layer group).
idx is abused as both a group index, and a layer index. These are
completely different (boy this code sucks).
(Oh yea, that is ugly!)
I felt sure I'd re-written this because it was ugly before now. I really
shudder to think the above was what _I_ came up with to fix it being
ugly.
--
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: gpcb-menu.res
On Thu, 2011-09-01 at 00:56 +0100, Peter Clifton wrote: On Wed, 2011-08-31 at 14:00 +0200, Kovacs Levente wrote: On Tue, 30 Aug 2011 12:01:00 -0700 Andrew Poelstra as...@sfu.ca wrote: Fixed in git head. Thanks! Maybe I can see why the automatic layer (group) change doesn't work. Can you give me any clue where it is located in the code? FWIW, a little skim and a vague recollection suggests this commit might have been related... I can't recall whether it was that it broke some behaviour in PCB+GL, or broke the tab-changes side feature you're talking about. I think it broke PCB+GL actually (at the time it hit). commit 9768e060fad7bc3dfc366da76ea1db8154005018 Author: DJ Delorie d...@delorie.com Date: Tue Sep 7 23:29:59 2010 -0400 Fix layer visibility logic for some boards. If the Groups() line listed the c/s layer before the copper layer, disabling silk would also disable the copper. This change searches the entire layer group looking for any layer that might need to be drawn, and uses that as the exemplar instead of blindly choosing the first layer in the list. (Turns out it is the origin of that complex code I was whining about in my last email ;) - Sorry DJ!). Perhaps a git bisect will help us pin down when the tab feature first stopped working... I'm really quite curious now. This commit looks like it fixes the issue for Lesstif: commit d7be5538da245ccdbd5e2c50d0231fb2d154e9ac Author: DJ Delorie d...@delorie.com Date: Fri Sep 10 01:53:31 2010 -0400 Fix lesstif SwapSides magic layer option. If the first layer in the layer group is silk, the swap sides key won't auto-toggle the solder and component groups, nor properly activate them if it does. Add code to find a visible *copper* layer in the layer group and use that. Finally, it was broken before my commit: commit f903b4be6b85efc110852f7be40edf8245f0a513 Author: Peter Clifton pc...@cam.ac.uk Date: Sat Aug 20 15:45:20 2011 +0100 hid/gtk: Some NOOP and whitespace changes to the SwapSides() function Split from of a later patch which reworks the view flipping APIs. Hopefully this makes the function a little simpler. However, it might be worth checking the logic there, as having re-read my NOOP changes, I wonder if I might have made a mistake about the setting of my bool new_comp_vis variable. Looking back, I'm 99% certain that I made a mistake on this. Furthermore, the assumed [0] index on the group entry is also present in this code. -- 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: revert vs reload
On Wed, 2011-08-31 at 19:44 -0400, DJ Delorie wrote: We would probably need the g_file_monitor_file API in GLib/GIO. Given the nature of PCB, I'd suggest tying it to the changed flag of the loaded PCB - so if you haven't edited it yet, you see reload but if you have unsaved changes, you see revert. Gah, PLEASE NO. Just stick with the Gnome HIG specification and be done with it. -- 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: gpcb-menu.res
The original bug for my layer visibility patch, IIRC, is a groups line like c,1;s,2 - note that the c/s are listed before the 1/2. The max_layer+1 trick is used for both the c/s magic layers *and* the silk layers. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: revert vs reload
Given the nature of PCB, I'd suggest tying it to the changed flag of the loaded PCB - so if you haven't edited it yet, you see reload but if you have unsaved changes, you see revert. Gah, PLEASE NO. Well, yeah, I wouldn't recommend magically changing menu buttons at all, but it's better than trying to see if someone edited the file out from under you when you're the one with the editor. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gpcb-menu.res
On Wed, 2011-08-31 at 20:41 -0400, DJ Delorie wrote: The original bug for my layer visibility patch, IIRC, is a groups line like c,1;s,2 - note that the c/s are listed before the 1/2. The max_layer+1 trick is used for both the c/s magic layers *and* the silk layers. I'm sure it used to work on fairly stock boards - perhaps those created with gsch2pcb, or a default PCB stack. I got the impression that the feature had broken recently. (I'm beginning to think I broke it further when re-writing parts of that code for clarity), but that was only last week or so. :( Yes - I did break it (at least partially).. I'll fix the bit I broke. -- 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: revert vs reload
On Wed, 2011-08-31 at 20:43 -0400, DJ Delorie wrote: Given the nature of PCB, I'd suggest tying it to the changed flag of the loaded PCB - so if you haven't edited it yet, you see reload but if you have unsaved changes, you see revert. Gah, PLEASE NO. Well, yeah, I wouldn't recommend magically changing menu buttons at all, but it's better than trying to see if someone edited the file out from under you when you're the one with the editor. Its a common practice for a lot of editors now, including vim (or at least gvim). I've lost count the number of times I've had the same schematic accidentally open twice by accident - for example. A warning when the file changes underneath me could be a huge bonus to know I need to _think_ before I save. More usefully, it would also make working between gschem and gattrib easier. -- 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: gpcb-menu.res
On Thu, 2011-09-01 at 01:46 +0100, Peter Clifton wrote:
Yes - I did break it (at least partially).. I'll fix the bit I broke.
Not a complete fix, but:
commit acbf10c2bf1814c5ffbe13dbcfd03fc9ffcaca89
Author: Peter Clifton pc...@cam.ac.uk
Commit: Peter Clifton pc...@cam.ac.uk
hid/gtk: Attempt to fix logic to flip component / solder group visibility
on flip
Should get back to better behaviour. I probably broke this somewhat with
commit f903b4be6b85efc110852f7be40edf8245f0a513, which attempted to
re-state the previous logic in a clearer fashon.
The logic now should:
If flipping sides, and only ONE of the solder / component layers (groups)
is visible, and that layer (group) is _active_, then swap the visibilities
of the component / solder layers (groups), and make the newly visible
layer (group) active.
There are still bugs in this code relating to the assumption that the
first entry in the layer group is the one which is being toggled. This
breaks if the first entry in the group is that corresponding to the silk
for that side of the board.
diff --git a/src/hid/gtk/gtkhid-main.c b/src/hid/gtk/gtkhid-main.c
index 4d9fdbe..7a6b8a8 100644
--- a/src/hid/gtk/gtkhid-main.c
+++ b/src/hid/gtk/gtkhid-main.c
@@ -1408,12 +1408,12 @@ SwapSides (int argc, char **argv, Coord x, Coord y)
if ((active_group == comp_groupcomp_on!solder_on) ||
(active_group == solder_group solder_on !comp_on))
{
- bool new_comp_vis = Settings.ShowSolderSide active_group ==
comp_group;
+ bool new_solder_vis = Settings.ShowSolderSide;
ChangeGroupVisibility (PCB-LayerGroups.Entries[comp_group][0],
- new_comp_vis, new_comp_vis);
+ !new_solder_vis, !new_solder_vis);
ChangeGroupVisibility (PCB-LayerGroups.Entries[solder_group][0],
- !new_comp_vis, !new_comp_vis);
+ new_solder_vis, new_solder_vis);
}
return 0;
--
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 gtk menu system
Andrew Poelstra wrote: On Tue, Aug 30, 2011 at 03:47:33PM -0700, Colin D Bennett wrote: A more general solution, and one that won't affect the accurate representation of the layer color by the swatch, is to draw a 1 or 2 pixel wide border around the swatch when the mouse hovers over that layer button. I tried this at home. It seemed to draw too much attention to the swatch, and indicate toggle me! rather than prelight. It says you can do something here, just like the items in a menu, the mm/mil button, the tools buttons, the route styles and the scroll bars do. IMHO, if we do anything to indicate prelighting, it should be (at least) as subtle as my color change. Whether this highlighting is subtle or a glaring contrast depends on the users GTK theme. I have seen both among the most downloaded themes at gnome-look.org. This is a basically a user decision, not something, the developers should care about. And I am not entirely sold that we should be doing anything. Every item, that can be clicked should be highlighted on mouse-over. Only items that cannot be clicked or dragged should stay silent. Surely, the gnome HIG says something along these lines. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 increasingly unhappy 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: gedasymbols.org down?
Russell Dill wrote: I imagine I'm not the only one running a git mirror of gedasymbols.org. If you rely on gedasymbols.org in any way, It'd be wise to do the same. Is there a way to propagate changes in the git repo to DJs cvs? (short of running cvs commit in a cron job) ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 increasingly unhappy 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: How to find which specific part of a PCB is shorted?
Thomas Oldbury wrote: I am getting these messages: Warning! Net 3V3plus is shorted to net GND Warning! Net GND is shorted to net 3V3plus The 3.3V bus is used all over the board. How can I locate specifically which part is shorted? This is what I do: 1) open the net list window 2) click on one of the offending nets. The right side of the netlist window will show all the pads and pins that are connected to this net. 3) double click a pin or pad. On the canvas, the cursor warps to the pin. 4) move the mouse slightly 5) zoom in 6) type [f] while te mouse hovers over the pin or pad 7) follow the highlighted path to see, where it goes off-road. Step 4 and 5 are really only necessary, if the pin count is fairly large. If the offending connection is to ground, like in your case, and there is a ground plane, then there may be find color all over the place. So, there is no visible path to follow. In that case, I put the polygons into their own layers with their own, private layer group. They are not considered connected anymore If everything else fails, I resort to plain old bisection: Remove the right half of the layout and check, whether the short goes away. Repeat, until you spot the problem. Then revert to the complete layout. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 increasingly unhappy 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: gedasymbols.org down?
On Wed, Aug 31, 2011 at 1:37 PM, Kai-Martin Knaak k...@familieknaak.de wrote: Russell Dill wrote: I imagine I'm not the only one running a git mirror of gedasymbols.org. If you rely on gedasymbols.org in any way, It'd be wise to do the same. Is there a way to propagate changes in the git repo to DJs cvs? (short of running cvs commit in a cron job) git cvsexportcommit ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
