Remaining Monad Issues

[ly29]

Aside from custom properties in #798.

What are the remaining issues with monads? Please fill in. It would be good to push this into master soon rather than later.

• [x] expand monad into nodes
• [x] add TAB to exit / enter a monad
• [x] monad inside monad
• [x] script nodes
• [x] pop, and append space.data.path consistently and correctly.
• [x] restructure files and functions for easier management
• [x] monad node color, better after restructure of files.

The issues below can be done while in master

• [x] append
• [x] link
• [x] groups in IO/json per https://github.com/nortikin/sverchok/issues/782 - new issue https://github.com/nortikin/sverchok/issues/810
• [ ] sort links (prevent most noodle intersections)
• [ ] auto layout expanded (ungrouping a monad doesn't push the surrounding nodes away).
• [ ] documentation
• [ ] node reroutes inside groups /w respect to iojson

[zeffii]

Nice work @ly29 . I'd say it was a joint effort.. but the difficult parts you did :)

• expand into nodes, I think can be done with relative ease by using the copy/paste operators again.
• monad inside monad, ok - not high on my radar, but it may be simple enough. Suggest making the poll function for the operator return False if the current ng is already a monad. Even if this is a short-term preventative measure.
• sort links, inputs is (as discussed earlier) a little easier than outputs. Neither of which are real blockers to usable monads, but we both agree there is some aesthetics/UX benefit to deal

[zeffii]

added reference to : https://github.com/nortikin/sverchok/issues/782

[zeffii]

maybe time to close: https://github.com/nortikin/sverchok/issues/462

[ly29]

Closed that old thing. I feel it was a joint effort. Expand is show stopper. Tab would be nice as well.

[zeffii]

i was busy adding TAB support, but found something neat / weird when cross referencing the Cycles nodetree behaviour. It seems TAB will also enter a node if the mouse is just over the node and the node isn't selected.

the ops.nodes.group_edit has an exit property which seems to make it behave exactly as the ops.nodes.tree_path_parent operator.

[ly29]

Many nice things that are hard to discover... But so nice

[zeffii]

not sure if the equivalent is possible here.. https://github.com/nortikin/sverchok/commits/dyn_misc (for Tab and Ctrl-Tab)

[zeffii]

a dedicated operator which can asses the context can distinguish if the user intends to Exit or Enter

.. it feels dirty to hijack an existing operator... but having the repetitious code also feels wrong. I'll push it away for a bit.

[zeffii]

for some reason I think it will also get more complicated to allow tab / tab , if we are eventually allowing nested monads.. much opportunity to invoke the wrong kind of operator...

[ly29]

I think it can be made to behave based on context

[ly29]

https://www.blender.org/api/blender_python_api_2_77_1/bpy.types.SpaceNodeEditorPath.html#bpy.types.SpaceNodeEditorPath

If a monad instance is active node push, the mouse pointer is slightly more complicated but not that much, If it ain't pop the path.

[zeffii]

20c922c makes tab do both scenarios.. not happy with the code... but it even seems to work if there is no direct active_node .

[ly29]

Also the file sv_monad_tools.py is getting a bit to big. But better to restructure when there aren't so many active branches.

I think the following makes sense, ` The path becomes`sverchok.ui.monad which skips repetitive naming.

sv_header.py + sv_monad_panel -> sverchok.ui.monad
sv_monad_tools (Operators) -> sverchok.utils.monad 
sv_monad_tools (monad class) -> sverchok.core.monad
nodes.basic_data.groups_exp (base class and concrete node classes) -> nodes.basic_data.monad

If there are any dependencies we solve them with proper interfaces, also each class get registered in each file.

[zeffii]

yeah, that looks tidy! it's about time for proper registration and consistent operator naming too.

[zeffii]

pushed the tab keymap + operator to dynamic_monad_node branch

[zeffii]

well..did a pull request - the code could be improved, but at least it works..

[ly29]

Okay I merged it.

[zeffii]

i'll have a stab at expand monad (into parent) today

[enzyme69]

Can I use this nice monad thing already? Any simple example or I just read the thread.

Can't be just you teo having party. Nikitron is still alive and around which is good.

[ly29]

@enzyme69 It isn't a party but more of a construction site right now. Soon, a day or two I think, we will put into master because then it will already be better than the current one.

@zeffii

Reading the SpaceNodeEditor document I (think) finally understand how works together. The spacedata.edit_tree is the .path[-1] and spacedata.node_tree is .path[0]. Also if we use the blender bpy.ops.node.tree_parent() it works but messes with space data so that we cannot enter the monad again with our operator. The node.sv_switch_layout operator does not do what we really want I think...

    def execute(self, context):
        if context.space_data.node_tree.name != self.layout_name:
            context.space_data.node_tree = bpy.data.node_groups[self.layout_name]
        else:
            return {'CANCELLED'}
        return {'FINISHED'}

[zeffii]

Yeah the current code that does the layoutswitch / overlay-underlay (multiple paths in the space_data) is probably done wrong and therefore also what causes the standard tree_parent operator to fail.

I know this is important, but it gave me a bit of a headache initially so found other things to occupy me. It would be great to finally see the code look correct there.

[ly29]

So instead of switch layouts we can just do something as this. I think. The up part is tested.

        path.clear()
        path.start(ng)
        path.append(monad)
        # or if and instance is available
        path.append(monad, node=monad.instance)

And to go down.

      path.pop()

[zeffii]

I had not seen path.start :)

[ly29]

Check here. https://www.blender.org/api/blender_python_api_2_77_1/bpy.types.SpaceNodeEditorPath.html

[zeffii]

yeah, i am more confident that's the way to go now.

[ly29]

A group inside of group inside of a group etc.

[ly29]

It is bit strange with the .bl_labelbeing used I think. NOPE node.name is used, which is based on bl_label I think label would be more useful. reference

[zeffii]

https://i.imgur.com/EOFU9ao.gif

[ly29]

Override of blender properties. This actually works like one might expect.

def _get_monad_name(self):
    return self.monad.name

def _set_monad_name(self, value):
    self.monad.name = value

class SvGroupNodeExp:
    """
    Base class for all monad instances
    """
    bl_icon = 'OUTLINER_OB_EMPTY'

    label = StringProperty(get=_get_monad_name, set=_set_monad_name)

[ly29]

Okay I cleaned up the operators a bit.

[ly29]

Moved into a new file in ui to keep it separate. Test if works for you.

[ly29]

Script node is working, only need to make sure properties gets propagated to node interface.

[zeffii]

I don't know which branch to test now? seems like last updates to dynamic_monad_node was 30+ minutes ago?

[ly29]

Script node just worked. So yeah the 30 minutes old is the most current.

[zeffii]

is monad_color a bit too similar to Script Nodes custom color?

[ly29]

Yeah, that is is.

[zeffii]

(0.46, 0.98, 1.0)
(0.196, 0.92, 1.0)

difficult to make solid colors with the opacity of the nodes..

[zeffii]

nice to see script node just 'work' for a change :)

[ly29]

If it makes you happy there are some issues still pin down. I generate the properties from the script node props, but for some reason it cannot use them for updating the node.

[ly29]

Now it works. Testing is welcome.

[zeffii]

I generate the properties from the script node props, but for some reason it cannot use them for updating the node.

updating from the node's script_str ?

[ly29]

I forgot to set the new properties update function to update=updateNode .

            if "prop_type" in prop_data:
                # I think only scriptnode uses this interface
                # anyway replace the prop data with new prop data
                if "float" in prop_data["prop_type"]:
                    prop_rna = FloatProperty(name=other.name, update=updateNode)
                elif "int" in prop_data["prop_type"]:
                    prop_rna = IntProperty(name=other.name, update=updateNode)
                prop_name = generate_name(make_valid_identifier(other.name), cls_dict)
                cls_dict[prop_name] = prop_rna
                prop_data = {"prop_name": prop_name}

[zeffii]

pitty this stuff is so hard to write automated tests for.

[zeffii]

reckon Ctrl+E would be ok for Expand nodes?

[ly29]

For the standard it is Alt G when having a group node selected.

[zeffii]

fine by me :)

[ly29]

@zeffii Looking at the code/comments in your expand I think you could make it simpler.

1. get the node to expand, via context or as argument, verify that it is a monad instance
2. get the monad and append into it
3. select all and copy all
4. pop the path back
5. deselect all and paste
6. find the input/output nodes
7. now we have whole monad and monad instance
8. replace the links one by one by parsing instance/input and then instance/output
9. remove the instance, input, and output
10. Finished

As a bonus it could be nice to move the other nodes a bit to the side.

By doing this way we don't have collect any links.

[zeffii]

oh.. wait

I was writing the operator to be executed from within a monad, turns out a little trickier to find the monad_instance_node, unless ...?

..hadn't thought about doing it from a perspective of having the monad_instance_node selected...

By all accounts if you feel like doing this -- I won't have quiet time for another few hours.

[zeffii]

thought about it and your approach is much preferred.

[ly29]

I won't have time until tomorrow, I gave it some thought after writing the upgrade and creation functions and this approach of collecting less data seems simpler. It also strikes me now that this could a be simpler way to do the monad creation as well...

For finding the nodes I don't have a more clever way that scanning all nodes looking for .bl_idname either.

The real issue is moving the things out of the way in a orderly manner.