Re: GUI questions

[John Darrington]

I'll deal with the gui philosphy questions in a seperate thread, when
I've got more time.

On Mon, Oct 01, 2007 at 10:10:29PM -0700, Ben Pfaff wrote:

     The reason I left out Z-scores from my initial DESCRIPTIVES
     dialog design was that I didn't think that they made any logical
     sense there.  It seems to be that they should be on the Transform
     menu, or at least in a separate "Compute Z-Scores" menu item
     under Analyze|Descriptive Statistics.  They're only a part of the
     DESCRIPTIVES procedure because it's convenient to put them there,
     not because it makes a lot of sense from a UI perspective.  But
     moving them to a new menu item could also confuse users who
     expect them to be in the old place.

OK.  I'm not sure how often it will be used anyway.  I think for now,
this could be left unimplemented.  Let's wait until somebody complains
about its absence.

     First, should we use psppire.glade
     for everything, as done so far, or should we use a separate glade
     file for each dialog?  Based on my experience thus far, my guess
     is that if two of us try to modify psppire.glade in separate
     check-ins, there are going to be massive conflicts.  The patch
     file that I posted looks pretty clean, but that's only because I
     edited out, by hand, a lot of superfluous changes that glade-3
     made throughout the rest of psppire.glade (even though I didn't
     change anything in the rest of the file).  Conflicts are a lot
     less likely if we break things up, since most changes would be to
     different .glade files.

Recently I've been thinking the same as yourself;  psppire.glade
should be split up into seperate files.
     
     For
     examples, procedures can't run without any data, so should we
     gray out the Analyze menu until there's data?  

I think not.  Procedures can run without data, although in most cases
they will give trivial (and perhaps meaningless) answers.

     specific procedures have more stringent requirements; for
     example, DESCRIPTIVES needs at least one numeric variable,
     CROSSTABS needs at least two variables (for any sensible
     results), and so on.  Should that be implemented by graying out
     menu items, by displaying an error dialog if the menu item is
     selected, or another way?

A "good" GUI should prevent the user from choosing invalid options.

If a procedure requires only numeric variables (or variables
satisfying any other predicate), then you can enforce that by only
displaying the appropriate variables in the treeview (use the last
argument of attach_dictionary_to_treeview).  See the weight cases
dialog for an example of this.

Currently, I don't think there's any way to deal with the situation
where there are two fields in the same dialog which have different
constraints on what properties a variable may have.


     Finally, there are constraints on what
     can be selected in a procedure before it can be invoked; e.g. for
     DESCRIPTIVES it's necessary to select at least one variable
     before clicking on Paste or OK.  How should this be enforced?

Paste and OK should be greyed ("insensitive" in GTK+ terminology)
until the dialog has been set up so that sensible things happen when
you click them.

This is an issue not only for DESCRIPTIVES, but for nearly all the
dialogs, and I haven't addressed it yet.  Probably I should add a
method on the PsppireButtonBox widgets.   I was going to wait until
after 0.6.0 before looking at that.  Do you think it's more urgent?

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