On Monday 16 November 2009 22:55:49 Peter Clifton wrote:
> On Mon, 2009-11-16 at 22:09 +0000, Kai-Martin Knaak wrote:
> > On Sat, 14 Nov 2009 14:59:49 +0000, Peter Clifton wrote:
> > > Please fetch, test, enjoy..
> >
> > Some quick notes:
> >
> > * There is next to no documentation. No man page, no output on "-?", no
> > help button in the GUI, either.
>
> It is supposed to be simple enough that isn't an issue ;)
> Ok, honest answer... we didn't get around to adding them. If you can
> think of anything useful to add in either case, let me know though.
>
> Perhaps the "--help" invocation should print something like
> "
> Usage: xgschpcb [project_filename]
> "
>
> But that's about all I can think..
We accept patches (well, Peter C. does). Questions:
- As Peter mentioned, xgsch2pcb takes only trivial command-line arguments.
- Are man pages an effective means for documenting GUI-only applications?
- What is the best way of presenting help information within the program?
What exactly should a "Help" button do, if we added one?
About command-line arguments: there's a reason we didn't implement the "GNU
standard" args to begin with. This is the current command-line parsing code:
if len(sys.argv) > 1:
window = MonitorWindow(sys.argv[1])
else:
window = MonitorWindow()
To support the "GNU standard" args, we'd have to write (or import) a pile of
option-parsing code that wouldn't be doing *anything useful* for the program
at all.
> Ideally the GUI should be simple enough that the user does not _need_
> help from within the program. If something about it isn't simple enough
> without help, then I assert that I or Peter B designed it wrong. ;)
>
> > * What is the format of the "extra gnetlist arguments"? Should the
> > options be preceded with "--"?
>
They shouldn't. (Actually, that field's a misfeature, IMHO.)
> > * A window that shows the actual project file would be welcome.
>
> I don't see it being that useful - this is meant to be a simple tool. I
> certainly don't want to offer an editable window for this, since it
> gives the user a great opportunity to shoot themselves in the foot.
Agreed. If you have enough knowledge to edit the gsch2pcb project file
directly, I don't see any reason not to use an appropriate tool for editing
text files. Definite NACK from me.
> > * How about a log window rather than sending all the spew to stdout?
> > This log should also include all gsch2pcb commands emitted by xgsch2pcb.
>
> That is a fair idea - although in an ideal world, the output is only for
> debugging, and should not be necessary. xgsch2pcb attempts to throw
> warning dialogs for anything "usual" it parses in the gsch2pcb spew,
> such as missing footprints.
I don't feel that a log window is a desirable feature for xgsch2pcb; improving
the application's ability to parse the gsch2pcb output and explain what went
wrong (and give suggestions about how to fix it!) is much more valuable.
> > * The GUI deviates from the usability standards of Gnome or KDE:
> > + There is no row of menus.
> > + A Quit-Button on the upper left of the GUI is pretty unusual.
>
> It doesn't need a menu, so why have one? By avoiding it, we remove the
> clutter. Point me to where either guide says all apps must have a menu.
I can confirm that the lack of a menu bar was a deliberate design decision; we
had few enough buttons that it seemed reasonable (and better from a UI point
of view) to put them one click away rather than two.
Peter
--
Peter Brett <peter@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user