Re: gEDA-user: pcb, how to suppress TCL/TK QFP footprint builder?
On 3/2/09, Stefan Salewski m...@ssalewski.de wrote: in INSTALL for pcb-20081128 we have In addition to the libraries listed above, there is a graphical QFP footprint creator which uses TCL/TK. If you do not wish to use this feature, and you do not have TCL/TK installed on your system, you may simply set WISH to /usr/bin/true in your configure environment. For example: env WISH=/usr/bin/true ./configure BTW, wouldn't these instructions better go to the configure script rather than INSTALL, like in the attached patch? Kind regards, Ineiev From f431f33010bf6b0c1ec7f92b803b6830cadcdda5 Mon Sep 17 00:00:00 2001 From: Ineiev ine...@users.sourceforge.net Date: Sat, 14 Feb 2009 09:24:32 +0300 Subject: [PATCH] eliminate hard dependency on `wish' --- ChangeLog |4 INSTALL | 15 +++ configure.ac| 11 +-- lib/Makefile.am |7 --- 4 files changed, 24 insertions(+), 13 deletions(-) diff --git a/ChangeLog b/ChangeLog index 4497f72..358883a 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2009-02-29 22:35 ineiev + + * configure.ac lib/Makefile.am: eliminate hard dependency on `wish' + 2008-11-27 22:35 danmc * doc/actions.texi: regen. diff --git a/INSTALL b/INSTALL index 1dfa0f8..5375f94 100644 --- a/INSTALL +++ b/INSTALL @@ -78,12 +78,12 @@ Printer HID's: is not given. In addition to the libraries listed above, there is a graphical QFP footprint -creator which uses TCL/TK. If you do not wish to use this feature, and you -do not have TCL/TK installed on your system, you may simply set WISH to -/usr/bin/true in your configure environment. For example: - - env WISH=/usr/bin/true ./configure +creator which uses TCL/TK. If you do not have TCL/TK installed on your +system, the creator will not be installed. If you do not wish to use +this feature, you may simply set WISH to none in your configure environment. +For example: + env WISH=none ./configure Please refer to the output of @@ -112,9 +112,8 @@ from the top level directory. - GNU m4. In particular your m4 must support -F for frozen files. -- wish (part of tcl/tk). If not installed, set WISH=/bin/false in - your configure environment and you just won't get the graphical - QFP footprint builder +- wish (part of tcl/tk). If not installed you just won't + get the graphical QFP footprint builder - gtk if you are using the gtk frontend diff --git a/configure.ac b/configure.ac index aed978b..e0bdc94 100644 --- a/configure.ac +++ b/configure.ac @@ -394,9 +394,16 @@ fi AC_PATH_PROGS(WISH, wish wish83 wish8.3 wish80 wish8.0 cygwish83 cygwish80,[none]) if test X$WISH = Xnone ; then - AC_MSG_ERROR([Did not find the wish executible. You need to make sure - that tcl is installed on your system and that wish is in your path]) + AC_MSG_RESULT([ + Did not find the wish executible. You need to make sure + that tcl/tk is installed on your system and that wish is in your path + in order to build qfp-ui script. If you do have it installed you may + want to set WISH in your configure environment, for example: + env WISH=/opt/tcl-tk/bin/wish ./configure + + ]) fi +AM_CONDITIONAL(WISH_FOUND, test x$WISH != xnone) AC_DEFINE_UNQUOTED(M4,$M4,[m4 executible]) GNUM4=$M4 diff --git a/lib/Makefile.am b/lib/Makefile.am index 5701d50..5ef6e51 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -11,9 +11,10 @@ LIBSCRIPTS= \ CreateLibraryContents.sh \ CreateLibrary.sh \ ListLibraryContents.sh \ - QueryLibrary.sh \ - qfp-ui - + QueryLibrary.sh +if WISH_FOUND +LIBSCRIPTS+= qfp-ui +endif dist_noinst_SCRIPTS= \ m4lib_to_newlib.sh -- 1.6.1.3 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: single-sided boards
On Sat, Feb 28, 2009 at 02:21:23PM -0500, Stuart Brorson wrote: How often does the need for single-sided boards arise? The question about single-sided boards is interesting, but the answer depends upon how you intend to fabricate your boards. If you're sending the boards to a PCB manufacturer, then the raw material they use is fiberglass clad with copper on both sides. In this case, it's senseless to ask for a single-sided board to save costs -- they start with a double-sided board in any case. However, some of them do provide a cheaper, single-sided service - even the low-volume panellising companies - for example, www.pcb-pool.com. If they are starting from double-sided stock, then they can save on the production of an artwork - just expose the component side fully (or not at all, depending on whether their photoresist requires a positive or a negative exposure). They can also save on through-hole plating. When I've used their single-sided service before, I just sent them my whole data file (yes, I know, I'm a sinner - I use a commercial PCB design package), and asked them to do just the bottom copper layer. I agree that it tends to trip up newbies. However, there's one Gerber file per (metal) layer, so you can always discard the back side file without any problems. That's what I was going to say :-) Finally, one of the projects slated for work under the Linux Fund's PCB project is to update PCB's handling of layers. Things like the ability to easily deal with single sided boards from inside of PCB are part of the work to be funded by the Linux Fund. I'll just remind everybody that they can make this work happen sooner by making a donation! If I may make a suggestion - solve the layer handling problem which prevents PCB's data files from being taken directly by companies like www.pcb-pool.com. (I think it's something to do with the fact that the file doesn't contain any info to define the meaning of each layer (e.g. top copper, bottom copper, etc.) Gerber is such a vile format; it's time it was consigned to the scrapheap :-) -- David SmithWork Email: dave.sm...@st.com STMicroelectronics Home Email: david.sm...@ds-electronics.co.uk Bristol, England GPG Key: 0xF13192F2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
On Sun, 01 Mar 2009 21:43:16 -0500, Dan McMahill wrote: GTK provides a printing API. The quick summary is the printing dialog box as well as a page setup dialog box are provided as part of this. Under unix-like operating systems it works well with cups, The print dialog of gschem does a better job when it comes to PDF output. Currently, print in pcb does not play nice with CUPS-PDF-Printer. Output is always called _stdin_. It contains only the first page of multi page output. 1) is this actually a useful enough feature for people to warrant putting any time into it? One thing we would probably be able to do better than now is support layer transparency. Ack. Transparency when printing is a missing feature. ---(kaimartin)--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
On Sun, 01 Mar 2009 22:03:38 -0500, DJ Delorie wrote: And if people are asking about printing, we should consider adding some page selection options for printing. I really miss the ability to define a local print policy. It should be possible to set up some kind of config file with defaults to print a number of user defined pages. Suggestion: A framework that selects groups of objects to be printed according to matching properties. Properties might be layer, type of object, or the object name. Each group would have parameters attached like color, transparency and flags like thin draw. Definition of a page would include the definition of a viewport and a number of groups printed on top of each other. A print job would contain a number of pages. The config file might be placed in ~/pcb or in the project file. This would allow for user defaults and still allow fo project specific printing. When I worked with protel95, we routinely used a print definition that was tuned to our needs. Currently it prints [probably] way too many pages for most people. The current set of pages in postscript output is probably only useful for those who do their own etching. For the docs a different set would be better -- One, that includes pages with values and the corresponding page with refdeses displayed. ---(kaimartin)- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
On Mon, Mar 2, 2009 at 7:20 AM, Kai-Martin Knaak k...@familieknaak.de wrote: Currently it prints [probably] way too many pages for most people. The current set of pages in postscript output is probably only useful for those who do their own etching. For the docs a different set would be better -- One, that includes pages with values and the corresponding page with refdeses displayed. I would really like to see an index with a grid along the edges of the board like a city map. Then the service tech can look up U101 in column A, row 3 etc. Regards, Mark markra...@gmail -- Mark Rages, Engineer Midwest Telecine LLC markra...@midwesttelecine.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB, nelma export needs libgd?
I have tried building PCB with jpeg, png and gif disabled. So libgd should be not needed. Got checking for gdlib-config... no Cannot find gdlib-config. Make sure it is installed and in your PATH. gdlib-config is part of the GD library available from www.boutell.com/gd. This is needed for the png HID. I will look for libgd anyway and maybe you will get lucky. checking for main in -lgd... no configure: error: You have requested the nelma and/or png HID but -lgd could not be found http://www.tablix.org/~avian/nelma/ Seems that libgd is needed for nelma? I think this is not mentioned in INSTALL or ./configure --help. Maybe it should? Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB -- a remark to png, jpeg and gif export
Just a minor remark: For PCB ./configure we currently have the --with-exporters= and --disable-png, --disable-jpeg, --disable-gif. Seems to work fine, but is this redundancy in configuration really necessary? If we have --with-exporters=gerber bom ps png then it should be clear that we do not want jpeg and gif. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB, two simple questions
The first one may be stupid: When building PCB we get for each footprint file *.fp a png image *.png. For what is this image necessary? Next one: If I remember correctly there was a statement on this list telling that current pcb generates newlib copies for all the m4 footprints. This may be fine for most people, but is there an option to disable this behavior if someone does not like it? Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB -- a remark to png, jpeg and gif export
we currently have the --with-exporters= and --disable-png, --disable-jpeg, --disable-gif. Seems to work fine, but is this redundancy in configuration really necessary? Yes. The PNG exporter supports png, jpeg, pbm, and gif output formats. However, you may not have all the support libraries needed for those, so you can do a partial build of the PNG exporter to match whatever libraries you have. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB, two simple questions
When building PCB we get for each footprint file *.fp a png image *.png. For what is this image necessary? We make HTML files also, so you can browse the library with a web browser. If I remember correctly there was a statement on this list telling that current pcb generates newlib copies for all the m4 footprints. This may be fine for most people, but is there an option to disable this behavior if someone does not like it? If we disable it, those footprints won't be available, at least on Windows, which doesn't have m4. We're trying to get rid of the runtime dependency on m4. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
DJ Delorie wrote: And if people are asking about printing, we should consider adding some page selection options for printing. Currently it prints [probably] way too many pages for most people. I've noticed gtk printing doing a good job on debian linux recently. The basic dialog box has a print page range. If we provided a hint of the list of files that are printable by the exporter, we would be done. Done to the point of usable by specifying a range like: 1-3, 5, 9,11at least. Centralizing printing to come from one library sounds good, but I can't commit time to it. It's just something for Mike getting the Win32 HID going to consider. I like Kai-Martin's idea of a config file, or gafrc config line(s) for which files get queued to print by the exporter. Kai-Martin's idea of configurable filters to print data objects in ways different from their current displayed appearance on screen sounds far off in the evolution of pcb/gschem, but I like it too. :-) John Griessen -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wcalc-1.1 released
Dan, I've found this tool useful in the past and was really glad to see the CPW model (which I really needed last week!). A couple questions: - what are the units for electrical length? - the Options and Window pull downs don't seem to contain anything - is there supposed to be something there or am I missing something? (I'm running this on Win XP/SP3 - I haven't tried the Linux install yet) Thanks - Joe T Dan McMahill wrote: After way way too long since the 1.0 release, I have finally released wcalc version 1.1. The home page is still http://wcalc.sf.net Wcalc is a transmission analysis/synthesis calculator. The main changes in version 1.1 over 1.0 are: Added series/parallel RC equivalent circuit calculator. Added series/parallel RL equivalent circuit calculator. Added self and mutual inductance of two rectangular bars. Added coplanar waveguide model. Added coupled stripline model. Corrected the Q calculations for low frequency (not skindepth) region in air core inductors. Also corrected Q calculation for conductors other than copper. Corrected the calculation of incremental conductance for the microstrip model. Corrected a bug in the calculation of conductor losses in the microstrip model. Added/enabled code for calculating conductor losses in the coupled microstrip model. When compiling with gtk-2.10 or newer, use gtkPrint for printing. This gives a more professional/standard print dialog and also enables printing under windows. Added a preliminary Dutch translation. Converted the figures to all use solid grayscale fills instead of pattern fills as the former prints better. Several updates to the build system to moderize it a bit. Uses AM_CONDITIONALS more appropriately, uses AC_PROG_LIBTOOL instead of AM_PROG_LIBTOOL, etc. Update the win32 build script to generate an installer that works correctly under vista. Add .wc file associations under vista. Update the octave build infrastructure to work with octave-3.0 and newer where mex support is built into mkoctfile instead of a standalone mex shell script. Switch to GPL licensing. Create several utility functions to make it faster to build new gtk forms. This is only visible to developers. Improved autogen.sh to check versions of several of the auto* tools to help make it easier to diagnose any issues which may come up. Repair compilation with the SunPRO compilers. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Grid Units in schematic editor
I've started trying to use Geda for the first time, starting with the schematic editor. How do you change the grid units from imperial to metric (i.e. mm)? Forgive me if it's obvious and I'm being thick but I have checked the documentation and can't find anything. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Grid Units in schematic editor
How do you change the grid units from imperial to metric (i.e. mm)? The gschem grid is unit-less; you don't switch it because it's not imperial. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Grid Units in schematic editor
On Mon, 2009-03-02 at 16:57 +, Alex Huntley wrote: I've started trying to use Geda for the first time, starting with the schematic editor. How do you change the grid units from imperial to metric (i.e. mm)? Forgive me if it's obvious and I'm being thick but I have checked the documentation and can't find anything. For the schematics editor gschem the grid units are arbitrary -- there is not a fixed unit, because schematics are abstract. Printout is usually scaled to fit to paper size. Most people use a title block, the border of this title block is then scaled to fit on the paper. Some title-blocks are called something like a4, but this is not really bound to a4 paper. We can use any title block we want (and print it). For gschem you can select grid size in menu, but you have to ensure that pins of symbols end on grid points which are multiple of 100. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
On Sun, Mar 1, 2009 at 10:03 PM, DJ Delorie d...@delorie.com wrote: Note that if Mike gets the Win32 HID working Any time line on that? I've been using PCB on Windows, and it has three significant problems. Printing, Library Paths, PostScript Export. it will support Win32-based printing. And if people are asking about printing. , we should consider adding some page selection options for printing I was the one that asked Dan about PCB printing on Windows. Actually I asked Dan about how to build PCB on Windows, base on some previous discussions in private email. Once I can get PCB built I was going to figure out why it won't print. As it is now it is simply impossible to print on Windows. All that happens is that a DOS box pops up, then vanishes before you can read what it said. Doesn't mater what you enter for a lprcommand. Currently it prints [probably] way too many pages for most people. I have no complaint, other than there is never a page one, even when I print from my Linux box, during PostScript export. The first page starts with 2. Component, I assume the missing 1. is the first index page itself? I'd be happy if PostScript Export worked, then I could use that to print. It does not work correctly on Windows with GhostScript/GhostView, which to me seems rather odd. This is the error message: DSC Error At line 3: %%Page: 1 This line is incorrect. The two arguments should be a label and an ordinal. The ordinal should be 1 for the first page and should increase by 1 for each following page. The page ordinal is missing or is not in sequence. It is likely that this line is part of an included file that was not enclosed in %%BeginDocument / %%EndDocument. 'OK' will ignore this page, assuming it is part of an incorrectly encapsulated EPS file. 'Cancel' will treat this as a valid page Response = OK DSC Error At line 35: %%Page: 2 This line is incorrect. The two arguments should be a label and an ordinal. The ordinal should be 1 for the first page and should increase by 1 for each following page. The page ordinal is missing or is not in sequence. It is likely that this line is part of an included file that was not enclosed in %%BeginDocument / %%EndDocument. ... for 14 pages. Selecting Cancel does get a workable document. The path name at the bottom of each page is wrong. There is no path separator, of any type. I assume there is some backslash quoting problem there. This is with the most recently released version of GhostScript, 8.63. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
On Sun, 2009-03-01 at 22:03 -0500, DJ Delorie wrote: Note that if Mike gets the Win32 HID working, it will support Win32-based printing. Is there any reason why this Win32 effort isn't / can't be merely adding developer time to ensure that the GTK code works well for its Win32 port, and adding native code as required to improve the integration / feel of the app for Windows users? (This might include work on Win32 printing, and / or native file-chooser dialogs). The way we're going, which I think is a shame, is to end up with three separate applications which happen to share a name, common file-format and a quantity of core code. We'll need three user guides, three bug-tracker (categories), ~3x developer effort for every feature added / changed which requires interaction with the user. Aside from the exercise to verify the decoupling of the HID API, (and at the risk of being controversial), what are the tangible reasons for the Lesstif HID's continued existence? Assuming a minimal GTK, with no theme engine etc.. are there any performance issues? If it is a UI design preference / usability issue, are they so far different from common GTK (or GNOME) UI design guidelines, that it couldn't be implemented through options? Either GTK, QT, or WxWidgets would give us a single toolkit, single code-base HID with true cross platform portability to Unix, Win32 and MacOS. Creating more HIDs than necessary is not cost-free from a maintenance and user-education point of view. EDA tools are sufficiently far from the category of desktop app, that I don't see a burning need to NIH a version for each and every favourite toolkit someone might come up with. (Says a biased Peter, who's favourite toolkit happens to be GTK at the moment). OTOH it would be nice to separate out the rendering layer if it means 3D-based rendering for Lesstif as well as GTK. If we could create a cairo module, for example, which the various HIDs can point at a window... I don't think it needs to be a full HID, just a rendering module that the HID can choose. Each HID using it would probably just need a bit of code to create the cairo_t, and pass it along to the the share cairo code. If someone reminds me, I'll try and find my old attempt at a cairo renderer for PCB when I get a chance. This is similar to the GL code (which needs an active GL context). I've separated the core GL drawing routines. I just need (at some point), to figure out how to abstract some of the more complex / hardware feature dependent code, such as VBOs / stenciling etc.. Best 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!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
On Mon, 2009-03-02 at 12:44 +, Kai-Martin Knaak wrote: 1) is this actually a useful enough feature for people to warrant putting any time into it? One thing we would probably be able to do better than now is support layer transparency. Ack. Transparency when printing is a missing feature. Sensibly, you want cairo to do this. postscript doesn't support transparency / compositing like PDF does, so you need fall-backs to images, or computational geometry to draw each combination of overlapped layers in the appropriate final colour. I'm not sure how quickly you'd hit image fall-backs with cairo doing compositing to a PS backend, but the code required to do otherwise sounds like it would be a nightmare to write. As much as I like .ps output in programs, I think we need to skip straight to .pdf if we want to support translucency in a meaningful way whilst retaining vector output. IE.. a PDF output HID using shared cairo code to render. -- 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!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
On Mon, 2009-03-02 at 08:05 -0600, Mark Rages wrote: On Mon, Mar 2, 2009 at 7:20 AM, Kai-Martin Knaak k...@familieknaak.de wrote: I would really like to see an index with a grid along the edges of the board like a city map. Then the service tech can look up U101 in column A, row 3 etc. FWIW, I've heard this asked for in gschem too. (By Tomaz Solc). Since gschem title-blocks already have such designations, the idea was that it would be nice to be able to query each entity for its location in that coordinate system. Of course, since in gschem the coordinates on the title-block are just graphics, such a feature wouldn't be directly possible without some kind of scripted / plugin attribute annotation which understands the notional coordinate system of the page's title block. -- 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!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Grid Units in schematic editor
Stefan Salewski wrote: On Mon, 2009-03-02 at 16:57 +, Alex Huntley wrote: I've started trying to use Geda for the first time, starting with the schematic editor. How do you change the grid units . . . . For the schematics editor gschem the grid units are arbitrary -- there is not a fixed unit, because schematics are abstract. Yes, and you may find a larger than letter size title block helpful if you like to put a lot of circuitry on any one page, such as: http://www.gedasymbols.org/user/john_griessen/symbols/title-B-cibolo.sym or http://www.gedasymbols.org/user/john_griessen/symbols/title-B-nameOnEdge.sym I use these with an 11x17 printer, but they'll print on letter size too. It's one of those style choices... John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
On Mon, 02 Mar 2009 17:37:04 +, Peter Clifton wrote: Ack. Transparency when printing is a missing feature. sounds like it would be a nightmare to write. Don't let it haunt your dreams ;-) There sure are many more lower hanging, more rewarding fruit. ---(kaimartin)--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
Peter Clifton wrote: As much as I like .ps output in programs, I think we need to skip straight to .pdf if we want to support translucency in a meaningful way whilst retaining vector output. IE.. a PDF output HID using shared cairo code to render. PDF output seems fine as far as openness to me. xpdf has command line options for converting to .ps. Postscript output could just be done in a chain after pdf output...with a dependency on xpdf or a pdf library that can be built on windows, or the gtk windows libraries that handle .pdf and .ps, (not sure how, but you seem to get that.). John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
Is there any reason why this Win32 effort isn't / can't be merely adding developer time to ensure that the GTK code works well for its Win32 port, and adding native code as required to improve the integration / feel of the app for Windows users? Because, as Mike puts it, GTK under windows doesn't look like windows, doesn't act like windows, and just confuses users. Aside from the exercise to verify the decoupling of the HID API, (and at the risk of being controversial), what are the tangible reasons for the Lesstif HID's continued existence? It looks different, acts different, etc. If it were me, I'd get rid of the GTK hid - it's the least maintainable for us. Either GTK, QT, or WxWidgets would give us a single toolkit, single code-base HID with true cross platform portability to Unix, Win32 and MacOS. And it would look like and act like none of the above. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
On Mon, 2009-03-02 at 13:22 -0500, DJ Delorie wrote: Is there any reason why this Win32 effort isn't / can't be merely adding developer time to ensure that the GTK code works well for its Win32 port, and adding native code as required to improve the integration / feel of the app for Windows users? Because, as Mike puts it, GTK under windows doesn't look like windows, doesn't act like windows, and just confuses users. Looks: Use the right theme engine, and it does a pretty good impression. File-choosers being the main exception, but you could (if desired), use custom code to invoke the Win32 file choosers. Acts: Need to make more use of GTK's APIs to reorder buttons on dialogs for different platforms perhaps? I'm more interested in specifics though.. this is all about conventions, not the toolkit. Win32 doesn't really have a toolkit as such, as far as I could tell last time I programmed for it. Different development platforms use / provided different APIs. Only commdlg32.dll (?) provided some coherency across the platform last time I coded Win32. (This was back when you chose between MFC / OWL / raw win32 APIs). Aside from the exercise to verify the decoupling of the HID API, (and at the risk of being controversial), what are the tangible reasons for the Lesstif HID's continued existence? It looks different, acts different, etc. If it were me, I'd get rid of the GTK hid - it's the least maintainable for us. Perhaps the code is a little crufty in places, but I wouldn't call it difficult to maintain. Just because it looks different - so what. Does it cause a problem with usability or speed? Does it act differently harm productivity? Either GTK, QT, or WxWidgets would give us a single toolkit, single code-base HID with true cross platform portability to Unix, Win32 and MacOS. And it would look like and act like none of the above. All of the above can use the native theme engine for Win32, either as a theme engine plugin, or as part of their native design. What you do with the toolkit may give you differences in UI paradigm between various platforms, but this is largely up to the programmer, not the toolkit. I think maintainability / unified documentation is far more important to us than making the apps feel 100% native, certainly at this point in time. I see developer effort as our most valuable asset, and it is a shame to divide it between multiple front-ends using different tool-kits where such effort could be minimised. New HID's (once merged) aren't free, from a core maintenance / design flexibility point of view. Unmerged HIDs create a headache for their maintainer as anyone else wants to alter the HID API between releases. -- 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!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
On Mon, 02 Mar 2009 13:22:00 -0500, DJ Delorie wrote: Because, as Mike puts it, GTK under windows doesn't look like windows, doesn't act like windows, and just confuses users. Non-GTK under windows confuses users too -- those windows users who dare to ask their linux buddy, who talked them into trying this weird EDA app rather than eagle. If it were me, I'd get rid of the GTK hid - it's the least maintainable for us. least maintainable, or just least maintained? ---(kaimartin)--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
1) is this actually a useful enough feature for people to warrant putting any time into it? One thing we would probably be able to do better than now is support layer transparency. Yes, I think it is worthwhile. I don't what level you'd define layer transparency at, but this needs to be solved for the GL HID too. On some levels it is a preference which lives with colours, on others, it is something which the GUI ought to be able to control dynamically depending on which layer / tools are selected. (Noting how thin-draw / translucent draw polygons can provide increased usability whilst editing). 2) does it make sense, and I think it probably does, for this to be a cairo HID and that HID depends on gtk (not the gtk HID, but the gtk libraries) to provide the print dialogs. The advantage of using the gtk print dialogs is they are there, they work on linux and win32, and we don't have to maintain our own. I'd turn it on its head. Let the HID produce the cairo_t to render into, and keep the cairo shared code as cairo only. Any creation of backend specific surfaces would have to be done by the HID. 3) can we do a layering sort of thing where we have a cairo HID that does not use gtk at all and then in the gtk HID, we can implement a call to the gtk print dialog and in the lesstif HID we somehow call the cairo HID to generate postscript to a file or lpr or pdf to a file? Rather just teach the common .ps / .eps exporter to use cairo as a backend? Doesn't the lpr exporter use the .ps exporter internally? -- 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!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb printing
It looks different, acts different, etc. If it were me, I'd get rid of the GTK hid - it's the least maintainable for us. Perhaps the code is a little crufty in places, but I wouldn't call it difficult to maintain. Dan doesn't have time and I don't know gtk as well as Motif, that's all. Just because it looks different - so what. Does it cause a problem with usability or speed? Does it act differently harm productivity? It depends on what you're used to ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB, two simple questions
On Mar 2, 2009, at 7:49 AM, DJ Delorie wrote: When building PCB we get for each footprint file *.fp a png image *.png. For what is this image necessary? We make HTML files also, so you can browse the library with a web browser. If I remember correctly there was a statement on this list telling that current pcb generates newlib copies for all the m4 footprints. This may be fine for most people, but is there an option to disable this behavior if someone does not like it? If we disable it, those footprints won't be available, at least on Windows, which doesn't have m4. We're trying to get rid of the runtime dependency on m4. i depend on the runtime M4 for my part library, i hope that, this could have been read as were making runtime M4 optional. yes i could switch to newlib and compile my sources, but that requires me to switch the environments of about 5 other engineers. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB, two simple questions
If we disable it, those footprints won't be available, at least on Windows, which doesn't have m4. We're trying to get rid of the runtime dependency on m4. i depend on the runtime M4 for my part library, i hope that, this could have been read as were making runtime M4 optional. You can do whatever you want with your library. We're trying to make the pcb core libraries not require m4. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB, two simple questions
On Mar 2, 2009, at 11:56 AM, DJ Delorie wrote: If we disable it, those footprints won't be available, at least on Windows, which doesn't have m4. We're trying to get rid of the runtime dependency on m4. i depend on the runtime M4 for my part library, i hope that, this could have been read as were making runtime M4 optional. You can do whatever you want with your library. We're trying to make the pcb core libraries not require m4. Good to know, it's one of those moments when you see a foundation you built upon get eroded away. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB, nelma export needs libgd?
Stefan Salewski wrote: I have tried building PCB with jpeg, png and gif disabled. So libgd should be not needed. as you found out it is also needed for nelma. Got checking for gdlib-config... no Cannot find gdlib-config. Make sure it is installed and in your PATH. gdlib-config is part of the GD library available from www.boutell.com/gd. This is needed for the png HID. I will look for libgd anyway and maybe you will get lucky. checking for main in -lgd... no configure: error: You have requested the nelma and/or png HID but -lgd could not be found http://www.tablix.org/~avian/nelma/ Seems that libgd is needed for nelma? yes it is. I think this is not mentioned in INSTALL or ./configure --help. Maybe it should? that should be added somewhere. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB -- a remark to png, jpeg and gif export
Stefan Salewski wrote: Just a minor remark: For PCB ./configure we currently have the --with-exporters= and --disable-png, --disable-jpeg, --disable-gif. Seems to work fine, but is this redundancy in configuration really necessary? If we have --with-exporters=gerber bom ps png then it should be clear that we do not want jpeg and gif. I picked an unfortunate name for the png HID. I should have called it the image HID or maybe the gdlib HID or some such thing. My intent was just png but then a realized fairly far along that jpeg and gif were for free *provided* that the libgd had jpeg and gif support compiled in. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wcalc-1.1 released
joeft wrote: Dan, I've found this tool useful in the past and was really glad to see the CPW model (which I really needed last week!). A couple questions: - what are the units for electrical length? degrees. Hopefully I'll remember to make this explicit next time I'm doing wcalc hacking. - the Options and Window pull downs don't seem to contain anything - is there supposed to be something there or am I missing something? nope. I need to comment those out or do something with them. The intent was to populate the windows menu with the list of all open windows, but I never got that done. (I'm running this on Win XP/SP3 - I haven't tried the Linux install yet) Should look the same although under linux the functions are all available via octave, scilab, or matlab as well. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [PATCH 1/4][PCB] Remove color fields from PCBType data strucutre
Currently color preferences are loaded/saved globally thus they don't need
to be stored in the PCBType struct. All references to colors previously
stored in the PCBType struct have been updated with the cooresponding
color stored in the global SettingType structure.
Signed-off-by: Peter Tyser pty...@gmail.com
---
src/autoroute.c |2 +-
src/create.c | 18 +---
src/draw.c | 96 +-
src/global.h | 11 -
src/hid/gtk/gui-top-window.c | 12 +++---
src/hid/lesstif/menu.c | 12 +++---
src/print.c |6 +-
src/rtree.c |6 +-
8 files changed, 68 insertions(+), 95 deletions(-)
diff --git a/src/autoroute.c b/src/autoroute.c
index 5c689e4..bf67e48 100644
--- a/src/autoroute.c
+++ b/src/autoroute.c
@@ -2525,7 +2525,7 @@ RD_DrawVia (routedata_t * rd, LocationType X,
LocationType Y,
if (TEST_FLAG (LIVEROUTEFLAG, PCB))
{
- gui-set_color (ar_gc, PCB-ViaColor);
+ gui-set_color (ar_gc, Settings.ViaColor);
gui-fill_circle (ar_gc, X, Y, radius);
}
}
diff --git a/src/create.c b/src/create.c
index fa0a394..37cd839 100644
--- a/src/create.c
+++ b/src/create.c
@@ -86,29 +86,13 @@ CreateNewBuffer (void)
}
/* ---
- * Perhaps PCB should internally just use the Settings colors? For now,
- * use this to set PCB colors so the config can reassign PCB colors.
+ * Update layer colors from Settings structure
*/
void
pcb_colors_from_settings (PCBTypePtr ptr)
{
int i;
- /* copy default settings */
- ptr-ConnectedColor = Settings.ConnectedColor;
- ptr-ElementColor = Settings.ElementColor;
- ptr-RatColor = Settings.RatColor;
- ptr-InvisibleObjectsColor = Settings.InvisibleObjectsColor;
- ptr-InvisibleMarkColor = Settings.InvisibleMarkColor;
- ptr-ElementSelectedColor = Settings.ElementSelectedColor;
- ptr-RatSelectedColor = Settings.RatSelectedColor;
- ptr-PinColor = Settings.PinColor;
- ptr-PinSelectedColor = Settings.PinSelectedColor;
- ptr-PinNameColor = Settings.PinNameColor;
- ptr-ViaColor = Settings.ViaColor;
- ptr-ViaSelectedColor = Settings.ViaSelectedColor;
- ptr-WarnColor = Settings.WarnColor;
- ptr-MaskColor = Settings.MaskColor;
for (i = 0; i MAX_LAYER; i++)
{
ptr-Data-Layer[i].Color = Settings.LayerColor[i];
diff --git a/src/draw.c b/src/draw.c
index 6d03be8..b8519d8 100644
--- a/src/draw.c
+++ b/src/draw.c
@@ -129,14 +129,14 @@ SetPVColor (PinTypePtr Pin, int Type)
TEST_FLAG (WARNFLAG | SELECTEDFLAG | FOUNDFLAG, Pin))
{
if (TEST_FLAG (WARNFLAG, Pin))
- color = PCB-WarnColor;
+ color = Settings.WarnColor;
else if (TEST_FLAG (SELECTEDFLAG, Pin))
- color = PCB-ViaSelectedColor;
+ color = Settings.ViaSelectedColor;
else
- color = PCB-ConnectedColor;
+ color = Settings.ConnectedColor;
}
else
- color = PCB-ViaColor;
+ color = Settings.ViaColor;
}
else
{
@@ -144,14 +144,14 @@ SetPVColor (PinTypePtr Pin, int Type)
TEST_FLAG (WARNFLAG | SELECTEDFLAG | FOUNDFLAG, Pin))
{
if (TEST_FLAG (WARNFLAG, Pin))
- color = PCB-WarnColor;
+ color = Settings.WarnColor;
else if (TEST_FLAG (SELECTEDFLAG, Pin))
- color = PCB-PinSelectedColor;
+ color = Settings.PinSelectedColor;
else
- color = PCB-ConnectedColor;
+ color = Settings.ConnectedColor;
}
else
- color = PCB-PinColor;
+ color = Settings.PinColor;
}
gui-set_color (Output.fgGC, color);
@@ -397,8 +397,8 @@ DrawEverything (BoxTypePtr drawn_area)
/* This is the reverse of the order in which we draw them. */
int drawn_groups[MAX_LAYER];
- PCB-Data-SILKLAYER.Color = PCB-ElementColor;
- PCB-Data-BACKSILKLAYER.Color = PCB-InvisibleObjectsColor;
+ PCB-Data-SILKLAYER.Color = Settings.ElementColor;
+ PCB-Data-BACKSILKLAYER.Color = Settings.InvisibleObjectsColor;
memset (do_group, 0, sizeof (do_group));
for (ngroups = 0, i = 0; i max_layer; i++)
@@ -557,7 +557,7 @@ DrawEverything (BoxTypePtr drawn_area)
doit = gui-set_layer (toppaste, SL (PASTE, TOP), NoData);
if (doit)
{
- gui-set_color (Output.fgGC, PCB-ElementColor);
+ gui-set_color (Output.fgGC, Settings.ElementColor);
ALLPAD_LOOP (PCB-Data);
{
if ((TEST_FLAG (ONSOLDERFLAG, pad) side == SOLDER_LAYER)
@@ -595,8 +595,8 @@ DrawEMark (ElementTypePtr e, LocationType X, LocationType Y,
if (e-PadN mark_size e-Pad[0].Thickness / 2)
mark_size = e-Pad[0].Thickness / 2;
- gui-set_color (Output.fgGC,
- invisible ? PCB-InvisibleMarkColor : PCB-ElementColor);
+ gui-set_color (Output.fgGC, invisible ?
+
gEDA-user: [PATCH 2/4][PCB] Add call to ghid_set_special_colors() to config_color_set_cb()
In the original code some changes to color preferences (eg changing the backgroung color) would not take effect until the color preferences were reloaded or pcb was restarted. This is inconsistent with other color preference changes which are updated immediately without reloading or restarting. Calling ghid_set_special_colors() in config_color_set_cb() allows some additional color preferences to be updated immediately without reloading color preferences or restarting pcb. Signed-off-by: Peter Tyser pty...@gmail.com --- src/hid/gtk/gui-config.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/hid/gtk/gui-config.c b/src/hid/gtk/gui-config.c index 55ab6e7..5230a58 100644 --- a/src/hid/gtk/gui-config.c +++ b/src/hid/gtk/gui-config.c @@ -1922,6 +1922,7 @@ config_color_set_cb (GtkWidget * button, ConfigColor * cc) gtk_widget_set_sensitive (config_colors_save_button, TRUE); gtk_widget_set_sensitive (config_color_warn_label, TRUE); + ghid_set_special_colors (ha); ghid_layer_buttons_color_update (); ghid_invalidate_all(); } -- 1.6.2-rc2.GIT ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [PATCH 3/4][PCB] Cross color update
Make color of cross-color a global variable and update its value
immediately when it is changed. Original code only updated the
cross color when pcb was restarted.
Signed-off-by: Peter Tyser pty...@gmail.com
---
src/hid/gtk/gtkhid-main.c |4
src/hid/gtk/gui-output-events.c |5 ++---
src/hid/gtk/gui.h |2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/hid/gtk/gtkhid-main.c b/src/hid/gtk/gtkhid-main.c
index 61e114e..93a1eab 100644
--- a/src/hid/gtk/gtkhid-main.c
+++ b/src/hid/gtk/gtkhid-main.c
@@ -714,6 +714,10 @@ ghid_set_special_colors (HID_Attribute * ha)
ghid_map_color_string (*(char **) ha-value, gport-grid_color);
set_special_grid_color ();
}
+ else if (!strcmp (ha-name, cross-color))
+{
+ ghid_map_color_string (*(char **) ha-value, gport-cross_color);
+}
}
void
diff --git a/src/hid/gtk/gui-output-events.c b/src/hid/gtk/gui-output-events.c
index 1a62dd8..6077607 100644
--- a/src/hid/gtk/gui-output-events.c
+++ b/src/hid/gtk/gui-output-events.c
@@ -398,7 +398,6 @@ ghid_show_crosshair (gboolean show)
gint x, y;
static gint x_prev = -1, y_prev = -1;
static GdkGC *xor_gc;
- static GdkColor cross_color;
if (gport-x_crosshair 0 || ghidgui-creating || !gport-has_entered)
return;
@@ -409,12 +408,12 @@ ghid_show_crosshair (gboolean show)
gdk_gc_copy (xor_gc, ghid_port.drawing_area-style-white_gc);
gdk_gc_set_function (xor_gc, GDK_XOR);
/* FIXME: when CrossColor changed from config */
- ghid_map_color_string (Settings.CrossColor, cross_color);
+ ghid_map_color_string (Settings.CrossColor, gport-cross_color);
}
x = DRAW_X (gport-x_crosshair);
y = DRAW_Y (gport-y_crosshair);
- gdk_gc_set_foreground (xor_gc, cross_color);
+ gdk_gc_set_foreground (xor_gc, gport-cross_color);
if (x_prev = 0)
{
diff --git a/src/hid/gtk/gui.h b/src/hid/gtk/gui.h
index f0b0618..b6373e0 100644
--- a/src/hid/gtk/gui.h
+++ b/src/hid/gtk/gui.h
@@ -199,7 +199,7 @@ typedef struct
GdkGC *bg_gc, *offlimits_gc, *mask_gc, *u_gc, *grid_gc;
- GdkColor bg_color, offlimits_color, grid_color;
+ GdkColor bg_color, offlimits_color, grid_color, cross_color;
GdkColormap *colormap;
--
1.6.2-rc2.GIT
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [PATCH 4/4][PCB] Crosshair color update
Update crosshair logic so that the current crosshair-color value is
used. The original code would not update the crosshair-color
immediately after changing the crosshair-color preference setting.
Signed-off-by: Peter Tyser pty...@gmail.com
---
src/crosshair.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/crosshair.c b/src/crosshair.c
index 8321929..3098d7b 100644
--- a/src/crosshair.c
+++ b/src/crosshair.c
@@ -583,6 +583,7 @@ DrawAttached (Boolean BlockToo)
switch (Settings.Mode)
{
case VIA_MODE:
+ gui-set_color (Crosshair.GC, Settings.CrosshairColor);
gui-draw_arc (Crosshair.GC,
Crosshair.X,
Crosshair.Y,
@@ -594,12 +595,13 @@ DrawAttached (Boolean BlockToo)
gui-set_color (Crosshair.GC, Settings.CrossColor);
gui-draw_arc (Crosshair.GC,
Crosshair.X, Crosshair.Y, s, s, 0, 360);
- gui-set_color (Crosshair.GC, Settings.CrosshairColor);
}
break;
/* the attached line is used by both LINEMODE and POLYGON_MODE */
case POLYGON_MODE:
+ gui-set_color (Crosshair.GC, Settings.CrosshairColor);
+
/* draw only if starting point is set */
if (Crosshair.AttachedLine.State != STATE_FIRST)
gui-draw_line (Crosshair.GC,
@@ -618,13 +620,13 @@ DrawAttached (Boolean BlockToo)
case ARC_MODE:
if (Crosshair.AttachedBox.State != STATE_FIRST)
{
+ gui-set_color (Crosshair.GC, Settings.CrosshairColor);
XORDrawAttachedArc (Settings.LineThickness);
if (TEST_FLAG (SHOWDRCFLAG, PCB))
{
gui-set_color (Crosshair.GC, Settings.CrossColor);
XORDrawAttachedArc (Settings.LineThickness +
2 * (PCB-Bloat + 1));
- gui-set_color (Crosshair.GC, Settings.CrosshairColor);
}
}
@@ -635,6 +637,7 @@ DrawAttached (Boolean BlockToo)
if (Crosshair.AttachedLine.State != STATE_FIRST
Crosshair.AttachedLine.draw)
{
+ gui-set_color (Crosshair.GC, Settings.CrosshairColor);
XORDrawAttachedLine (Crosshair.AttachedLine.Point1.X,
Crosshair.AttachedLine.Point1.Y,
Crosshair.AttachedLine.Point2.X,
@@ -661,7 +664,6 @@ DrawAttached (Boolean BlockToo)
Crosshair.X, Crosshair.Y,
PCB-RatDraw ? 10 : Settings.
LineThickness + 2 * (PCB-Bloat + 1));
- gui-set_color (Crosshair.GC, Settings.CrosshairColor);
}
}
break;
@@ -678,6 +680,10 @@ DrawAttached (Boolean BlockToo)
case INSERTPOINT_MODE:
XORDrawInsertPointObject ();
break;
+case ARROW_MODE:
+ /* We're going to draw a selection rectangle */
+case RECTANGLE_MODE:
+ gui-set_color (Crosshair.GC, Settings.CrosshairColor);
}
/* an attached box does not depend on a special mode */
--
1.6.2-rc2.GIT
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PATCH 0/4][PCB] Color setting updates
Hi DJ, On Tue, 2009-03-03 at 01:28 -0500, DJ Delorie wrote: Personally, I think the direction we should be going in is *to* saving layer color information in .pcb files. Not sure how much of an argument I'd have for the non-layer colors though. me thinks user expectations and consistency apply here. IMHO, if we were to make the above change it's either all colors or keep as is (do not change). doing nothing is a choice as well as choosing one of all the other possibilities :) my EUR 0.02 Kind regards, Bert Timmerman. BTW: I did google for my EUR 0.02 bert and came up with EUR 4,98 :) now -- EUR 5.00 , time for a donation to LF. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PATCH 0/4][PCB] Color setting updates
On 3/3/09, DJ Delorie d...@delorie.com wrote: Personally, I think the direction we should be going in is *to* saving layer color information in .pcb files. Not sure how much of an argument I'd have for the non-layer colors though. That thought crossed my mind too but I reasoned: 1. Whether the colors are stored in the PCB structure or global settings structure, the colors fields should only be defined once. (eg ViaColor should not be defined in 2 different places). 2. Functions like load_colors_from_pcb() and save_colors_to_pcb() could be added to add the ability to load/save colors from/to a .pcb file. I thought this would be cleaner than having duplicate colors defined at both the global and PCB levels. 3. It made more sense to keep the colors in the global settings structure since many PCBs don't/won't have color information in them and will continue to use the current color setting configuration scheme. 4 I imagine some users might not want to inherit the colors of the PCBs they open. I agree that it would be nice to have the ability to store colors in a .pcb file, but I thought that these changes would be an improvement with or without that feature. If others have some suggestions as far as a cleaner implementation or about saving/loading colors in the .pcb files I'd be happy to give it a go. I believe the last 3 patches should apply even if the 1st one is rejected FWIW. Thanks, Peter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
