El mar, 07-11-2006 a las 23:56 +0000, Peter Clifton escribió:
[snip]
> El vie, 03-11-2006 a las 12:47 +0000, Peter Clifton escribió:
> > [snip]
> > > Peter B and I were looking at the possibility of introducing some
> > > plugable input validation / auto-complete modules into the gschem
> > > attribute editing system. The down side of course, is these must be
> > > configured (by default if you will) to understand what attributes are
> > > necessary, and what is legal.
>
> I should qualify my statement... "Looking at" as in had planed how it
> might work from a user perspective.
>
> We wanted / want to move the attribute editor to be a side-bar, or a
> non-modal dialog which picks up its context from the selected
> components.
>
> Peter B was looking how we needed to hook selection changes, however we
> concluded that a lot of this code needs refactoring to have glib signals
> so a "selection-changed" event or similar can be emitted as necessary.
> Whilst I didn't dig deep in that area myself, Peter B at the time
> mentioned that there are some cases where the hook calling isn't
> consistent enough to catch all mechanisms for selection changes in a
> simple and maintainable way.
>
> > I was thinking about this for a while before you post this mail...
> >
> > My two wishes are:
> >
> > 1) gschem should know what attributes can have a given object (and hide
> > the rest in the attribute editor window). Example: if editing the
> > attributes of a net, don't show the refdes, slot,... attributes as
> > options in the drop down menu.
>
> In our model, we would have the attributes grouped by destination too,
> e.g. Under a "PCB" heading we'd see "footprint", Under a "spice"
> heading, we'd see "model" etc.. Some generic ones such as "value" may
> come higher up, but essentially the user can now see which attributes
> matter to them. Further, if we somehow tell gschem what the schematic is
> being used for (PCB, spice etc.) it need not offer the other attributes
> by default.
>
> The way you describe requires more meta-data in the component library
> which I'm all for having. I presume we need to define a list of known
> attributes (or categories) for each symbol? (With the exception of
> "slot" etc., as these can be inferred from the file format as is.
I don't want them in the library. We can just have a scheme list in the
gschemrc file like:
("COMPLEX" ("refdes" "footprint" "value")) storing the allowed
attributes for the object of type "COMPLEX".
Maybe the lists for all objects can be grouped in a single list.
> In the mean time, grouping attributes by tool reduces the clutter, and
> only requires config / code changes, not a big library + fileformat
> update.
You can create another scheme list for that...
> > 2) user configurable input validation (both for the content of the
> > attribute, as well as attribute bounds (don't allow to set slot=5 for a
> > part with only 2 slots), and object checking (don't allow to set the
> > refdes attribute for a net, for example).
>
> Indeed.. user configurable as in - you can edit the scheme, I thought?
> Perhaps we write a series of default validators, and users can add /
> remove them with lines in the gschemrc. Perhaps you can pass arguments
> to the validators from the config file? This could allow more generic
> validators to be useful.
That's the idea.
> > At that time, I thought to:
> > 1) add a scheme function which takes an object list (a list with the
> > objects selected), and returned the common attributes of all the
> > objects. This would be used to fill the attribute name list in the
> > attribute editor. Of course we need a way to define the object type an
> > attribute can be attached to, but that's a simple problem.
>
> This is not something I'd thought of, however it also works nicely with
> the concept of a non-modal attribute editor. When editing non-common
> attributes, the attribute would be greyed / blanked out, but can be
> over-ridden for the whole selection should the user want to.
>
> (Perhaps I'm mixing our ideas here though.. I recall another UI
> "design" / concept we thought of for inherited attributes where greyed
> out values represent attributes inherited from a parent object / group.
>
> > 2) add a new scheme function to check the attribute. When the user adds
> > a new attribute, call this function, which would return a string showing
> > the problem description. Thus, an error window can be raised, and the
> > message and checks are user configurable. A general regular expression
> > can be defined for each attribute as well as any other check function.
>
> I'd not have an error window. I'm already frustrated enough with
> gschem's log window popping up when I load gschem.
Check the wiki:
http://geda.seul.org/wiki/geda:faq-gschem#each_time_i_start_gschem_the_log_message_window_is_shown._can_i_disable_it
I added this one right now ;-) .
> I was thinking more
> along the lines of colour coding the text / background of the entry, red
> (error) / green (known ok) / yellow (Unknown or unvalidated).
>
> The other idea I had was to have a little bullet / traffic light lamp
> light up in one of those colours next to the entry.
>
> Both methods require a tooltip (probably not discoverable enough), or
> status line to explain the validation results. For generic scheme
> validators, this would have just to be a returned string.
>
> The regular expression validation sounds like a really good idea. Any
> idea which library we can pull in to do it simply? Does glib do regexp?
I think scheme does it:
http://www.delorie.com/gnu/docs/guile/guile_198.html
(Thanks DJ!)
Regards,
Carlos
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
