My only request is to design it with the disabled in mind. If its
graphical, include shortcut keys. Using the accessiblity mouse keys and
waiting for the mouse to travel from point to point multiplied by repetitive
tasks effects the time to completion significantly.
On Dec 20, 2007 4:00 PM, John
On Dec 20, 2007, at 1:24 PM, Dave McGuire wrote:
> On Dec 19, 2007, at 5:47 PM, John Doty wrote:
>>>As do I. I've always thought that gattrib's functionality being
>>> implemented as a separate program is a bit odd. I think there
>>> should
>>> be a menu choice like "Edit all component at
On Dec 19, 2007, at 5:47 PM, John Doty wrote:
>>As do I. I've always thought that gattrib's functionality being
>> implemented as a separate program is a bit odd. I think there should
>> be a menu choice like "Edit all component attributes..." which would
>> bring up what we now see as gattri
Peter TB Brett wrote:
> On Wednesday 19 December 2007 23:51:37 John Doty wrote:
The attribute value in the parts file then
>> overrides the value in the graphics, but the graphical properties of
>> the attribute still originate in the graphics.
>
> For e.g. inductors, how do you make sure that the
Dave N6NZ wrote:
> John Doty wrote:
>> 3. The flat file is a simple interface between BOM management and the
>> schematic->netlist->layout flow. Modular.
>>
>
> I suppose as an intermediate step, you could get the same effect with a
> sch2sch attribute replacer. It could look for the trigger a
On Dec 20, 2007, at 1:51 AM, Peter TB Brett wrote:
> On Wednesday 19 December 2007 23:51:37 John Doty wrote:
>
>> There is no graphical information in the parts file. For an attribute
>> to be visible in the schematic, a visible default/placeholder
>> attribute should be visibly present in the sy
On Wednesday 19 December 2007 23:51:37 John Doty wrote:
> There is no graphical information in the parts file. For an attribute
> to be visible in the schematic, a visible default/placeholder
> attribute should be visibly present in the symbol or visibly attached
> in the schematic. The attribute
John Doty wrote:
> 2. The flat file is another place where one can inspect or intervene in
> the flow.
There is value in that, certainly.
> 3. The flat file is a simple interface between BOM management and the
> schematic->netlist->layout flow. Modular.
>
I suppose as an intermediate step,
On Dec 19, 2007, at 10:01 PM, Dave N6NZ wrote:
>
>
> John Doty wrote:
>> On Dec 18, 2007, at 2:32 PM, Peter TB Brett wrote:
>>
>>> "Rewrite the component library C & Scheme APIs, and make a new GUI
>>> for it in
>>> gschem" is achievable (just). Ideally, I'd like to be able to do
>>> it in a
>>>
John Doty wrote:
> On Dec 18, 2007, at 2:32 PM, Peter TB Brett wrote:
>
>> "Rewrite the component library C & Scheme APIs, and make a new GUI
>> for it in
>> gschem" is achievable (just). Ideally, I'd like to be able to do
>> it in a
>> tidy, self-contained way.
>
> May I suggest the follo
John Doty wrote:
> Consider that a design might contain a bunch of chips, each with a
> bypass capacitor. Now, for sanity, it makes a lot of sense to use the
> *same* bypass capacitor device throughout the design. However, what
> if you need to change it?
This would argue for being able t
> Can the method DJ used for plugins in pcb be used by gschem at all?
That works if you have a way to "register" functions and call them by
name, instead of linking them in. Should be easy with the existing
guile support.
As for *what* to register, I suppose that depends on the user. PCB
just
Peter Clifton wrote:
> If the the core gattrib functionality were a GUI plugin, and gattrib a
> framework shell for loading schematics into memory etc.., then passing
> the TOPLEVEL to the gattrib widget, we might be able to have the best of
> both worlds.
>
> Plugins won't be too far away in gsc
On Dec 18, 2007, at 2:32 PM, Peter TB Brett wrote:
> "Rewrite the component library C & Scheme APIs, and make a new GUI
> for it in
> gschem" is achievable (just). Ideally, I'd like to be able to do
> it in a
> tidy, self-contained way.
May I suggest the following path to the future? I beli
On Dec 19, 2007, at 2:56 PM, Dave McGuire wrote:
> On Dec 19, 2007, at 3:52 PM, Ivan Stankovic wrote:
>>> Is there any barrier to integrating gattrib with gschem? I think
>>> I'd
>>> be
>>> happy with being able to pop up gattrib as a gigantic modal dialog.
>>
>> I had actually proposed just t
On Wednesday 19 December 2007 19:57:58 John Griessen wrote:
> Peter TB Brett wrote:
> > On Tuesday 18 December 2007 23:22:49 Levente wrote:
> >> I wanted to do that, but, to be honest, I have zero knowledge of gschem
> >> internals. I've tried to figure things out, but failed.
> >
> > That's where
On Tuesday 18 December 2007 18:52:39 [EMAIL PROTECTED] wrote:
> What I would quite like to do is to implement something similar to what
> has been described, especially since I have found a major bug which only
> (yet another) serious component library API change will fix.
I'd like to point out t
On Wed, Dec 19, 2007 at 09:15:03PM +, Peter Clifton wrote:
> On Wed, 2007-12-19 at 21:48 +0100, Ivan Stankovic wrote:
> > Yes, I have been working on a gattrib rewrite and I've just barely
> > got to load/save component attribs.
>
> If this is in git, it would be great to be able to track prog
On Wednesday 19 December 2007 20:28:22 John Griessen wrote:
> Levente wrote:
> > Peter TB Brett <[EMAIL PROTECTED]> wrote:
> >> - Each symbol (or part) has to be uniquely identified by a string, and
> >> each database/website/directory gets queried in reverse order of being
> >> added to the librar
On Dec 19, 2007, at 3:52 PM, Ivan Stankovic wrote:
>> Is there any barrier to integrating gattrib with gschem? I think I'd
>> be
>> happy with being able to pop up gattrib as a gigantic modal dialog.
>
> I had actually proposed just that some months ago (it was on IRC),
> but the idea was dismiss
On Dec 19, 2007, at 12:40 PM, DJ Delorie wrote:
>> Keeping thing simple for new users is very important.
>
> I.e. we need to make it *seem* like there's one unified library,
> regardless of how we actually distribute the data.
[sorry for jumping in again]
That's exactly what I had in mind a
Hi Ivan,
On Mittwoch, 19. Dezember 2007, Ivan Stankovic wrote:
> On Wed, Dec 19, 2007 at 12:02:34PM -0800, Dave N6NZ wrote:
> > Is there any barrier to integrating gattrib with gschem? I think
> > I'd be happy with being able to pop up gattrib as a gigantic modal
> > dialog.
>
> I had actually pr
On Wed, 19 Dec 2007 21:52:47 +0100, Ivan Stankovic wrote:
> Personally, I think integrating gattrib with gschem (as in:
> gattrib-in-gschem would just be gschem's attribute dialog on steroids)
> makes perfect sense.
Me too.
---<(kaimartin)>---
--
Kai-Martin Knaak
Peter TB Brett wrote:
> On Wednesday 19 December 2007 12:48:55 DJ Delorie wrote:
> Secondly, I object strongly to the idea of using a BOM as a master document.
>
> 2. How do you do design re-use?
[jg]If you mean, how do you send out reusable chunks easily, you could embed
light symbols in gschem,
On Wed, 2007-12-19 at 21:48 +0100, Ivan Stankovic wrote:
> On Wed, Dec 19, 2007 at 05:42:59PM +, Peter Clifton wrote:
> > I'm not arguing to replace gattrib though. Ivan Stankovic is / was doing
> > work on gattrib, so I'd expect to see some improvements there in due
> > course.
>
> Yes, I ha
On Wed, 2007-12-19 at 21:52 +0100, Ivan Stankovic wrote:
> On Wed, Dec 19, 2007 at 12:02:34PM -0800, Dave N6NZ wrote:
> > Is there any barrier to integrating gattrib with gschem? I think I'd be
> > happy with being able to pop up gattrib as a gigantic modal dialog.
>
> I had actually proposed j
On Dec 19, 2007, at 1:54 PM, Andy Peters wrote:
> On Dec 19, 2007, at 8:34 AM, DJ Delorie wrote:
>
>>
>>> That is true. But why do we need this? Why should pcb know that the
>>> attribute "value=LM2596" came from a database, or from manual input,
>>> script generated?
>>
>> I'm thinking of the ca
On Wed, Dec 19, 2007 at 12:02:34PM -0800, Dave N6NZ wrote:
> Is there any barrier to integrating gattrib with gschem? I think I'd be
> happy with being able to pop up gattrib as a gigantic modal dialog.
I had actually proposed just that some months ago (it was on IRC),
but the idea was dismisse
On Wed, Dec 19, 2007 at 05:42:59PM +, Peter Clifton wrote:
> I'm not arguing to replace gattrib though. Ivan Stankovic is / was doing
> work on gattrib, so I'd expect to see some improvements there in due
> course.
Yes, I have been working on a gattrib rewrite and I've just barely
got to load/
On Dec 19, 2007, at 8:34 AM, DJ Delorie wrote:
>
>> That is true. But why do we need this? Why should pcb know that the
>> attribute "value=LM2596" came from a database, or from manual input,
>> script generated?
>
> I'm thinking of the case where an attribute is defaulted by some BOM
> manager be
Peter TB Brett wrote:
> On Wednesday 19 December 2007 12:48:55 DJ Delorie wrote:
> Secondly, I object strongly to the idea of using a BOM as a master document.
>
> 1. How do you cope with the designer deleting a component and then renumbering
>the ones that are left?
BOM has no unique IDs, t
On Dec 19, 2007, at 1:28 PM, John Griessen wrote:
>
> Me too. I don't want to get stuck inoperable without finding the
> mate to a long UUID style
> string of identifier numbers.
Again, I like the "stockroom" concept, where everything you need gets
automagically imported into a directory tha
DJ Delorie wrote:
>> For the time being, however, I don't see any reason not to stick to
>> using some sort of external helper programs for actually accessing
>> the database, as long as we can get the UI and basic Scheme API
>> nailed down.
>
> I've argued in the past that gattrib should be respo
Levente wrote:
> Peter TB Brett <[EMAIL PROTECTED]> wrote:
>
>> - Each symbol (or part) has to be uniquely identified by a string, and each
>> database/website/directory gets queried in reverse order of being added to
>> the library. This is as currently.
But not for all time. can't it just s
John Doty wrote:
wouldn't a project parts database be better? Use a
> light symbol, attach a single attribute identifying it to your parts
> database, and put the rest of the attributes there.
>
> That's what I think of as BOM-centric design.
I can imagine attribs at the gschem level and a bom
Peter TB Brett wrote:
we need to be back-compatible with all the heavy symbol libraries
> people currently have.
>
> (Or for that matter to use light symbols directly for documentation diagrams
> without needing to having to faff around with a database).
>
> That's not say that a specific databa
Peter Clifton wrote:
> On Wed, 2007-12-19 at 09:35 -0800, Dave N6NZ wrote:
>
>> And as to it being painful to go back and forth between gschem and
>> gattrib, why, by golly, you are right. Except for the fact that it
>> currently happens to be a whole lot less painful than entering all your
Peter TB Brett wrote:
> On Tuesday 18 December 2007 23:22:49 Levente wrote:
>> I wanted to do that, but, to be honest, I have zero knowledge of gschem
>> internals. I've tried to figure things out, but failed.
>
> That's where I come in.
>
>> I think we should have in rc files specification to da
On Dec 19, 2007, at 6:18 AM, Peter TB Brett wrote:
> On Wednesday 19 December 2007 12:48:55 DJ Delorie wrote:
>>> For the time being, however, I don't see any reason not to stick to
>>> using some sort of external helper programs for actually accessing
>>> the database, as long as we can get the
values
> from the DB.
Yes! Yes!
>
> In fact, this scheme is normally called the "parameterized cell"
> design, which makes billion transistor VLSI design possible.
>
>
>
> -Original Message-
> From: Levente <[EMAIL PROTECTED]>
> To: [EMAIL PROT
On Wed, 2007-12-19 at 09:35 -0800, Dave N6NZ wrote:
> And as to it being painful to go back and forth between gschem and
> gattrib, why, by golly, you are right. Except for the fact that it
> currently happens to be a whole lot less painful than entering all your
> attributes directly in gsch
> Keeping thing simple for new users is very important.
I.e. we need to make it *seem* like there's one unified library,
regardless of how we actually distribute the data.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin
Peter TB Brett wrote:
> Um... I think exactly the opposite. What you're suggesting would just make
> the already-steep gschem learning curve even worse. I'm trying to find a way
> to make it so that there is *one* unified part/symbol library that's
> sufficiently powerful and flexible for pe
Peter TB Brett wrote:
> On Wednesday 19 December 2007 12:48:55 DJ Delorie wrote:
>>> For the time being, however, I don't see any reason not to stick to
>>> using some sort of external helper programs for actually accessing
>>> the database, as long as we can get the UI and basic Scheme API
>>> n
> That is true. But why do we need this? Why should pcb know that the
> attribute "value=LM2596" came from a database, or from manual input,
> script generated?
I'm thinking of the case where an attribute is defaulted by some BOM
manager because it's the only option that fits. For example, if yo
I think here we are using the term bom for a file that has possibly a
lot of information in it. Maybe more then we want to give to a
purchasing group.
Should we change our usage here and now to keep the traditional meaning
of bom and that bom should be a csv file? I would agree.
Then we need a di
One more time
in -> process -> out
-
Today's model
1) sch, sym -> gschem -> sch, sym, ps
2) sch -> gattrib -> sch
3)
sch, sym -> gnetlist -> netlist, bill_of_materials
or
sch, sym -> gsch2pcb/gnetlist -> pcb_file
3) netlist, p
On Wednesday 19 December 2007 15:02:44 Steve Meier wrote:
> 6) bom -> ? -> csv
>
> Somebody has to take bom and convert it to a csv text file suitable for
> ordering parts
I've never understood why the BOM isn't just a csv file?
Peter
--
Peter Brett
Electronic Sys
in -> process -> out
-
Today's model
1) sch, sym -> gschem -> sch, sym, ps
2) sch -> gattrib -> sch
3)
sch -> gnetlist -> netlist, bill_of_materials
or
sch -> gsch2pcb/gnetlist -> pcb_file
3) pcb_file -> pcb -> gbr, cnc, ps, bi
Levente's Model?
in -> process -> out
-
1) sch, bom -> gschem (with db interface)-> sch, bom, ps
2) sch, bom -> gattrib (with db interface) -> sch, bom
3) sch, bom -> netlister -> netlist
4) netlist -> pcb -> gbr, cnc, ps, eco
5
DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>> For the time being, however, I don't see any reason not to stick to
>> using some sort of external helper programs for actually accessing
>> the database, as long as we can get the UI and basic Scheme API
>> nailed down.
>
> I've argued in the past that
in -> process -> out
-
1) sch -> gschem -> sch, ps
2) sch, bom -> gattrib (with db interface) -> sch, bom
3) sch, bom -> netlister -> netlist
4) netlist -> pcb -> gbr, cnc, ps, eco
5) sch, bom, eco -> netlister -> sch
I use netl
On Wed, 2007-12-19 at 09:34 -0500, DJ Delorie wrote:
> > > pcb has a similar problem - there's nothing in the file format that
> > > says "footprint name goes here". However, I'm thinking we can just
> > > store that in an attribute.
> >
> > It would then become ambiguous -- not to mention remov
On Wednesday 19 December 2007 14:34:25 DJ Delorie wrote:
> > > pcb has a similar problem - there's nothing in the file format that
> > > says "footprint name goes here". However, I'm thinking we can just
> > > store that in an attribute.
> >
> > It would then become ambiguous -- not to mention rem
On Wed, 2007-12-19 at 09:23 -0500, DJ Delorie wrote:
> I suppose we could have a separate attribute verb, that sets an
> invisible attribute without needing to specify a location, size,
> color, etc.
That would be really nice. Peter B and I looked at it this way...
Attribute verb defines the at
> > pcb has a similar problem - there's nothing in the file format that
> > says "footprint name goes here". However, I'm thinking we can just
> > store that in an attribute.
>
> It would then become ambiguous -- not to mention removing backward
> compatibility -- unless the database system was
Peter TB Brett <[EMAIL PROTECTED]> wrote:
> That's called embedding. :) Without a file-format change, the only
> non-ambiguous way of associating a symbol in the schematic with a symbol in
> the library/database/whatever is to use the field in the component
> specification reserved for the comp
On Wednesday 19 December 2007 14:25:25 DJ Delorie wrote:
> > Without a file-format change, the only non-ambiguous way of
> > associating a symbol in the schematic with a symbol in the
> > library/database/whatever is to use the field in the component
> > specification reserved for the component nam
> When all is said and done, however we get there don't schematics have to
> be able to display at least for a hard copy.
Depends on the attribute. Value and pin numbers definitely need to be
displayed on the schematics. Preferred vendor? RoHS status?
Probably not.
__
> Without a file-format change, the only non-ambiguous way of
> associating a symbol in the schematic with a symbol in the
> library/database/whatever is to use the field in the component
> specification reserved for the component name.
pcb has a similar problem - there's nothing in the file form
> Pin numbers on the schematic _ARE_ back-annotation from the part of
> the work-flow which maps light->heavy.
That works too. IIRC, the technical problem is that gschem has no way
of adding attributes to pins at the schematic level, unless the symbol
is embedded. As we all know, I'm not a fan
When all is said and done, however we get there don't schematics have to
be able to display at least for a hard copy.
The real pin number and the real value? I can't imagine debugging a
board without them.
Steve Meier
DJ Delorie wrote:
>> For the time being, however, I don't see any reason not
When all is said and done, however we get there don't schematics have to
be able to display at least for a hard copy.
The real pin number and the real value? I can't imagine debugging a
board without them.
Steve Meier
DJ Delorie wrote:
>> For the time being, however, I don't see any reason not
On Wednesday 19 December 2007 12:17:02 Levente wrote:
> Peter TB Brett <[EMAIL PROTECTED]> wrote:
> > I still haven't been convinced by these arguments, especially since
> > _nothing_ you've described can't be implemented with symbols which are
> > embedded by default. (So there. :P )
>
> Ok, you
On Wed, 2007-12-19 at 07:48 -0500, DJ Delorie wrote:
> I think the only things that need to be added to the symbols
> themselves are things that need to appear in the schematics - like pin
> numbers. We need a way to assign pin numbers to labelled pins so that
> you can see in the schematic which
On Wednesday 19 December 2007 12:48:55 DJ Delorie wrote:
> > For the time being, however, I don't see any reason not to stick to
> > using some sort of external helper programs for actually accessing
> > the database, as long as we can get the UI and basic Scheme API
> > nailed down.
>
> I've argue
> For the time being, however, I don't see any reason not to stick to
> using some sort of external helper programs for actually accessing
> the database, as long as we can get the UI and basic Scheme API
> nailed down.
I've argued in the past that gattrib should be responsible for
attributes, no
Peter TB Brett <[EMAIL PROTECTED]> wrote:
> [-- multipart/signed, encoding 7bit, 1 lines --]
>
>[-- text/plain, encoding quoted-printable, charset: iso-8859-1, 119 lines
> --]
>
> On Wednesday 19 December 2007 09:52:49 Levente wrote:
>> Peter TB Brett <[EMAIL PROTECTED]> wrote:
>>
>> [...]
>
On Wednesday 19 December 2007 09:52:49 Levente wrote:
> Peter TB Brett <[EMAIL PROTECTED]> wrote:
>
> [...]
>
> >> The symbol files should be as light as possible, and we should make them
> >> heavy by adding information coming from the database.
> >
> > Totally agree. Could we implement this by a
Peter TB Brett <[EMAIL PROTECTED]> wrote:
[...]
>> The symbol files should be as light as possible, and we should make them
>> heavy by adding information coming from the database.
>
> Totally agree. Could we implement this by asking the backend to take care
> of where the symbols come from, an
ansistor VLSI design possible.
-Original Message-
From: Levente <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Wed, 19 Dec 2007 12:33 am
Subject: Re: gEDA-user: Parts DB API
Steve Meier <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-12-18 at 23:22 +, Levente wrote:
>>
Steve Meier <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-12-18 at 23:22 +, Levente wrote:
>> [EMAIL PROTECTED] wrote:
>>
>> Hi Peter,
>>
>>
>
>>
>> The symbol files should be as light as possible, and we should make them
>> heavy by adding information coming from the database.
>>
>
>
> So
On Tuesday 18 December 2007 23:59:50 Steve Meier wrote:
> On Tue, 2007-12-18 at 23:22 +, Levente wrote:
> > [EMAIL PROTECTED] wrote:
> >
> > The symbol files should be as light as possible, and we should make them
> > heavy by adding information coming from the database.
>
> So can we make a li
On Tuesday 18 December 2007 23:22:49 Levente wrote:
> I wanted to do that, but, to be honest, I have zero knowledge of gschem
> internals. I've tried to figure things out, but failed.
That's where I come in.
> I think we should have in rc files specification to database server(s), and
> a relativ
-Original Message-
From: Steve Meier <[EMAIL PROTECTED]>
To: gEDA user mailing list
Sent: Tue, 18 Dec 2007 3:59 pm
Subject: Re: gEDA-user: Parts DB API
On Tue, 2007-12-18 at 23:22 +, Levente wrote:
> [EMAIL PROTECTED] wrote:
>
> Hi Peter,
>
>
>
> The symbol
On Tue, 2007-12-18 at 23:22 +, Levente wrote:
> [EMAIL PROTECTED] wrote:
>
> Hi Peter,
>
>
>
> The symbol files should be as light as possible, and we should make them heavy
> by adding information coming from the database.
>
So can we make a list of what should come from the light symb
Peter,
I have been working on the scheme interface quite a bit recently. What
you are discussing is fairly similar to the area I am digging into.
As a bit of a back ground. The basic algoryth I use for reading in a
project is to.
Take the list of input files from the command line.
For each of
[EMAIL PROTECTED] wrote:
Hi Peter,
I have a few thoughts on this topic, but maybe they are not quite answers to
your questions.
I've been thinking about this topic while I was in Stuttgart in the summer.
What I did is a database structure, and a simple command line application,
that connects to
On Tuesday 18 December 2007 21:18:21 Dave N6NZ wrote:
> [EMAIL PROTECTED] wrote:
> > Hi folks,
>
>
>
> > What I would quite like to do is to implement something similar to what
> > has been described, especially since I have found a major bug which only
> > (yet another) serious component library
[EMAIL PROTECTED] wrote:
> Hi folks,
> What I would quite like to do is to implement something similar to what
> has been described, especially since I have found a major bug which only
> (yet another) serious component library API change will fix.
Excellent!
>
> - What you want the API to be
Hi folks,
There has been an interesting discussion about parts databases and the
gschem component library.
What I would quite like to do is to implement something similar to what
has been described, especially since I have found a major bug which only
(yet another) serious component library API c
81 matches
Mail list logo
