mainframe and Tool Dev Question with Maya.

[Padraig Ó Cuínn]

Hi Just a curious question for everyone. 

I was wondering when you are building a mainframe for your tools and separate your code from your GUI work,

what part of the tool do you decide is GUI and what part is maya code?

i.e 

I have a tool that lists, relists, renames and changes attributes of nodes, 

GUI = Buttons, layout look and feel etc 

MayaCode = Pymel section for changing names, adding nodes etc

Where would you put the relisting section as it deals with both aspects of the tool?

Would you strictly have pure GUI on it own and then create a sub function to call from the maya code?

I'm sure you have difference experiences and results but its good to hear from both. 

padraig

[Justin Israel]

Hi

Mainframe seems like the wrong word here. Makes me think of a hardware server :-)

I would say that you should try to make your business logic (the stuff that actually does work) all in one library layer. And then the code that handles user interactions (gui) in another layer. The GUI should just be able to call the business logic. And another user should also be able to use it as a library without a gui. This decouples your code and makes for a good reusable design. It means you can replace the gui any time but your business logic stays the same.

It also helps to further separate generic logic that can be reused without Maya.

Justin

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/bf57a823-c36a-419e-ae67-e5162da6a14e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Justin Israel]

Where would you put the relisting section as it deals with both aspects of the tool?

Would you strictly have pure GUI on it own and then create a sub function to call from the maya code?

Sorry. To be more specific in answering your question, I would ask : can you run your resisting code without a gui? If the answer is no, then you probably need to do some refactoring to create that decoupling, so that your relister doesn't depend on gui code. Because maybe some day you want to swap between Maya native UI, or PySide or PyQt or other. 

[Padraig Ó Cuínn]

The GUI does work stand alone. I haven't added any testing code because I feel it's a little unnecessary. I have some of the old TDs work that he created about 57 scripts but they are all single file scripts which I have no problem with but I want to refactoring it all and remamage them to make my life easier for the future work. That way as you said I'll be able to reuse part by part and the GUI separately like a library. 

Padraig Ó Cuínn

[damon shelton]

I always setup a lib module for all tools to access. And for tools with GUIs I have wrapper functions in the Gui that gather all the info from the gui and pass those as arguments into the lib function. That way other tools can use the code outside of the gui

On Saturday, October 1, 2016, Padraig Ó Cuínn <patchquin...@gmail.com> wrote:

The GUI does work stand alone. I haven't added any testing code because I feel it's a little unnecessary. I have some of the old TDs work that he created about 57 scripts but they are all single file scripts which I have no problem with but I want to refactoring it all and remamage them to make my life easier for the future work. That way as you said I'll be able to reuse part by part and the GUI separately like a library. 

Padraig Ó Cuínn

--

You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/sipm69oxtre16mfrwmf4y273.1475375183516%40email.android.com.