Re: gEDA-user: Comments after successfully running gnetman . . . .

[sdb@cloud9.net (Stuart Brorson)]

Carlos, 

Thank you for your test.  I downloaded the CVS version of gEDA and
have been digging around in the gschem code to try to figure out how
to implement some of these changes.  I'm glad you started this 'cause
I realized that it would take me some time.  I also like your
multi-line text edit widget.

Some comments below.


> El mar, 18-11-2003 a las 01:14, Stuart Brorson escribi=F3:
> [snip]
> > As far as the change goes, my thought was to create a 6th button on
> > the attribute saying "enter value text" or something like that.  When
> > you clicked it, it would give you a multi-line text entry widget where
> > you could enter the attribute value.   This widget would pop up on top
> > of the attribute edit box.  You would type in the multi-line text, and
> > then you would click on "OK" in the multi-line text widget, and it
> > would place the text in the attribute's value & return focus back to
> > the attribute edit widget.
> >=20
> 
> I made a quick test for you: I replaced the value text entry widget in
> the multi-attribute editor window by a multiline text entry widget. This
> way, you can enter multiline attribute values.

That's a good test.  For the production version, I think that the user
should be offered the choice of editing either the single-line
attribute (as it works right now), or clicking on a button and
invoking your multi-line text editor.

> But the bad news is that gschem's behaviour is not what you want (at
> least by now).
> I place the spice directive in a schematic, double click on it and the
> multiattribute editor window is showed.
> Then, click on "value" property, and enter a new value (any two lines
> text, for example: "line1\nline2"). Click on "change" button. The text
> is changed in the attribute list showed in that window (despite it's not
> shown in a properly way), but something strange happened in the
> schematic window : the "line1\nline2" text should be displayed, but
> "value=3Dline1\nline2" is showed instead.
> If I double-click again on the spice directive symbol, and I check the
> attribute list, then I don't see any "value" property. A property
> without name neither value is showed in the list, in the place where
> "value" property was before.

Hmmm. . . . it sounds like I need to better understand the data
structure holding the attributes.  I'm looking at the stuff in
x_multiattrib.c.  Is that the right place?  Ales, how are attribute
name/value pairs stored?

> So something more is necessary before you can do something like this.
> The most important thing you will want is to load/save schematics with
> such values, and from Ales's words I guess that gschem is not prepared
> yet to do that.

Interesting point.  The problem is likely the file format.  (Ales,
correct me please if I a wrong.)   Here is the spice-include symbol as
instantiated in one of my schematics: 

C 26900 55300 1 0 0 spice-include-1.sym
{
T 27000 55700 5 10 1 1 0 0
refdes=A1
T 27400 55400 5 10 1 1 0 0
file=./Simulation.cmd
}

I can see that a multi-line attribute would look like this:

C 26900 55300 1 0 0 spice-include-1.sym
{
T 27000 55700 5 10 1 1 0 0
refdes=A1
T 27400 55400 5 10 1 1 0 0
value=Here is a bunch of text 
with various carrage returns
in it.
}

That would make the parser puke 'cause the parser is line oriented.
I can think of several ways to fix this: 

1.  When the parser encounters a valid attribute, it can continue
reading in lines & assigning them to the attribute (with \n chars
included as part of the string) until it encounters a line which is a
valid object line (i.e. a } or a T 333 333 33 . . ..).  Then it would
terminate & store the attribute.

2.  Define a different style of attribute -- a multi-line attribute --
which *requires* that delimination chars be used to save it.  For
example, one could use triple-double quotes (Python style) like this:

value="""Here is a bunch of text
with various carrage returns
in it.
"""

Then the parser would key off the presence of """ as the first three
chars of the attribute & read each line until it encountered a """ at
the start of a line.

3.  Currently, attributes are not handled specially.  Rather, they are
just a type of text embedded in a component.  Perhaps using a special
attribute tag:

A value=Here is a bunch of text
A with various carrage returns 
A in it.

would distinguish attributes from commentary text, and would also
allow multi-line attributes.

Of course, the problem with all these schemes is that they change the
file format to some degree or another, and thereby break the ability
of older versions to read newer schematics.  On the other hand,
options 1 & 2 don't break the ability of new versions to read old
schematics, which is a good thing.

Also, all options require changing the parser, but if there is
community agreement about which one is best -- or somebody makes a
better choice -- I would volunteer to fix the parser. 

> Anyway, if anyone wants to play with this, I can send the whole tarball
> or the diff.

Can you put the diff on a web page?  Alternatively, if the diff is
small, please e-mail it to me at: sdb AT cloud9 DOT net.

Thanks,

Stuart