Re: gEDA-user: Wire-only Symbols - Netlist problems
On Thu, Sep 08, 2011 at 07:08:45PM +0530, Abhijit Kshirsagar wrote: I tried adding 0Volt sources for the series-creating device and 0Amp current sources for the paralleling device. But no avail. The nets are still disjoint in the second case. Would it help it I posted a schematic? Could anyone shed some light please? Please tell us what version of gschem and gnetlist you're using. I remember a similar bug has been fixed in gEDA 1.7.1: https://bugs.launchpad.net/geda/+bug/698395 Best regards, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Layer button backgrounds
2011/8/18 Andrew Poelstra as...@sfu.ca: Kai (and others), what do you think of this mockup?: http://wpsoftware.net/andrew/dump/mockup.png Looks good. It resembles GtkTreeView and that raises a question - will it still be possible to toggle visibility without changing the active layer (moving the selection)? I also like the stronger visual indication of currently active layer. To me the size of layer color indication for hidden layers is too small - for example its hard to tell difference between power and outline. So I would either increase the size or skip showing color for invisible layers at all. I assume graying out the last 4 layers has some meaning - they're not selectable - but that's not immediately clear by looking at the widget. Cheers, Krzysztof ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Off topic: request for a little help
2011/8/17 Stephen Ecob silicon.on.inspirat...@gmail.com: If you're willing to help then please check out the shop and let me know if there's anything amiss - would you consider buying the product, or is there something in the site that would deter you ? From a perspective of Firefox user browsing with disabled JavaScript: The main page is nearly empty (just menus) and seems to indicate website is not complete? Top menus do not work without JS enabled Links on the bottom of the page work, but target of the link is not visible to the user. I believe you should also consider getting rid of the gray text in the main content - first impression is that this text is unimportant and it's hard to get accustomed to the fact you should actually read it ;-) [after enabling JS] The page load time is far from optimal, from my location image load times (each 100kB-150kB) are between 400 and 2200 ms. I'm also seeing some 404s in the trace: URL=http://www.sioi.com.au/shop/images/bg_list_arrow.png URL=http://www.sioi.com.au/shop/images/footer_item.gif URL=http://www.sioi.com.au/shop/images/banners/slide_banner_02.jpg Cheers, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Automatically start wire placement when you press the hotkey?
2011/8/11 Kai-Martin Knaak kn...@iqo.uni-hannover.de: yamazakir2 wrote: I had to redo my linux box so I installed a fresh copy of gschem from git and it seems like the method of wire placement has changed. When i press the wire hotkey, I have to click somewhere on the schematic before I can start drawing the wire. I noticed the change, too. Is this a bug, or deliberate? If it is deliberate, what was the reason for the change? The change was introduced with this commit: http://git.gpleda.org/?p=gaf.git;a=commit;h=2197952617d42ccbe2355747ef48668c63ece30b commit 2197952617d42ccbe2355747ef48668c63ece30b Author: Peter Clifton pc...@cam.ac.uk Date: Wed May 11 18:06:20 2011 +0100 gschem: Make the user click the first point when adding nets or buses This allows magnetic net mode to be used for the start-point of a net as well as its end-point, whilst still being able to initiate net drawing with the n key. I have updated buses as well in an effort not to have them diverge yet further in their behaviour. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Automatically start wire placement when you press the hotkey?
2011/8/11 Colin D Bennett co...@gibibit.com: Another thing that might make working with nets easier is it took fewer clicks to move vertices. Similar to how it is often irritating to have to (1) Click, (2) Pause, (3) Click+Drag a symbol to move it *, to move a line you have to click it, then click and drag either the line itself or one of its endpoints. ... * I know about the 'm' key now and I do use it often, but it's still annoying to not be able to just click and drag a component in one smooth action, as new users expect to be able to do. The click and drag is also partiallty fixed: http://git.gpleda.org/?p=gaf.git;a=commit;h=7f88749446b61493e881ad6aeb0a82f909a8c0d7 commit 7f88749446b61493e881ad6aeb0a82f909a8c0d7 Author: Peter Clifton pc...@cam.ac.uk Date: Mon Mar 21 22:51:23 2011 + gschem: Don't require select to drag objects This comes from watching users interacting with gschem and their clear expectations that objects can be dragged around the canvas without an explicit selection step first. When a mouse drag starts on non-selected object, starting dragging that object rather than forming a box selection. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem gnetlist problem
2011/7/13 Kai-Martin Knaak k...@familieknaak.de: I remember to have been scratching my head on this, when I did my first BOMs. My students tend to fall into this trap, too -- Even when they were told they'd need an attrib file. The keyword backtrace suggests a severe crash had happened. I guess, it is a scheme one-liner to text for existance of the file and issue a newbie friendly message. Or even better, produce a sensible default file on the fly. Peter B? John D.? Can you whip up such a line? I thought of adding something like this - possibly refdes and device attributes could be used by default + a warning message presented to the user if the attrib file is missing. Bonus points for suggesting how to make the gnetlist backend messages traslatable :-) Cheers, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test updates to auto-uref.scm
Thanks for the comments, it's now in git HEAD. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Please test updates to auto-uref.scm
Hello, Taking advice from Peter B I have implemented some changes to the auto-uref script. It does not cache refdeses anymore, and allows refdes reuse after deleting components from the schematic. Another change allows to specify refdes numbering offset that is applied automatically - for example: Page contains R10, R121 and R33, offset set to 100. Resistors will be numbered: R1, R2, R3... Page contains R123, R223, R102, offset set to 100. Resistors will be numbered: R101, R102, R103... Script requires recent modifications to libgeda, so test with git HEAD. Comments ideas welcome. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ;; gEDA - GPL Electronic Design Automation ;; gschem - gEDA Schematic Capture ;; Copyright (C) 1998-2010 Ales Hvezda ;; Copyright (C) 1998-2010 gEDA Contributors (see ChangeLog for details) ;; ;; This program is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 2 of the License, or ;; (at your option) any later version. ;; ;; This program is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; ;; You should have received a copy of the GNU General Public License ;; along with this program; if not, write to the Free Software ;; Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA (use-modules (ice-9 regex) (srfi srfi-1)) (define auto-uref-page-offset 0) ;; Redefine value of page-offset. ;; Refdeses will be numbered from integer multiples of page-offset, ;; depending on the lowest refdes value found on the page. ;; If lowest value is 323 and page offset is 100, then next refdes ;; will be 301. ;; Setting to 0 disables the feature. (define (auto-uref-set-page-offset new-offset) (set! auto-uref-page-offset new-offset)) ;; Modify attributes of an object to assign next unused refdes value (define (auto-uref attribs) ; Return (prefix . number) on match or #f on failure (define (split-value value) (let ((match (string-match ^([A-Za-z]+)([0-9]+)$ value))) (if match (cons (match:substring match 1) (string-number (match:substring match 2))) #f))) ; Extract prefix from a refdes attribute value (define (get-prefix value) (let ((prefix (string-match ^[A-Za-z]+ value))) (if (= 0 (match:end prefix)) #f (match:substring prefix ; Filter non-inherited refdes values (define (refdes-attrs attribs) (filter (lambda (a) (and (not (attrib-inherited? a)) (string=? refdes (car (get-attribute-name-value a) attribs)) ; Extract numbers from refdeses that have given prefix (define (extract-numbers object prefix) (let* ((refdeses (refdes-attrs (get-object-attributes object))) (vals (map (lambda (a) (cdr (get-attribute-name-value a))) refdeses)) (prefix-numbers (filter-map split-value vals)) (numbers (filter-map (lambda (n.v) (if (string=? prefix (car n.v)) (cdr n.v) #f)) prefix-numbers))) numbers)) ; Collect all numbers associated with prefix on current page (define (collect-all-numbers prefix) (let ((objects (get-objects-in-page (get-current-page (concatenate (map (lambda (o) (extract-numbers o prefix)) objects ; Return first number not present in used greater or equal to minimum (define (find-first-unused used minimum) (define (go n xs) (cond ((null? xs) n) (( n (car xs)) n) ((= n (car xs)) (go (1+ n) (cdr xs))) (else (go n (cdr xs) (go minimum used)) ; Do the work - first check if attributes contain refdes with prefix (let* ((refdeses (refdes-attrs attribs)) (refdes (if (null? refdeses) #f (car refdeses))) (prefix (if refdes (get-prefix (cdr (get-attribute-name-value refdes))) #f))) (if prefix (let* ((used-nums (sort-list (collect-all-numbers prefix) )) ; minimum value considering the page-offset (min-num (if (or (null? used-nums) (= auto-uref-page-offset 0)) 0 (* (floor (/ (car used-nums) auto-uref-page-offset)) auto-uref-page-offset))) ; next refdes number
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
Maybe we should aim at core gnetlist API being available in libgeda? Or in libgnetlist? Then SWIG [1] could be used to provide bindings to multiple scripting languages with relatively low effort. Of course if we want to embed a scripting language (as we currently do) then we need to stick to one choice :) [1] http://www.swig.org/ -- Krzysztof Kościuszkiewicz Skype: dr.vee, Gadu: 111851, Jabber: k...@jabster.pl Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
W dniu 26 maja 2011 17:52 użytkownik DJ Delorie d...@delorie.com napisał: Maybe we should aim at core gnetlist API being available in libgeda? Or in libgnetlist? What would this API provide? Would PCB need/want to use it? I'm not sure yet - just were trying to think how to provide an option to use multiple scripting languages. Currently backend methods are discovered loaded by the gnetlist core. That is only possible if scripting language is embedded into executable. If gnetlist became a library, common low-level code the driving part would be kept there. Backends would then be standalone executables/scripts that would load gnetlist library, register callbacks and kick gnetlist core to start processing. Another way is to provide primitive operations for querying schematics and other data sources and implement whole netlister flow in the backend - depends on the level of freedom/burden we want to have in the scripting layer. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: file format documentation formatting in the wiki
On Wed, May 25, 2011 at 05:04:04PM +0200, Felix Ruoff wrote: I like this idea! Had the same problem few times... +1 -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Bugtracker-cleanup
Thanks for taking the time to report the list - status update below. On Sun, May 22, 2011 at 06:01:49PM +0200, Felix Ruoff wrote: Here is the list: a) Patches for documentation - 699306 elements color in manual Committed. - 699391 refcard updates Committed. - 699476 G-CODE export GUI Commented on the tracker - we need eps files updated Makefile.am aa) Patches for the Webside - 704086 download page links to sourceforge Commented - Peter wanted to run some tests with robot on this bug b) Patches for GTK-gui - 769815 Fix warnings 'gray50 ignored' for gtk menu Committed. - 699496 Detect case-different accelerators as unique - 699510 Cleanup conditional code because GTK 2.12 is required now Committed. - 699493 Add plus and minus to possible keyboard-shortcuts c) New features/modifications - 699508 Use GTK dialog for confirming file-overwrite (replaces pcb-dialog-implementation with a dialog given by gtk+) d) Patches to the core - 699478 refdes labels in new layout can't be moved without restart Cheers, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: How to make a ground plane in PCB and attach all GND and VSS nets
2011/5/2 Rob Butts r.but...@gmail.com: So, how can I find those symbols? That means that if I don't use the VDD and VSS nets I have to copy all symbols into my own symbol directory? Wow, that is an inconvenience to say the least; especially where I will never use VDD or VSS. There's no other way to save them in their original directories? You can - get a root access for a system-wide installation directory or install in your user's home dir (say passing --prefix=$HOME to the ./configure script). Overwriting the default symbols is not recommended because if you migrate your design to another workstation it will use default symbols that were not modified. If you don't want to copy modify the symbols for your design you can always override the attributes in each instance of used symbol. Simply attach an attribute to the symbol instance and specify the power connection yourself. You can find an example here: http://www.geda.seul.org/wiki/geda:na_howto Another way that would work in the development version of gEDA would be to simply create an alias between VDD/VSS and your selected netnames for the power pins. You would have to create a wire with two netnames attached, or short two power symbol pins together to create an alias. Best regards, Krzysztof Kościuszkiewicz ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Attribute Net (without pin assignment) - for Power and Port Symbols
On Wed, Apr 13, 2011 at 10:41:23PM +0100, Peter Clifton wrote:
pin[pinnumber=1] {pinnumber=2;}
pin[pinnumber=2] {pinnumber=1;}
I've long seen this to be the most sane way of managing back-annotation
into a hierarchy. I would go as far to say refdes should be
back-annotated as such:
#X1 #X1 #R1 {refdes = R99;}
#X1 #X2 #R1 {refdes = R123;}
#X1 #X3 #R1 {refdes = R3;}
That looks neat powerful - and starting to closely resemble XPath/XSLT/CSS
transformations.
But I think we're actually getting farther from something that:
* is backwards compatible with the name=value attribute definition/syntx
* can be simply used to add hierarchy/depth to attribute assignments
It would be best to keep these two things aligned - syntax used for
general transformations should be a natural extension of the one used
for attribute definitions.
And a small comment regarding hierarchy separators - I would personally
choose anything that does not require shift-keystroke to type the most
commonly used separator - so '/' and '.' seem to be the two natural
candidates.
--
Krzysztof Kościuszkiewicz
Simplicity is the ultimate sophistication -- Leonardo da Vinci
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Attribute Net (without pin assignment) - for Power and Port Symbols
On Tue, Apr 12, 2011 at 04:31:03PM +0100, Peter Clifton wrote: This is a really neat idea.. P pin number :1 doesn't really matter, it is just a way of referring to a particular pin. If we could reference by other means, that would also be cool. I'm thinking of some kind of id=... attribute like CSS / HTML / SVG would use to refer to other elements. As someone who's just ranted against lots of magic special cases.. how would people feel to a primitive id=... attribute which is handled by API to look up and element's ID. We could make the code DEFAULT to looking up pinnumber= or pinseq= for pins (if an id=... doesn't exist), so the new syntax could key off id=, not pinnumber= or So we are more or less looking at a simplified hierarchical path syntax, where elements without explicit id= provide default id based on the type and other attributes? Examples: U1.1.net=Vcc (global attribute, pinnumber assumed for 1) 1.net=Vcc (attribute attached to U1) D1.A.net=Vcc (global, pinlabel assumed for A) Same could be specified in hierarchical design and would possibly solve the problem of different values in different instances of subcircuits. We'd have to work a bit on the syntax, precedence, resolution rules and how to refer to target attribute (in the above examples net would need to be a keyword). From that there's only a small step towards referring to arbitrary values in expressions (to specify component values etc). -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Attribute Net (without pin assignment) - for Power and Port Symbols
On Mon, Apr 11, 2011 at 11:25:19PM +0100, Peter Clifton wrote:
What about the cases where this is a mistake? The net= attribute was
supposed to refer to some implicit power pin - not the device's one
symbolic pin, but the user forgot the suffix.
The special case applies only to symbols with a single pin, so no such
error is possible here.
Our power symbols already fell like a bit of a kludge as there is no
physical pin or component which ends up in the netlist file.
(Why should we have to give that power symbol's pin ANY pinnumber
attribute? Why is pin 1 special?)
That's right - if a symbol has only one pin, then if it is :1 or :999
it does not matter. I added this restriction only because default power
symbols use :1, but that can be dropped.
_I_ think it adds to the confusion - as it would mean there are two
completely different syntax for the same attribute to be used in
different situations.
I don't want to see that special case code proliferate in gEDA. We have
enough already!
That is the main case against this change - one that changes from an
improvement to a kludge :)
A far more satisfying solution in the long run would be to make the
symbols which annotate net naming (like the power and ground symbols,
off-page labels etc..) have an editable attribute associated with the
PIN which gets hooked up to the net which becomes named (or renamed).
(netname=) as if it were on the net its-self.
That would be the best idea, of course. The power symbol with a
net=NETNAME{:PINNUMBER} actually acts same way (probably modulo gnetlist
config options) as netname=NETNAME attached to the same net.
Any idea how to make such annotation symbols work? Another variation
along the lines of graphical=1? Attributes (inherited or explicit) of
such symbol could be applied directly to the connected net/bus.
--
Krzysztof Kościuszkiewicz
Simplicity is the ultimate sophistication -- Leonardo da Vinci
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Attribute Net (without pin assignment) - for Power and Port Symbols
On Sun, Apr 10, 2011 at 11:22:54PM +0200, Markus Traidl wrote: Actually I would like to use only the net attribute. There I could assign net=3V3 instead of net=3V3:1. You might have missed a recent discussion on the topic: http://archives.seul.org/geda/user/Mar-2011/msg00074.html -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Attribute Net (without pin assignment) - for Power and Port Symbols
On Sun, Apr 10, 2011 at 11:22:54PM +0200, Markus Traidl wrote:
Actually I would like to use only the net attribute. There I could
assign net=3V3 instead of net=3V3:1.
I know that the :1 is that the gnetlist tool knows that the 3V3 is
connected to pin 1.
But in case of a One-Pin-Symbol the gnetlist tool could assume that
the only net should be assigned to the only pin.
This has been asked for several times and I don't see a reason why this should
not be allowed for single pin symbols and only for pin number 1.
The patches are attached - please test and report any potential breakage.
--
Krzysztof Kościuszkiewicz
Simplicity is the ultimate sophistication -- Leonardo da Vinci
From 336dbb62f859a19c5078504828c8298a11d47210 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Krzysztof=20Ko=C5=9Bciuszkiewicz?= k.kosciuszkiew...@gmail.com
Date: Mon, 11 Apr 2011 23:03:12 +0200
Subject: [PATCH 1/3] gnetlist: refactor s_netattrib_net_search
Replace two loops with one by using o_attrib_search_object_attribs_by_name.
Factor out inside of the loop to a separate function,
netname_if_matching_wanted_pin.
---
gnetlist/src/s_netattrib.c | 94
1 files changed, 34 insertions(+), 60 deletions(-)
diff --git a/gnetlist/src/s_netattrib.c b/gnetlist/src/s_netattrib.c
index 957735c..c8052f9 100644
--- a/gnetlist/src/s_netattrib.c
+++ b/gnetlist/src/s_netattrib.c
@@ -213,84 +213,58 @@ s_netattrib_handle (TOPLEVEL * pr_current, OBJECT * o_current,
}
}
+static char* netname_if_matching_wanted_pin (OBJECT *o_current,
+ char *net_attr,
+ const char *wanted_pin)
+{
+ char *char_ptr = strchr (net_attr, ':');
+
+ if (char_ptr != NULL) {
+/* found a colon separating netname and list of pins */
+char *net_name = s_netattrib_extract_netname (net_attr);
+char *start_of_pinlist = char_ptr + 1;
+char *current_pin = strtok (start_of_pinlist, DELIMITERS);
+
+while (current_pin) {
+ if (strcmp (current_pin, wanted_pin) == 0)
+return net_name;
+ current_pin = strtok (NULL, DELIMITERS);
+}
+
+g_free (net_name);
+return NULL;
+ } else {
+fprintf (stderr, Got an invalid net= attrib [net=%s]\n
+ Missing : in net= attrib\n, net_attr);
+return NULL;
+ }
+}
+
char *s_netattrib_net_search (OBJECT * o_current, char *wanted_pin)
{
char *value = NULL;
- char *char_ptr = NULL;
char *net_name = NULL;
- char *current_pin = NULL;
- char *start_of_pinlist = NULL;
- char *return_value = NULL;
int counter;
if (o_current == NULL ||
o_current-complex == NULL)
return NULL;
- /* for now just look inside the component */
- for (counter = 0; ;) {
-value = o_attrib_search_inherited_attribs_by_name (o_current,
- net, counter);
+ for (counter = 0; ; ++counter) {
+value = o_attrib_search_object_attribs_by_name (o_current,
+net, counter);
if (value == NULL)
break;
-counter++;
-
-char_ptr = strchr (value, ':');
-if (char_ptr == NULL) {
- fprintf (stderr, Got an invalid net= attrib [net=%s]\n
- Missing : in net= attrib\n, value);
- g_free (value);
- return NULL;
-}
-
-net_name = s_netattrib_extract_netname (value);
-
-start_of_pinlist = char_ptr + 1;
-current_pin = strtok (start_of_pinlist, DELIMITERS);
-while (current_pin !return_value) {
- if (strcmp (current_pin, wanted_pin) == 0) {
-return_value = net_name;
- }
- current_pin = strtok (NULL, DELIMITERS);
-}
+net_name = netname_if_matching_wanted_pin (o_current, value, wanted_pin);
g_free (value);
- }
-
- /* now look outside the component */
- for (counter = 0; ;) {
-value = o_attrib_search_attached_attribs_by_name (o_current,
- net, counter);
-if (value == NULL)
- break;
-
-counter++;
-char_ptr = strchr (value, ':');
-if (char_ptr == NULL) {
- fprintf (stderr, Got an invalid net= attrib [net=%s]\n
- Missing : in net= attrib\n, value);
- g_free (value);
- return NULL;
-}
-
-net_name = s_netattrib_extract_netname (value);
-
-start_of_pinlist = char_ptr + 1;
-current_pin = strtok (start_of_pinlist, DELIMITERS);
-while (current_pin) {
- if (strcmp (current_pin, wanted_pin) == 0) {
-g_free (return_value);
-return net_name;
- }
- current_pin = strtok (NULL, DELIMITERS);
-}
-
-g_free (value);
+if (net_name != NULL)
+ return net_name;
}
- return return_value;
+ return NULL;
}
char *s_netattrib_return_netname(TOPLEVEL * pr_current, OBJECT * o_current,
--
1.7.4.1
From 68eeaa6103d851371b1264f24eab10a126fa97ad Mon Sep 17 00:00:00 2001
From
Re: gEDA-user: gschem usability: expand the component tree after filtering
On Thu, Apr 07, 2011 at 04:59:12PM +0200, Felix Ruoff wrote: I have also done a feature request for this patch at https://bugs.launchpad.net/pcb/+bug/753643. Hope, some of you like this feature, too and hope to get it accepted. Pushed with changed patch title (added gtk/hid). Thanks! -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Bug in gnetlist?
2011/4/5 Abhijit Kshirsagar abhijit...@gmail.com: I have multi-page schematics with a number of off-page connectors (realised using the symbols input-1.sym and input-2.sym) as described in the howto: [1]http://www.geda.seul.org/wiki/geda:na_howto#what_is_the_net_attribut e_used_for I noticed that if multiple net attributes happen to be present on the same net in the schematic, then the netlist seems to treat them as completely different nets and /ignores/ any interconnections. I suspect your case is covered by one of the bugs below: https://bugs.launchpad.net/geda/+bug/698395 https://bugs.launchpad.net/geda/+bug/698524 https://bugs.launchpad.net/geda/+bug/698570 Two of them were recently fixed in the git HEAD, so you can try to use development version of gnetlist to check. The remaining bug is harder to fix. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Un-translate a symbol?
On Sun, Mar 20, 2011 at 10:00:03AM -0400, Rob Butts wrote: I think I just figured out a way of doing it. I zoomed out, selected everything and moved it up and out. Then I will re-translate when I'm done with the changes. You can always select the translate action (shortcut et) and type in positive value instead of 0. For example 500 gives you translation of 5 default grid spaces to the right and top. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: subcircuit definition and channelised design
Dnia 2011-03-15 o godzinie 21:03 Bert Timmerman napisał(a): http://www.xs4all.nl/~ljh4timm/downloads/geda_sch2sym.tar.gz #!/bin/bash # gEDA - GNU Electronic Design Automation # geda_sch2sym.bsh # Copyright (C) 2007 Andrew Tan Says it all. It is also waiting for review here: https://bugs.launchpad.net/geda/+bug/698670 -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
2011/3/10 jpka jo...@kvidex.ru: Great! Thank you :) The last question is, when i find correct callback signature, passed arguments absolutely cannot be modified in any way, including adding random arguments, right? You can pass whatever you want (if it is known at callback registration time) as gpointer user_data. For example create a structure to hold pointers to everything you need in callback, then pass pointer to that structure as user_data. Of course the structure must not be allocated on stack. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
On Wed, Mar 09, 2011 at 11:39:36AM +, jpka wrote: Each signal handler has its required signature. This can be found in the GTK docs. Is there any success-story about it or example using docs IRL ? The success story would look like: 1) Look up the function ghid_button_connected() 2) the function creates a GtkButton b and calls: if (cb_func) gtk_signal_connect (GTK_OBJECT (b), clicked, GTK_SIGNAL_FUNC (cb_func), data); 3) Hence you look up signal clicked in GtkButton http://library.gnome.org/devel/gtk/unstable/GtkButton.html#GtkButton-clicked 4) There you find correct callback signature: void user_function (GtkButton *button, gpointer user_data); -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
2011/3/3 jpka jo...@kvidex.ru: There's no need to write a callback; default one will refresh the GtkTreeView widget to include your changes to the model. Please have a look at the attached patch. Thanks for help! Both codes work well in case of initial drawing radiobuttons instead of string, and result looks good. But in case of user input, when i apply this patch, i fall into several problems. 1. If i use patch 'as is', editing of grid values not work: my 'cb_edited_mm_or_mil' assumes PCB-CurrentGrid already changed to current before call: it uses PCB-Grid[PCB-CurrentGrid] = . , but when i use patch, editing value in table not switch PCB- CurrentGrid: it was tied to treeview row selection before and was done before editing (it was when i place cursor on needed row), but now it's not true: when i select row but not touch toggle button, PCB-CurrentGrid not updates. And anyway i prefer use radiobuttons here only for display but not for callback. BUT... Okay, I missed that part :) I would decouple changing the grid from editing the grid settings. The editing callbacks can query the path in the model and update PCB-Grid directly. The ultimate (but also most time consuming) would be to provide a custom implementation of GtkTreeModel that would map operations on the PCB-Grid and vice-versa. 2. If i try to restore my previous state when PCB-CurrentGrid updates not here g_signal_connect(renderer, toggled, (GCallback) cb_toggled_active, treeview); but here g_signal_connect(select, changed, G_CALLBACK(on_changed), select); (i.e. even work using cursor keys in treeview to select row) then i again and again fall into same hair-tearing problem as before this patch: ... Sorry for this long text. Each signal handler has its required signature. This can be found in the GTK docs. Same for the function passed to gtk_tree_view_foreach() etc. BTW2 - why do you store grid mm and mil spacings as strings?? Sorry i don't precisely understand you. The only place for strings in my code is in display/editing routines. Spacing is double PCB-Grid[PCB-CurrentGrid]; int PCB-GridStep[PCB-CurrentGrid]; regardless of mil or mm mode. I was asking why in the model you keep strings and not ints/floats? -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
Please check the attached patch - now everything in the model is updated
correctly.
--
Krzysztof Kościuszkiewicz
Simplicity is the ultimate sophistication -- Leonardo da Vinci
From 9e58163f910c9e24ecd6400b2dc81e158c86152b Mon Sep 17 00:00:00 2001
From: Krzysztof Kosciuszkiewicz k.kosciuszkiew...@gmail.com
Date: Fri, 4 Mar 2011 02:14:53 +0100
Subject: [PATCH 2/2] hid/gtk: further improvements to new grid config
---
src/const.h |4 +-
src/hid/gtk/gtkhid-gdk.c |2 +
src/hid/gtk/gui-config.c | 116 -
3 files changed, 76 insertions(+), 46 deletions(-)
diff --git a/src/const.h b/src/const.h
index 7b952f8..8062569 100644
--- a/src/const.h
+++ b/src/const.h
@@ -71,8 +71,8 @@
#define COOR_TO_MM 0.000254000
#define MM_TO_COOR 3937.007874
-#define COOR_TO_MIL 1. / 100 //added 02.02.2011 for uniformity
-#define MIL_TO_COOR 100. / 1
+#define COOR_TO_MIL 0.01 //added 02.02.2011 for uniformity
+#define MIL_TO_COOR 100.0
enum// Currently not used except mil and mm, but i will
{ // become happy if at least microns can be added.
MIL = 0, // Major code changes in some places need for this, though.
diff --git a/src/hid/gtk/gtkhid-gdk.c b/src/hid/gtk/gtkhid-gdk.c
index 55951e4..c78d1e8 100644
--- a/src/hid/gtk/gtkhid-gdk.c
+++ b/src/hid/gtk/gtkhid-gdk.c
@@ -132,6 +132,8 @@ ghid_draw_grid (void)
if (d==0) { // static grid without any check to min distance, zooming, etc,
// made by request
+if (g == 0)
+ return;
gridmode = 1;
pcbgrid = g;
} else {
diff --git a/src/hid/gtk/gui-config.c b/src/hid/gtk/gui-config.c
index e864da1..1cb82ae 100644
--- a/src/hid/gtk/gui-config.c
+++ b/src/hid/gtk/gui-config.c
@@ -1352,45 +1352,74 @@ enum
NUM_COLS
} ;
-void cb_edited_mm_or_mil(GtkCellRendererText *cell, gchar *path, gchar *text,
- GtkTreeView *treeview) {
- double d;
- GtkListStore *store;
- GtkTreeIter iter;
- int units;
- store = GTK_LIST_STORE (gtk_tree_view_get_model (treeview));
- gtk_tree_model_get_iter_from_string (GTK_TREE_MODEL (store), iter, path);
- units = (GPOINTER_TO_INT (g_object_get_data (G_OBJECT (cell), column)) == 0) ? MM : MIL;
-printf(%d\n,units);
- d = c_strtod(text);
- if (d0) {d=0;}
- PCB-Grid[PCB-CurrentGrid] = (units) ? (d * MM_TO_COOR) : (d * MIL_TO_COOR);
- if (Settings.DrawGrid) UpdateAll ();
- ghid_set_status_line_label();
- gtk_list_store_set (store, iter, COL_GRID_MM, (units) ? (c_dtostr(d)) : (c_dtostr(d*MIL_TO_MM)), -1);
- gtk_list_store_set (store, iter, COL_GRID_MIL, (units) ? (c_dtostr(d*MM_TO_MIL)) : (c_dtostr(d)), -1);
-}
-
-
-void cb_edited_step(GtkCellRendererText *cell, gchar *path, gchar *text, GtkTreeView *treeview) {
- int i;
- GtkListStore *store;
- GtkTreeIter iter;
- store = GTK_LIST_STORE (gtk_tree_view_get_model (treeview));
- gtk_tree_model_get_iter_from_string (GTK_TREE_MODEL (store), iter, path);
- i=(int)c_strtod(text);
- if (i0) {i=0;}
-if (i==1) {i=2;}
- if (i100) {i=100;}
- PCB-GridStep[PCB-CurrentGrid] = i;
- if (Settings.DrawGrid) UpdateAll ();
-// ghid_set_status_line_label();
- gtk_list_store_set (store, iter, COL_GRIDSTEP, i, -1);
+void cb_edited_mm_or_mil (GtkCellRendererText *cell,
+ gchar *path,
+ gchar *text,
+ GtkTreeView *treeview)
+{
+ GtkTreeModel *model = gtk_tree_view_get_model (treeview);
+ GtkTreePath *treePath = gtk_tree_path_new_from_string (path);
+ int gridNum = CLAMP (gtk_tree_path_get_indices (treePath)[0],
+ 0,
+ MAX_USER_GRIDS-1);
+ gboolean unitsMm;
+ GtkTreeIter iter;
+ double d;
+
+ unitsMm = GPOINTER_TO_INT (g_object_get_data (G_OBJECT (cell), column)) == COL_GRID_MM;
+ d = MAX (0, c_strtod(text));
+ PCB-Grid[gridNum] = (unitsMm) ? (d * MM_TO_COOR) : (d * MIL_TO_COOR);
+
+ if (gridNum == PCB-CurrentGrid) {
+if (Settings.DrawGrid)
+ UpdateAll ();
+ghid_set_status_line_label();
+ }
+
+ gtk_tree_model_get_iter (model, iter, treePath);
+ /* two separate calls because c_dtostr() uses static buffer */
+ gtk_list_store_set (GTK_LIST_STORE (model), iter,
+ COL_GRID_MM, unitsMm ? c_dtostr(d) : c_dtostr(d*MIL_TO_MM),
+ -1);
+ gtk_list_store_set (GTK_LIST_STORE (model), iter,
+ COL_GRID_MIL, unitsMm ? c_dtostr(d*MM_TO_MIL) : c_dtostr(d),
+ -1);
+ gtk_tree_model_row_changed (model, treePath, iter);
+ gtk_tree_path_free (treePath);
+}
+
+
+void cb_edited_step (GtkCellRendererText *cell,
+ gchar *path,
+ gchar *text,
+ GtkTreeView *treeview)
+{
+ GtkTreeModel *model = gtk_tree_view_get_model (treeview);
+ GtkTreePath *treePath = gtk_tree_path_new_from_string (path);
+ int gridNum = CLAMP (gtk_tree_path_get_indices (treePath)[0],
+ 0
Re: gEDA-user: Please test new grids for GTK PCB
On Mon, Feb 28, 2011 at 10:48:50AM +, jpka wrote:
Krzysztof Kościuszkiewicz wrote:
* to have GtkTreeView updated you need to emit
row-changed signal, like:
gtk_tree_model_row_changed (GTK_TREE_MODEL (model), path, iter);
I find it, but unfortunately i can't write callback function correct
(don't know or even can't imagine which arguments i must pass, i need
complete
example)
There's no need to write a callback; default one will refresh the
GtkTreeView widget to include your changes to the model.
Please have a look at the attached patch.
BTW - selecting a grid that does have 0 spacing segfaults pcb.
BTW2 - why do you store grid mm and mil spacings as strings??
--
Krzysztof Kościuszkiewicz
Simplicity is the ultimate sophistication -- Leonardo da Vinci
From 73574b2f6d6736257bf22c9683ba2b9a45196a03 Mon Sep 17 00:00:00 2001
From: Krzysztof Kosciuszkiewicz k.kosciuszkiew...@gmail.com
Date: Thu, 3 Mar 2011 01:12:06 +0100
Subject: [PATCH] hid/gtk: improvements to grid preferences window
---
src/hid/gtk/gui-config.c | 76 ++---
1 files changed, 37 insertions(+), 39 deletions(-)
diff --git a/src/hid/gtk/gui-config.c b/src/hid/gtk/gui-config.c
index 9eacfc0..e864da1 100644
--- a/src/hid/gtk/gui-config.c
+++ b/src/hid/gtk/gui-config.c
@@ -1394,42 +1394,42 @@ void dummy (void) {
}
-void on_changed(GtkWidget *widget)
-//void on_changed(GtkWidget *widget, gpointer treeview)
-{
- GtkTreeIter iter;
- GtkTreeModel *model;
- GtkTreePath *path;
- gint *indexes;
- //GtkListStore *store;
- int i;
-
- if (gtk_tree_selection_get_selected(
- GTK_TREE_SELECTION(widget), model, iter)) {
-path = gtk_tree_model_get_path(model, iter);
-indexes = gtk_tree_path_get_indices(path);
-i = indexes[0];
-if (i0) i = 0;
-if (i(MAX_USER_GRIDS-1)) i = MAX_USER_GRIDS-1;
-//g_print(Row number %i selected.\n, i); /* FIXME remove after debug */
- PCB-CurrentGrid = i;
-
- if (Settings.DrawGrid) UpdateAll ();
- ghid_set_status_line_label();
-
-/* FIXME */ g_print(Please fixme: \n
- here's word 'Yes' must be placed at 'Current?' column and (i) line, \n
- but i can't find a way to do it after a day fighting with gtk and hair tearing...\n);
-
-// store = GTK_LIST_STORE (gtk_tree_view_get_model (GTK_TREE_VIEW (treeview)));
-// gtk_tree_model_get_iter_from_string (GTK_TREE_MODEL (store), iter, path);
-// gtk_list_store_set (store, iter, COL_GRIDCURRENT, Yes, -1);
-
+static gboolean refresh_gridcurrent (GtkTreeModel *model,
+ GtkTreePath *path,
+ GtkTreeIter *iter,
+ gpointer data)
+{
+ GtkTreePath *selectedPath = (GtkTreePath*) data;
+ gtk_list_store_set (GTK_LIST_STORE (model),
+ iter,
+ COL_GRIDCURRENT,
+ gtk_tree_path_compare (path, selectedPath) == 0 ? TRUE : FALSE,
+ -1);
+ gtk_tree_model_row_changed (model, path, iter);
+ return FALSE;// continue iterating
+}
+
+
+static void cb_toggled_active (GtkCellRendererToggle *cell,
+ gchar *path_string,
+ GtkTreeView *view)
+{
+ GtkTreePath *path = gtk_tree_path_new_from_string (path_string);
+ gint *indices = gtk_tree_path_get_indices (path);
+ int i = CLAMP (indices[0], 0, MAX_USER_GRIDS-1);
+ if (PCB-CurrentGrid != i) {
+PCB-CurrentGrid = i;
+if (Settings.DrawGrid)
+ UpdateAll ();
+ghid_set_status_line_label();
+gtk_tree_model_foreach (gtk_tree_view_get_model (view),
+refresh_gridcurrent,
+path);
}
+ gtk_tree_path_free (path);
}
-
static GtkWidget *create_grid_treeview (void) {
GtkCellRenderer *renderer;
GtkTreeView *treeview;
@@ -1439,7 +1439,7 @@ static GtkWidget *create_grid_treeview (void) {
int i;
char /*y[256],*/y2[256]; /* FIXME remove this ugly stuff */
- store = gtk_list_store_new (NUM_COLS, G_TYPE_STRING, G_TYPE_STRING, G_TYPE_UINT, G_TYPE_STRING);
+ store = gtk_list_store_new (NUM_COLS, G_TYPE_STRING, G_TYPE_STRING, G_TYPE_UINT, G_TYPE_BOOLEAN);
for (i=0; iMAX_USER_GRIDS; i++) {
// strcpy(y, c_dtostr((PCB-Grid[i])*COOR_TO_MM));
strcpy(y2, c_dtostr((PCB-Grid[i]*COOR_TO_MIL)));
@@ -1449,12 +1449,18 @@ static GtkWidget *create_grid_treeview (void) {
// COL_GRID_MIL, c_dtostr((PCB-Grid[i])*COOR_TO_MIL), - not work! :(
COL_GRID_MIL, y2, // work but ugly...
COL_GRIDSTEP, PCB-GridStep[i],
- COL_GRIDCURRENT, (i == PCB-CurrentGrid) ? Yes:,
+ COL_GRIDCURRENT, (i == PCB-CurrentGrid) ? TRUE : FALSE,
-1);
}
treeview = GTK_TREE_VIEW (gtk_tree_view_new_with_model (GTK_TREE_MODEL(store)));
g_object_unref (store);
+ renderer = gtk_cell_renderer_toggle_new
Re: gEDA-user: What stops PCB autorouter/toporouter from working right?
On Thu, Feb 24, 2011 at 11:50:55PM +, Peter Clifton wrote: We have a winner from git bisect: 089fbaf59c78fe75475db737e7e2827cd745d570 is the first bad commit Git bisect can do wonders :) It seems that for loops in src/autoroute.c:BreakManyEdges() call directionIncrement() but ignore the return value. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open Collector Error Checking
On Mon, Feb 14, 2011 at 02:39:38PM +0100, Karl Hammar wrote: To change this habit, was one of the motivations for the with the switch from sourceforge to launchpad (hint, hint...) At least patches can be more easily retrieved on the trackers. I understand the hint etc., but we should have one or more person that could actually *commit* thoose simple fixes, either at the official or a seperate site. I could possible set up a git repo for thoose simple fixes. Do anyone want to join? In what way a git repo would be better than separate patches? For testing? Each separate set of changes would still have to be reviewed, and I suppose that (together with the discussion/suggestion of improvements) constitutes the main effort for accepting changes to the main source tree. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open Collector Error Checking
On Fri, Feb 11, 2011 at 08:38:47AM +0100, Karl Hammar wrote: ERROR: Pin(s) with pintype 'open collector': U70:2 U70:4 are connected by net 'unnamed_net204' to pin(s) with pintype 'open collector': U70:2 U70:4 ... Attached patch corrects that. Can you file the patch on the tracker so it isn't forgotten? http://bugs.launchpad.net/geda/+filebug ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
2011/1/27 Kai-Martin Knaak kn...@iqo.uni-hannover.de: Maybe something much simpler: Define a range of zoom scales, were the cues keep their size relative to the screen. That way, they'd shrink when zoomed way out. On the other end of the zoom scale, the cues should never get smaller than the width of a net. Zoom-dependent scaling is already applied to selection handles and that does not work very well... https://bugs.launchpad.net/geda/+bug/698785 I would keep the unconnected net cues size constant in WORLD coordinates, and selection handles size constant in SCREEN coordinates. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: numslots=0
On Sun, Feb 06, 2011 at 08:47:05PM +0300, Vladimir Zhbanov wrote: On Sat, Feb 05, 2011 at 05:07:06AM +0100, Kai-Martin Knaak wrote: The master attribute list explicitly requires all symbols to contain an numslots attribute, even if slotting does not apply at all. IIRC, gnetlist does not care about missing numslots=0 since quite some time. But gsymcheck does care (at least in 1.6.1 which I'm using yet. And I've found no changes for the program in the main git repository since that version). ... There is also 'gsymfix' which should be used to fix some attributes issues. And in that case it also should be fixed. (It should be fixed anyway because it wrongly sets the XXX value for missed attributes that violates requirements of the 'Master Attributes List' document e.g. to set footprint=unknown for symbols without known footprint and so on.) Please file a bug so these findings are not lost. https://bugs.launchpad.net/geda/+filebug -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
2011/1/24 DJ Delorie d...@delorie.com: Perhaps we need a concept of net with more than one name ? We'd have to define rules for DRC to follow. Multiple names for a single wire - this sounds like a good solution. Each gnetlist backend could then provide a net-unification function to map multiple input net names to single/multiple output netnames. DRC will be tricky, yes :) -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Visual cue of zero length pin endpoint
All, I'd like to get opinions on the drawing of visual cues (endpoints) of pins. Curently: * Zero length pins have a short line drawn at endpoint * Pins with rotation other than 0, 90, 180 and 270 have nothing One proposal would be to reuse endpoint marker of unconnected nets (same size shape). Another is to keep the current marker for longer pins, and below some configured length use a box-shaped cue (same as unconnected net). Opinions, other proposals? Bug report: https://bugs.launchpad.net/geda/+bug/706552 Related discussion: https://bugs.launchpad.net/geda/+bug/705397 -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On Sun, Jan 23, 2011 at 09:25:53AM -0800, Colin D Bennett wrote: However, after some investigation as to why I wasn't getting the right rats in 'pcb' after a gsch2pcb import, I realized that connecting two nets in gschem (using a power symbol and/or an I/O port symbol connected with a net line) does not create that connection in the netlist! I think the gnetlist drc did emit a warning due to this, but I did not understand the cause... This sounds like related to this bug and its duplicates: https://bugs.launchpad.net/geda/+bug/698395 -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Bugs, warts and feature requests (5)
2011/1/12 Peter TB Brett pe...@peter-b.co.uk: How about: Like the drop-down list of default attributes the add Attribute line presents. netname footprint value refdes source ... I guess, this order was determined by intuition of a developer long time ago. Suggestion: take this list as a default order for the list of attributes. Make this default configurable in gschemrc. Ouups, this is another feature request ;^) It's configurable in system-gschemrc. Sorting request doesn't seem unreasonable. Sorting could be done to present attributes in the same order as defined in system-gschemrc. That might be a good first attempt. If somebody wants a different ordering for another workflow, just supply different ordering in rc file. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Bugs, warts and feature requests (5)
2011/1/12 Kai-Martin Knaak kn...@iqo.uni-hannover.de: • gsch2pcb wart: The net of input/output symbols is evaluated from its refdes. Consequently, the restrictions to refdeses apply: No uncapitalized suffix, no hyphen, etc. Proposal: evaluate the net from dedicated attributes. E.g. in-net=, out-net= What would be the semantics of these attributes when attached to some other symbol? Should they be attached to symbol or to individual pins? What about handling in different backends? I would say the existing attribute/backend/semantics interaction matrix is complex enough to require full analysis of the implications of yet another attribute being added... -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem usability: expand the component tree after filtering
2011/1/4 kai-martin knaak k...@familieknaak.de: +1 Every click that can be avoided for common tasks adds to the productivity. I hope, this patch will be accepted. Thanks to cooperation with Peter B it is already accepted. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gschem usability: expand the component tree after filtering
All, I found it annoying that I need to click through the whole component tree after filtering the symbol file names. For some time I've been running my copy with the change that expands the tree after the filtering by name is done. This saves 1+ clicks in the most common use-case: add a known symbol to the diagram. The patch is here: https://sourceforge.net/tracker/?func=detailaid=3149995group_id=161080atid=818428 Best regards, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: pcb opengl: ps export malformed
Hello, It seems in Peter's pcb branch ps export does not work as intended. For a 2-layer board both front and back copper layers are exported twice, as indicated by console output during export. When using multifile export the *.front.ps and *.back.ps files look like the assembly drawings, and *assembly.ps files contain image of an empty board. If using a single-file output two additional pages are printed with same effect (empty assembly drawings). In the original pcb (git HEAD) the problem is not present. Best regards, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Garbage drawn outside of pcb board area
On Sat, Aug 28, 2010 at 04:18:38AM +0100, Peter Clifton wrote: On Thu, 2010-06-10 at 00:16 +0200, Krzysztof Kościuszkiewicz wrote: On Tue, Jun 08, 2010 at 09:14:12PM +0100, Peter Clifton wrote: You were right - it seems the driver is at fault... It wasn't always like that so I'll try to track down what change broke the rendering. It might not be the driver's fault if I'm doing evil things like making GL calls out of valid context setup. (Which I was). You were right, I have to retract the statement about the driver's fault. I got the hint from this FAQ: http://www.opengl.org/resources/faq/technical/clipping.htm#0080 The attached patch fixes the issue for me. I finally got a chance to look at this - sorry it took so long! I'm not sure it is correct.. the expose event doesn't necessarily cover the whole drawing area, so we only actually want to glClear the areas being drawn. I still wonder if this relates to a driver bug. Perhaps you could try a clean checkout of my latest before_pours branch (just pushed). I've spent a little time refactoring the code, and have put in a few (temporary) hacks to avoid various GL calls which were being made out of proper context setup. I did try the fresh checkout and the annoying effect is now gone. Good work - thanks! Best regards, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Garbage drawn outside of pcb board area
On Tue, Jun 08, 2010 at 09:14:12PM +0100, Peter Clifton wrote: You were right - it seems the driver is at fault... It wasn't always like that so I'll try to track down what change broke the rendering. It might not be the driver's fault if I'm doing evil things like making GL calls out of valid context setup. (Which I was). The patch I sent should (as far as I know) avoid the offending drawing calls, but it does not 100% guarantee that nothing else calls a drawing routine directly when it shouldn't. I assume from your response that the patch didn't get rid of the rubbish on screen. I'm not sure what to suggest trying next. Perhaps I could produce a patch which extends the locking to every drawing call, just in case something slipping past. No, the patch did not fix the rubbish issue, just the segfault. We could look at whether it is possible to trim down various drawing calls / methods, and see at what point the rubbish goes away. If this is present even for empty boards, then there aren't many things that get drawn (cursor, selection, background?) This could be a viable option. Is it present for all boards, (including blank), or does it depend on what you have on the board? It is present for all boards I've tested, including blank. It manifests itself only in the area not occupied by the board, or outside the drawing area. If I zoom in and the full window is occupied with the board, I can see no garbage. Best regards, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Garbage drawn outside of pcb board area
On Tue, Jun 08, 2010 at 09:14:12PM +0100, Peter Clifton wrote: You were right - it seems the driver is at fault... It wasn't always like that so I'll try to track down what change broke the rendering. It might not be the driver's fault if I'm doing evil things like making GL calls out of valid context setup. (Which I was). You were right, I have to retract the statement about the driver's fault. I got the hint from this FAQ: http://www.opengl.org/resources/faq/technical/clipping.htm#0080 The attached patch fixes the issue for me. Best regards, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci diff --git a/src/hid/gtk/gui-output-events.c b/src/hid/gtk/gui-output-events.c index 1fa2640..2bf934d 100644 --- a/src/hid/gtk/gui-output-events.c +++ b/src/hid/gtk/gui-output-events.c @@ -1802,7 +1802,9 @@ ghid_port_drawing_area_expose_event_cb (GtkWidget * widget, glStencilMask (~0); glClearStencil (0); + glDisable (GL_SCISSOR_TEST); glClear (GL_COLOR_BUFFER_BIT | GL_STENCIL_BUFFER_BIT); + glEnable (GL_SCISSOR_TEST); hidgl_reset_stencil_usage (); /* Disable the stencil test until we need it - otherwise it gets dirty */ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Segfault on startup and garbage drawn outside of pcb board area
On Tue, Jun 08, 2010 at 12:41:50AM +0100, Peter Clifton wrote: On Tue, 2010-06-08 at 01:05 +0200, Krzysztof Kościuszkiewicz wrote: I have noticed two bugs with recent git versions of gl-enabled pcb (6507083b0401e0). 1) Garbage is displayed outside of board area. Try this patch, and see if it changes the behaviour / helps / breaks things further. Thanks, this does the trick. I haven't been able to get the segfault with your patch. Best regards, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Segfault on startup and garbage drawn outside of pcb board area
On Tue, Jun 08, 2010 at 12:30:46AM +0100, Peter Clifton wrote: On Tue, 2010-06-08 at 01:05 +0200, Krzysztof Kościuszkiewicz wrote: 1) Garbage is displayed outside of board area. What graphics card / driver are you using Radeon R300 + Mesa? This bug is almost certainly going to turn out to be driver dependent. I have ATI Mobility Radeon X700 on PCIe. Since you are using a mesa based driver, try with: LIBGL_ALWAYS_SOFTWARE=1 pcb ... This one removes the garbage. and or LIBGL_ALWAYS_INDIRECT=1 pcb ... This one does not... You were right - it seems the driver is at fault... It wasn't always like that so I'll try to track down what change broke the rendering. Thanks! -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Segfault on startup and garbage drawn outside of pcb board area
All,
I have noticed two bugs with recent git versions of gl-enabled pcb
(6507083b0401e0).
1) Garbage is displayed outside of board area.
Contents are flashing annoyingly (black/background color) on every mouse
move event within the PCB drawing area. Contents of the drawing area
not occupied by the board depend on what was displayed in other windows,
ie after switching virtual desktops content from previous application
can be seen in the background.
Output of glxinfo and screenshot after rotating an empty board in 3d
space are attached.
2) pcb sometimes segfaults in glEnable() during startup.
I'm using tiling WM and in some cases pcb segfaults during startup.
I suspect this depends on the order of X events being sent to the
application. Stack trace is attached. If needed I can do more
debugging/build with debug libs, but I'm no X expert :)
Should I create items for these in the bug tracker?
Anybody observed anything similar?
Best regards,
--
Krzysztof Kościuszkiewicz
Simplicity is the ultimate sophistication -- Leonardo da Vinci
(gdb) run
Starting program: /home/kokr/geda/bin/pcb
[Thread debugging using libthread_db enabled]
[New Thread 0xb68a2aa0 (LWP 15078)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb68a2aa0 (LWP 15078)]
0xb6dec616 in glEnable () from /usr/lib/libGL.so.1
(gdb) bt
#0 0xb6dec616 in glEnable () from /usr/lib/libGL.so.1
#1 0x081194f7 in ghid_show_crosshair (show=0) at
hid/gtk/gui-output-events.c:614
#2 0x0811a129 in ghid_port_window_leave_cb (widget=0x829d5e0, ev=0x83fc148,
out=0x81db6a0)
at hid/gtk/gui-output-events.c:2302
#3 0xb74ee374 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#4 0x0829d5e0 in ?? ()
#5 0x083fc148 in ?? ()
#6 0x081db6a0 in ?? ()
#7 0xb70765ba in ?? () from /usr/lib/libgobject-2.0.so.0
#8 0x0002 in ?? ()
#9 0x0008 in ?? ()
#10 0xb6cf73c0 in ?? () from /lib/i686/cmov/libc.so.6
#11 0xb70925a4 in g_type_check_instance_is_a () from
/usr/lib/libgobject-2.0.so.0
#12 0xb7077f62 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#13 0xb708c3a8 in ?? () from /usr/lib/libgobject-2.0.so.0
#14 0x08410430 in ?? ()
#15 0xbfd00c24 in ?? ()
#16 0x0002 in ?? ()
#17 0x0843d4f0 in ?? ()
#18 0xbfd00c10 in ?? ()
#19 0x0843d4f0 in ?? ()
#20 0xbfd00bc8 in ?? ()
#21 0xb707a272 in g_object_ref () from /usr/lib/libgobject-2.0.so.0
#22 0xb708d5b8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#23 0xb708dba6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#24 0xb760aafe in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#25 0x0829d5e0 in ?? ()
#26 0x002d in ?? ()
#27 0x in ?? ()
(gdb) fr 2
#2 0x0811a129 in ghid_port_window_leave_cb (widget=0x829d5e0, ev=0x83fc148,
out=0x81db6a0)
at hid/gtk/gui-output-events.c:2302
2302 ghid_show_crosshair (FALSE);
(gdb) p widget
$6 = (GtkWidget *) 0x829d5e0
(gdb) p *widget
$7 = {object = {parent_instance = {g_type_instance = {g_class = 0x83f31c8},
ref_count = 4,
qdata = 0x84129d0}, flags = 73664}, private_flags = 3584, state = 0 '\0',
saved_state = 0 '\0', name = 0x0, style = 0x8228458, requisition = {width =
0, height = 0},
allocation = {x = 0, y = 0, width = 547, height = 806}, window = 0x84110a8,
parent = 0x8232778}
(gdb) p ev
$8 = (GdkEventCrossing *) 0x83fc148
(gdb) p *ev
$9 = {type = GDK_LEAVE_NOTIFY, window = 0x84110a8, send_event = 0 '\0',
subwindow = 0x0,
time = 248194684, x = 388, y = 328, x_root = 541, y_root = 380, mode =
GDK_CROSSING_NORMAL,
detail = GDK_NOTIFY_ANCESTOR, focus = 0, state = 16}
(gdb) p out
$10 = (GHidPort *) 0x81db6a0
(gdb) p *out
$11 = {top_window = 0x8225850, drawing_area = 0x829d5e0, trackball = 0x8408000,
pixmap = 0x8403480,
mask = 0x0, drawable = 0x8403480, width = 547, height = 806, glconfig =
0x81fdc78,
trans_lines = 0, bg_color = {pixel = 15066597, red = 58853, green = 58853,
blue = 58853},
offlimits_color = {pixel = 13421772, red = 52428, green = 52428, blue =
52428}, grid_color = {
pixel = 0, red = 0, green = 0, blue = 0}, colormap = 0x8200818, X_cursor =
0x8426368,
X_cursor_shape = GDK_LEFT_PTR, has_entered = 1, panning = 0, zoom =
1096.892138939671,
view_x0 = 0, view_y0 = 0, view_width = 60, view_height = 50, view_x =
116400,
view_y = 98400, x_crosshair = 116000, y_crosshair = 98000}
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info
Re: gEDA-user: [PATCH] Add line end to line type dialog
Armin, On Sun, Apr 25, 2010 at 02:59:22AM +0200, Armin Faltl wrote: Is it correct, that round linestyle is default because of its superior mechanical/thermal properties? - I definitely read this for pads and it's easy to imagine, that a corner more easily delaminates than a round edge. In the light of this, a small bend corner style would be cool ;-) The discussion was about line style in gschem, not pcb :) Best regards, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [PATCH] Add line end to line type dialog
, END_ROUND, END_ERASE} OBJECT_END;
/*! \brief line style of lines, rect, circles, arcs */
typedef enum {TYPE_SOLID, TYPE_DOTTED, TYPE_DASHED, TYPE_CENTER, TYPE_PHANTOM,
TYPE_ERASE} OBJECT_TYPE;
--
1.6.2
--
Krzysztof Kościuszkiewicz
Simplicity is the ultimate sophistication -- Leonardo da Vinci
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PATCH] Add line end to line type dialog
On Thu, Apr 22, 2010 at 03:39:22PM +0100, Peter Clifton wrote: On Thu, 2010-04-22 at 15:32 +0200, Krzysztof Kościuszkiewicz wrote: * Add END_ERASE to OBJECT_END type in libgeda. Why? I think I see what this patch is attempting to do though.. although the above description really doesn't explain the full story! I'm not personally convinced that there is a strong need for customisable line end types - but if we do want them.. having a dummy type END_ERASE is misleading. It really isn't a good name for a don't change anything place-holder, certainly it isn't a valid line-end type as the others are. I agree, though this is directly derived from implementation of TYPE_* enums. I guess this excuse is not good enough :) gtk_option_menu and friends are deprecated, and should not be used in new code.. I appreciate you may be copying from existing gschem code, but that needs to be re-written, rather than copied. (Re-writing that first and copying the new code reduces the size of the task someone will eventually have with GTK 3.0). FWIW, a brief scan suggests there is a lot more deprecated / poor coding style in the code which you've copied. You're right, this was done without too much thought. I'll try to rewrite this and resubmit - unless you think that the core of this patch (having an option to edit line end style) is moot... Best regards, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [PATCH 0/2] Cleanup of line type handling in dialog code
As discussed before - cleaning parts of the old code dialog code first. Please comment on style/implementation issues. Krzysztof Kosciuszkiewicz (2): gschem: line type edit dialog now uses GtkComboBox libgeda: remove TYPE_ERASE from OBJECT_TYPE enum gschem/src/x_dialog.c| 212 +++--- libgeda/include/libgeda/struct.h |2 +- libgeda/src/o_arc_basic.c|6 - libgeda/src/o_box_basic.c|6 - libgeda/src/o_circle_basic.c |6 - libgeda/src/o_line_basic.c |6 - libgeda/src/o_path_basic.c |6 - utils/src/convert_sym.c |2 +- 8 files changed, 131 insertions(+), 115 deletions(-) -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [PATCH 1/2] gschem: line type edit dialog now uses GtkComboBox
(); - gtk_option_menu_set_menu(GTK_OPTION_MENU(optionmenu), - create_menu_linetype (w_current)); - gtk_table_attach_defaults(GTK_TABLE(table), optionmenu, + type_combo = create_line_type_combo(); + gtk_table_attach_defaults(GTK_TABLE(table), type_combo, 1,2,0,1); width_entry = gtk_entry_new(); @@ -980,7 +1026,7 @@ void line_type_dialog (GSCHEM_TOPLEVEL *w_current) gtk_table_attach_defaults(GTK_TABLE(table), width_entry, 1,2,1,2); - gtk_signal_connect(GTK_OBJECT (optionmenu), changed, + gtk_signal_connect(GTK_OBJECT (type_combo), changed, (GtkSignalFunc) line_type_dialog_linetype_change, line_type_data); @@ -999,7 +1045,7 @@ void line_type_dialog (GSCHEM_TOPLEVEL *w_current) /* populate the data structure */ line_type_data-dialog = dialog; line_type_data-width_entry = width_entry; - line_type_data-line_type= optionmenu; + line_type_data-line_type= GTK_COMBO_BOX (type_combo); line_type_data-length_entry = length_entry; line_type_data-space_entry = space_entry; @@ -1010,7 +1056,7 @@ void line_type_dialog (GSCHEM_TOPLEVEL *w_current) width, length, space); /* calling it once will set the dash space/length activity */ - line_type_dialog_linetype_change(optionmenu, line_type_data); + line_type_dialog_linetype_change(type_combo, line_type_data); gtk_widget_grab_focus(width_entry); gtk_widget_show_all (dialog); -- 1.6.2 -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [PATCH 2/2] libgeda: remove TYPE_ERASE from OBJECT_TYPE enum
TYPE_ERASE was not documented in file format spec and not used in the code.
---
libgeda/include/libgeda/struct.h |2 +-
libgeda/src/o_arc_basic.c|6 --
libgeda/src/o_box_basic.c|6 --
libgeda/src/o_circle_basic.c |6 --
libgeda/src/o_line_basic.c |6 --
libgeda/src/o_path_basic.c |6 --
utils/src/convert_sym.c |2 +-
7 files changed, 2 insertions(+), 32 deletions(-)
diff --git a/libgeda/include/libgeda/struct.h b/libgeda/include/libgeda/struct.h
index fef18c7..232142a 100644
--- a/libgeda/include/libgeda/struct.h
+++ b/libgeda/include/libgeda/struct.h
@@ -81,7 +81,7 @@ typedef enum { F_OPEN_RC = 1,
typedef enum {END_NONE, END_SQUARE, END_ROUND} OBJECT_END;
/*! \brief line style of lines, rect, circles, arcs */
-typedef enum {TYPE_SOLID, TYPE_DOTTED, TYPE_DASHED, TYPE_CENTER, TYPE_PHANTOM,
TYPE_ERASE} OBJECT_TYPE;
+typedef enum {TYPE_SOLID, TYPE_DOTTED, TYPE_DASHED, TYPE_CENTER, TYPE_PHANTOM}
OBJECT_TYPE;
/*! \brief fill style of objects like cirle, rect, path */
typedef enum {FILLING_HOLLOW, FILLING_FILL, FILLING_MESH, FILLING_HATCH,
FILLING_VOID} OBJECT_FILLING;
diff --git a/libgeda/src/o_arc_basic.c b/libgeda/src/o_arc_basic.c
index 761a347..60ffce7 100644
--- a/libgeda/src/o_arc_basic.c
+++ b/libgeda/src/o_arc_basic.c
@@ -677,12 +677,6 @@ void o_arc_print(TOPLEVEL *toplevel, FILE *fp, OBJECT
*o_current,
case(TYPE_PHANTOM):
outl_func = o_arc_print_phantom;
break;
-
-case(TYPE_ERASE):
- /* Unused for now, print it solid */
- length = -1; space = -1;
- outl_func = o_arc_print_solid;
- break;
}
if((space == 0) || (length == 0)) {
diff --git a/libgeda/src/o_box_basic.c b/libgeda/src/o_box_basic.c
index c99ccde..77e9259 100644
--- a/libgeda/src/o_box_basic.c
+++ b/libgeda/src/o_box_basic.c
@@ -733,12 +733,6 @@ void o_box_print(TOPLEVEL *toplevel, FILE *fp, OBJECT
*o_current,
case(TYPE_PHANTOM):
outl_func = o_box_print_phantom;
break;
-
-case(TYPE_ERASE):
- /* Unused for now, print it solid */
- length = -1; space = -1;
- outl_func = o_box_print_solid;
- break;
}
if((length == 0) || (space == 0)) {
diff --git a/libgeda/src/o_circle_basic.c b/libgeda/src/o_circle_basic.c
index c9b9b68..b6f0a1f 100644
--- a/libgeda/src/o_circle_basic.c
+++ b/libgeda/src/o_circle_basic.c
@@ -641,12 +641,6 @@ void o_circle_print(TOPLEVEL *toplevel, FILE *fp, OBJECT
*o_current,
case(TYPE_PHANTOM):
outl_func = o_circle_print_phantom;
break;
-
-case(TYPE_ERASE):
- /* Unused for now print it solid */
- length = -1; space = -1;
- outl_func = o_circle_print_solid;
- break;
}
if((length == 0) || (space == 0)) {
diff --git a/libgeda/src/o_line_basic.c b/libgeda/src/o_line_basic.c
index b35a705..47b1ea1 100644
--- a/libgeda/src/o_line_basic.c
+++ b/libgeda/src/o_line_basic.c
@@ -592,12 +592,6 @@ void o_line_print(TOPLEVEL *toplevel, FILE *fp, OBJECT
*o_current,
case(TYPE_PHANTOM):
outl_func = o_line_print_phantom;
break;
-
-case(TYPE_ERASE):
- /* Unused for now, print it solid */
- length = -1; space = -1;
- outl_func = o_line_print_solid;
- break;
}
if((length == 0) || (space == 0)) {
diff --git a/libgeda/src/o_path_basic.c b/libgeda/src/o_path_basic.c
index 1e3b7dd..9e87c38 100644
--- a/libgeda/src/o_path_basic.c
+++ b/libgeda/src/o_path_basic.c
@@ -960,12 +960,6 @@ void o_path_print(TOPLEVEL *toplevel, FILE *fp, OBJECT
*o_current,
case TYPE_PHANTOM:
outl_func = o_path_print_phantom;
break;
-
-case TYPE_ERASE:
- /* Unused for now, print it solid */
- length = -1; space = -1;
- outl_func = o_path_print_solid;
- break;
}
if((length == 0) || (space == 0)) {
diff --git a/utils/src/convert_sym.c b/utils/src/convert_sym.c
index fa61810..66cc281 100644
--- a/utils/src/convert_sym.c
+++ b/utils/src/convert_sym.c
@@ -81,7 +81,7 @@ extern int optind;
/* gEDA style enumerators */
typedef enum {END_NONE, END_SQUARE, END_ROUND} OBJECT_END;
typedef enum {TYPE_SOLID, TYPE_DOTTED, TYPE_DASHED, TYPE_CENTER,
- TYPE_PHANTOM, TYPE_ERASE} OBJECT_TYPE;
+ TYPE_PHANTOM} OBJECT_TYPE;
typedef enum {FILLING_HOLLOW, FILLING_FILL, FILLING_MESH, FILLING_HATCH,
FILLING_VOID} OBJECT_FILLING;
typedef enum {NORMAL_PIN, BUS_PIN} OBJECT_PINTYPE;
--
1.6.2
--
Krzysztof Kościuszkiewicz
Simplicity is the ultimate sophistication -- Leonardo da Vinci
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: Latex
On Sat, Feb 06, 2010 at 06:16:02PM +0100, Stefan Salewski wrote: I would prefer PS-Tricks instead of old METAPOST. Unfortunately PS-Tricks is postscript only. For both PS and PDF I would recommend using TikZ. Beamer (written by the same author) uses low level routines from TikZ to produce its pretty slides. Best regards, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Gerber Editor
Tony, It seems that you're missing the simpleparse module. You can install it using package manager of your distribution, or download it here: http://simpleparse.sourceforge.net/ Best regards, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GNUdino V0.2 (ARDUINO Board Designed using gEDA)
On Mon, Mar 23, 2009 at 12:39:23AM -0700, jeffrey_ant...@yahoo.com wrote: I have once more designed a revised version of GNUdino. Please check it and report errors if any. You have too small drill size (0.51mm or 15mil) on the axial diodes. Also the pads connected to polygons are missing thermals. You can also safely increase the copper annulus on the header connectors. This would help people making the board using toner transfer. I assume that some vias are there to allow soleding pieces of wire on the top side instead of making 2-layer board. To make that clear you can make the connections yourself on the component copper layer. Hope that helps, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [PATCH] gschem: Add name completion to attribute edit dialog
Replace deprecated GtkCombo with GtkComboEntryBox.
Make sure to use GtkEntryCompletion features compatible with GTK 2.8.
Signed-off-by: Krzysztof Kosciuszkiewicz k.kosciuszkiew...@gmail.com
---
gschem/src/x_attribedit.c | 29 ++---
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/gschem/src/x_attribedit.c b/gschem/src/x_attribedit.c
index 56f9be6..c08859f 100644
--- a/gschem/src/x_attribedit.c
+++ b/gschem/src/x_attribedit.c
@@ -294,7 +294,7 @@ void attrib_edit_dialog (GSCHEM_TOPLEVEL *w_current, OBJECT
*attr_obj, int flag)
GtkWidget *show_options;
GtkWidget *show_options_menu;
GtkWidget *glade_menuitem;
- GtkWidget *attrib_combo;
+ GtkWidget *attrib_combo_box_entry;
GtkWidget *attrib_combo_entry;
GtkWidget *value_entry;
GtkWidget *visbutton;
@@ -303,10 +303,10 @@ void attrib_edit_dialog (GSCHEM_TOPLEVEL *w_current,
OBJECT *attr_obj, int flag)
GtkWidget *addtocompsbutton;
GtkWidget *addtonetsbutton;
GtkWidget *overwritebutton;
+ GtkEntryCompletion *attrib_combo_entry_completion;
/* gschem specific */
GList *s_current = NULL;
- GList *combo_items = NULL;
char* string = NULL;
int nsel=0, i, len;
char *name = NULL;
@@ -380,13 +380,14 @@ void attrib_edit_dialog (GSCHEM_TOPLEVEL *w_current,
OBJECT *attr_obj, int flag)
(GtkAttachOptions) (GTK_FILL),
(GtkAttachOptions) (GTK_FILL), 0, 0);
- attrib_combo = gtk_combo_new ();
- gtk_table_attach (GTK_TABLE (table), attrib_combo, 1, 2, 0, 1,
+ attrib_combo_box_entry = gtk_combo_box_entry_new_text ();
+ attrib_combo_entry = gtk_bin_get_child(GTK_BIN(attrib_combo_box_entry));
+ gtk_table_attach (GTK_TABLE (table), attrib_combo_box_entry, 1, 2, 0, 1,
(GtkAttachOptions) (GTK_EXPAND | GTK_FILL),
(GtkAttachOptions) (0), 0, 0);
- attrib_combo_entry = GTK_COMBO (attrib_combo)-entry;
- gtk_widget_ref (attrib_combo_entry);
- gtk_object_set_data_full (GTK_OBJECT (aewindow), attrib_combo_entry,
attrib_combo_entry,
+ g_object_ref (attrib_combo_entry);
+ g_object_set_data_full (G_OBJECT (aewindow),
+ attrib_combo_entry, attrib_combo_entry,
(GtkDestroyNotify) gtk_widget_unref);
/* Value entry */
@@ -541,13 +542,19 @@ void attrib_edit_dialog (GSCHEM_TOPLEVEL *w_current,
OBJECT *attr_obj, int flag)
i = 0;
string = (char *) s_attrib_get(i);
while (string != NULL) {
-combo_items = g_list_append(combo_items, string);
+gtk_combo_box_append_text(GTK_COMBO_BOX(attrib_combo_box_entry), string);
i++;
string = (char *) s_attrib_get(i);
}
- combo_items = g_list_prepend(combo_items, name);
- gtk_combo_set_popdown_strings(GTK_COMBO(attrib_combo), combo_items);
- g_list_free(combo_items);
+
+ /* Add completion to attribute combo box entry */
+ attrib_combo_entry_completion = gtk_entry_completion_new();
+ gtk_entry_completion_set_model(attrib_combo_entry_completion,
+ gtk_combo_box_get_model(GTK_COMBO_BOX(attrib_combo_box_entry)));
+ gtk_entry_completion_set_text_column(attrib_combo_entry_completion, 0);
+ gtk_entry_completion_set_inline_completion(attrib_combo_entry_completion,
TRUE);
+ gtk_entry_completion_set_popup_single_match(attrib_combo_entry_completion,
FALSE);
+ gtk_entry_set_completion(GTK_ENTRY(attrib_combo_entry),
attrib_combo_entry_completion);
/* gschem specific */
gtk_widget_show_all(aewindow);
--
1.5.6.5
--
Krzysztof Kościuszkiewicz
Simplicity is the ultimate sophistication -- Leonardo da Vinci
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
