In my latest push to the master branch, I’ve added a feature update from
Sebastian Koslowksi for GRC. Previously, every change to an edit box in
a
GRC Properties box would cause GRC to reevaluate the entire application
to
tell you if your entry was right or wrong. If wrong, it would show up
immediately in red and turn black when it was correct.
This seems fine, but I’ve run into two major issues with that behavior.
First, certain changes would cause errors that would change the focus in
the dialog box. So you would then have to re-click the edit box to enter
what you wanted to in the first place. The second problem was that you
could find yourself in the midst of typing a Python function, like, say,
editing a filter definition, that would incur a huge calculation only
because you weren’t finished typing. GRC immediately tries to run the
calculation and causes everything to freeze. Both very annoying when
they
happen to you.
Sebastian’s tweak is to change from on-change to remove-focus.
Basically,
now, when you edit a field, the field label turns blue to indicate a
change, but it doesn’t try to run anything until you’ve removed the
focus
by tabbing to or clicking on another box in the properties list. It then
evaluates it and produces any error messages.
I personally like this new method a lot. The downside is that if you
aren’t
paying attention, you might enter the wrong thing and hit ok or enter
only
to find out then that you made an error and will have to reopen the
properties box to fix it. I see the upside to this behavior as
beneficial
to this downside. But I think that Sebastian and I would appreciate
thoughts on this or alternative ways to handle things.
Thanks,
Tom
On Thu, Apr 10, 2014 at 03:55:53PM -0400, Tom R. wrote:
I personally like this new method a lot.
I like the sound of it.
Mike
On 4/10/14 3:55 PM, Tom R. wrote:
I personally like this new method a lot. The downside is that if you
aren’t paying attention, you might enter the wrong thing and hit ok or
enter only to find out then that you made an error and will have to
reopen the properties box to fix it.
In general, I like it too, but I see your point about “not paying
attention”, as I’m a “hunt n peck” two-finger typist, and am
often looking down at the keyboard instead of at the screen.
How hard would it be to pop up a bother box if you attempt
to enter with outstanding parameter error(s). Give you
a chance to confirm or cancel the enter, because you may want to
deliberately enter something that’s wrong now but will be
fixed later (for instance a variable name that you haven’t
created yet).
@(^.^)@ Ed
I think this change might be breaking a few things. If anyone else can
check, please let me know if I’m nuts:
I am running v3.7.4git-95-g24191d86 on Ubuntu 13.10 x64. In GRC, when I
try to change the type associated with a block via the select box, it
changes (and the text turns blue), but when I close the parameter
window,
nothing actually changes. I also saw similar behavior with combo boxes.
In that case, selecting an option did not take, but overwriting it did.
Very Respectfully,
Dan CaJacob
On 04/10/2014 04:13 PM, Ed Criscuolo wrote:
How hard would it be to pop up a bother box if you attempt
to enter with outstanding parameter error(s). Give you
a chance to confirm or cancel the enter, because you may want to
deliberately enter something that’s wrong now but will be
fixed later (for instance a variable name that you haven’t
created yet).
I certainly like the “evaluate when you leave the box” paradigm, but I’m
also the kind of developer who will enter a variable name, etc, that
hasn’t actually been created yet.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Same here. Thanks for reporting. I pushed a fix to the GRCWG repo,
should make it into the mainline soon.
Sebastian
On 04/11/2014 04:27 AM, Dan CaJacob wrote:
Very Respectfully,
[email protected] <mailto:[email protected]>
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Sebastian Koslowski
Research Associate
Kaiserstrae 12
Building 05.01
76131 Karlsruhe, Germany
Phone: +49 721 608-46275
Fax: +49 721 608-46071
Email: [email protected]
Web: http://www.cel.kit.edu/
KIT University of the State of Baden-Wuerttemberg and National
Research Center of the Helmholtz Association
On Thu, Apr 10, 2014 at 7:00 PM, Marcus D. Leech [email protected]
wrote:
I certainly like the “evaluate when you leave the box” paradigm, but I’m
also the kind of developer who will enter a variable name, etc, that
hasn’t actually been created yet.
–
Marcus L.
Yeah, I’ll do the same; enter a variable I haven’t created yet. I’m
afraid
of putting pop-up boxes like this, though. You’ll still see the red text
in
the block and the GRC error button will be enabled to help you track
things
down, so there will be an indication that you’ve done something wrong,
it
might just be after you’ve closed the box and will have to reopen it. My
problem with adding pop-up error boxes is the “Windows Vista” effect of
just “dammit, I know what I’m doing!” and close it without necessarily
reading the warning or error.
Tom
On Fri, Apr 11, 2014 at 3:29 AM, Koslowski, Sebastian (CEL) <
[email protected]> wrote:
Same here. Thanks for reporting. I pushed a fix to the GRCWG repo,
should make it into the mainline soon.
Sebastian
I just merged and pushed Sebastian’s quick fix for the issue.
Tom