I’ve always found the process of writing GUI tools with maya.cmds a hell of a lot more cumbersome than it needs to be, so I wrote this library to make things a little easier on myself. It’s a very lightweight toolkit that takes advantage of existing UI functionality in Maya, but if a full-blown QT tool is overkill for the job at hand (or you need to support older versions of Maya without a huge fuss), it lets you write tools without mountains of ugly boilerplate. So, I figured I’d release it open source! Here’s a video that shows how it works:
//youtu.be/rjGa6j-rzIM
The source code is available from this GitHub repo: GitHub - awforsythe/melgui: A small library for facilitating the creation of GUI tools in Maya.
There are no restrictions on modification or use: commercial, non-commercial, whatever. I’m curious to see whether this is something that other people are likely to adopt and use, or if everybody already has their own solution to Maya’s inelegance (or just uses QT for everything).
My secret ulterior motive is that I need work samples for my website, and this seemed like a good way of demonstrating that I know how to do the things my resume claims I can do. Would you say this is a decent thing to have in a Pipeline TD’s portfolio?
Well defiantly beats the maya.cmds way of doing things, but really the main advantage i see is the parenting and indenting in the syntax. This is already possible to do from pymel since it uses the “with” statement along with it’s UI classes to control indentation and parenting. I think most would prefer, the pymel way to where every UI element is a object, with it’s own convince methods for setting and getting values on it after creation, instead of the dict with all the UI objects in it.
Also about that dict full of UI objects you got, maybe you should attach convince methods too it like pymel, instead of cloning the edit and query modes.
i think something like
value = gui['intSlider'].getValue()
or
gui['button'].setCommand(function)
would look a little cleaner, though would be harder to do pragmatically, but still possible, or since almost all flags got a edit and query mode, pragmatically make them into properties.
Also I’m assuming you cant define what function object a callback uses in the from_string() method? If it does it via passing a string, would have issues with a lambda, partial or a decorated function object reference?
It is nice that it does some setup stuff for you like finding any windows with the same name etc, and your callBack notifier looks really cool.
Really overall looks great, blows the cmds and mel approach out of the water, and the callbacks are better than what pymel has.
I’d never used pymel for UI stuff – it’s good to see that it has some improvements over MEL/commands. I made this library (instead of going with pymel or QT) because I often find myself making standalone tools that’ll be distributed to a bunch of freelancers who are using Maya 2008 or 2009. Since they’re all remote and I have no easy way to control their operating environment, I tend to cram everything I’m distributing into a single file and avoid having artists and animators deal with installing dependencies. The other reason is that I had free time and I find this stuff fun 
I thought about allowing command arguments to be specified plaintext in the declaration – it’d be easy enough to implement using eval, but I have a healthy aversion to eval so I figured I’d leave that out for now. There’s already some not-quite-obvious indirection that happens with commands to throw away the almost-always-useless argument that Maya passes to callbacks:
def thunk_commands(flags):
"""
Modifies and returns the given dictionary so that all function
values associated with command flags are thunked into anonymous
functions that ignore the arguments passed to them by Maya.
"""
for flag, value in flags.iteritems():
if 'command' in flag.lower() and hasattr(value, '__call__'):
flags[flag] = lambda _: value()
return flags
…so I didn’t want to complicate it any more than that for now.
Just to be clear, the collection of GUI control objects isn’t a plain dictionary – it just overrides getitem to provide dictionary-style access. It’s actually Gui object, with methods for adding controls to and extending the GUI, as well as processing batch edits from a dictionary.
Dude you should do voiceover work.
Also that’s a pretty cool approach to GUI work.
ah so the gui dict is doing all the element access it;s self, instead of containing each element in the UI as a new object.
For your purposes it defiantly is nice, especially since you can support all the way back to maya 2009 with it.
[QUOTE=SuppleTeet;23351]Dude you should do voiceover work.[/QUOTE]
Ha, if I had a nickel for every time I’ve heard that…
…but I’m a lot more interested in tools programming work. For shame!
This kind of reminds me of things like PyJS or RapydScript which are basically ‘python that compiles to javascript’. In this case it’s more like ‘python that compiles to mel’, at least after a fashion. Interesting. I do some of this for the handful of gui bits in 2011 that are not properly wrapped in cmds, but your method is more general than mine.
The idea of having a little DSL for gui is kind of interesting (after all, that’s what HTML and XAML really are, in addition to being spawns of Satan) . If I was going to try something along these lines I think I’d look into coming up with a CSS style abstraction to provide a ‘stylesheet’ functionality for controlling the layouts, colors, and spacing of the elements in the final output; that way you could maintain consistent looks and rythhms in the finished stuff without the usual fiddly crap about specifying sizes down to the pixel. I guess the other issue would be tool chain - once you have a declarative GUI language the obvious thing to look at would be an editor for designing UI graphically. I know this has been done a couple of times for Maya but I’ve never fallen in love with any of the attempts I’ve seen. I wonder what would be involved in using QT designer files as inputs to rather than hand coding?
Alex, your stuff is always really interesting. I will have to give this a shot next time I need to do some gui work.
