gEDA-user: RFC - gschem (resend)

[Ales Hvezda <ahvezda@seul.org>]

[ Ales here, I'm reposting this since majordomo didn't recognize the
  e-mail as being subscribed to the geda-dev/user mailinglist.  Keith,
  I looked in the subscription lists and you are subscribed but with
  a different address, please send me private e-mail, so we can get
  that fixed.  Thanks.  -Ales ]

[ Some of the below points look interesting/useful.  However like
  most things, it is only available developer time/bandwidth which
  contrains which of the requests can be implemented.  Maybe somebody
  will get inspired to implement some of them and I'm always willing to
  give advice where to look in the code etc...  -Ales ]

-- Cut here --
From: "Keith Outwater" <Keith_Outwater@microvision.com>

Greetings all - 
I have been playing around with gschem and I like it already (a lot
better than orcad capture).
As a former Mentor Graphics Design Architect user I was spoiled and I'd
really like to have some of DA's features again:

1. The concept of attribute (or property) ownership.  For example, a net
name attribute is 'owned' by a net object.  When a user moves a visible
attribute, a ghost line is drawn between the basepoint of the attribute
and the owning object.  This is useful, for example when moving a net
name since you know which net it belongs to.

2. The ability to change your selection model from 'individual' (i.e.
what gschem has now) to 'additive'.  This would allow you to select
multiple objects without having to constantly hold down the shift key.
Of course an 'unselect' command would be needed as well...

3. The ability to rip busses using an index (or rule property for DA
users) instead of having to specify the complete name of the bus
element.  For example, assume a bus named data[15:0].  To access bit 10
on this bus many schematic editors require the user to name the ripped
net name  data[10].  So to rip off all 16 wires you must type data[0],
data[1], etc...
Now what if you want to change the bus name to cpu_data[15:0]?  Now you
have to rename everything.  This is a bad, especially for cases in which
you want to re-use chunks of other designs.  You end up doing lots of
work.

Using a 'rule' attribute to rip off wires makes things MUCH easier. To
rip off data[10] in the previous example, add a 'rule' attribute whose
value is 10 to the net.  Throw in a 'sequence text' command and editing
busses is trivial.

4. Tool scriptability. What if gschem implemented a command set
(presumably in scheme) and every action performed by a gschem user was
translated into a command and then passed to the tool?  For example,
lets say the user changed to color of nets with a pull down menu.  The
call back for that menu item would construct a command that looked
something like 'change-color(net, yellow)' and pass that to gschem.
gschem would execute to command and log it.

This type of architecture would enable all sorts of useful things.  For
example:
  a. The tool would not necessarily have to operate in GUI mode.  A
script could open a schematic, perform edits and then close the
schematic.
  b. Repetitive tasks could be automated easily.  For example, an FPGA
symbol could have nets added automatically added to it based upon the
output of the FPGA router tool.  I used to do this a lot with Mentor DA.
  c. Extensions or customizations to the tool could be added easily. For
example, custom menus and menu items.

  The list goes on.

5. The ability to examine the characteristics of a particular object or
instance. For example, a 'report instance' command that would dump
information on the selected instance (or instances) such as
attribute-value pairs, sheet location, component library path, etc...

6. The ability to change the selection behavior from 'select object only
if fully enclosed by the select box' to 'select if any portion is in the
select box'

7. The ability to select objects using a select filter.  For example,
selecting all instances with the attribute 'refdes' and then doing an
update component could be handy...

8. Instead of doing a symbol translate to 0, how about introducing the
concept of a symbol 'origin'.  The origin would be indicated by a
special mark on the symbol. The origin could be moved or placed by
putting the edit cursor at the desired position and executing the
'origin' command.  When the symbol is instantiated, the user's cursor
snaps to the symbol origin for dragging and placement on the schematic.
All subsequent symbol updates are perfumed such that the origins of the
currently instantiated symbol and the updated symbol are matched.  A
consequence of this is that if you change the origin point on a symbol
in the library and then do an update, the symbol will move on the
schematic.

9. Colors.  Right now colors seem to be pretty rigidly defined.  How
about letting the user freely assign colors by object (i.e. nets, pins,
comment text, symbol body, etc...).  Could the gnome color selector
widget be used for this?

10. Implement polygons with the ability to fill them.  Makes drawing
arrowheads easier.

11. Allow bitmaps to be placed on a schematic.  I'll admit this one is
pure fluff, but nice for company logos and such.

12. Add command (hotkey?) to simply change the value of the selected
text.  Man times you simply want to edit the value and nothing else.
After 15 year with MGC tools it's I still hit shift-f7!

13. Implement a grid which consists of 'major' and 'minor' grid points
with both major and minor grid user-configurable.  The major points
could be displayed as normal brightness points of maybe a 3X3 pixel
'plus sign' while the minor grid points could be dimmed single pixel
dots.  A useful setup would be a major grid on 0.1" increments and 5
minor points per major grid point.  You could restrict symbol pins to
major points if you wanted to.  Having a snap able minor grid sure makes
positioning text fast and easy.  Really makes it easy to draw a neat and
tidy schematic.

14. Automatic versioning to a user-specified version depth.  Makes life
a little easier if you mess something up and notice that fact after the
fourth save!

Well, what do you think?  Any of these worth working on?

Keith

Keith Outwater
Sr. Staff Engineer
Microvision, Inc.
19910 N. Creek Parkway
Bothell, WA 98011