Re: PSPP conference call notes.

[John Darrington]

On Thu, Jun 01, 2006 at 07:52:45PM -0700, Ben Pfaff wrote:
     John Darrington <address@hidden> writes:
     
     > This is my first attempt at writing a non-trivial GUI program, and I'm
     > still learning.  One thing I'm finding is that it's almost impossible
     > to automate testing in the way that we do the rest of PSPP.
     > Consequently, it's necessary to think very carefully before inserting
     > new code.  I can always use feedback from people who discover problems.
     
     A few quick web searches did turn up that there is something out
     there called "gnome-test-tool" that appears to try to automate
     gtk+ testing.  I wonder whether it is mature enough that it
     actually works...

I'll have a look and find out.  I tried using Xnee, but it really
operates a lower level than what I needed.  I came to the conclusion
that there would need to be extra structures compiled into the GTK+
library so that I could make a widget emit (say) a "clicked" signal on
demand, and script a series of such signals.  I sent a few messages to
that effect to the one o the GTK+ lists, but got a cool response.
     
     >      Here are some of the things that I took away from the
     >      conversation, in addition to what you say:
     >      
     >      - Need casefile bookmarking/cloning.  Should be easy; I'll take
     >        care of it soon.
     >      
     >        This will enable RANK.
     >
     > It will also enable (I hope) integration of casefiles into the GUI.
     > There's a fundamental problem here:  The GUI needs to scroll through
     > the cases.  Scrolling forwards is not a problem.  Scrolling backwards
     > is something that casefiles don't allow.  My idea is to cache a small
     > number of cases (about twice the number that fits in the window) which
     > allows for small magnetude scrolling.  Scrolling back through larger
     > offsets is where the bookmark would come into play.
     
     There is no reason that casefiles *can't* support random access.
     The reason that they *don't* allow it currently is to discourage
     accessing them randomly: in the context of a procedure and a very
     large casefile, jumping around randomly in a casefile in a single
     pass is going to be slower than, say, doing two sequential
     passes.
     
     But I can easily add random access for the GUI to use.  That's a
     situation where it makes perfect sense to support random access.


How would random access cope if somebody uses the GUI to open a system
file with a *HUGE*  number of cases? It would have to swap back and
forth to disk. Perhaps we should discuss this in a seperate thread.
     
     >      - Should add log file support and support for sending errors to
     >        the listing file.  Both should be easy now.
     >
     > But we need to consider the i18n issues involved.
     
     Are there any new ones, beyond those in sending errors to the
     console?

The main question is, "In what language should the errors should be,
if the output language (from SET OLANG) happens to be different from
the langauge of the system locale?"  Again perhaps a discussion for a
seperate thread.

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.

signature.asc
Description: Digital signature