#2 Be able to comment out entire lines/parameters

[Anna Wojtowicz]

Users should be able to comment out an entire parameter if they don't want to use it (but don't want to delete it per se). We could add a check box next to each parameter in the Property Viewer table to offer the option to comment/uncomment lines.

Which logic should we use here? Checked box == commented or uncommented line? Intuitively, I'd think having an unchecked box means the line won't be used during BISON execution (ie. is commented out).

Implementing this would require two steps:

1. Adding the check box to the Property Viewer table and corresponding it to some value on the parameter Entry. (Jordan)
2. Making sure the file reader/writers can parse/write commented out parameters correctly. (Anna)

[Jordan Deyton]

We should be able to just plug up the Entry description to these comments
provided we aren't already using it. Adding a new column to the table
should be no problem.
On Sep 18, 2014 2:48 PM, "Anna Wojtowicz" awoj@users.sf.net wrote:

• assigned_to: Jordan Deyton
• Comment:

Jordan, I'm assigning this to you initially so you see it, and then you
can sic it on me later if you want.

---

• [moosefeatures:#2]
  http://sourceforge.net/p/niceproject/moosefeatures/2 Be able to comment
  out entire lines/parameters*

Status: open
Milestone: 2.0
Created: Thu Sep 18, 2014 04:09 PM UTC by Anna Wojtowicz
Last Updated: Thu Sep 18, 2014 04:09 PM UTC
Owner: Jordan Deyton

Users should be able to comment out an entire parameter if they don't want
to use it (but don't want to delete it per se). We could add a check box
next to each parameter in the Property Viewer table to offer the option to
comment/uncomment lines.

Which logic should we use here? Checked box == commented or uncommented
line? Intuitively, I'd think having an unchecked box means the line won't
be used during BISON execution (ie. is commented out).

Implementing this would require two steps:

1. Adding the check box to the Property Viewer table and corresponding
   it to some value on the parameter Entry. (Jordan)
2. Making sure the file reader/writers can parse/write commented out
   parameters correctly. (Anna)

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/niceproject/moosefeatures/2/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Jordan Deyton]

Sorry. I somehow replied to the wrong email. In any case, I agree that we
should add a check box to the left of the parameters

[Anna Wojtowicz]

Jordan, I'm assigning this to you initially so you see it, and then you can sic it on me later if you want.

[Jordan Deyton]

I've figured out how to add CheckBoxes to the TableViewer of properties, but I haven't figured out yet where we can store whether or not an Entry should be commented out.

Currently, we're not using the tag for anything in particular... it just gets the name of the Entry. Since the requested feature is MOOSE specific and the tag is not being used by our MOOSE plugins, we may want to use it for now to signal that a parameter should be commented out. If we need to use the tag for something else in the future, we could always either add a new attribute to Entry or extend Entry to get a new MOOSEParameterEntry.

[Jay Jay Billings]

What about setting the required flag on the Entry?

Jay
On Oct 6, 2014 5:09 PM, "Jordan Deyton" jdeyton@users.sf.net wrote:

I've figured out how to add CheckBoxes to the TableViewer of properties,
but I haven't figured out yet where we can store whether or not an Entry
should be commented out.

Currently, we're not using the tag for anything in particular... it just
gets the name of the Entry. Since the requested feature is MOOSE specific
and the tag is not being used by our MOOSE plugins, we may want to use it
for now to signal that a parameter should be commented out. If we need to
use the tag for something else in the future, we could always either add a
new attribute to Entry or extend Entry to get a new MOOSEParameterEntry.

---

• [moosefeatures:#2]
  http://sourceforge.net/p/niceproject/moosefeatures/2 Be able to comment
  out entire lines/parameters*

Status: open
Milestone: 2.0
Created: Thu Sep 18, 2014 04:09 PM UTC by Anna Wojtowicz
Last Updated: Thu Sep 18, 2014 06:48 PM UTC
Owner: Jordan Deyton

Users should be able to comment out an entire parameter if they don't want
to use it (but don't want to delete it per se). We could add a check box
next to each parameter in the Property Viewer table to offer the option to
comment/uncomment lines.

Which logic should we use here? Checked box == commented or uncommented
line? Intuitively, I'd think having an unchecked box means the line won't
be used during BISON execution (ie. is commented out).

Implementing this would require two steps:

1. Adding the check box to the Property Viewer table and corresponding
   it to some value on the parameter Entry. (Jordan)
2. Making sure the file reader/writers can parse/write commented out
   parameters correctly. (Anna)

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/niceproject/moosefeatures/2/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Anna Wojtowicz]

The Entry.required flag currently corresponds to the required field of each MOOSE parameter, as specified in the YAML file.

When writing the blocks to file, it will write out all Entries marked as required, plus any non-required Entries that have valid data.

[Jordan Deyton]

I'm just going to go ahead and leave these links here because they were helpful for me.

http://wiki.eclipse.org/Tables_And_Trees_And_NativeControls
http://tom-eclipse-dev.blogspot.com/2007/01/tableviewers-and-nativelooking.html
http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet230.java
http://www.eclipse.org/articles/article.php?file=Article-CustomDrawingTableAndTreeItems/index.html

Also, there was a bug with drawing Controls (widgets) to an SWT Image. The code they use in the second link above (and elsewhere on the internet) goes as follows:

GC gc = new GC(control);
Image image = new Image(control.getDisplay(), control.getSize().x, control.getSize().y);
gc.copyArea(image, 0, 0);
gc.dispose();

This didn't play well with the UI thread on my machine (Win32), and usually at least 2 of the Images of checkboxes were exactly the same (I create one for each state... enabled/disabled and checked/unchecked, so 4 total Images). I came up with this solution:

Image image = new Image(control.getDisplay(), control.getBounds());
GC gc = new GC(image);
control.print(gc);
gc.dispose();

I guess this solution actually makes more sense, because the GC is created by passing in the "receiver" for the drawing... the thing that gets drawn on. However, I didn't notice this anywhere in the documentation and saw no examples of this anywhere else, and it took me a while to connect Control#print(GC) with the proper constructor for a GC.

Anyway, hopefully this will be useful to someone else out there.

[Jordan Deyton]

I just submitted a bunch of code in preparation for this. There is some commented out code in MOOSEPropertySection.java that sets up the checkbox column at the front of the table. I'm going to test it on other platforms first before I uncomment it out, though.

[Jordan Deyton]

This works well on Windows 7, Fedora 19, and OS X (On OS X, the checkboxes are not square because the check mark goes outside the box a little bit. When unchecking a checked box, you can still see the corner of the checked Image, but it's just a few pixels and changes when the Table cell loses focus.) I think I can finally call it quits for this request on the UI side.

Giving the ticket to Anna so she can close it after she implements support for commenting out the entire line.

[Anna Wojtowicz]

I've added this feature. It should be able to handle lines commented out, in-line comments, and both at the same time. Commented out lines are disabled, and in-line comments are written to the parameter's description.

This is also true for blocks as well, where a block beginning with a hash is set as inactive. The only caveat is that top-level blocks are all automatically forced as active by MOOSEModel.reviewEntries() as part of the input/YAML consolidation process that happens later; so any top-level blocks that are commented out are forced as active. I don't know if there's any way around this.