> On Sep 21, 2017, at 8:18 AM, Seth Hall <[email protected]> wrote: > > Yep, this notion of making things abstract-able into easy configuration > interfaces and/or good documentation (using the inline broxygen > comments) was always in the proposal, Johanna pointed it out in the > original code sample.
Yeah, I was wondering what a UI would currently look like if you tried to use existing functionality, e.g. just identifier names and broxygen comments. Like Jan, I had a hard time understanding the benefit having two names for the same value: the identifier and config string. It seems to push more burden than needed onto script authors, like maybe they don’t really care about a UI, but want the improved configuration capabilities. i.e. maybe the requirements of a UI can be separate from the requirements of the new “configuration variables” concept. Maybe one thing to do is try to actually build/design your ideal UI and/or configuration tool starting with just the existing Bro functionality. You’ll definitely get an understanding of the low-level requirements that way. i.e. first design/build the most basic user experience that functionally works and then, from that state, add whatever you think will be an improvement. > There is just something about the idea of exposing variable names to > users (even if it's wrapped in a gui) that is intensely unpalatable to > me. It's pretty much unheard of among other types of software. It > would be like exposing internal variable names to command line programs > instead of abstracting it into easy flags (i.e. -a or --help) or, if in > a gui a text entry box had a label next to it like > "GUI::My_Program::user_name" instead of showing "Username". I’m half facetious in bringing it up, but have you seen CMake? https://cmake.org/runningcmake/ - Jon _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
