API - In-View Editor

API - In-View Editor

Nico0307
Participant Participant
330 Views
1 Reply
Message 1 of 2

API - In-View Editor

Nico0307
Participant
Participant

Hello beautiful maya people,GUID-A26018B4-6175-4996-96BD-FACB5D3A64AA

 

being full of motivation after finally climbing the mountain that is POLYMODIFIERCMD,

I'm now trying to figure out how to connect an in-view editor to my polycmd nodes.

 

As far as I can tell, the native commands transition into a post command context and the in-view editor ui seems to be a manipulator attached to it.

 

I looked through the devkit examples and documentation for openmayaui but couldn't find any manipulators that fit, other than maybe the ui table thing? Somehow I have memories of old forum posts saying it was somehow possible, but I can't find those anymore either .... 😞

I'd love to just try everythign out, but it always takes me a lot of time to dive into any new api related topics, so I'm hoping for some light.

 

I already explored pyside uis with a dynamic draggrContext, but ideally I would like to give my commands as native a feel as possible.

 

I'd love any input. Thank you!

 
0 Likes
331 Views
1 Reply
Reply (1)
Message 2 of 2

Nico0307
Participant
Participant

Ok, I have since then found the necessary procedures myself.
Therefore I will conclude this thread with a short writeup of my findings. That is, unless your experience differs or if some of my findings aren't correct. In that case please do reply!

 

The InView Editor is in fact handled as a manipulator, but there is no functionset for it. Here's what I found:

 

Setup:

1) Create a Manipulator plugin using MPxManipContainer

Manipulators can either be applied to a plugin context or to a node.

2) Give your Manipulator the name of the nodetype it should show alongside to, appended by "Manip" (important)

3) Call "MPxManipContainer.addToManipConnectTable()" in the node initialize, where you declare your plugs.

(also make sure to use "removeFromManipConnectTable()" when unloading your plugin)

4) Inside the MPxManipContainers "connectToDependNode()" method, use "addPlugToInViewEditor()" on any plug of the selected node, given it's the one you want.

(It doesn't matter which plug, since the inview editor will at that point show up for all keyable/channelbox attrs)

5) No further setup steps, like you would usually have for other manips

6) in the case of a polycmd, after you're done commanding, select your node and set the context to "ShowManips"

 

Limitations: (Assumed)

- After some research and from my own experience, MPxManipContainer is currently practically not usable in python api 2.0, so if you're using api2, a separate plugin file has to be created for the manip, written in api1 or c++. A py2 Node can interact with such a manipulator just fine, which was what I had tested.

- There is no control over the order and visibilty of attributes on this plugin iv-editor. The only thing that controls if an attribute shows is if that attribute was keyable/shown in the channelbox. The menu to hide/show attributes shows up, but the settings do not persist and there is no way to catch those changes, so even if there was some file in the prefs that dictated what shows, it would be a very manual process regardless.

- The tab hotkeys to switch between attributes as well as control via mel/cmds' showManipCtx() is not supported

- Selecting an object together with activating the required "showManips" context usually picks up the manipulator of the latest modifiercmd node by itself. In this case, however, the node has to be selected specifically via the node editor or the channelbox(for a polycmdmod). A combination of callbacks could be used to mirror the default behaviour, which I think would be too intrusive.


Conclusion:

Now, I have only used an api1 manipulator with an api2 node, so I can't say if things are different for a c++ implementation, or other possible configurations, but unless someone has some other information,

I think it's fair to say that the current api implemention of the in view editor simply has too many limitations/differences compared to the expected user experience.


Personally I will stick to a custom approach