[Pipet Devel] documents and viewers (was: excerpt from CHANGES)

[J.W. Bizzaro]

Brad Chapman wrote:
> 
>     WRT the text viewer--that should be no big deal to do, but do you
> want this contained in the "document" widget or as a separate viewer
> widget? It just seems like it might be annoying to have to load the
> contents of a file every time you want to refrence it, especially if
> you have huge text files like some FASTA file or something.

You're absolutely right, Brad, and I'm wrong.  The fact that you're correcting
me on the paradigm shows that you're catching on :-)

DOCUMENTS WILL NOT HAVE A VIEWER IN THEIR WINDOWLETS.  Documents are holding
places for the data, which are transient and ephemeral.

To give a document a viewer, the user would have to connect an appropriate
viewer to the document and make a composite of the two.  Hmmmm.  But could
Loci produce these document-viewer composites automagically, according to mime
types???  Interesting.

> The reason I added the file selection is so that you 
> could get at a file directly if you added a document widget directly 
> onto the workspace.

Documents represent data that are being held in the filesystem somewhere.  So,
Brad is right that the path is important.  But I still maintain that documents
can't change their association with a filesystem file.  They should be treated
as Mac icons, as I mentioned before.  I would put the path in a label widget
rather than an edit box.

> Also, I thought this would be needed if you wanted 
> to use the document widget to supply a file for command line 
> construction.

I kept changing my mind about how files can be added to the command-line, but
I think I've settled on using two different loci:

  (1) Document locus: I/O capable locus that represents data being held
      on the filesystem.  An important feature of the document locus is
      that it can redirect data flow (pipe).

  (2) Command-line infile/outfile locus: Provides the location of the file
      to the command-line (prints out a string) and redirects data flow
      (pipe) to a standard document locus.

Recall Gary's example command-line:

    x-povray -I /path/to/temp.def.ini /path/to/temp.my_povray_file.pov

Here I've reposted the Loci way to construct this command-line:

                     ---->(1)+----------+
                     ---->(2)| x-povray |
+------------------------------------------------------------------+
|                                        |                  |      |
|        (workspace)                    \|/                \|/     |
|                                       (1)                (2)     |
|+-----------+      +------+        +---------+        +---------+ |
|| processor | ---> | flag | -----> | infile  | -----> | infile  | |
|+-----------+      +------+        +---------+        +---------+ |
|| x-povray  |      |  -I  |                                       |
|+-----------+      +------+                                       |
+------------------------------------------------------------------+

Each COMMAND-LINE INFILE LOCUS has 2 connectors: one is 'string adding'
(unlabeled) and the other is piping (labeled 1 and 2).

Both piping (1 and 2) connectors are disconnected.  So, they appear on the
composite locus:

                                 +----------+
                         ---->(1)| x-povray |
                         ---->(2)+----------+

                              (windowlet closed)

Now, connect the documents to the respectively numbered input connector:

 +------------+         +-----------+
 |  document  | ---->(1)| x-povray  |
 +------------+     >(2)+-----------+
 |  def.ini   |    / 
 +------------+   /
                 / 
     +------------+
     |  document  |
 +---+------------+---+
 | my_povray_file.pov |
 +--------------------+

You see, document loci and command-line infile loci are different.

Document loci can provide filesystem path information to other connected loci,
but they can't go in-line with other command-line constructing loci.  These
command-line constructing loci (1) spit a string of text out to the
command-line and (2) gather data from stdout for piping.  They can also (3)
pipe in data and use them as stdin.  I didn't show that in the example, but it
would mean 2 more connectors for the command-line processor:

    |   (2)
    |   /|\
   \|/   |
   (1)   |
+-----------+         +------+       
| processor | --->(3) | flag | ----->
+-----------+         +------+       
| x-povray  |         |  -I  |        
+-----------+         +------+       

Here, connector (1) is a stdin piping type connector, (2) is a stdout piping
type connector, and (3) is a text string adding (used in all command-line type
loci) type connector.

If (1) and/or (2) are left unconnected when a composite is made, they'll
appear on the composite's icon.

Not also that the processor in this example is a special command-line
processor type locus with a string adding type connector.  So, what makes a
locus a command-line locus?  IT HAS A STRING ADDING CONNECTOR.

Cheers.
Jeff
-- 
                      +----------------------------------+
                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |        BIOINFORMATICS.ORG        |
                      |           The Open Lab           |
                      |                                  |
                      |    http://bioinformatics.org/    |
                      +----------------------------------+