What do you use to develop your maya GUI?

Coding
, ,
1

I’ve been programming for a little while now (nothing to do with maya or python tho) and I decided to write a tool for maya. I’m still kinda new to python but I’m learning quite quick it seems. I’ve been doing some research and it seems like pymel is the way to go.

So now the thing I need to figure out now is what is the fastest most efficient way of developing sophisticated GUIs in maya tk wx pyQT. I read that tk is kinda unintuitive when it comes to more complex GUIs. For now I’m kinda leaning towards pyQt. What do you guys use ? Also how does pymel play with wx or pyQT do they get along?

2

We have PyQt, wx, and tk being used in house here. We are beginning to lean more towards PyQt because of how robust the language is, as stated, tk is unintuitive for me to work with and, while wx isn’t bad, I don’t think it has near the library size and functionality as PyQt.

That being said, you can still write some very good GUIs using maya’s built in internal libraries.

3

For really simple tools, just the normal Maya.cmds. For anything more, I rapid prototype in QT designer, and then implement using pyqt.

4

Do you use pymel in your production? Does QT work well with pymel ?

5

We use maya’s own libraries. Once you are used to them (as we from MEL) they are quite fast to build with.

But I guess we will move over to PyQT once we are fully moved over to Maya 2011.

6

[QUOTE=CombatCow;8032]Do you use pymel in your production? Does QT work well with pymel ?[/QUOTE]

Qt works fine with pymel. pymel even provides some functions to convert Maya widgets to Qt widgets.

We don’t use pymel due to it’s performance issues (Inherent to any api to maya.cmds str casting sadly).

7

Qt is the best option for sure. Very powerful tool set and very easy to use compared to anything else I’ve tried.

8

Thanks for the answers guys. Cleared up a lot of questions.

9

[QUOTE=Temujin;8035]We don’t use pymel due to it’s performance issues (Inherent to any api to maya.cmds str casting sadly).[/QUOTE]

Same here.

10

[QUOTE=Wolfsong;8050]

[QUOTE=Temujin;8035]
We don’t use pymel due to it’s performance issues (Inherent to any api to maya.cmds str casting sadly).[/QUOTE]

Same here.[/QUOTE]

The benefits of object oriented method calls on any python node or component far, FAR outweighs any performance issues PyMEL has.

We’ve written 1,000 of scripts, only 2 suffer from slow performance. In general, it is mesh iteration that gets really slow as PyMEL creates a PyNode object for every vert it iterates, so just use plain 'ol maya.cmds for that script. Problem solved.

Until you start using PyMEL for a couple of months and you start to realize that you can get any command you’d want to run on any Maya object auto-completed for you in an all-knowing IDE because every command you’d need is attached as a method to your PyNode object, you will not fully appreciate how powerful PyMEL is.

11

[QUOTE=Count_Zr0;8056]The benefits of object oriented method calls on any python node or component far, FAR outweighs any performance issues PyMEL has.[/QUOTE]

Agree (man i’m just derailing threads all over the place today).

Ok so I’ve been trying to avoid getting into these Pymel vs the world discussions personally, but anymore i feel like this whole “OMG PYMEL IS TEH SLOW AND SUX0RZ” is getting out of hand and putting people off of even trying it, which i think is tragic. Sure it IS slow compared to things like cmds and built-ins, but let’s be honest, python itself isn’t really that high performance anyway, so if speed is genuinely a concern, go back to Mel and C++. In larger codebases, readability and maintainability both trump performance in many cases. If you’re working in an environment where you have a large team working in your python codebase and you’re actually on any sort of a deadline, those considerations need to be at the forefront when picking APIs. Truth is, you could write some UGLY python code that was super fast because you’re using all these cool tricks, but come back to it six months later in the middle of crunch. Voice of experience telling you that actually, you won’t be quite as proud of your “high-performance” python in that case. And trust me, being humbled by a more senior developer because your super fast python code reads like a torn up, muddy roadmap will make you feel like a n00b faster than getting owned as a first timer in Counterstrike, even worse when it’s coming from a pymel dev (“uhhh, why are you recasting all those PyNodes back to PyNodes? Why are you casting individual components to Pymel types? You know those are iterators, right?”)

At the end of the day, if Pymel’s speed hit doesn’t translate to negative user experience, then i’m not really sure what the problem is. I mean, yeah i guess it’s cool that we can all walk around talking about performance like “real engineers”, but i’ll take my slow, readable, maintainable Pymel with some of it’s really cool advanced features that actually contribute to both the aforementioned readability and maintainability vs whatever benefits you think you’re getting from maya.cmds, that like i said, at the end of the day PROBABLY don’t matter that much to the people you should be most worried about as a Tech-Artist, aka YOUR ARTISTS.

Ok ok, so my point: to my mind good code lives at the crossroad of readability, maintainability, and ability to provide good user experience. Pymel makes it happen, maya.cmds, sure, but not so much. At least not as much as people think the perf savings are worth. And trust me, i’ve built two pipelines on pymel now, haven’t had any perf issues to speak of. Use pymel where it’s best suited, use cmds where it’s best suited, use the C++ api where it’s best suited. Seriously, we CAN all just be friends.

Example: Custom nodetype
C++ for the plugin because i want it to have a custom draw and draws in Python are? Yep, slow!

Pymel/maya.cmds/api for the function set. Function set is implemented as a virtual class in Pymel that relies on both cmds and the python api at certain points. Why a pymel virtual class? I mean geez, now i’m making ls() even slower on purpose!!

  1. Maintainability. Now i don’t have to go back into the C++ and recompile if i want to add to or change the function set.

  2. Writing tools on top of that virtual class are nice and readable, ie they look just like any other normal python/Pymel code, but because i’ve already built out my function sets in a lower level module, i don’t have to write any special handlers/hackarounds in any of my other code.

Try doing that with just cmds or the C++ api…
</and breathe out…>

12

[QUOTE=Count_Zr0;8056]In general, it is mesh iteration that gets really slow as PyMEL creates a PyNode object for every vert it iterates, so just use plain 'ol maya.cmds for that script. Problem solved.[/QUOTE]
And that is probably 80% of what we do in scripts inside Maya. Mesh iterations. Hence the problem.

For scripts that are used by the artists on quite large scenes repetitively all day as parts of validation and export pipelines, performance is an issue if you can cut 3 minutes each time.

Not saying that we don’t use PyMEL at all, as we do for some tools.

13

Sorry, didn’t mean to start a Pymel sucks fest. I like pymel just fine, and like you said, for most cases it really would work just fine. The only reason performance is an issue for me is because I’m using OpenMaya almost exclusively for most of my tools lately. I’m really interested in MRV actually, since that seems to be a more API focused package.

I definitely feel people should evaluate packages themselves, rather than rely on here-say. Don’t avoid it or use it just because someone says to, try it for yourself and see if it suits your needs before making a decision.

At the end of the day, maya.*, Pymel, MRV, etc… are just python packages like anything other. Whatever gets the job done right, and will be easy to maintain in the future is what I will choose.

14

The choice of using pymel vs cmds vs anything else comes down to the task at hand. If I’m working on a publishing / export pipeline that needs virtually no introspection then using pymel is like using a hammer to kill a fly. So in this specific case “the benefits of object oriented method calls on any python node or component” do not “far, FAR outweighs any performance issues PyMEL has”

15

[QUOTE=ShadowM8;8099]If I’m working on a publishing / export pipeline that needs virtually no introspection then using pymel is like using a hammer to kill a fly."[/QUOTE]

Hammers kill fly’s way faster, easier, and harder than maya.cmds. :D:

If you’re dealing with lots of paths in your pub/export pipe (I know I am, seems like a good 50% of my code is dealing with paths), pymel offers an awesome Path class:
pymel.util.common.path

Which rocks over plain 'ol os.path. And the methods are attached to your filePath string as a path object, instead of using a command. i.e. -

###maya.cmds (regular python): #####
import os.path
myPath = ‘C:/temp/test.txt’
os.path.basename(myPath)

you can assign your filePath string to a Path object:

pymel’s path class:

import pymel.all as pm
myPath = pm.Path(‘C:/temp/test.txt’)
myPath.basename()

The subtle difference is, of course:
command(object)
v.
object.method()

PyMEL IS more pythonic, helps keep your mind in the object oriented mindset, instead of Maya’s old command mindset.

(and the extended path class is helpful) (and all the other extended utility methods on every other class are helpful)