Re: GUI

[John Darrington]

On Fri, Nov 04, 2005 at 06:07:43PM -0800, Ben Pfaff wrote:
     
     > Phase 3:  Add the ability perform transformations on the data (eg. SORT,
     >  AGGREGATE etc).  I suggest the best way to do this is to have
     >  the GUI generate a syntax string eg "SORT CASES BY /x" and pass
     >  this request to an external daemon, similar to the way Ben
     >  suggested earlier.  The exact details of this protocol will have
     >  to be worked out --- eg it'll be necessary to specify a socket
     >  or pipe to stream the casefile from the gui to the backend, and
     >  vice-versa.
     
     Maybe we should specify some protocol that's easier to emit and
     parse than the syntax.  I dunno.  I guess we'll see how it goes
     when we get there.

I don't think that spss syntax is particularly hard to emit, and we'd 
probably want to implement log files a la spss anyway.  Admittedly it's
not easy to parse, but we already have a parser for it.  In the back of
my mind something like this:

 ** <meta> read casefile from port x; write casefile to port y </meta>.

 SORT CASES by /x.

 LIST.

.. but like you say, we'll see when we get there.
     
     > Phase 4:  Add procedures (eg EXAMINE, T-TEST, REGRESSION).  This will
     >  work much the same way as Phase 3.  The new issue will be how to
     >  display the output.  One way will be to use our existing output
     >  mechanism and to add a GDK driver to it.  This will however will 
     >  not allow for  interaction with the "Pivot Tables" the way that
     >  spss does.  Other options exist, which I've not really thought
     >  about much, and it's probably more in Ben's area of expertise.
     
     I have a bit of a plan here.  We'll see how it works out.  The
     idea is that procedures emit their output in a neutral,
     machine-readable format (possibly HDF5 or XML) and then readers
     can convert it into whatever format they like (plain text,
     PostScript, etc.) or display it as pivot tables or whatever.
     There's a huge, huge stack of details to work out of course.

That certainly seems like the correct long term solution.  The GDK
driver idea might be an acceptable fill in solution if the HDF5/XML
infrastructure is not ready when we get there.  Or if we wanted to do
something even less elegant, somewhere there's a 3rd party GTK widget
capable of displaying postscript.

J'


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

pgpa3ASq5RuTm.pgp
Description: PGP signature