Re: [Discuss-gnuradio] New GRC behavior request for comment
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: 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 Thu, Apr 10, 2014 at 7:00 PM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: 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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Sebastian Koslowski Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe, Germany Phone: +49 721 608-46275 Fax: +49 721 608-46071 Email: sebastian.koslow...@kit.edu Web: http://www.cel.kit.edu/ KIT – University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New GRC behavior request for comment
On Fri, Apr 11, 2014 at 3:29 AM, Koslowski, Sebastian (CEL) sebastian.koslow...@kit.edu 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 On 04/11/2014 04:27 AM, Dan CaJacob wrote: 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 Thu, Apr 10, 2014 at 7:00 PM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: 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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Sebastian Koslowski Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe, Germany Phone: +49 721 608-46275 Fax: +49 721 608-46071 Email: sebastian.koslow...@kit.edu Web: http://www.cel.kit.edu/ KIT - University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New GRC behavior request for comment
On Thu, Apr 10, 2014 at 7:00 PM, Marcus D. Leech mle...@ripnet.com wrote: 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 Leech 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New GRC behavior request for comment
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 Agreed, as long as there's still some indication, I'm cool with that. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] New GRC behavior request for comment
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New GRC behavior request for comment
On Thu, Apr 10, 2014 at 03:55:53PM -0400, Tom Rondeau wrote: I personally like this new method a lot. I like the sound of it. Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New GRC behavior request for comment
On 4/10/14 3:55 PM, Tom Rondeau 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New GRC behavior request for comment
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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New GRC behavior request for comment
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 Thu, Apr 10, 2014 at 7:00 PM, Marcus D. Leech mle...@ripnet.com wrote: 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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
