lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: [lmi] first version of multi dimensional data editor control chec


From: Vadim Zeitlin
Subject: Re[2]: [lmi] first version of multi dimensional data editor control checked in
Date: Sun, 8 Jan 2006 23:30:50 +0100

On Sun, 08 Jan 2006 19:59:12 +0000 Greg Chicares <address@hidden> wrote:

GC> >   What is missing is a way for the user to remove the unwanted axis,
GC> >   i.e. those along which the data doesn't change at all.
GC> > 
GC> >  Is this correct?
GC> 
GC> The user can also add an axis that had not previously been used.

 In the approach I proposed, all axis would be always shown, so instead
of "remove" I should have said "disable" above. And, of course, what you
can disable, you can also enable.


GC> Here's what I think. MDGrid is a general-purpose component, or at
GC> least it's much more generic than the product editor; if you envision
GC> reusing it in other circumstances, then it should be designed the way
GC> you think best, though of course I'd like to make sure that won't make
GC> life harder for lmi users.

 I do hope to make this control available under wx licence (although not
necessarily as part of wx) so I tried to make it rather generic but I also
thought that this would be good for lmi as, from my experience, it's better
to have something more flexible even if it means that you have to
specialize it and not use all its features than to make a very particular
kind of control which would then have to change if program needs change.
At least in my own code I often regretted not having done this.

 Unfortunately I made a big mistake and didn't realize that the user, and
not the programmer, selects the number of axis to show for the given
entity. I thought that it would be determined by the entity itself...

GC> Now, lmi users may benefit from the legacy editor's modality: it
GC> prevents them from "accidentally" changing the dimension of an entity.
GC> Is there another way to give them that "safety" within your new
GC> paradigm? Yes, I think--one could potentially add a "lock dimensions"
GC> checkbox. If selected, it would prevent crossing the vertical bar in:
GC>   Strike:   "Invariant" | {"European", "American"}
GC> so that "Invariant", if chosen, could be displayed but disabled; and,
GC> if "Invariant" is not chosen, then a selection between "European" and
GC> "American" options would be forced.

 Just to be sure, you mean a global "lock dimensions" checkbox instead of
having one "use this axis" checkbox for each axis, right? But otherwise
we'd still use my idea with adding a special value to all comboboxes,
except that comboboxes would be disabled when this "lock" checkbox is
checked?

GC> This would simplify use of the interface in the typical case where an
GC> entity actually varies across zero or one dimensions, because almost
GC> everything would be grayed and the user could only choose which axes to
GC> display.

 Well, this would be the case without "lock" checkbox as well. If I
understand you correctly, it's really just an additional safety mechanism
and doesn't add any features on its own.
 
GC> We could even go one step further: offer no choice at all for scalars,

 Sorry, I'm confused again: but how do we know which ones are scalars?

GC> Consider also how the editor might be used for read-only files.

 To be able to view all data when it varies along more than 2 axis, the
user would still have to select values in the other comboboxes so I don't
think we can disable unlocking even in this case.

GC> And, if this idea doesn't greatly appeal to you, consider making the
GC> "lock dimensions" behavior optional, say, with a constructor flag.
GC> If the flag isn't given, then no such checkbox would even be shown,
GC> as if the option didn't exist. What do you think?

 I agree that it's probably better to make it optional as people are either
going to love it because it prevents them from making accidental mistakes,
or hate it because it slows them down in doing what they want to do. And
the best UI probably depends on the importance of the data being edited.

 Thanks again for taking [more] time to discuss this,
VZ





reply via email to

[Prev in Thread] Current Thread [Next in Thread]