gEDA-user: what does "Error while clipping PBO_SUB: 3" mean?
I'm trying to work with a rather compex polygon ground plane. I get the following spew on the terminal, then crash: Error while clipping PBO_SUB: 3 Error while clipping PBO_SUB: 3 Error while clipping PBO_SUB: 3 Error while clipping PBO_SUB: 3 Error while clipping PBO_SUB: 3 Error while clipping PBO_SUB: 3 Error while clipping PBO_SUB: 3 Error while clipping PBO_SUB: 3 Error while clipping PBO_SUB: 3 Just leaked in Subtract Segmentation fault Any ideas on where to look for the problem? Regards, Mark markra...@gmail -- Mark Rages, Engineer Midwest Telecine LLC markra...@midwesttelecine.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
> Unless the problem is inherently graphical, a GUI isn't needed, and > the design should be implemented without it. The "problem" is organization and presentation. Is that inherently graphical? If a new user can't manage their flow because all those little tools are difficult to visualize, we've failed them. A GUI is more than just sugar, or for inherently graphical tasks. It's a way of organizing information such that humans can relate easily. Just saying "use make" is not going to solve that problem, no matter how clever your make-fu is. No, we don't *need* a GUI. We really, really want one, though. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
On Feb 9, 2010, at 1:10 PM, al davis wrote: A GUI is just a visual aid. If you have junk under the hood, and hide it with a GUI, you just have more junk. I agree completely. Unless the problem is inherently graphical, a GUI isn't needed, and the design should be implemented without it. Then, if you want the sugar, you can wrap a GUI around it. But a user should be able to throw away the GUI without loss of functionality. If the GUI is at all necessary, it will be a barrier to automation and integration at higher levels. After all, a project isn't just circuits. It includes software, simulations, test fixtures, documentation, presentations, ... gEDA integrates well into scripted higher level flows. Let's keep it that way. Maybe even improve it. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
Chris, > And I wasn't saying that xgsch2pcb should > be a drop-in window "as-is" to gschem, but I think it would be rather > nice if you could generate netlists and output to pcb straight from > gschem. Just a thought. I might even be willing to help if anyone else > is interested in the idea. Maybe this mail from geda-dev could help: "A GTK based "Generic Gschem Dynamic Scripting Tools Menus" package is available" >From http://www.seul.org/pipermail/geda-dev/2008-August/013756.html "The dynamic scripting tools menu system allows you to invoke any program or script (Scheme, Shell, Python, Perl, etc) from the menu thru the Scheme/Shell interface with the ability to pass Gschem internal parameters to/from your scripts, and with the ability to use UI dialog easily." Example code: http://www.seul.org/pipermail/geda-dev/2008-July/005769.html I never used or tried the example given above, it might be your starting point. Bas -- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: Latex
Dan McMahill writes: > Before switching I was a die hard word user. Word? Wordstar! My first thesis war written with wordstar, on CP/M2.2. Then I switched to LaTeX. And how proud I was, when EMTeX run faster on my new 486DX33 notebook, than the TeX on the VAX at the institute (at night!), until they got those alpha machines. Almost as proud as I was when I wrote my first thesis on that selfmade Z80 computer, with Wordstar. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
On Tuesday 09 February 2010, Peter Clifton wrote: > Not for a GUI, it isn't. Seriously. Right concept, bad > integration. > A GUI is just a visual aid. If you have junk under the hood, and hide it with a GUI, you just have more junk. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
On Tue, 2010-02-09 at 19:05 +, Peter Clifton wrote: > On Tue, 2010-02-09 at 18:40 +, Peter Clifton wrote: > > > "Make" is the tool. > > > > Not for a GUI, it isn't. Seriously. Right concept, bad integration. > > There are not enough decent hooks in make to integrate it with a GUI*. > It is fine if things _work_, otherwise you would have to litter your > makefile with commands to prod back status to the GUI tool. I thought I was going to have to really eat my words. Although I don't know of the stability to this interface, "make -p" dumps the internal database from make... Unfortunately, it also executes the "make" process - which is rather a pain. "make -np" helps, but can't prevent certain side-effects from the Makefile's variable expansion. Worst still, having tried this on one of my design projects, I discovered that make isn't able to tell me if a target is out of date. It claims to have updated it already, by the time the database is emitted. "make -dn" gives this kind of info (in text), but this is a "debug" mode, and probably not something we can rely on as an interface. It was hoping it would be possible to prod "make" to get enough information back to the project manager as to which targets need updating etc., which you could then call "make" to update. I also wanted to be able to extract the digraph make constructs - so the GUI can display _why_ something is out of date. The reasons to want this (rather than growing our internal "make" implementation): 1. Avoids having to write the "make" algorithm again 2. Allows the project manager to be based on customisable Makefiles 3. Allows the GUI to show what (and why) things are out of date. - IF.. we could get the info out of "make"! Reasons to write our own make digraph algorithm: 1. Probably less work than all the glue needed to interface with external "make" 2. Less worry about additional tools to be built for Win32 3. GUI can know which targets are up-to-date, without second-guessing the Makefile - Remember, it seems Make can't tell us nicely what is out of date! 4. Stick it in a library, give the library IPC capability - and let the suite tools talk to each other about what files are still open. Mitigating reasons it isn't evil to writing our own make digraph: 1. We could (conceivably) write out a Makefile equivalent for the user to use. 2. If we decided to be masochistic, we could work with Makefiles - similarly to how xgsch2pcb works with gsch2pcb files. Probably not a great idea though, as we could not realistically hope to re-write make and/or support _all_ the syntax make does. 3. User can still choose _not_ to use the tool! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
On Feb 9, 2010, at 11:40 AM, Peter Clifton wrote: "Make" is the tool. Not for a GUI, it isn't. Seriously. Right concept, bad integration. Any attempt to solve the suite of problems here without "make" will wind up as a crummy imitation of "make". Some problems simply are not well suited to GUI. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
Chris Cole wrote: Jason wrote: To me, The 'A' answer is to treat the gui like a scripted workflow. All the CLI pieces underneath adhere to the Unix flexibility philosophy, and a scripted UI/GUI joins it all together into your particular workflow by calling each CLI program with the appropriate options based on user input. Well put. This is why I don't necessarily think it's a bad idea to include gsch2pcb, or the ability to create a netlist, etc. in a GUI tool. Maybe it's not particularly suited inside gschem, however and the real tool that's missing is a gEDA IDE to help with the design workflow? I haven't been particularly fond of IDE's in the past, but that's mostly because they were software development IDE's and I like to write code in Emacs :) Wow, holy code-doesn't-die, batman!. This thread got me to thinking about some old code I wrote. So I did some searching and found it. dvd9to5 was a Perl script I wrote years ago for backing up my DVDs. This was before dual-layer burnable discs. You can find it here [1]. It's a good example of what I was trying to describe. Although, please ignore coding style, comments, capitalization, attitude, swearing, and the language Perl. I've learned a lot (at least, what _not_ to do) since I wrote that. However, it's a good example of wrapping individual CLI tools into one workflow to get a job done. thx, Jason. [1] - http://gentoo.osuosl.org/distfiles/dvd9to5-0.1.7.tar.bz2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb action to set refdes?
Ok, so the way I eventually solved this was to set the first refdes in the element file, then paste in the subsequent parts in refdes order. The autoincrement handled it from there. The sequence is like this: LoadFrom(ElementToBuffer,packages/SYMBOLNAME) PasteBuffer(ToLayout,2000,2000,mils) FreeRotateBuffer(-72) (repeat PasteBuffer and FreeRotateBuffer four times, using trig to determine PasteBuffer coords) SaveTo(Layout) Quit() I made a Python script to generate this sequence, which I piped into pcb --listen (It would be so nice to have a real scripting language in pcb, and an interactive shell like a proper CAD program does.) Regards, Mark markra...@gmail -- Mark Rages, Engineer Midwest Telecine LLC markra...@midwesttelecine.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
On Tue, 2010-02-09 at 18:40 +, Peter Clifton wrote: > > "Make" is the tool. > > Not for a GUI, it isn't. Seriously. Right concept, bad integration. There are not enough decent hooks in make to integrate it with a GUI*. It is fine if things _work_, otherwise you would have to litter your makefile with commands to prod back status to the GUI tool. *(And if there are.. my search-fu is failing me.. try "make gui" or "gui for make" in Google, and see the frustration. "make" as a program name is about as useful as "PCB" in this regard!) Perhaps I take this back... Anjuta seems to do a decent job of second-guessing what make and autotools are up-to from within a GUI. This is probably in part due to the predictability of autotools generated Makefiles. It seems to have some smarts to figure out which command line invocations are compiling what file - so it displays more intelligible output for these commands, rather than the whole GCC command line. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
Jason wrote: Chris Cole wrote: Jason wrote: Chris Cole wrote: Just curious, why not include xgsch2pcb functionality inside of gschem? As an aside, the first thing that lept to mind, was the Unix philosophy of "one tool, one job." So, I started digging to find where it came from. It's one of those "quoted all over the place, but no origin to be found" kind of phrases. The best I could find was this [1], which sums it up nicely. I personally don't use xgsch2pcb. I run gsch2pcb from a Makefile, but that's my personal preference. I prefer to script jobs that shouldn't need to be interactive. ymmv. I personally don't use xgsch2pcb either (I might if it were part of gschem)... I'm definitely a script jockey too, but sometimes I like to look at things from the perspective of those who can't / won't be script jockeys. You know, the kind of people who are used to using windows software and don't want to have to drop into a shell every 5 seconds to run commands. I think the Unix design philosophy is nice for programs designed to be run strictly from the command line -- but I think the line blurs a tad-bit when you cross over into a UI-based programs. What's the workflow for a Windows-based EDA program like Eagle? To me, The 'A' answer is to treat the gui like a scripted workflow. All the CLI pieces underneath adhere to the Unix flexibility philosophy, and a scripted UI/GUI joins it all together into your particular workflow by calling each CLI program with the appropriate options based on user input. Well put. This is why I don't necessarily think it's a bad idea to include gsch2pcb, or the ability to create a netlist, etc. in a GUI tool. Maybe it's not particularly suited inside gschem, however and the real tool that's missing is a gEDA IDE to help with the design workflow? I haven't been particularly fond of IDE's in the past, but that's mostly because they were software development IDE's and I like to write code in Emacs :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
Peter Clifton wrote: On Tue, 2010-02-09 at 10:57 -0500, Jason wrote: Chris Cole wrote: Just curious, why not include xgsch2pcb functionality inside of gschem? As an aside, the first thing that lept to mind, was the Unix philosophy of "one tool, one job." So, I started digging to find where it came from. It's one of those "quoted all over the place, but no origin to be found" kind of phrases. The best I could find was this [1], which sums it up nicely. That fits really well with a command-line approach. It really increases usability of the whole. I would also venture to suggest that this design philosophy has (probably) come about from a time when GUIs were not in common use. True. With a GUI approach - the boundaries of the user interface do not need to match the logical boundaries of the operations involved. Things become more document oriented. Why should I load "open-office-print-spooler" when I can click the print button in my "open-office-text-editor" program? Right, see my other email about the GUI being a scripted wrapper of CLI tools for a given workflow. IMO, the Unix philosophy can still apply - only you have to look deeper under the user-interface. Libraries, code abstraction and similar techniques play a part. Defined interfaces between separate programs are also important - such as the file-based forward-annotation interface between gschem and PCB. "libgerbv" is good at loading gerbv files. That means we could add that functionality to a number of other programs as convenient without re-inventing the wheel. We don't need (or want) separate GUI tools such as gbr2pcb gbr2lpr gbr2pdf gbr2ps, as might be sensible for UNIX command line tools. (NB. Such tools could probably be implemented quite trivially using libgerbv) Agreed, code maintenance comes into play. having libgerbv be the one spot for code to interact with gerber files make sense. I've seen numerous times programmers abstracting just for the sake of abstracting. eg one guy was 'refactoring' (a word I hate) his code so that you could open a file, or a TCP socket or a UDP socket with one function call. My, "Why?" earned me a dumb look. I personally don't use xgsch2pcb. I run gsch2pcb from a Makefile, but that's my personal preference. I prefer to script jobs that shouldn't need to be interactive. ymmv. I use scripts a lot when working with text-based tasks, such as programming and building code. For gEDA, when working in a GUI, I find xgsch2pcb much more convenient than typing. Similarly with Lyx.. I let its GUI take care of building the right image formats and running pdflatex for me. I _could_ do it manually, but I find it much more convenient to hit the "preview PDF" button in the editor GUI. Yeah, I tried four different CLI email clients and couldn't get them to work right for my email workflow. I eventually settled on setting up an imap server and a vpn. I've been using Thunderbird for years now with this setup. It isn't ideal, but it does allow me to get my job done with minimal hassle. thx, Jason. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
> "Make" is the tool. Not for a GUI, it isn't. Seriously. Right concept, bad integration. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
Chris Cole wrote: Jason wrote: Chris Cole wrote: Just curious, why not include xgsch2pcb functionality inside of gschem? As an aside, the first thing that lept to mind, was the Unix philosophy of "one tool, one job." So, I started digging to find where it came from. It's one of those "quoted all over the place, but no origin to be found" kind of phrases. The best I could find was this [1], which sums it up nicely. I personally don't use xgsch2pcb. I run gsch2pcb from a Makefile, but that's my personal preference. I prefer to script jobs that shouldn't need to be interactive. ymmv. I personally don't use xgsch2pcb either (I might if it were part of gschem)... I'm definitely a script jockey too, but sometimes I like to look at things from the perspective of those who can't / won't be script jockeys. You know, the kind of people who are used to using windows software and don't want to have to drop into a shell every 5 seconds to run commands. I think the Unix design philosophy is nice for programs designed to be run strictly from the command line -- but I think the line blurs a tad-bit when you cross over into a UI-based programs. What's the workflow for a Windows-based EDA program like Eagle? To me, The 'A' answer is to treat the gui like a scripted workflow. All the CLI pieces underneath adhere to the Unix flexibility philosophy, and a scripted UI/GUI joins it all together into your particular workflow by calling each CLI program with the appropriate options based on user input. I've done this with Perl a long time a go (it hurts to recall it ;-) ). And it works really well, other than the unnecessary use of Perl. The thing it misses is the "one GUI for everyone" philosophy of windows programs. Which, I can personally do without. The idea that everyone thinks/works the same is just fundamentally wrong. Especially with anything complicated. thx, Jason. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
On Feb 9, 2010, at 9:45 AM, Peter Clifton wrote: I'm not totally opposed to teaching gschem how to call gnetlist and export various netlist formats, It would be nice to teach gschem to call "make": that's the way to put the pieces together. This should be a simple scripting problem, except that the gschem scripting API is undocumented, so one needs to be a world's expert on gschem/libgeda internals to write it. If I was one of those world's experts, I'd want to give the API documentation high priority, if only to get myself out of design loops like this. but where it starts to fall apart is this.. A single schematic is rarely a sufficient description to generate your design netlist. Only very small designs will 1 schematic -> 1 board, and that means the "File->Export->PCB netlist" option will not produce useful output for (probably) the majority of board designs using PCB. We have no concept which allows us to find (given one open schematic), which other schematics must be netlisted to together in a given project. It seems especially tricky from the point of view of schematic reuse. This is where the prerequisite for "better integration" comes - introducing the concept of a project. "Make" is the tool. The flow contains more than just gschem->netlist. There are all sorts of data products in a project: BOM, simulations, documentation, etc. Often more than one board, and maybe even an ASIC. "Make" can help keep track of all this. And it's enormously handy to have a Makefile for a complex project that has been on ice for a couple of years. No need to remember the build procedures... John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
On Tue, 2010-02-09 at 10:57 -0500, Jason wrote: > Chris Cole wrote: > > Just curious, why not include xgsch2pcb functionality inside of gschem? > > > > As an aside, the first thing that lept to mind, was the Unix philosophy > of "one tool, one job." So, I started digging to find where it came > from. It's one of those "quoted all over the place, but no origin to be > found" kind of phrases. > > The best I could find was this [1], which sums it up nicely. That fits really well with a command-line approach. It really increases usability of the whole. I would also venture to suggest that this design philosophy has (probably) come about from a time when GUIs were not in common use. With a GUI approach - the boundaries of the user interface do not need to match the logical boundaries of the operations involved. Things become more document oriented. Why should I load "open-office-print-spooler" when I can click the print button in my "open-office-text-editor" program? IMO, the Unix philosophy can still apply - only you have to look deeper under the user-interface. Libraries, code abstraction and similar techniques play a part. Defined interfaces between separate programs are also important - such as the file-based forward-annotation interface between gschem and PCB. "libgerbv" is good at loading gerbv files. That means we could add that functionality to a number of other programs as convenient without re-inventing the wheel. We don't need (or want) separate GUI tools such as gbr2pcb gbr2lpr gbr2pdf gbr2ps, as might be sensible for UNIX command line tools. (NB. Such tools could probably be implemented quite trivially using libgerbv) The really important point, is not to forget that individual automatable tasks can still be _very_ useful in a work-flow. The question should not be "why does your schematic editor have a kitchen-sink attached", rather.. can I still use a separate "kitchen-sink" if I want to. > I personally don't use xgsch2pcb. I run gsch2pcb from a Makefile, but > that's my personal preference. I prefer to script jobs that shouldn't > need to be interactive. ymmv. I use scripts a lot when working with text-based tasks, such as programming and building code. For gEDA, when working in a GUI, I find xgsch2pcb much more convenient than typing. Similarly with Lyx.. I let its GUI take care of building the right image formats and running pdflatex for me. I _could_ do it manually, but I find it much more convenient to hit the "preview PDF" button in the editor GUI. Best regards, Peter C. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
On Tue, 2010-02-09 at 10:10 -0500, Chris Cole wrote: > > I think I see what you're saying...however as an example...if I'm > working in OpenOffice.org, I have the ability to save as ODF, PDF > or even (*gasp*) a proprietary format, although I may never use > more than one workflow. And I wasn't saying that xgsch2pcb should > be a drop-in window "as-is" to gschem, but I think it would be rather > nice if you could generate netlists and output to pcb straight from > gschem. Just a thought. I might even be willing to help if anyone else > is interested in the idea. Those Openoffice examples work because the data-formats it exports to are "compatible" with the contents of the native document. PDF is a natural export for a document, and if it can be translated, so are other formats for writing office documents. I'm not totally opposed to teaching gschem how to call gnetlist and export various netlist formats, but where it starts to fall apart is this.. A single schematic is rarely a sufficient description to generate your design netlist. Only very small designs will 1 schematic -> 1 board, and that means the "File->Export->PCB netlist" option will not produce useful output for (probably) the majority of board designs using PCB. We have no concept which allows us to find (given one open schematic), which other schematics must be netlisted to together in a given project. This is where the prerequisite for "better integration" comes - introducing the concept of a project. Best wishes, Peter C. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
Jason wrote: Chris Cole wrote: Just curious, why not include xgsch2pcb functionality inside of gschem? As an aside, the first thing that lept to mind, was the Unix philosophy of "one tool, one job." So, I started digging to find where it came from. It's one of those "quoted all over the place, but no origin to be found" kind of phrases. The best I could find was this [1], which sums it up nicely. I personally don't use xgsch2pcb. I run gsch2pcb from a Makefile, but that's my personal preference. I prefer to script jobs that shouldn't need to be interactive. ymmv. I personally don't use xgsch2pcb either (I might if it were part of gschem)... I'm definitely a script jockey too, but sometimes I like to look at things from the perspective of those who can't / won't be script jockeys. You know, the kind of people who are used to using windows software and don't want to have to drop into a shell every 5 seconds to run commands. I think the Unix design philosophy is nice for programs designed to be run strictly from the command line -- but I think the line blurs a tad-bit when you cross over into a UI-based programs. What's the workflow for a Windows-based EDA program like Eagle? Chris ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
Chris Cole wrote: Just curious, why not include xgsch2pcb functionality inside of gschem? As an aside, the first thing that lept to mind, was the Unix philosophy of "one tool, one job." So, I started digging to find where it came from. It's one of those "quoted all over the place, but no origin to be found" kind of phrases. The best I could find was this [1], which sums it up nicely. I personally don't use xgsch2pcb. I run gsch2pcb from a Makefile, but that's my personal preference. I prefer to script jobs that shouldn't need to be interactive. ymmv. thx, Jason. [1] - http://www.faqs.org/docs/artu/ch01s06.html ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: Latex
gene glick wrote:
Do you all use Latex for editing docs, or maybe open office or other?
I'm getting fed up with the open office bugs and starting to think that
Latex is a better alternative. Busy compiling Lyx as we speak.
Just curious if it works out well-
I switched to LaTeX 15 years ago and have never looked back. mmm
LaTeX.
\begin{shamelessplug}
You may also want latex-mk available at http://latex-mk.sf.net
\end{shamelessplug}
I have never bothered with Lyx. Since switching to LaTeX I have used it
for class handouts, a thesis, a book, a couple of journal papers, many
letters, memos, technical documents, and more. The ability to collect
data and get it formatted in a programming fashion and the ability
control it all via a makefile has been a huge benefit to me.
Before switching I was a die hard word user. I'd actually taken the
time to read the entire manual and felt like I qualified as an expert
user of it. But I finally hit a point where it just wasn't working well
for a bunch of reasons (bugs, poor scaling to large documents, poor
multi-author support, poor interaction with cvs or other source control
system, poor/no interaction with other scripting, and more). I'm sure
some of those things are different now, but you couldn't pay me to
switch back.
-Dan
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
Peter Clifton wrote: On Tue, 2010-02-09 at 09:39 -0500, Chris Cole wrote: Just curious, why not include xgsch2pcb functionality inside of gschem? xgsch2pcb was implemented as a proof of concept project manager, and doesn't really "belong" inside gschem. gschem supports a great diversity of work-flows, only one of which involves producing PCBs with the "PCB" package. This means it would be in-appropriate the make assumptions along these lines in the gschem UI. I think I see what you're saying...however as an example...if I'm working in OpenOffice.org, I have the ability to save as ODF, PDF or even (*gasp*) a proprietary format, although I may never use more than one workflow. And I wasn't saying that xgsch2pcb should be a drop-in window "as-is" to gschem, but I think it would be rather nice if you could generate netlists and output to pcb straight from gschem. Just a thought. I might even be willing to help if anyone else is interested in the idea. There might be future scope for making gschem (and other applications) "project aware", but that would likely be much less explicit than xgsch2pcb, as it would need to cater for (or keep out of the way of) all other work-flows. Better integration is a personal goal of mine though. Best wishes, Peter C ___ 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: why separate xgsch2pcb?
On Tue, 2010-02-09 at 09:39 -0500, Chris Cole wrote: > Just curious, why not include xgsch2pcb functionality inside of gschem? xgsch2pcb was implemented as a proof of concept project manager, and doesn't really "belong" inside gschem. gschem supports a great diversity of work-flows, only one of which involves producing PCBs with the "PCB" package. This means it would be in-appropriate the make assumptions along these lines in the gschem UI. There might be future scope for making gschem (and other applications) "project aware", but that would likely be much less explicit than xgsch2pcb, as it would need to cater for (or keep out of the way of) all other work-flows. Better integration is a personal goal of mine though. Best wishes, Peter C ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: why separate xgsch2pcb?
Just curious, why not include xgsch2pcb functionality inside of gschem? Chris ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb action to set refdes?
On Tue, 2010-02-09 at 00:12 -0500, DJ Delorie wrote:
> > They are new components. We are panelizing a board with several
> > variants of a tricky footprint to see which one will work best in the
> > SMT process.
>
> Perhaps you could hack the new Import code to specify the placement of
> parts being added, perhaps via an Attribute() ? The default is to
> place the part at 0,0 but if you look for an override...
xgsch2pcb already allows pasting at an offset, as it uses the
paste-buffer.
Here is a snipped from its "pcbmanager.py":
if self.pcb_actions_iface.ExecAction("LoadFrom", ["LayoutToBuffer",
newparts]):
# TODO: WARN USER?
pass
# Paste the new components near the origin
if self.pcb_actions_iface.ExecAction("PasteBuffer",
["ToLayout","10","10","mil"]):
# TODO: WARN USER?
pass
I'm sure, given a known footprint origin on your file, you could
"FootprintToBuffer" and then paste with a programmed offset.
Best wishes,
Peter C.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Translations for gEDA 1.6.1....
On Sun, 2010-02-07 at 12:05 +0100, Bert Timmerman wrote: > How to translate accelerator stuff ? > > en: "_Save" > > nl: "Opslaan" > > or > > nl: "_Opslaan" and break the key binding ? Whatever is common in other translated programs.. For the former, did you mean "Op_slaan"? That would work, and keep the "s" key binding. (IF), it is common to have Alt+F, then "S" for save as the keyboard short-cut. Bert, please note that I've update the stable branch translations again recently, so to avoid merge conflicts, it would be good to grab the starting .po files from the stable-1.6 branch of the repository. Assuming you have a checkout of the git.gpleda.org repository, you want something like git checkout -b for-stable-1.6 orgin/stable-1.6 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Translations for gEDA 1.6.1....
Hi Peter, Florian, On Sun, 2010-02-07 at 09:35 +0100, Florian Teply wrote: > On Sunday 07 February 2010 00:42:29 Peter Clifton wrote: > > Hi guys, > > > > In preparation for the gEDA 1.6.1, I've been trying to sort out our > > translations. I've imported all translations from Launchpad, and have > > been reviewing places where untranslated strings were visible in gschem. > > > > Unfortunately, we've got a lot of broken menu translations - due to > > incorrect strings in rcstrings.c. (Mostly my fault probably!) > > > > Mostly this was due to adding "_Accelerators" to the menu text, but not > > updating rcstrings.c > > > Just to get Things straight: that _Accelerator stuff is the Keyboard entry > mode for menus, right? So just like +, for Hierarchy -> Up? > > Regards, > Florian > > How to translate accelerator stuff ? en: "_Save" nl: "Opslaan" or nl: "_Opslaan" and break the key binding ? Please advice ! Kind regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Translations for gEDA 1.6.1....
Hi Peter, On Sun, 2010-02-07 at 11:32 +, Peter Clifton wrote: > On Sun, 2010-02-07 at 09:35 +0100, Florian Teply wrote: > > On Sunday 07 February 2010 00:42:29 Peter Clifton wrote: > > > Hi guys, > > > > > > In preparation for the gEDA 1.6.1, I've been trying to sort out our > > > translations. I've imported all translations from Launchpad, and have > > > been reviewing places where untranslated strings were visible in gschem. > > > > > > Unfortunately, we've got a lot of broken menu translations - due to > > > incorrect strings in rcstrings.c. (Mostly my fault probably!) > > > > > > Mostly this was due to adding "_Accelerators" to the menu text, but not > > > updating rcstrings.c > > > > > Just to get Things straight: that _Accelerator stuff is the Keyboard entry > > mode for menus, right? So just like +, for Hierarchy -> Up? > > Actually, no - I was referring to the underlined letters on a menu which > let you access the menu-item by letter when it is open. For example, > most application have "_File" "_Edit" etc... so you can do Alt+F+... > > Actually, gschem doesn't accelerate any of its top-level menus. I can't > recall why we never did this - but it might also be worth doing for > 1.6.1. (Assuming we call the lack of accelerators a "bug"). > > > We are kind-of duplicating functionality with our existing hot-keys, but > it's not uncommon for applications to have both menu accelerators, and > keyboard short-cuts (which are usually modifier key based). > > Peter > > > How to translate accelerator stuff ? en: "_Save" nl: "Opslaan" or nl: "_Opslaan" and break the future accelerator key binding ? Kind regards, Bert Timmerman. BTW: this e-mail, and a similar reply to Florian's, might show up on the list in 5 days or so. I'm experience strange, and random, lags when posting to geda-user or geda-dev. Looks like a Heisenbug in the mailman to me :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Translations for gEDA 1.6.1....
On Sun, 2010-02-07 at 12:03 +, Peter Clifton wrote: > On Sun, 2010-02-07 at 12:56 +0100, Bert Timmerman wrote: > > Hi Peter, > > > How to translate accelerator stuff ? > > > > en: "_Save" > > > > nl: "Opslaan" > > > > or > > > > nl: "_Opslaan" and break the future accelerator key binding ? > > I'd go with whatever fits best with the rest of the applications on the > system. > The first option is quick to do - of course, and one I could have > bulk-updated for people, but I wanted to give translators the choice. > > You could have: > > nl: "Op_slaan" > > If you want to keep "s" the accelerator key. > No diff with low caps ? > If you change the accelerators keys, you need to do it in the context of > an open gschem menu - and make sure the ones you decide to assign don't > clash with each other in a given menu. > Where there is no easy match, I better leave out the "_" to avoid conflicts. > > > > BTW: this e-mail, and a similar reply to Florian's, might show up on the > > list in 5 days or so. > > I'm experience strange, and random, lags when posting to geda-user or > > geda-dev. > > Looks like a Heisenbug in the mailman to me :) > > Ping Ales about that. It has happened before (although typically not > just to individual people, rather a general slowness in delivery). > > Kind regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
