[petsc-dev] discoverability

[Barry Smith]

   Jed,

    Over 10 years ago we had support for exactly this. Each section  
bracketed by PetscOptionsBegin/PetscOptionsEnd resulted in a page of  
options one could select for in a GUI. This is what the dead variable  
PetscOptionsPublish is related to. It used the Alice Memory Snooper to  
communicate between the PETSc processes and a Tcl GUI. It was pretty  
sweet, but DOE politics killed the Alice Memory Snooper.

    The PetscOptionsGetXXXX() were the old, non-GUI routines and the  
PetscOptionsXXX without the Get  were layered on top and set up the  
data that was communicated to the GUI services by  
PetscOptionsEnd_Private().

    I think the way to resurrect it is by using the Zope stuff that we  
added to PETSc a few years ago and display the GUI's in a browser  
(with javascript I guess). This would give portability and not require  
the user to install any GUI packages. Roughly the PetscOptionsEnd()  
routine would communicate via sockets to the Zope server which would  
display and get back the options via HTTP and the users browser. What  
the GUI system does is present the options and allow the user to set/ 
change the options database graphically as the program runs; except  
for actually sending/getting back the values from the server the code  
is in PetscOptionsEnd_Private().

    Barry

  Zope is pretty cool but the damn fools have only support for very  
specific versions of Python which pisses me off, why should it be  
specific for what they do I don't know.


On Feb 21, 2010, at 11:46 PM, Jed Brown wrote:

> A discussion last week culminated in the following thought.  Certain
> functionality, especially command-line options are not very
> discoverable.  Running with -help is quite verbose, especially when
> multilevels solvers are in use, and this can be rather overwhelming.
> Something that seems readily implementable (provided a cross-platform
> GUI toolkit is available) is a hierarchical help browser.  My thought
> was that -help_gui could bring up something like a two-pane browser  
> with
> options on the left (hierarchical and collapsed by default, perhaps  
> with
> "advanced" stuff colored differently) and corresponding man pages on  
> the
> right.  All this semantic information is already available, although
> "level" is only present in the man pages themselves.
>
> For certain options, such as lists and enums, dropdown menus could be
> presented, with the gui producing a suitable command-line.  I don't  
> know
> which GUI toolkits are viable options, nor how easy it is to embed  
> HTML
> rendering (maybe just wait until everyone has WebKit?).  I just wanted
> to put this idea out for something to think about, it seems like it
> would improve discoverability and help to eliminate the context switch
> between looking up documentation and configuring solvers.
>
> Something I personally would like more is bash completion, but that is
> tricky because the available options can't be presented without  
> running
> the program.  Cutting the job off early is awkward because some  
> options
> aren't available until PCSetUp which is well within the solve phase,
> thus it may take a long time to get that far (a matrix needs to be
> assembled first).  I'm not sure whether this cost would be excessive
> compared to scp and friends which actually establish an SSH session to
> the remote machine when you press TAB.
>
> Jed