You're sort of on the right track here. I'll see if I can explain it better.

Inside a contraption, any settings we want to remember will need to be stored in widgets inside the contraption. These widgets will often be invisible; just for internal use by scripts.

An ordinary widget has "attributes", like the "text" attribute of a field which can be read from or written to by scripts; I'm sure you've done this many times:

myField.text:"welp"   # write to the text attribute of the field widget myField
myField.text          # read the text attribute of the field widget myField

In contraptions, we need to tell Decker what should happen when an attribute is read from or written to by defining appropriately-named event handlers.

If you wanted to be able to manipulate a contraption from an external script like this:

myThing.textColor:23 # write to the textColor attribute of the contraption myThing
myThing.textColor    # read from the textColor attribute of the contraption myThing

Inside the contraption you'd need to have a widget to keep track of that text color setting. Let's say the internal "storage" widget for the textColor attribute  is a slider widget named "gringus" set up to store an integer between 0 and 255. The contraption prototype's script would then need to include something like the following to wire up the attribute to the storage:

# handle reading from the .textColor attribute, retrieving the value from gringus:
on get_textColor do
 gringus.value
end
 
# handle writing to the .textColor attribute, storing the new value (x) in gringus:
on set_textColor x do
 gringus.value:x
end

The "get_textColor[]" event handler is called on a read, and the "set_textColor[]" event handler is called on a write. If only a "get_textColor[]" handler is written, the attribute is read-only. If only a "set_textColor[]" event handler is written, the attribute is write-only (which is a bit unusual). In your example it looks like you have the naming convention backwards; for example you have "bCol_set" instead of "set_bCol".

To actually do something with that "textColor" attribute aside from storing it, you'd also probably have a view[] event handler in that contraption prototype script along the lines of your example. You can freely choose between retrieving the text color setting directly from "gringus" or by calling "get_textColor[]":

on view do
 canvas1.clear[]
 canvas1.pattern:gringus.value    # this works
 canvas1.pattern:get_textColor[]  # equivalent to the above
 # etc...
end

In some cases you may want writing to a contraption attribute to have a "side-effect" in addition to storing the new setting. For example, after recording the new textColor we could call the view[] event handler to immediately update the appearance of the contraption to reflect the change:

on set_textColor x do
 gringus.value:x
 view[]
end

(There's a bit of subtlety here for complex contraptions, as the scripts triggered by a get_ or set_ have to finish quickly; I'd be happy to expand on this later if needed, and there's some general advice in the reference manual. For simple contraptions this approach is fine.)

The "Prototype Attributes" panel is how you tell Decker that certain attributes are meant to be manually-editable in the properties pane of each instance of the contraption, and how they should look. These will only work properly if there are underlying get_ and set_ event handlers in the prototype script corresponding to the "name" of each attribute in this list.

In the Decker Reference Manual, the example describes building a prototype which externally exposes an attribute named "value", accessed like "counter1.value", which is stored in an internal field named "val", and wired up with internal event handlers named "get_value" (which reads from the "val" field) and "set_value" (which writes to the "val" field). I can see how the similarity in these names might get a little confusing; I'll consider rewriting some sections of that tutorial.

Is this explanation any clearer?