gEDA-user: Improving the DRC error presentation

[Ben Jackson <ben@xxxxxxx>]

On Cygwin/X, the DRC presentation leaves a lot to be desired.  Each 'ok'
dialog to step to the next error pops up in a slightly different place.
It's usually right on top of the work.  It's a distracting popup when
there are two simultaneous other attention events, a message in the log
and some selection change on the display.

I was thinking of three possible ways to improve it, in order from least
to most complex:

1)  Extend the confirm_dialog to have a persistent mode for things like
the DRC, where the buttons would be like 'next'/'cancel'.  The dialog
would pop up once, stay up for the duration and then be closed by some
final call from the DRC.  This would require some extension to the HID
interface, the simplest is probably a new HID API call like confirm_dialog
which stays up until you call it with a NULL or something to indicate
you're done.  Then a wrapper like call confirm if the hid didn't support
the new form.

2)  Extend the Message interface to allow for messages that require
confirmation.  If you've ever played nethack, this would be akin to
having the log message say, "Your wire is too close. -more-" and a new
button would appear near dismiss/clear to step through the messages,
and it would disppear when there were no more.  In fact, the
implementation of idea (1) for a given HID could look just like this.

3)  *Really* extend the Message interface so that all messages can have
a context that includes a location and possibly objects.  'DRC Check'
just blows through all the checks and dumps them all into a log (ala Eagle)
and then you can move through the log with next/prev or by clicking and
each time it would be able to identify the object/location originally
associated with the message.  You could imagine this being useful for
all kinds of messages, not just DRC.

This dialog could be a new one, only for DRC and similar messages, or
it could just be an extension of the current Message.  For example, the
standard %-style substitution could be extended to have a %point and
a %element which would be translated into text but also recognized as
metadata for the log message.

-- 
Ben Jackson AD7GD
<ben@xxxxxxx>
http://www.ben.com/


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