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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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)
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
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
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
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
Dan McMahill d...@mcmahill.net 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
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
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.
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
27 matches
Mail list logo
