Newbie Mel UI question

04chiak · March 13, 2012, 3:54am

Hey guys I’m still very new at Mel however i have a quick question I was hoping you guys could answer.

currently i have an example script which is

//////////////////////////////////////////////////
string $window = window;
columnLayout;
rowLayout -numberOfColumns 2;
intFieldGrp -l “Min” ;
intFieldGrp -l “Max” ;
showWindow $window;

/////////////////////////////////////////////////////
It works fine but the spacing between the two intFieldGrp are too far away.
so i tried adding a -cw to control the width but it breaks my script I’m hoping you guys could help me out

(script with -cw broken)
///////////////////////////////////////////////////////

string $window = window;
columnLayout;
rowLayout -numberOfColumns 2;
intFieldGrp -l “Min” –e –cw 1 50 –cw 2 150 maxFieldGrpControl2;
intFieldGrp -l “Max” –e –cw 1 50 –cw 2 150 `maxFieldGrpControl2;
showWindow $window;

//////////////////////////////////////////////////////////

thanks for the look and hopefully you guys could help me out! :):

04chiak · March 13, 2012, 5:52am

hmm having the edit function at the start seems like it would work better, however its still not working hmm

primal_r · March 13, 2012, 6:04am

Do you only have a license for an old version of Maya?

Otherwise - stop using MEL and start using Python.

ldunham1 · March 13, 2012, 8:41am

if you doing something that mel was built for, such as creating a simple UI for maya, there is no advantage to doing it in python.

There was multiple problems with your script, this is what you was after;

string $window = `window` ;
columnLayout ;
rowLayout -nc 2 ;
intFieldGrp -l "Min" -cw 1 25 minFieldGrpControl ;
intFieldGrp -l "Max" -cw 1 25 maxFieldGrpControl ;
showWindow $window ;

avoid using the same name for multiple entities, you wont be able to get the info you want, and check your code for mistakes.

Rob_Galanakis · March 13, 2012, 4:02pm

“if you doing something that mel was built for, such as creating a simple UI for maya, there is no advantage to doing it in python.”

Aside from learning a useful language and writing code that is easier for most people (at least those likely to answer his question) to understand?

ldunham1 · March 14, 2012, 7:43am

lol aside from that

I agree python is by far the better language (and I’d much rather use it), and more people are able to help as a result, however, I do often find people asking for help with a simple mel issue and getting “just learn python” or been given a python answer, they already may know python, and are using mel some reason (adding/editing existing code, studio restrictions etc - and im well aware its usually pretty easy to spot someone new to scripting and make a quick judgement on their abilities).

Its no dispute that python is the better language to use and I applaud anyone who gives any help, its what makes the world go round
Although it is oh-so limited, mel can be pretty handy at times and not particularly slow when doing something it was built for, and it can be quick (although generally dirty) to write.
I think I try give the answer they may want, and if it would be better to do in python, I’d suggest that as well.

Again, I’m not looking for any mel vs python debate, anyone with half a brain can solve that, instead perhaps just a teeny-weeny bit more ‘compassion’ (maybe too strong a word lol) for mel? and perhaps this is definitely the wrong forum to mention that lol.

04chiak · March 14, 2012, 9:52am

Ah thanks for your reply it works like a charm. And for the python Mel debate. I’m currently taking a Mel based class. I plan on leaning Python afterwards just baby steps. =), thank you guys for helping me out. It means a lot.

primal_r · March 14, 2012, 10:07am

You can have a look at the MotionBuilder API. It was built for python from scratch.

If you try it out, you’ll see that the Maya API is severely gimped due to the legacy existence of MEL. MEL is like Cancer growing in the heart of Maya.

Rewriting your MEL-stuff to Python wouldn’t take long*. Just going through each line and converting the syntax. It would be far from the prettiest/smartest Python code but it would be prettier than the MEL that spawned it.

Any studio which have a studio restriction against using Python in favor of MEL deserves bankruptcy. Or a change of restrictions.

AutoDesk would do best in totally dropping support for MEL as fast as possible (which however is probably not very fast).

If you have a huge library of MEL-stuff it’s due to one of the following reasons:

because the library have been around for a long time. And if it’s been around for long I’d bet you that most of the stuff in there is already done by the software itself in the newer versions.
You have an army of MEL-scripters. Converting them to an army of Python-coders would be a good solution.

I know you didn’t want a discussion on the topic, but I couldn’t help myself =P

primal_r · March 14, 2012, 10:08am

[QUOTE=04chiak;14919] […] Mel based class. […] [/QUOTE]

.arrghhHhhh. My eYes Are BuuurNiing in Pain!

ldunham1 · March 14, 2012, 10:57am

Haha, well aware of this, and have been a victim of it. I agree mel’s days are numbered, due to its limitations (and a helping hand with the introduction of python to maya (and soon max)) but it is still widely used at present.

The problem I find in doing this (and probably just me) was this was my approach to learning python, rewriting it line-by-line, approaching it as I did with mel, and I found grasping things very difficult (again it could just be me), such as what importing actually does and its need, classes, OOP etc (so I would instead suggest building it almost from scratch in python, you’ll learn far more and far quicker than line by line - but i suppose that is depending on the user)

Haha totally agree, however i would have thought, for whatever reason, some studios may still be running pre maya 8 (i believe that’s the version python was introduced), or perhaps have an entire workflow based around mel and not the time or money to rebuild (they would have to eventually).

Completely agree as a scripter, but wouldn’t it stuff up alot of smaller studios and individuals not quite there with python if it was a sudden change?

Again, completely agree.

Haha well if it was an uncontrollable reaction then I suppose it couldn’t be helped lol, and I believe im just as bad lol ^

I think my main point was just that some people ask for help with mel and dont get far, whether they should learn/use python or not, they could be in a situation where python is not option. So I completely agree with most of your points, I was just speaking about the minorities and apologies if I’ve just started something, I can already tell you I’ll lose lol.

EDIT: after seeing this post as a whole, I realised how pedantic I came across quoting to break paragraphs down, lol

Rob_Galanakis · March 14, 2012, 3:25pm

“You can have a look at the MotionBuilder API. It was built for python from scratch.”

Really? I thought it was just SWIG bindings? It isn’t pythonic at all and has all the hallmarks of a C API. That said, it is nicer than maya.cmds and their hideous MEL ‘flag’ stuff, though that’s not the API. The API is OpenMaya but and my OpenMaya code ends up looking somewhat similar to my mobu python code (as both are, AFAIK, just SWIG bindings, though yes OpenMaya is uglier though I think that’s the API in general and nothing to do with python).

bclark · March 14, 2012, 7:01pm

what is funny is that people talk about MEL like maxscript, like it was an afterthought in MAYA. Maya and MEL were the same thing and still many parts of it are.

Sure python is “more” but it was an add on, MotionBuilder was designed to never, ever have scripting and then Python was bolted after enough user request and other things but it has been a slow process to expose and improve python access to the MotionBuilder internals.

So while python is the new hotness in applications, people forget where things were just 10 or 5 years ago. I agree with Lee.

primal_r · March 15, 2012, 12:36am

[QUOTE=Rob Galanakis;14945]“You can have a look at the MotionBuilder API. It was built for python from scratch.”

Really? I thought it was just SWIG bindings? It isn’t pythonic at all and has all the hallmarks of a C API. That said, it is nicer than maya.cmds and their hideous MEL ‘flag’ stuff, though that’s not the API. The API is OpenMaya but and my OpenMaya code ends up looking somewhat similar to my mobu python code (as both are, AFAIK, just SWIG bindings, though yes OpenMaya is uglier though I think that’s the API in general and nothing to do with python).[/QUOTE]

Yes you are right, my choice of words was sub-optimal. What I meant was that the scripting language never existed in any form before the python implementation. As such, there was never any software-components written in a non-oo manner.
I’m not adamant about python at all; I think f.ex. that ruby would have worked well instead (but an industry de-facto standard is more important). It’s just the concept of oo or not for the components/functionality/operations that makes the big difference.

I apparently use some terms (like API) a bit too loosely.

So yeah I guess it’s just maya.cmds; and getting results as a string I hate.

[QUOTE=bclark;14954][…]
So while python is the new hotness in applications, people forget where things were just 10 or 5 years ago. I agree with Lee.[/QUOTE]
But if someone learn today what was a reality 5-10 years ago in this industry…

What I’m saying is that if you’re spending your limited study time doing a MEL-class at school; you’re spending time learning computer history - not the trade of TA’ism.

Wolfsong · March 15, 2012, 1:40am

[QUOTE=primal_r;14966]
So yeah I guess it’s just maya.cmds; and getting results as a string I hate.
[/QUOTE]
And still it’s faster then PyMEL despite all those string operations…

I still feel MEL has it’s place as it’s quite fast, faster then Python in Maya for most things. And if you are not setup with Visual Studio with the right version and all that which always stopped me from learning C++ in Maya, and of course if you don’t know C++, it’s a way to speed up some code (UI in this topic not being such a case of course). Also it’s to a certain degree a requirement if you want to plug into the core Maya functionality by overriding some default scripts (at your own risk), like the RMB menu. Still I may write 1 line of MEL for every 1000 python theses days.

It’s funny how people (not just based on this discussion) can look down on a language which has been one of Maya’s greatest strengths compared to it’s competitors for way over a decade.

h6x6n · March 15, 2012, 6:15am

The importance of speed in many operations involved in TA work is really negligible. we’re usually talking about differences of less than a quarter second after a button press. There are times where the speed may become a factor, either due to the speed of specific processes being significantly slower, or your scripts looping enough that the millisecond differences in time add up, but those are edge cases, and in almost every situation, the time you save writing and maintaining the better language will be much more significant than the time saved by writing in an ever so slightly faster language.

I’m not saying that there aren’t reasons for knowing (and even occasionally using) MEL, but most of the times I’ve seen it implemented for “speed,” the gains are completely unnecessary.

Rob_Galanakis · March 17, 2012, 3:58am

“It’s funny how people (not just based on this discussion) can look down on a language which has been one of Maya’s greatest strengths compared to it’s competitors for way over a decade.”

Is it? I don´t think it´s funny at all. I think it´s entirely natural. It is said there are two types of software projects: Cancelled ones, and legacy nightmares. I can hardly think of a major technical decision or system I’ve made or implemented that has not become a ball and chain far less than 5 years later. I would actually be terrified if it were still relevant 10 years later. The software landscape is wildly different now than 10 years ago. Maya is being used for wildly different things than it was 10 years ago. Maya’s great strength was its first class support of scripting, and I suppose MEL made sense at the time. It is that first class support of scripting that is still relevant. MEL as a language is irrelevant and it is an awful language. That is not a criticism on its heritage or past utility. It is an objective fact of its current state.

Tyler: I say the same thing about tools and C++/C#. When people tell me C# or python is too slow, I ask them how much of their bottleneck is in IO and how much of their code runs asynchronously. I inevitably get blank stares. To say nothing of maintainability.

Wolfsong · March 18, 2012, 12:49am

When it comes to legacy nightmares, I been saying a long time that Autodesk should write a new application, or at least to a clean re-write every 4-5 years. But until Autodesk re-writes Maya without having it structured around MEL like it is today (which I’m not against), MEL knowledge it is still valuable. And I don’t think it’s as bad a script language as it usually appear in these forums.

I could answer any topic about Max or Maxscript with “use Maya”, as I personally think Maya is better to work with then Max, and it is an option to switch for anyone so why not? I don’t because I think people should use what they want, no matter how stupid I think it is. This is sadly not always the way Python vs MEL vs PyMEL is reflected in these forums.

Rob_Galanakis · March 18, 2012, 5:52am

That is just a profoundly flawed comparison. Switching between Max and Maya is absolutely nothing like MEL and Python:

MEL and Python are very easy to interop between where necessary. Thank MEL’s strings-for-everything design. DCC programs are years away from being able to do this, if ever.
You can still do things in the imperative MEL style even when writing Python (and things are named the same), so you can focus on learning the basics of the language before learning how to write it well. There is no ‘Max mode’ in Maya for transitioning from another program.
It is an objective fact that python is both superior, and the future of Maya scripting. There is no such clear situation with Maya and Max. And as a side note, they are doing ‘clean rewrites’ of parts of Max.

I have no problem that Maya is structured around MEL because, for the most part, PyMEL provides a suitable abstraction. I have no desire to see Maya rewritten because I think total rewrites of popular products are unmitigated disasters. Actually the main problem I have is that people think it is acceptable to be writing, and even worse teaching, MEL. Enough people are already predisposed to not learning new disruptive things, the last thing I think we should be doing is encouraging that in such a clear-cut case as this.

ScottHarber · March 18, 2012, 9:09am

MEL knowledge it is still valuable. And I don’t think it’s as bad a script language as it usually appear in these forums.

Quoted because I agree with it. :):

As ever, it’s a case of picking the right tools for the job.

Python has classes and threading and can be ported between applications and is infinitely upgradable through modules etc etc etc. If I’m writing anything that’s supposed to be scalable, I’d go straight to Python.

But Mel has an advantage in being quicker to write. For example, doing something as simple as “ls -sl” is a half-dozen keystrokes in Mel, but about two lines in Python. If I need to quickly automate a task, or batch process a load of models, I’d go for Mel just for efficiency.

Regarding teaching, I don’t expect that any school is still teaching Mel as a primary production system. It’s more like a gateway drug. Syntactically, Mel is a watered-down version of C with instant visual feedback, no compiling, and some custom Maya commands thrown in, that allow complete control over a 3D modelling environment. What better way to explain programming to an artist? Plus none of it is wasted knowledge, since the way in which Mel scripts are laid out has a lot of commonality with a lot of other programming/scripting languages. I’ve always thought that starting a novice TA on Mel and moving up to Python (or better yet, having them learn it themselves) is a more sensible progression than just going straight to Python.

LoneWolf · March 18, 2012, 6:21pm

[QUOTE=ScottHarber;15065]Quoted because I agree with it. :):

But Mel has an advantage in being quicker to write. For example, doing something as simple as “ls -sl” is a half-dozen keystrokes in Mel, but about two lines in Python. If I need to quickly automate a task, or batch process a load of models, I’d go for Mel just for efficiency.

Regarding teaching, I don’t expect that any school is still teaching Mel as a primary production system. It’s more like a gateway drug. Syntactically, Mel is a watered-down version of C with instant visual feedback, no compiling, and some custom Maya commands thrown in, that allow complete control over a 3D modelling environment. What better way to explain programming to an artist? Plus none of it is wasted knowledge, since the way in which Mel scripts are laid out has a lot of commonality with a lot of other programming/scripting languages. I’ve always thought that starting a novice TA on Mel and moving up to Python (or better yet, having them learn it themselves) is a more sensible progression than just going straight to Python.[/QUOTE]

I disagree that mel is faster to write. Besides the ugly syntax and all the weird tokens you have to think about, and let’s not get into the discussion about “half a dozen keystrokes” in mel, you are not a machine that can work at 100% effectivity / efficiency that you will see the benefit of few less keystrokes, besides there is so many weird keystrokes that happen in MEL that I don’t think it’s faster to write if we are to make “keystroke” comparisions which I think is pointless anyway.

About “than just going straight to Python”. Why does people target learning python inside maya? Learn it outside maya first. I don’t understand where python vs mel comes into comparision :S. It’s like “I want to learn c++ inside maya API”, good luck have fun =P