On Tue, 2006-11-07 at 20:00 +0100, Carlos Nieves Ónega wrote: > Hi, > Moving this thread to geda-dev... > > 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. In the mean time, grouping attributes by tool reduces the clutter, and only requires config / code changes, not a big library + fileformat update. > 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. > 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. 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? > > One idea was "footprint" (assuming your config states that validation > > and auto-complete for this attribute should be for "PCB", not some other > > layout package). > > > > The user setting the footprint attribute would auto-complete with a > > drop-down list of the available footprints - obviously requires a > > knowledge of how / where PCB finds its footprint lists, or a library > > interface to this functionality in PCB. > > The validation method described above relies on scheme, and maybe it's > not as flexible and powerful as you may want. I don't see how to do the > PCB stuff that way. Scheme can be made to run external processes.. I don't see why it can't be as flexible as we want. Sure, bi-directional pipes might be a pain (I don't know), but I expect we can fork a helper which you pass strings, and it returns validation results. > Do you have some thoughts about how to do it? More ideas about what it ought to be able to do, I've not yet dug into gschem's internals to see about implementing it. I did mock-up some coloured attribute editing entries to see if it looked ok, conveyed the information. I've not added status lines to these yet, so they are basically nothing special. (Patrick's nice new single attrib editor + some coloured backgrounds). It should go in the multi-attrib editor too. I'm concerned with possible slowdown, and want to see any validation / drop-down footprint lists etc. be implemented using asynchronous logic + appropriate glib signals. This should avoid us blocking if a notional validation / choice list is either computationally intensive, or requires connecting to a parts database server at some point in the future. I think we need to discuss more about how it should be used / look, and then come to a consensus on how it could work internally before we try to implement it. I did consider hacking on it for a bit and presenting something which "works", however it seems it would be non-trivial to get right. I'm quite busy, so don't foresee any time to work on it before the new year. I already have the DBus support for PCB to finish... I should get one job done at a time, its just cleaning up the (now working) test code takes takes time! Once that is done, (and hopefully into CVS pcb), I need to fix xgsch2pcb to work nicely with it, and hopefully deploy it here for testing. Regards, Peter C _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
