Re: gEDA-user: Ben mode feature request
On Nov 1, 2010, at 2:01 PM, Vanessa Ezekowitz wrote: On Mon, 1 Nov 2010 10:05:17 -0600 John Doty j...@noqsi.com wrote: What you want doesn't matter. What the *job* needs is the thing that matters. Suppose the user can't get the job done *at all* without whatever feature is being proposed? That is the crux of my argument here. The key to problem-solving ... is to identify the right primitive operations and to put them at the right place. ... Merely adding features does not make it easier for users to do things — it just makes the manual thicker. -- Brian Kernighan and Rob Pike So, if the job can't be done, asking for a feature is the wrong approach. The first step is to figure out what primitive operation is missing from the toolkit. Sometimes when you ask that question, the answer is nothing, because merely asking that question focuses your attention on the tools, and you find a way. Other times, the necessary primitive operation is best implemented with a separate tool. Piling everything into a single tool as features leads to inflexibility and low productivity. It might be okay for a tool with limited horizons, but it is important to preserve toolkits like gEDA that serve wide horizons with minimal complexity. This is not to say that I am not intelligent enough to use a simulator outside of a GUI environment - I defy anyone to make that argument. Rather, it means I am not necessarily *skilled* enough to use one. The thing is, I shouldn't need to learn any special skills just to simulate a simple circuit. Indeed. But in fact, I bet if you did a time and motion study you'd find that typing commands is much faster than point and click. Point and click is a seductive time waster *except* for inherently graphical parts of the job. For some things, the command line is a little faster, but for some stuff, it doesn't make any sense. It also depends on how the interface in question is implemented and whether you are a particularly fast and accurate typist. I, for example, can barely manage 40 words a minute. I'm slower than that. But unlike button pushes, commands don't have to be retyped much. Any time I find myself doing the same thing repeatedly, I can make an alias, script, or makefile rule. And these approaches can be combined to automate very complex operations triggered by simple commands. But GUI operations generally depend on having a human guide them (by selecting something, filling out a form, etc.), so they are much less friendly to automation. In the case of the little script I mentioned, to run it I must open a terminal via a hotkey I already have set up for that purpose, hit ctrl-r and a few keys to find the command, hit Enter, and then supply my password. All told, it takes about 15 seconds and about 20 keypresses. Why do you tolerate such barriers? For one gEDA project, I recently had a simple change request. I hadn't worked on the project in months, but a quick grep for the refdes found the page, five minutes with gschem made the change (GUI *in its place* is great), then typing make rebuilt 50 pages of documentation, a 600 part BOM, and the netlist in the customer's requested format. The project's structure is specific to the customer's requirements, but I don't have to remember those details: the makefile remembers them for me. That's ease and productivity. No need to remember some complicated path through incomprehensible menus. On a bad day, my own inability to type accurately can inflate those figures significantly. Hell, just getting past the login prompt can take that long on a particularly bad day. On the other hand, I could just set up sudo to allow that script to run without my password, in which case a single click of the mouse would start the backup. It would undoubtedly save time, and save a lot of typing, but it's also insecure, as far as I'm concerned. Any other command line function I do is generally slowed down by the same problems, as are things such as this email. All you're saying is that you don't use the command line functions effectively. That's OK: work however you want. But then please don't ask that gEDA, an unusually effective toolkit for a different approach than yours, be changed to reflect a less flexible and scalable approach. You want a different tool. Your implication here is that these tools are and should be reserved only for experts, Absolutely not. However, there should exist tools that serve needs of experts. There are lots of tools out there that sacrifice productivity and flexibility for user comfort. Fair enough, but it doesn't have to be that way. The stupidity of some programmers' design decisions does not imply that *all* programmers make stupid decisions. The existence of a feature does not imply the requirement to *use* that feature, or the requirement to discard whatever feature(s) it is capable of replacing. Part
Re: gEDA-user: Ben mode feature request
John Griessen wrote: That is a standard feature of the usual chip design software Not only chip design software. Many mechanical design applications provide this feature, too. autocad, varicad, ustation are just those, I got in touch with. ---)kaimartin(~~~--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Vanessa Ezekowitz vanessaezekow...@gmail.com writes: On Mon, 1 Nov 2010 13:46:51 -0700 Steven Michalske smichal...@gmail.com wrote: I code the latter way, writing a good low level API that has a simple command line UI, then I add the GUI on top of it when it is warranted. Which is precisely what I was suggesting; since such tools obviously already exist, why not build a GUI (or adapt an existing one) some time in the future that makes use of them as a backend, for those whose needs can't be met using only CLI tools? Well, the public was invited to do exaclty that for years, but the need for such a GUI was obviously not too urgent, so it never got very far. The problem is probably, that the heavy coders here do not want to use it themselves, so and those who want to use the GUI do not want to code it. I don't know how I should judge the situation. When our Linux-using students observe the unix plumbing magic that I type into the xterm all day, and ask how they can learn all this, I reply that they should never have started to use the graphical file manager of their shiny desktop, but use a simple window manager and fire up a lot of xterms. OTOH, they'd be using Windows instead, if that was their only option. I could easily convert my eagle using colleagues to geda with an integrating GUI, but then their productivity will not necessarily go much beyond what they do with eagle. A GUI that does not hide the magic is a good way to go. For example, a history window that records all executed PCB actions during a point and click session, that could be replayed as a script to repeat all steps would be helpfull. And to cut and paste actions into the :command window. I once did a push button digital ASIC design that way. After place and route I manually added the power distribution and similar touchups to the layout. Then I copied the actions into a script, that was later called from a Makefile whenever I had to rerun place and route. The Makefile basically did the complete chip from scratch. Modify a verilog source file, type make, and got a new complete layout, synthesized, simulated, place and route, LVS and DRC included. I could only do that, without any prior experience with the tools, because of that history window. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Nov 2, 2010, at 9:44 AM, Stephan Boettcher wrote: When our Linux-using students observe the unix plumbing magic that I type into the xterm all day, and ask how they can learn all this, They perceive that software is necessarily a tangled mess because the GUI things they use are tangled messes, full of *hidden* magic. They don't see the command line stuff as simple independent tools that can easily be learned one at a time, as needed. 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: Ben mode feature request
On 11/02/2010 10:44 AM, Stephan Boettcher wrote: A GUI that does not hide the magic is a good way to go. For example, a history window that records all executed PCB actions during a point and click session, that could be replayed as a script to repeat all steps would be helpfull. And to cut and paste actions into the :command window. That is a standard feature of the usual chip design software that runs on Solaris or Linux. Putting the commands in a window that can be scrolled to see them is a very helpful feature. It keeps you able to quickly make scripts to automate anything that needs repetition. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 31 Oct 2010 20:39:40 -0600 John Doty j...@noqsi.com wrote: On Oct 31, 2010, at 2:31 PM, Markus Hitter wrote: Then, there are many people which know cp xxx yyy, but prefer to avoid it anyways. You want to catch these. You don't want to dumb down the toolkit [...] gEDA is the toolkit for *experts* doing *great* things *now*. Let's not lose that. One size does not fit all here. Ok... Sorry, John, but I have to stop you right there, as you are completely missing the point. To clarify Markus' example somewhat: I don't want to have to fire up a terminal every time I want to copy some random file to/from a thumbdrive, memory card, etc. Sometimes, I'd rather just plug the damn thing in and let a file manager pop up so that I can handle it from there. It isn't because I can't, it's because I don't *want* to. On the other hand, I use a simple script that uses rsync to back up a few important partitions and directories and take logs of the activity, which is best run from a command line, because for that particular case, it is the right tool for the job. rant mode=on To bring this back into context, I am by no means an expert in electronics or programming, but I am reasonably good at the few things I do with gEDA and PCB, at least so say the other folks who are in my particular field. Your implication here is that these tools are and should be reserved only for experts, which is akin to saying that everyone else should basically just uninstall their copies of these programs and get out of the way, even if the intent is to help improve the project. Um, no. In the old days it was common, if not *expected*, for a person to first draw his or her schematic on paper and then lay out a board on one or another physical media prior to etching. Hell some people *still* do it this way if it is more convenient to do so. What we didn't have back then was an easy way to do circuit simulation - you did your truth tables and math on paper, built a prototype on plugboard, and then prayed that it passed the initial smoke test when you switched it on. Now we have easy to use systems to allow one to design a schematic and ensure that the board created from it is at least electrically identical, so far as the copper is concerned anyway. We just need the equivalent for circuit simulation. Some reasonably good GUI tools already exist for this (Xcircuit, QUCS), they're just not part of (or compatible with) the gEDA suite. Just because one is doing this on a computer instead of paper does NOT mean one should be forced to use the command line to do it. Computers are supposed to make things easier for people, and allow them to be more productive; that's what they were created for. If introducing a computer to a user's workflow doesn't improve his or her productivity, then either the computer is simply the wrong tool altogether, or the person responsible for the software therein is the one who is at fault. In the commercial world, if the software were the problem, one would of course blame the admin for installing ineffective programs, or the programmer(s) for failing to understand what users really need. I hesitate to make that claim against gEDA, since it is a *very* effective tool set, and the need for improvement is clearly recognized (or we wouldn't be discussing this). The existence of a GUI does not have to preclude the use of equivalent command-line utilities. /rant -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://starbase.globalpc.net/~ezekowitz Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Nov 1, 2010, at 12:32 AM, Vanessa Ezekowitz wrote: On Sun, 31 Oct 2010 20:39:40 -0600 John Doty j...@noqsi.com wrote: On Oct 31, 2010, at 2:31 PM, Markus Hitter wrote: Then, there are many people which know cp xxx yyy, but prefer to avoid it anyways. You want to catch these. You don't want to dumb down the toolkit [...] gEDA is the toolkit for *experts* doing *great* things *now*. Let's not lose that. One size does not fit all here. Ok... Sorry, John, but I have to stop you right there, as you are completely missing the point. To clarify Markus' example somewhat: I don't want to have to fire up a terminal every time I want to copy some random file to/from a thumbdrive, memory card, etc. Sometimes, I'd rather just plug the damn thing in and let a file manager pop up so that I can handle it from there. It isn't because I can't, it's because I don't *want* to. What you want doesn't matter. What the *job* needs is the thing that matters. On the other hand, I use a simple script that uses rsync to back up a few important partitions and directories and take logs of the activity, which is best run from a command line, because for that particular case, it is the right tool for the job. Indeed. But in fact, I bet if you did a time and motion study you'd find that typing commands is much faster than point and click. Point and click is a seductive time waster *except* for inherently graphical parts of the job. rant mode=on To bring this back into context, I am by no means an expert in electronics or programming, but I am reasonably good at the few things I do with gEDA and PCB, at least so say the other folks who are in my particular field. Your implication here is that these tools are and should be reserved only for experts, Absolutely not. However, there should exist tools that serve needs of experts. There are lots of tools out there that sacrifice productivity and flexibility for user comfort. I am tremendously grateful to Ales for creating a toolkit that can do what I *need* rather than what some marketer decided I would want. which is akin to saying that everyone else should basically just uninstall their copies of these programs and get out of the way, even if the intent is to help improve the project. I have a Jeep with a manual transmission and manual transfer case. Most drivers today would consider an automatic transmission and all wheel drive an improvement. But the manual controls enable me to drive through nasty conditions where more automatic vehicles get stuck (getting up my driveway is often the worst problem). I live high in the mountains, so this is important to me. It is a good thing that that the comfort of the majority did not dictate the design of this vehicle. Um, no. In the old days it was common, if not *expected*, for a person to first draw his or her schematic on paper and then lay out a board on one or another physical media prior to etching. Hell some people *still* do it this way if it is more convenient to do so. What we didn't have back then was an easy way to do circuit simulation - you did your truth tables and math on paper, built a prototype on plugboard, and then prayed that it passed the initial smoke test when you switched it on. Now we have easy to use systems to allow one to design a schematic and ensure that the board created from it is at least electrically identical, so far as the copper is concerned anyway. We just need the equivalent for circuit simulation. With gEDA, we already have that for chip design. I have the working silicon to prove it. And this is a place where gEDA's superior scriptability really shines: it's a *massive* waste of time to run a comprehensive series of simulations manually after changing something. Some reasonably good GUI tools already exist for this (Xcircuit, QUCS), they're just not part of (or compatible with) the gEDA suite. The most difficult problem here is outside of our control: obtaining models compatible with whatever simulator you prefer. But on my gedasymbols page you'll find some *simple* opamp models, and a bunch of symbols for my friend Professor Ikeda's Openip library of models for mixed-signal VLSI design. I know somebody who has used the Openip symbols and models as an aid for learning logic design. You don't, of course, actually need to go all of the way to silicon. The overloading of pinseq= is also troublesome for simulating slotted components, but fixing this requires no changes to the gEDA core: it's implemented in the spice and spice-sdb back ends. And one really cool thing here is that a gnetlist back end can generate symbolic equations for a circuit, so you can do things like find the ratio of RC time constants that give critical damping. Again, that's enormously more productive than tweaking a simulation. Where's the find critical damping condition button on your favorite GUI
Re: gEDA-user: Ben mode feature request
On Nov 1, 2010, at 9:05 AM, John Doty wrote: Putting a GUI on non-graphical functions *almost always* torques the design away from effective scripting. You can claim this isn't necessarily so, but actual software designers aren't usually smart enough to avoid this trap. Agreed 100% This is why I cringe when the guys I write tests for ask for a GUI for the test. When all they want is a message box. and they could just read the big bold line on the terminal that says Pass or FAIL! :-) Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On 11/01/2010 11:05 AM, John Doty wrote: Point and click is a seductive time waster*except* for inherently graphical parts of the job. A lot of layout is. Rearranging some sets of files' locations is faster by GUI than by commands, since whole swaths of files can be moved at once after a quick selection task done visually. (and no, regexp's would not help this.). JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Nov 1, 2010, at 10:49 AM, John Griessen wrote: On 11/01/2010 11:05 AM, John Doty wrote: Point and click is a seductive time waster*except* for inherently graphical parts of the job. A lot of layout is. Rearranging some sets of files' locations is faster by GUI than by commands, since whole swaths of files can be moved at once after a quick selection task done visually. (and no, regexp's would not help this.). I like combining GUI and command line, select the files in the gui and drag to the terminal! JG ___ 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: Ben mode feature request
On Nov 1, 2010, at 11:49 AM, John Griessen wrote: On 11/01/2010 11:05 AM, John Doty wrote: Point and click is a seductive time waster*except* for inherently graphical parts of the job. A lot of layout is. Sure. That's a good use of GUI. But parts selection, assigning pin numbers, revision control, document generation, running simulations (as opposed to inspecting siumulation results), etc. are all fundamentally clerical tasks where a GUI gets in the way, especially if the job is outside the GUI designer's necessarily limited horizon. But there's lots of overlap. For example, gattrib is great for a little touch up of a few attributes, but for larger scale changes it is a time waster. Because gattrib is a separate tool communicating through a clean interface whose design it did not influence, it's also harmless. An integrated gattrib would be much more troublesome. Rearranging some sets of files' locations is faster by GUI than by commands, since whole swaths of files can be moved at once after a quick selection task done visually. I bet if you actually measured the time, you wouldn't find the selection as quick as you think. GUI's warp perception. They make things easy, not quick. (and no, regexp's would not help this.). They do for me. mv `ls | grep ...` wherever. But mostly I try not to get into a mess where there are large numbers of files in a directory. 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: Ben mode feature request
On 11/01/2010 01:35 PM, John Doty wrote: (and no, regexp's would not help this.). They do for me. mv `ls | grep ...` wherever. But mostly I try not to get into a mess where there are large numbers of files in a directory. We're going to be doing things differently with our different approaches is all. And as PCB gets more ease of use features, you are still not going to be using it, and if you did, you could still script it and gschem and gnetlist as much. On 11/01/2010 01:35 PM, Steven Michalske wrote: I like combining GUI and command line, select the files in the gui and drag to the terminal! Sounds like a trick! Does that work with the GUI program known as GNOME Terminal? John G ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Nov 1, 2010, at 11:46 AM, John Griessen j...@ecosensory.com wrote: On 11/01/2010 01:35 PM, Steven Michalske wrote: I like combining GUI and command line, select the files in the gui and drag to the terminal! Sounds like a trick! Does that work with the GUI program known as GNOME Terminal? Mac OS Terminal, it worked in kde I recall I get all my favorite unix and GUI applications! John G ___ 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: Ben mode feature request
John Griessen j...@ecosensory.com writes: Rearranging some sets of files' locations is faster by GUI than by commands, since whole swaths of files can be moved at once after a quick selection task done visually. not, when I count the time for cleaning up after fat-fingering a mouse button during the operation, and the whole mess was dropped in the wrong place. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Mon, 1 Nov 2010 10:05:17 -0600 John Doty j...@noqsi.com wrote: What you want doesn't matter. What the *job* needs is the thing that matters. Suppose the user can't get the job done *at all* without whatever feature is being proposed? That is the crux of my argument here. This is not to say that I am not intelligent enough to use a simulator outside of a GUI environment - I defy anyone to make that argument. Rather, it means I am not necessarily *skilled* enough to use one. The thing is, I shouldn't need to learn any special skills just to simulate a simple circuit. Indeed. But in fact, I bet if you did a time and motion study you'd find that typing commands is much faster than point and click. Point and click is a seductive time waster *except* for inherently graphical parts of the job. For some things, the command line is a little faster, but for some stuff, it doesn't make any sense. It also depends on how the interface in question is implemented and whether you are a particularly fast and accurate typist. I, for example, can barely manage 40 words a minute. In the case of the little script I mentioned, to run it I must open a terminal via a hotkey I already have set up for that purpose, hit ctrl-r and a few keys to find the command, hit Enter, and then supply my password. All told, it takes about 15 seconds and about 20 keypresses. On a bad day, my own inability to type accurately can inflate those figures significantly. Hell, just getting past the login prompt can take that long on a particularly bad day. On the other hand, I could just set up sudo to allow that script to run without my password, in which case a single click of the mouse would start the backup. It would undoubtedly save time, and save a lot of typing, but it's also insecure, as far as I'm concerned. Any other command line function I do is generally slowed down by the same problems, as are things such as this email. Your implication here is that these tools are and should be reserved only for experts, Absolutely not. However, there should exist tools that serve needs of experts. There are lots of tools out there that sacrifice productivity and flexibility for user comfort. Fair enough, but it doesn't have to be that way. The stupidity of some programmers' design decisions does not imply that *all* programmers make stupid decisions. The existence of a feature does not imply the requirement to *use* that feature, or the requirement to discard whatever feature(s) it is capable of replacing. Just because PCB has a schematic import function now, for example, doesn't mean people have to give up using gsch2pcb. I'm sure some will continue to use it, while others will use the import function instead (and I am quite happy it exists - thanks DJ :-) ). It is a good thing that that the comfort of the majority did not dictate the design of this vehicle. The comfort of the majority didn't dictate the design of *your* vehicle, sure, but your analogy is lacking here. I am reminded at this point of the song, Hey Little Cobra. Most of the song of course is not relevant to this discussion, but it raises one concept that wasn't even explored within the song itself: The singer owns both a Mustang and a Cadillac, the former being towed behind the latter each time he goes out to race. Obviously the singer enjoys the comfort of his Caddy, but recognizes that his hopped-up Mustang is the best choice for street racing. In the end though, both cars were designed by their OEMs for the same purpose: to move people and stuff around with some reasonable level of comfort. The same goes for your Jeep. Each car in existence has its strengths and weaknesses, whether they be speed, comfort, towing capacity/torque, economy, bragging rights, whatever. The same can be said of the gEDA suite - it is composed of many tools that are designed for the sole purpose of getting stuff done. Some parts of that suite provide a comfortable environment (PCB, Gschem), some parts are meant to do one thing and do it very fast (gsch2pcb), and others are workhorses (gnetlist). The difference between the car analogy and gEDA though, is that most cars can't easily be switched between the above duties without sacrificing something important. The same is not true of software, when you have good programmers in control, and I have every reason to believe that is the case with gEDA. Now we have easy to use systems to allow one to design a schematic and ensure that the board created from it is at least electrically identical, so far as the copper is concerned anyway. We just need the equivalent for circuit simulation. With gEDA, we already have that for chip design. I'm not talking about chip design, and unless I missed something, neither is anyone else in this thread. The overloading of pinseq= is also troublesome for simulating slotted components, but fixing this requires no changes
Re: gEDA-user: Ben mode feature request
On Mon, 01 Nov 2010 13:46:55 -0500 John Griessen j...@ecosensory.com wrote: Does that work with the GUI program known as GNOME Terminal? Works in XFCE's terminal also; drag and drop from Thunar adds a space-separated list of the absolute paths of the dropped objects to the end of the command line and leaves the cursor at the end. Any objects with spaces in the name get individually enclosed in single quotes. Huh. I never even thought to try this before. -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://starbase.globalpc.net/~ezekowitz Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
snip everything /snip I think the point John wants to make is that if you only program for a GUI, then you loose the scriptability. I have see this many times in software. Where is you write the GUI first, the scripting is an afterthought. Where as if you write something scriptable in the first place, putting a GUI on top of it is easier. I code the latter way, writing a good low level API that has a simple command line UI, then I add the GUI on top of it when it is warranted. My favorite example of fritterware is Excel spreadsheets for computation of complex formulas. Instead of a program that takes in the data files and makes the graphs and reports. I HATE taking the data files and manipulating them by hand to enter them into the spread sheets. Though this example is not GUI vs CLI, it is really GUI (Excel) vs. scripted report tool. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Am 01.11.2010 um 19:35 schrieb John Doty: the GUI designer's necessarily limited horizon. You become offending. Please go ahead and implement the CLI interface. It won't go away when the GUI arrives. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Mon, 1 Nov 2010 13:46:51 -0700 Steven Michalske smichal...@gmail.com wrote: I code the latter way, writing a good low level API that has a simple command line UI, then I add the GUI on top of it when it is warranted. Which is precisely what I was suggesting; since such tools obviously already exist, why not build a GUI (or adapt an existing one) some time in the future that makes use of them as a backend, for those whose needs can't be met using only CLI tools? This whole discussion brings to mind another comparison: Which is better, using K3B/Brasero/etc. to burn a CD or DVD, or going to the command line and directly using growisofs and/or cdrecord. Answer: whichever one works best for you - they're just two ways to use the same set of tools. -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://starbase.globalpc.net/~ezekowitz Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sunday 31 October 2010, Stefan Salewski wrote: Can you please explain why we will always need the command line for simulation in gEDA? (I have newer found the time doing simulations...) Try this without a command line: Experimentally finding model parameters: http://gnucap.org/dokuwiki/doku.php?id=gnucap:manual:examples:experimentally_finding_model_parameters Distortion analysis of an oscillator: http://gnucap.org/dokuwiki/doku.php?id=gnucap:manual:examples:phase_shift_oscillator Bandwidth analysis of an FM transmitter: http://gnucap.org/dokuwiki/doku.php?id=gnucap:manual:examples:fm_spectrum_analysis You should be able to do basic stuff without a command line, but outgrow it by your senior year in college. Most GUI's lead you into a trap. We need a GUI that teaches you to move on. We don't have it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 00:44 +0200, kai-martin knaak wrote: Evan Foss wrote: I may have missed it but has anyone suggested the brlcad format. It might be better than freecad in that it has export/import from a lot of other formats already written. It might be worse in that its user interface is prohibitively non- intuitive. I looked at the application a few years ago, when I was in need for a mechanical CAD application. Even the most simple operations required a number of complex steps. There is a whole chapter in the manual on how to move a component. The user base of brlCAD is marginal and will probably shrink even more, as more intuitive open source CAD applications will become a viable alternative. That may be true, but I am not really happy with the wording. Some kids may be tempted to do something like sed -i -e 's/brlCAD/gEDA-PCB/' ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Stefan Salewski wrote: The user base of brlCAD is marginal and will probably shrink even more, as more intuitive open source CAD applications will become a viable alternative. That may be true, but I am not really happy with the wording. Some kids may be tempted to do something like sed -i -e 's/brlCAD/gEDA-PCB/' Well, the usability of geda-PCB is not that far off-road. It is on par, or better than its main competitors kicad and eagle (in my humble opinion). That said, it is certainly true that geda looses potential users because of the command line thing. It makes the newbie expect the need for much more command line magic down the line. In reality, you just issue simple commands a few times per project. And you can avoid even these with xgsch2pcb or pcb-pull. These two work-flows really should be advertised more -- In the documentation, tutorial and in the articles in wikipedia. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Hi all, -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of kai-martin knaak Sent: Sunday, October 31, 2010 6:36 PM To: geda-u...@seul.org Subject: Re: gEDA-user: Ben mode feature request Stefan Salewski wrote: The user base of brlCAD is marginal and will probably shrink even more, as more intuitive open source CAD applications will become a viable alternative. That may be true, but I am not really happy with the wording. Some kids may be tempted to do something like sed -i -e 's/brlCAD/gEDA-PCB/' Well, the usability of geda-PCB is not that far off-road. It is on par, or better than its main competitors kicad and eagle (in my humble opinion). That said, it is certainly true that geda looses potential users because of the command line thing. It makes the newbie expect the need for much more command line magic down the line. In reality, you just issue simple commands a few times per project. And you can avoid even these with xgsch2pcb or pcb-pull. These two work-flows really should be advertised more -- In the documentation, tutorial and in the articles in wikipedia. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 Avoiding the command line won't help you on the gschem -- simulation work flow. Loosing potential users due to a command like thing is probably something a lot of *nix apps and tools suffer from. I can't help people who will not try to learn what is neccesary, or do whatever it takes, to solve their *own* problems. Sad, but true. IMHO there is no true hacker fu in them. 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: Ben mode feature request
That said, it is certainly true that geda looses potential users because of the command line thing. The demo I did at Devcon didn't use the command line at all. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sat, Oct 30, 2010 at 5:44 PM, kai-martin knaak k...@familieknaak.de wrote: Evan Foss wrote: I may have missed it but has anyone suggested the brlcad format. It might be better than freecad in that it has export/import from a lot of other formats already written. It might be worse in that its user interface is prohibitively non- intuitive. I looked at the application a few years ago, when I was in need for a mechanical CAD application. Even the most simple operations required a number of complex steps. There is a whole chapter in the manual on how to move a component. The user base of brlCAD is marginal and will probably shrink even more, as more intuitive open source CAD applications will become a viable alternative. Following that logic gEDA will be made extinct by kicad any day now. brlCAD is truely free while freecad is based on opencascade which has a quasi open source licence. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Bert Timmerman wrote: Avoiding the command line won't help you on the gschem -- simulation work flow. It ain't necessarily so. (cite from a song I'll sing on Wednesday :) The current simulation work flow of geda sucks big time. Absence of a GUI way is only a minor itch when compared with the real issues. Anyway, it is difficult to convince users on the power of your framework, if they refuse to use it from first impressions. Loosing potential users due to a command like thing is probably something a lot of *nix apps and tools suffer from. There are not that many CAD applications that rely on the command line. Unix tools tend to deal with tasks that don't need a GUI in the first place. The same cannot be said of schematic capture and pcb layout. Both lend themselves naturally to graphical user interfaces. In a way, geda+pcb+command line is like a GUI text editor that relies on shell commands to do searchreplace. I can't help people who will not try to learn what is neccesary, or do whatever it takes, to solve their *own* problems. Since there are commandline-less alternatives, they do what it takes to solve *their* problems. However, none of them will contribute to geda/pcb in any way. Sad, but true. A project with a dwindling user base will slowly freeze to death. Sad, but also true. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 19:09 +0100, Bert Timmerman wrote: Avoiding the command line won't help you on the gschem -- simulation work flow. Can you please explain why we will always need the command line for simulation in gEDA? (I have newer found the time doing simulations...) Loosing potential users due to a command like thing is probably something a lot of *nix apps and tools suffer from. I can't help people who will not try to learn what is neccesary, or do whatever it takes, to solve their *own* problems. Sad, but true. IMHO there is no true hacker fu in them. I fully agree. There will not be much real benefit from Windows/Ubuntu-type of users. If they do not understand a line like cp xxx yyy -- can we really hope that these people will at some time do serious coding? Of course it is OK if they use Linux tools, but they don't have to. If someone likes to use proprietary Windows or Apple -- why should they use free software at all. That people do not really care about the word FREE, and they do not care about feeding Gates and Jobs. It's OK. Of course, from time to time we may see some smart people using still Windows, Eagle or similar proprietary stuff, we should try to catch them. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Evan Foss wrote: Following that logic gEDA will be made extinct by kicad any day now. I tried kicad for a little pet project a few months ago. There were quite a few usability issues. It didn't feel like wow, it was that easy!. On the contrary, I frequently wished they had done things differently. I had these wow-moments with inkscape after several years of coreldraw exposure... brlCAD is truely free while freecad is based on opencascade which has a quasi open source licence. Well, freecad is open source enough to enter the debian repository. The debian policy is certainly on the free side. The only gripe I have with the opencascade license is that it is yet another one. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 21:05 +0100, Stefan Salewski wrote: I fully agree. There will not be much real benefit from Windows/Ubuntu-type of users. Oi.. lets not forget that at least one of the gEDA developers (me) is an Ubuntu user. There is no shame in wanting your tools to just work! /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Peter Clifton wrote: /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. Side note: I just purchased a used ATI Radeon HD 4670 that free3d.org announces as the fastest card with open sourced drivers. I'll keep you posted on my mileage. What kind of acceleration does your GL enabled version actually use? XAA, EXA, UXA ... just some buzz acronyms I got from the guy who recommanded the ATI card to me. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 31 Oct 2010 19:30:46 + Peter Clifton pc...@cam.ac.uk wrote: On Sun, 2010-10-31 at 21:05 +0100, Stefan Salewski wrote: I fully agree. There will not be much real benefit from Windows/Ubuntu-type of users. Oi.. lets not forget that at least one of the gEDA developers (me) is an Ubuntu user. There is no shame in wanting your tools to just work! /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. Seconded - Ubuntu here as well. They do a reasonably good job of making things just work. If something isn't in Ubuntu's repository, or it is broken or outdated, then I'll seek out a .deb or I'll pull down the latest sources and build it myself. So far, only PCB and one or two unrelated programs fall into the build-it-myself category. But, while I may be familiar with the command line, that doesn't automatically mean I *want* to use it. If I can get things done efficiently without touching a terminal, I am happy. :-) -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://starbase.globalpc.net/~ezekowitz Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 19:30 +, Peter Clifton wrote: On Sun, 2010-10-31 at 21:05 +0100, Stefan Salewski wrote: I fully agree. There will not be much real benefit from Windows/Ubuntu-type of users. Oi.. lets not forget that at least one of the gEDA developers (me) is an Ubuntu user. There is no shame in wanting your tools to just work! /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. Sure -- I wrote Ubuntu-type of users. That type is very close to Windows users, putting the install CD into the drive and using autostart -- having to click on something like Install icon is already too complicated. Ubuntu may be not too bad, and of course there are some really smart people amongst the large quantity of users. Wanting your tools to just work is fine, but crying and complaining if something is not working exactly as one expects is silly. Some people do not describe their problems or send data files to verify the bugs, even when asked to do, they just abuse the developers. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 20:49 +0100, kai-martin knaak wrote: Side note: I just purchased a used ATI Radeon HD 4670 that free3d.org announces as the fastest card with open sourced drivers. I'll keep you posted on my mileage. I hope it will work fine for you -- some months ago you only advertised nvidia... http://archives.seul.org/geda/user/May-2010/msg00192.html ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 19:30 +, Peter Clifton wrote: /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. Indeed I wonder why framerate is critical -- is this only for rotating the board in 3D view? For other editing operation most of the board should be statical, so we have the static background which we copy for each frame to the display, and only one element (footprint, trace, ...) which needs real new drawing for each frame. (When I started my toy gschem clone in Ruby my fear was indeed a sluggish display, but with smart cairo layer buffers there should be no problem.) Of course you are very smart, so I seem to miss something... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Am 31.10.2010 um 21:05 schrieb Stefan Salewski: There will not be much real benefit from Windows/Ubuntu-type of users. If they do not understand a line like cp xxx yyy -- can we really hope that these people will at some time do serious coding? Then, there are many people which know cp xxx yyy, but prefer to avoid it anyways. You want to catch these. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 20:49 +0100, kai-martin knaak wrote: Peter Clifton wrote: /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. Side note: I just purchased a used ATI Radeon HD 4670 that free3d.org announces as the fastest card with open sourced drivers. I'll keep you posted on my mileage. What kind of acceleration does your GL enabled version actually use? XAA, EXA, UXA ... just some buzz acronyms I got from the guy who recommanded the ATI card to me. None really.. (because they are 2D acceleration APIs in the X server). My machine uses UXA, which is the X server acceleration technique used by Intel drivers. (Only Intel IIRC). UXA was originally based on EXA, which was designed to accelerate XRender operations. Cairo uses XRender, so EXA (should) be good with Cairo, and a modern desktop. UXA shares that benefit. XAA is the older X acceleration API, designed to accelerate traditional X operations such as blits / line drawing.. basically our old 2D drawing stuff. This is one of the reasons why PCB / gschem got slower on modern hardware and Xservers, that the old XAA APIs which were designed to accelerate those old kind of drawing operations were phased out in favour of acceleration APIs tailored to modern drawing APIs. UXA + DRI2 + GEM play together nicely on Intel. On Radeon / Nouveau open source drivers, I think it is something along the lines of: EXA + DRI2 + TTM. (Although I'm not 100% sure). DRI2 is the kernel / X11-application interface, and GEM/TTM are in kernel graphics memory / buffer managers. I should probably push my latest experimental changes for speed in a separate branch and let you compare the old PCB+GL for one which uses more modern rendering techniques such as VBOs and a pixel shader. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Stefan Salewski wrote: I hope it will work fine for you -- some months ago you only advertised nvidia... Yes, there was a shift. A year ago, people in de.comp.os.unix.linux.hardware discouraged me from purchasing an ATI card. Now, it is more like both should work, but free ATI drivers can do decent openGL. The drivers radeon and fglrx must have made real progress, recently. ---)kaimartin(--- PS: Writing this on a box with a moderate ATI card (Sapphire HD5450) -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 22:29 +0100, Stefan Salewski wrote: On Sun, 2010-10-31 at 19:30 +, Peter Clifton wrote: /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. Indeed I wonder why framerate is critical -- is this only for rotating the board in 3D view? Not just that, but any interactive rendering operation will repaint areas of the frame. I'm looking at moderately complex boards which can only just reach 30fps. Many boards I've got as test cases will struggle to do 10fps, or 5fps even. Above approx 10fps is usable, but you really want 15-20 upwards. Part of the problem is CPU, part is GPU. The 30fps I'm talking about above is JUST graphics render, without any overhead of changing the objects being rendered. That represents the best case frame-rate with caching of static geometry. For other editing operation most of the board should be statical, so we have the static background which we copy for each frame to the display, and only one element (footprint, trace, ...) which needs real new drawing for each frame. PCB (and my GL code) is not smart enough to make use of limited damage regions, and redraws the whole frame every time. Yes, we could do better, but there would still be memory copies involved. If we were _really_ clever, we could use the double buffering of frames, and compute damage VS. the frame _previous_ to the frame on screen, (in the back-buffer). It is already a frame behind, but if it can be updated to current, it saves copying the front-buffer as your rendering start point. (Alternatively, you would have to have a back-buffer copy rather than swapbuffers for each frame). (When I started my toy gschem clone in Ruby my fear was indeed a sluggish display, but with smart cairo layer buffers there should be no problem.) Of course you are very smart, so I seem to miss something... The update code is sadly pretty dumb. What I wanted to ensure was fast, would be panning / zooming, which involved full frame redraws. I want to optimise that first, _then we can make the editing small areas case lightning fast. Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 21:43 +, Peter Clifton wrote: The update code is sadly pretty dumb. What I wanted to ensure was fast, would be panning / zooming, which involved full frame redraws. I want to optimise that first, _then we can make the editing small areas case lightning fast. Unfortunately there are not much examples, at least not for clever buffering with cairo. My guess: For zooming we have to do a complete redraw of the visible area. For panning: I intend to draw to a buffer, which dimension increases when we zoom in, and copy a part of that buffer to the smaller cairo drawing area of the GTK window. So panning is fast, only copy. Moving a symbol: Mark that symbol as invisible, draw buffer, copy area of buffer to window, draw moving symbol to window. For each new frame: Copy area of buffer, draw that moving symbol. I guess that may work, even for slow Ruby. Of course for PCB and OpenGL all is more difficult. Recently I was wondering if that Clutter library may be useful, but I think that will make all more complicated. http://www.clutter-project.org/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Hm, does this mean you can implement a library, but you mustn't use material from the standard to document it? DJ Delorie wrote: STEP is an ISO standard, which likely means you have to buy the standard itself, but you can implement it freely: http://en.wikipedia.org/wiki/ISO_10303 ___ 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: Ben mode feature request
On Mon, 2010-11-01 at 00:19 +0100, Stefan Salewski wrote: Unfortunately there are not much examples, at least not for clever buffering with cairo. No, although gerbv actually seems to do a good job in this regard. IIRC, just redrawing edges which need repainting after a pan. Zoom can be fudged by stretching your current image up when zooming in, or shrinking it (then repainting the whole screen when you get a moment) when zooming out. With GL, I was looking at storing images of each layer in texture memory. Sounds good.. but I can't store much bigger than my native screen size due to hardware limitations on texture size.. I'd need to split it up into tiles smaller than the hardware limit to be sure of it working at high resolution. (And of course, different chips will have different limits). My guess: For zooming we have to do a complete redraw of the visible area. For panning: I intend to draw to a buffer, which dimension increases when we zoom in, and copy a part of that buffer to the smaller cairo drawing area of the GTK window. So panning is fast, only copy. Fair enough. To be honest, I'd love to instrument a version of PCB with zoom / panning / ... tracked, and have some testers actually work with it for various common tasks: 1. Editing a board 2. Making changes to an existing board 3. Populating / Debugging the board, with reference to the PCB for finding connectivity. Those would all be in my common work-flow, but I've not had cause to design so many boards recently. (Also, I might be biased by having preconceptions about the test). Moving a symbol: Mark that symbol as invisible, draw buffer, copy area of buffer to window, draw moving symbol to window. For each new frame: Copy area of buffer, draw that moving symbol. I guess that may work, even for slow Ruby. As long as the graphics routines are fast (which they ought to be), overhead ought not to be too bad. Of course for PCB and OpenGL all is more difficult. Recently I was wondering if that Clutter library may be useful, but I think that will make all more complicated. http://www.clutter-project.org/ Gnome shell / Ubuntu unity use that. I'm not sure if its clutter's fault, or the underlying mutter window manager (which uses clutter), but it isn't fast enough. That said.. it might be fun, but I don't think it is really suited to be the PCB application's canvas. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Oct 31, 2010, at 2:31 PM, Markus Hitter wrote: Then, there are many people which know cp xxx yyy, but prefer to avoid it anyways. You want to catch these. You don't want to dumb down the toolkit. Now, if somebody wants to write a fat, sweet integrated tool using the gEDA file formats, but tuned to the student/hobbyist market, I would cheer. Hobbyists and students are very important: they are the future. But gEDA is not that: instead it is a toolkit of broad capability, far beyond what its designers expected, I think. gEDA is the toolkit for *experts* doing *great* things *now*. Let's not lose that. One size does not fit all here. 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: Ben mode feature request
Hi Vanessa, Have a look at OpenSACD at: http://openscad.org/ Runs on both windoze and linux (works for me on Fedora). There are some examples included. If your looking for EDA model stuff, I'm evaluating the feasibility of using this for pcb and have my stuff in a git repo at github. http://github.com/bert/openscad Kind regards, Bert Timmerman. -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Vanessa Ezekowitz Sent: Friday, October 29, 2010 5:56 PM To: geda-user@moria.seul.org Subject: Re: gEDA-user: Ben mode feature request On Fri, 29 Oct 2010 17:31:28 +0200 Bert Timmerman bert.timmer...@xs4all.nl wrote: Anyone volunteering for the difficult part ? Ah, if only I knew some kind of true 3D modeling environment... Technical graphics/artwork is kind of a hobby for me, and I'd like to think I'm pretty good at it, so if I knew what the hell I was doing in the 3D realm, ;-) I'd volunteer for at least some of the models. Alas, I only know how to work with 2D stuff. -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://starbase.globalpc.net/~ezekowitz Vanessa Ezekowitz vanessaezekow...@gmail.com ___ 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: Ben mode feature request
Hi, I may have missed it but has anyone suggested the brlcad format. It might be better than freecad in that it has export/import from a lot of other formats already written. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Hi Evan, I mentioned BRL-CAD some days ago: quote Maybe Blender, OpenSCAD or BRL-CAD should become our 3D-friends ? /quote If there is a packaged version in Fedora I will give it a try because the last time I visited the web site it looked like it's more mature than FreeCAD (freecad, or however it's spelled). FreeCAD seems to use python for scripting, yet another language for me to learn ;-) At the moment I'm strugling with OpenSCAD to get a 1/4 of a toroid ;-( This requires a sequence of boolean operations: rotate_extrude a circle and then subtract some translated cubes as to get the bend of a through hole resistor. Chip capacitors and resistors are easy: just some cubes ;-) Kind regards, Bert Timmerman. -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Evan Foss Sent: Saturday, October 30, 2010 8:09 PM To: gEDA user mailing list Subject: Re: gEDA-user: Ben mode feature request Hi, I may have missed it but has anyone suggested the brlcad format. It might be better than freecad in that it has export/import from a lot of other formats already written. ___ 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: Ben mode feature request
On 10/29/2010 09:55 AM, Peter Clifton wrote: Whilst that isn't as general as a full VRML importer, it might be nice to be compatible with other OSS CAD tools and their models. VRML has been around so long that it is one of the ones you want to be able to translate to and from. On 10/29/2010 10:15 AM, Phillip Jones wrote: quick search on sourceforge reveals: http://exp-engine.sourceforge.net/ I couldn't figure out what this feature list for Express Engine means: * Browse and Validate Express (ISO 10303-11) schemas * Browse and Validate Express Data Populations * Validate and Evaluate Express-X (ISO 10303-14) views and maps * GUI and command-line interfaces * Express Shell On 10/29/2010 06:05 PM, kai-martin knaak wrote: That's why I keep suggesting an export to freecad format. http://en.wikipedia.org/wiki/FreeCAD_(Juergen_Riegel)a I tried using Freecad 2 months ago and it was very slow when more than two rectangular shapes were modeled. Boolean slices took forever and made the model slow also. It needs more work before doing a 3D rep of a board with components. On 10/30/2010 12:15 PM, Bert Timmerman wrote: http://openscad.org/ Runs on both windoze and linux (works for me on Fedora). OpenSCAD has just had some discussion on its list about upgrading it so STEP can be output, and also there is some talk of using its native file save format for the 3D file to make things from with reprap.org tools. So it could be good for two formats soon. On 10/30/2010 01:09 PM, Evan Foss wrote: I may have missed it but has anyone suggested the brlcad format. It might be better than freecad in that it has export/import from a lot of other formats already written. Steep learning curve. Few can take it long enough to get usability. OpenSCAD is programmer friendly so it's a natural. It is not a GUI integrated view/click/drag tool like FreeCAD will be some day, it is a scripting tool to generate 3D output to view in some other tool, then change the script, repeat till you like it. You can use it with git and it's just like coding a program for functions, instead your output is 3D shapes. By cut and pasting the scripts you get a lot of reuseability without even having it in a reusable 3D format. But they're working on that and probably will have STEP crudely working soon. 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: Ben mode feature request
Evan Foss wrote: I may have missed it but has anyone suggested the brlcad format. It might be better than freecad in that it has export/import from a lot of other formats already written. It might be worse in that its user interface is prohibitively non- intuitive. I looked at the application a few years ago, when I was in need for a mechanical CAD application. Even the most simple operations required a number of complex steps. There is a whole chapter in the manual on how to move a component. The user base of brlCAD is marginal and will probably shrink even more, as more intuitive open source CAD applications will become a viable alternative. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Hi all, IMHO, openSCAD could be a (FOSS) candidate as well for generating a 3D view a the board. It's input file is a script resembling C. For the user manual see: http://en.wikibooks.org/wiki/OpenSCAD_User_Manual Simple components (CAPC et al) could be defined as a module containing a cube for a body, and two other translated cubes for the leads. Complicated parts can be assembled by means of conditinal and iterator functions containing 3D primitives. PCBoards can be put together by a toplevel script invoking all parts (modules) and an extruded outline (may even be a DXF file). I try to work out a proof-of-concept board to investigate the feasibility. Kind regards, Bert Timmerman. -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of DJ Delorie Sent: Thursday, October 28, 2010 10:09 PM To: gEDA user mailing list Subject: Re: gEDA-user: Ben mode feature request Anyway I started to think could it be possible to write tool that populates the PCB? First we know the footprint. There are the legs. Then we need case. Selecting from few different cases it could be possible to select desired case. Size could be little bit smaller than outline in footprint. And then the last thing is add text and resistor ribbons. This information is required before the picture is exported. And when we export image, these pictures are pasted on picture. In theory, the XYZR output (bom exporter) is enough to let you paste other pictures onto the pcb picture. However, there's the whole need a huge pile of pictures problem still. Then you'd annotate the footprints to include a photo name and perhaps some hook to fix it (like resistor stripes or number), some offset/rotation code, etc. Remember, features get added by the people with the time and desire to add them... ___ 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: Ben mode feature request
One suggestion I got a Devcon was to support STEP format for 3-d graphics. While it's a hairy format, it was said to be the standard for sharing 3-d models of components. Of course, it would be nicer if someone *else* supported it for us :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Hi DJ, IMHO and AFAICT STEP is a closed standard, that is, one will have to (probably ?) buy a copy of the standard and then violate the copyright notice prohibiting to disclose (reproduce ?) its contents into some sort of a library (libSTEP ?), which then could be published under LGPL and used by GPL-compatible FOSS. Please correct me if I'm having a wrong impression here, as I would be glad to hear that ;-) And then the mentioning of a hairy format ... Me shivers ... Hmm, would that give us robust code ? If we want to export towards (proprietary) mechanical CAD I would rather put my money on IDF. Maybe Blender, OpenSCAD or BRL-CAD should become our 3D-friends ? Kind regards, Bert Timmerman. -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of DJ Delorie Sent: Friday, October 29, 2010 4:27 PM To: gEDA user mailing list Subject: Re: gEDA-user: Ben mode feature request One suggestion I got a Devcon was to support STEP format for 3-d graphics. While it's a hairy format, it was said to be the standard for sharing 3-d models of components. Of course, it would be nicer if someone *else* supported it for us :-) ___ 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: Ben mode feature request
On Fri, 2010-10-29 at 10:26 -0400, DJ Delorie wrote: One suggestion I got a Devcon was to support STEP format for 3-d graphics. While it's a hairy format, it was said to be the standard for sharing 3-d models of components. KiCad (last time I looked a long while ago) use a very specific sub-set of VRML exported from Wings3D for their models. Whilst that isn't as general as a full VRML importer, it might be nice to be compatible with other OSS CAD tools and their models. This would help if indeed people wanted to make converters to / from KiCad, so 3D models could be preserved. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
STEP is an ISO standard, which likely means you have to buy the standard itself, but you can implement it freely: http://en.wikipedia.org/wiki/ISO_10303 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
IMHO and AFAICT STEP is a closed standard, that is, one will have to (probably ?) buy a copy of the standard and then violate the copyright notice prohibiting to disclose (reproduce ?) its contents into some sort of a library (libSTEP ?), which then could be published under LGPL and used by GPL-compatible FOSS. Please correct me if I'm having a wrong impression here, as I would be glad to hear that ;-) ISO 10303 - Automation systems and integration — Product data representation and exchange more commonly known as STEP http://en.wikipedia.org/wiki/ISO_10303 quick search on sourceforge reveals: http://exp-engine.sourceforge.net/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
OK, I'm corrected and happy for us ;-) Anyone volunteering for the difficult part ? Kind regards, Bert Timmerman. -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Phillip Jones Sent: Friday, October 29, 2010 5:15 PM To: gEDA user mailing list Subject: Re: gEDA-user: Ben mode feature request IMHO and AFAICT STEP is a closed standard, that is, one will have to (probably ?) buy a copy of the standard and then violate the copyright notice prohibiting to disclose (reproduce ?) its contents into some sort of a library (libSTEP ?), which then could be published under LGPL and used by GPL-compatible FOSS. Please correct me if I'm having a wrong impression here, as I would be glad to hear that ;-) ISO 10303 - Automation systems and integration - Product data representation and exchange more commonly known as STEP http://en.wikipedia.org/wiki/ISO_10303 quick search on sourceforge reveals: http://exp-engine.sourceforge.net/ ___ 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: Ben mode feature request
DJ Delorie wrote: One suggestion I got a Devcon was to support STEP format for 3-d graphics. While it's a hairy format, it was said to be the standard for sharing 3-d models of components. Of course, it would be nicer if someone *else* supported it for us :-) That's why I keep suggesting an export to freecad format. http://en.wikipedia.org/wiki/FreeCAD_(Juergen_Riegel) Import/export to a native format of an open Source CAD application catches many worms with one move: a) Use FreeCAD to create 3D models of components b) FreeCAD can integrate the layout, complete with components with mechanical models of where ever it has to fit in. c) FreeCAD app can take care of exports to other, more wide spread formats. Let it worry about the peculiarities of STEP, VRML, blender, etc. The FreeCAD project still has some way to go until their goal is in sight -- be comparable to Catia, or SolidWorks. But it advances fast and is already quite usable. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Anyway I started to think could it be possible to write tool that populates the PCB? First we know the footprint. There are the legs. Then we need case. Selecting from few different cases it could be possible to select desired case. Size could be little bit smaller than outline in footprint. And then the last thing is add text and resistor ribbons. This information is required before the picture is exported. And when we export image, these pictures are pasted on picture. In theory, the XYZR output (bom exporter) is enough to let you paste other pictures onto the pcb picture. However, there's the whole need a huge pile of pictures problem still. Then you'd annotate the footprints to include a photo name and perhaps some hook to fix it (like resistor stripes or number), some offset/rotation code, etc. Remember, features get added by the people with the time and desire to add them... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
