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
_______________________________________________ pspp-dev mailing list pspp-dev@gnu.org http://lists.gnu.org/mailman/listinfo/pspp-dev
