gEDA-dev: More thoughts from Peter Clifton ... was: Re: Your mailsto geda-dev (fwd)

[sdb-at-NOSPAMcloud9_dot_net (Stuart Brorson)]

Peter is still having problems receiving geda-dev.  He sent this to
me, and I am forwarding it to geda-dev since his thoughts are relevant
to all developers.

Stuart


Forwarded message:
> 
> On Tue, 2006-06-20 at 17:21 -0400, Stuart Brorson wrote:
> > Peter --
> > 
> > Your e-mails are coming through on geda-dev in a timely way.  I don't
> > know why you can't see them.  Ales recently changed to a new e-mail
> > prog recently; maybe that has to do with it?  I'm cc'ing Ales here; he
> > might be able to see if anything is wrong.
> > 
> > Or maybe you have an overly-agressive spam blocker?
> > 
> > Stuart
> 
> Ok, still no emails from the dev list, but I wanted to reply to my
> previous post, to indicate that I will otherwise be out of contact in
> the near future, (Until past 17th July). For the next week, I will have
> intermittant contact as I'm preparing for a field-work project surveying
> some hills in Scotland.
> 
> Thankyou both for your positive replies. I would like to add further
> explanation:
> 
> The current stage of our project is the definition of what we want to
> achieve, how we might go about it, and what time-scales we might
> realistically expect. (What we can achieve over a programming / work
> period of 10 weeks, with two people).
> 
> For background:
> 
> I have hacked PCB a _little_ before (the pre-HID Gtk port), and looked
> into the "C" bits of gschem to investigate what I considered a
> useability bug in gschem. (Always selecting the title-block, rather than
> the components.) Reading the source, I discovered the "lock" option, and
> had my solution without doing any coding. (It is still not great for new
> users, but if we start them with a "template" schematic which contains a
> locked title-block, that is solved.)
> 
> Whilst I can't speak for Peter Brett's programming experience, I do know
> that he's used gschem a lot lot more than I have. (And that I'm probably
> more familiar with "pcb").
> 
> I have looked at coding GUIs in PyGTK / PyGlade, and am a big fan... far
> far far far easier than using GTK in "C". Are there any pre-existing
> bindings for libgeda in Python? (If that might be useful)?
> 
> My familiarity is with "C", but I can read / write (with references)
> Python, and can decipher Scheme. (I did once write a GIMP script in
> Scheme, but that wasn't anything major).
> 
> Work plan (still vague):
> 
> I expect our attack to be threefold, and roughly in this order.. 1/2 may
> swap.
> 
> 1. Project manger, intergrating with the existing workflows. Not sure if
> this will use makefiles, or some internal procedure.
> 
> 2. Fiddling mouse / key bindings for our local users, to better match
> Windows "standard", and to aid discoverability. I expect many of these
> will end up as local patches for ourselves.
> 
> 3. Looking at architectural changes:
> 	Busses:
> 		Peter Brett has some ideas about the appropriate syntax for busses,
> similar to VHDL (? - I've not used it), where strings such as [foo1:9]
> would expand along the lines foo0, foo1, ...., foo9
> 	Back / Forward Annotation: (Need to discuss with Dan McMahill)
> 		My own ideas here is to introduce a differentiation with a logical
> pin-pin (net) connection between components, and "wires" on the
> schematic which fufill those nets, in the same way as PCB tracks fufill
> the nets.
> 		Some types of back-annotation would require the notion of "rat-lines"
> in the schematic, so the user can then rip-up and relay "wires" to match
> the connectivity in the nets.
> 		Communication between processes is not something I'm particularly
> familiar with, but might involving watching the "netlist" / schematic
> files for changes, or communicating via DBUS or a pipe.
> 		I get a nasty feeling that all this will require gnetlist to be used
> differently / not at all, with gschem maintaining an "on the fly"
> structure of nets and connection. (I'll have to spend some time thinking
> out how this works across multiple / heirachical schematics)
> 	Attributes: (Need to discuss with Dan McMahill)
> 		Some library component (Attribute manager?) which understands editing
> attributes, possibly providing a gtk widget / dock for use in multiple
> apps.
> 		An idea:
> 		  1. In project manager, define tools you're woring with, e.g. gschem,
> PCB, ngspice.
> 		  2. Tool specific config files are parsed, or the tools are invoked
> with a method to retrieve a set of attributes they use / need. (These
> may want to be fleshed out with metadata such as description, necessity
> etc..)
> 		  3. Attribute manager merges the list of offered / needed attributes
> into a tree(?) for presenting in the attribute setting widget.
> 		  4. Object attributes may be inherited from  "parent" groups or
> objects, including the "gEDA project", or the specific schematic file
> concerned. These can be overridden by more specific settings. (e.g.
> Posix / WinNT ACLs).
> 
> 
> Random PCB thoughts:
> 
> 	Instead of listing lots of "pcblib" footprints, can we have some way
> for the "M4" macros which generate them to promote the config /
> parameters which generate a given footprint, so instead of listing every
> possible DIL socket config, we can use the appropriate M4 macro and send
> it the correct parameters. (This might make scanning for components in
> the list more managable)
> 	  - Perhaps this isn't as useful for the gschem -> pcb workflow, but
> for people going paper -> pcb (as I have in the past), it could be
> handy.
> 
> 
> Regards, 
> 
> Peter Clifton
> 
> 
> 
> 

_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev