UI Plugins with Maya API?

#1

Out of curiosity, does anybody know which classes are used to create UI objects in the Maya API? For example, say I wanted to create a plugin that allowed the creation of a button(), but that was drawn circular.

Or for a more effective example, create a window with a dial to control the speed of an object. The control would be called by MEL, but the actual draw routine would have to be done with a plugin. But curiously, I haven’t found any documentation on creating new UI controls that exist in Maya’s GUI windows, and not the 3D scene with OpenGL.

Any thoughts? Even possible?
Thanks!

#2

Sadly, no. As far as GUIs are concerned, you are more or less stuck with MEL’s gui toolkit.
You can use contexts and locators to add opengl shapes to the viewports, but that’s about it.
I have been requesting similar features for close to 3 years now from alias, without much success (mind you, I’m sure it isn’t easy to change this in maya and it probably is impossible to please everyone).
The best you can do now is get the maya window’s Display or windows DC context and then write platform specific code (say, MFC code on windows), which is obviously no good.
The reason for my asking this is multiple:
a) I find writing decent MEL guis a pain in the neck. I would love to have a visual toolkit a la FLTK’s fluid to do it.
b) I miss the ability to go beyond what MEL offers (say have transparent popup menus, better/more colorful sliders, etc)
c) I wish I could use class inheritance for new widgets.
d) I would also love to be able to hook up an open source toolkit like FLTK, FOX or wxWindows.
e) I would also love to have the gui callback mechanism be left open to other language bindings (ex: python, ruby, etc. so I can start ditching MEL alltogether).

#3

Well, that doesn’t bode well for my carefully (and rapidly) laid out plans.

Then let me pose the following query. Since we can’t create our own GUI controls, is there a way to create some kind of local 3D space that isn’t necessarily within the DG heirarchy of a Maya scene, with a single MEL viewport/camera to view it?

My reasoning for this is, if we can’t change the default controls, let’s create new ones in a 3D space, but that won’t be visible within the scene (and won’t affect automatic clip planes, shadowmaps, etc…)

I know this goes against the entire Dependency Node setup, but I’m pulling at straws now. Or any other thoughts of a way to achieve the whole custom-control setup without disrupting other people’s workflows?

Thanks!

#4

Finally, someone else who doesn’t think Alias’s brain-dead variant of Tcl is God’s gift to the animation industry :slight_smile:

#5

>Any thoughts? Even possible?

i remember a few years ago being able to grab the maya window context and write a Motif based plug-in UI. there are a number of hurdles to overcome, but it should still be doable. similarly, the SLIM plugin is tcl / tk based for all UI related operations. you probably won’t be able to mess with existing UI elements of Maya, but if your plugin opens its own window, inside that widget you can have full control. if you can get it registered within the ELF context, you might even be able to open a GL viewport in there.

i am a bit confused as to what you are trying to achieve though… sexier looking plugins ? different camera movement controls ? new UI widgets ?

#6

Alright, the Motif Window sounds interesting. First question would be, can Motif windows be used when another window manager (FVWM, Gnome, KDE, etc…) are running? I haven’t experimented, but my first attempt yielded an error regarding multiple window managers running on the same system.

Or on top of that, would it be possible to launch a window using any of the above stated window managers, or is it limited to Motif only?

Thanks for all the suggesstions!

#7

Or to add to my own list,
I recently saw a MEL script that created animation controls (for selection purposes), and then parented them to the camera with a semi-transparent lambert assigned to them.

So I’m thinking, why not write a plugin that achieves the same effect through an OpenGL Draw() routine to the active viewport (like a HUD option) instead of adding empty poly shapes and shading nodes to every scene?

I’ve seen a few things for adding custom text-data to the viewport, but does anyone know about running other shapes (such as with MPxLocator) directly to the screen as an overlay?

#8

Well, it’s the Motif widget API that is in question, so that part is independant of the Window Manager/Desktop Environment. There a Motif window manager (mwm), which controls the interaction between Motif applications, but (If I’m correct) it doesn’t help much when you’re only running one Motif app.

#9

I used Motif because :
a) i was writing on an Octane
b) it was easier than X

but once you have the X context, it shouldn’t be too difficult to develop on top of that. again, you can take MtoR / SLIM as an example of a UI written in Tcl TK that runs off Maya. if it comes down to it, you could even spawn a child process and have it interact with Maya through a client / server type plugin and then you are 100% free to use whatever you want to design your UI and custom widgets. you won’t be able to open a maya viewport there though.

overlaying GL stuff on top of an active maya viewport is a different issue and quite a bit difficult. i haven’t put my nose into the 0 API, but i can’t remember of any way of hooking something directly into the redraw of those GL viewports.

still fuzzy on what your objective is.

#10

That’s fighting talk! Seriously thought Dan - I’d be interested to hear your main issues with Mel. For years I’ve wanted a class/stucture style data type to keep functions organised and make the passing of data easier , but other than that I find mel quite cool. But then again maybe I don’t know what I’m missing…

Cheers

Rob

#11

I’ve been pondering this… Perhaps you could write a dialog window in QT (cross platform friendly, if you can afford the commercial version) that is linked against the Maya API, which can execute a custom MEL script to control your attributes.

But, if you’re interested in just creating a fancy looking UI, then you just might be fighting an uphill battle.

#12

MEL really is a horrendous language. It could do with references and data structures to make it more powerful. Also it is very inconistant -f can mean one thing for one command, a different thing for another and for another it is a completely different flag for the same thing.

I realise the C API can be used for a lot if this, but really a scripting language should be powerful enough to give you basic data structures beyond vector arrays.

XSI looks like it has a really nice system - being able to choose your language is nice. Of course Alias got in there first with a hacked together system and took over the market. (there are a lot if nice things about Maya too of course).

Simon

#13

Hmm, not sure how with hundreds of commands that all do different things it would be possible to standadize the use of -f. Usually this will be short for something that you may type in full if you wish -force, -file etc. But yeah, references and structures are a must. The UI limitations aren’t really a Mel problem as such, more just a design that ‘stopped’ way too soon.

Not used XSI, but picking your language does sound interesting. Does it actually work though - or is it one of those things thats easier said than done?

#14

MEL was probably fine for its intended uses - writing expressions and small scripts. But it is not well-designed as a progamming language, and that bites you when do try to do anything fancy with it.

The syntax really bothers me. I hate having to use string concatenation and backticks to construct function calls. The inability to nest calls is annoying. e.g.:

 float $focal = eval("float $dummy = `getAttr " + $cam + ".focalLength`");

whereas I want to write:

 float $focal = $cam.focalLength;

MEL’s type system is inadequate. Not only does it lack higher-level types like structures and first-class functions, but the types of many built-in functions don’t even make sense. e.g. getting the world-space position of an object, “xform -q -ws -t”, which should be a 3D point, instead returns an array of 3 floats. “xform -q -matrix” should return a matrix but instead it returns 16 floats. The API lacks all sorts of basic functions like vector/matrix multiplication, matrix transposition, inversion, etc.

MEL has some scoping problems, it doesn’t use ordinary lexical or dynamic scoping like “real” programming languages. I can’t point to a specific example, but I know I’ve stubbed my toe several times by thinking some variable went out of scope when it really hadn’t.

I would like a rudimentary exception-handling system for clean-up, e.g. if I open 3 files for output, then get an error, I want an easy way to delete the incomplete files.

I think the best solution would be to replace or adapt the API to an existing language that already has these features, like Python, Java, or Scheme. I do not believe having a large number of supported languages is a good thing in itself, but it’s important to have at least one good solid scripting language (in addition to the C++ API).

I think the packages that support N different programming languages are basically coming up with a generic object/class model and then expressing it within the type system of each different language (much like how Microsoft’s CLR runtime is accessible from all the .NET languages). This is OK but I think a lot of that effort is wasted, you only need one really good, well-integrated scripting language. I would personally choose Python for this. Java, Scheme, or even C# would be valid choices too. (garbage collection would be the major concern, although I think a simple mark-sweep system would take care of it)

Also Alias should think about some way to unify the C++ API with the scripting API. Currently MEL commands live in an entirely different world from the C++ API classes. The fact that you can do certain things in MEL but not C++, and vice versa, makes life difficult. (e.g. implementing a basic “hello world” DAG node involves 2-3 pages of C++ code, there should be a way to do it in 5-10 lines of script). I would like to see the C++ API classes and MEL join together, so you could access the C++ API in some logical way from the scripting language.

The MEL documentation, while thorough, makes it difficult to locate important information. e.g. it took me a LONG time to find out how to extract the knots and CV coordinates from a NURBS surface. (I would prefer to access these as attributes of a NURBS surface node, but instead they must be queried with a MEL command string)

On the positive side, I do like how much of Maya’s internals and GUI are actually implemented in MEL. I once found an answer by looking into Maya’s internal MEL scripts, which I could never have found if it were compiled to C++ code. I think if MEL were more powerful and a better progamming language, even more of the system could be implemented with it.

My guess is that MEL started out as a purely text-based language for sending and receiving strings from the Maya C++ API. They might have even started out using the Tk window toolkit, which would explain why the syntax resembles Tcl. Alias probably underestimated how much Maya end users wanted to expand the package with custom scripts. That explains why MEL has grown beyond its ability to support itself.

#15

>The API lacks all sorts of basic functions like vector/matrix multiplication, matrix transposition, inversion, etc.

the API actually has all these functions in the matrix & vector classes. they even used to be inlined directly i the headers so you could examine the implementation. MEL on the other hand…

   >I would like a rudimentary exception-handling

catch( ) ?

> a lot of that effort is wasted, you only need one really good

agree

>so you could access the C++ API in some logical way from the scripting language.

not sure what you mean… you can write command plugins that are added to MEL’s set. and vice versa, API plugins can run MEL commands.

>The MEL documentation, while thorough, makes it difficult to locate important information.

the old HTML documentations were bette. they butchered both the API and the MEL indexes about 2 versions ago.

>I do like how much of Maya’s internals and GUI are actually implemented in MEL.

i don’t… the ELF widget structure has a lot of design inconsistencies and is missing a lot of options.

>that explains why MEL has grown beyond its ability to support itself.

i would disagree with that… but then again : everyone is entitled to his opinion. MEL takes a bit of practice to get used to… but in the end, it’s fairly usable. the API on the other hand is still lacking a number of critical classes, and Maya itself has a number of features that “bypass” the DAG system that can be most annoying when trying to customize them. those would be my main gripes (that and stupid bugs that have been around for years like the penumbra angle being wrong)

#16

[QUOTE=dmaas]
I think the packages that support N different programming languages are basically coming up with a generic object/class model and then expressing it within the type system of each different language (much like how Microsoft’s CLR runtime is accessible from all the .NET languages). This is OK but I think a lot of that effort is wasted, you only need one really good, well-integrated scripting language. I would personally choose Python for this. Java, Scheme, or even C# would be valid choices too. (garbage collection would be the major concern, although I think a simple mark-sweep system would take care of it)

[QUOTE]

Hey dan, if you like python + scheme + garbage collection, you definitively have to check out ruby.
Current performance will not beat MEL but I’m confident a new implementation of ruby under CLR or Parrot can get you to about 85-90% of its speed (with all the source code available these days, writing a language interpreter/compiler is not that difficult these days).
Personally I am not too keen on python, as I also think it is a badly designed language and I would most definitively not want to deal with whitespace syntax in something like the script editor.
That being said, I do agree with all your criticisms.

#17

Yeah I think whitespace-based syntax was worth trying out, but ultimately I prefer curly braces and semicolons :slight_smile:

The actual choice of language doesn’t matter to me, I’ve got tons of code that looks almost exactly the same in C++, Python, Perl, etc. More important is how well the language is integrated with the 3D API. e.g. As far as I know, in Maya some things can only be done by string-concatenating a piece of MEL code and eval()ing it. This is the kind of thing a good language would avoid.

In regards to combining the C++ and MEL APIs - what I meant was, say Alias adds some function to the C++ API, like MNurbsSurface::makeAwesome(). Ideally you should be able to call it directly from script, like “$foo = getSelection(); $foo.makeAwesome();”. Likewise if you implement a command in MEL, you should be able to call it from C++, ideally with pointers and strong type-checking (as opposed to just strings). You’d have two main problems: converting arguments and return values between the language layers, and keeping track of reference so objects don’t get freed prematurely. These are both solvable. An example of how this can be accomplished is the SWIG interface generator, which automatically writes small bits of glue code to hook up C++ APIs to scripting languages. (I’m not saying Alias should just SWIG up the entire C++ API, I just want to give an example of a system that tackles these problems)

I favor Python because the “glue code” that you use to bind C functions into Python is extremely simple and easy to write. The Python interpreter adds in a modest amount of baggage (less than a Java VM, but more than Lua or probably Ruby). Having access to all the standard Python libraries would be wonderful. (imagine using Numpy to perform very fast numerical operations on large grids, or solving linear systems in script, or writing an HTTP interface to Maya, say for controlling renders, or adding an SQL interface to pull scenes from a database server… drool)

#18

>I think whitespace-based syntax was worth trying out,

wasn’t Cobol enough ? j/k

#19

Thanks Dan - thats alot of good points. I guess I’ve never thought too hard cause whenever the goings gotten too tough with mel I’ve implemented a plugin command or node via the API.

I have to admit that something like your example - “$foo = getSelection(); $foo.makeAwesome();” seems to be asking for trouble. Without implementing a large subset of c++ into mel your example wouldn’t be possible. Bring stuff like pointers into the equation and things get way way more complicated, I would personally find pointers a hinderence in mel especially considering the lack of decent debugging tools. I’m guessing but you sound like you have a strong programming background and mels simplicity is frustrating - I agree too - although it was mel that got me into programming and then into c++. If Mel had been like learning c++ from the outset there’s a chance I (and many others) would have given up long before.

Rob

#20

i honestly think MEL is where it should be : simple enough to be a quick scripting language, flexible enough to give you access to 90% of the software. sure, there are a lot of things that could be improved :

  • lack of data structuring
  • being able to implement node classes from MEL (so you don’t have to write a plug-in to make a new node)
  • faster interpretater (the MEL VM is sloooooow)
  • native functions to access image files
    …

in the spirit of using the right tool for the right job : if i am planning a major tool development round like say a hair system, it’s pretty obvious MEL is not going to cut it and i’ll probably want to a hybrid approach with C++.