Today

• 33 min ago

  issue 120 (add factory mechanism for casting results to pynodes) Status changed by chadrik   -  

  Status: Fixed

  Status: Fixed
• 35 min ago

  issue 122 (ikHandle query doesn't result in jointList) changed by chadrik   -  

  Status: Fixed

  Labels: Milestone-1.0.x

  Status: Fixed

  Labels: Milestone-1.0.x
• 36 min ago

  issue 130 (pymel.tools.py2mel.py2melProc can't handle functions with ar...) Status changed by chadrik   -  

  Status: Fixed

  Status: Fixed
• 15 hours ago

  version_1_0_todo (road to 1.0) Wiki page edited by chadrik   -   Revision r1526 Edited wiki page through web user interface.

  Revision r1526 Edited wiki page through web user interface.
• 15 hours ago

  version_1_0_todo (road to 1.0) Wiki page edited by chadrik   -   Revision r1525 Edited wiki page through web user interface.

  Revision r1525 Edited wiki page through web user interface.
• 23 hours ago

  issue 117 (Wrapped api funcs which are passed 'unsigned int &' are not ...) Status changed by elrond79   -  

  Status: Fixed

  Status: Fixed
• 23 hours ago

  issue 145 (stubs - handling of "from mymodule import *" overly aggressi...) Labels changed by elrond79   -  

  Labels: Type-Enhancement Priority-Low

  Labels: Type-Enhancement Priority-Low
• 23 hours ago

  issue 145 (stubs - handling of "from mymodule import *" overly aggressi...) reported by elrond79   -   Currently, the parser for the stubs file does a from mymodule import * whenever ANY object from mymodule is found in another module. This works, but obviously leaves the stub module with a lot more items than necessary, and makes autocompletion slower. Made aborted attempt to override __import__ function, to detect imports... however, while it detects from mymodule import MyClass it fails to detect from mymodule import * Solution would probably be to see if everything (or above a certain percentage?) in the one module is in the other module before using import *; can use sepecific from imports for others.

  Currently, the parser for the stubs file does a from mymodule import * whenever ANY object from mymodule is found in another module. This works, but obviously leaves the stub module with a lot more items than necessary, and makes autocompletion slower. Made aborted attempt to override __import__ function, to detect imports... however, while it detects from mymodule import MyClass it fails to detect from mymodule import * Solution would probably be to see if everything (or above a certain percentage?) in the one module is in the other module before using import *; can use sepecific from imports for others.

Yesterday

• 24 hours ago

  issue 144 (help(cmdFromPlugin) fails for some plugin commands) reported by elrond79   -   ...only example I found right now is on our own internal plugin: help(lmShot) It's failing in addCmdDocsCallback, when it tries to fetch flagDocs = cmdInfo['flags'] docs = flagDocs[flag] typ = docs['args'] for flags such as shot_num and getElement - the entries for these look like: getElement : {'docstring': ''} shot_num : {'docstring': ''} ...whereas the entry for a 'normal' flag is putOnHold : {'numArgs': 0, 'shortname': 'poh', 'args': <type 'bool'>, 'docstring': '', 'longname': 'putOnHold'} Either see why no data for these flags is generated, or check if there is no data, or both.

  ...only example I found right now is on our own internal plugin: help(lmShot) It's failing in addCmdDocsCallback, when it tries to fetch flagDocs = cmdInfo['flags'] docs = flagDocs[flag] typ = docs['args'] for flags such as shot_num and getElement - the entries for these look like: getElement : {'docstring': ''} shot_num : {'docstring': ''} ...whereas the entry for a 'normal' flag is putOnHold : {'numArgs': 0, 'shortname': 'poh', 'args': <type 'bool'>, 'docstring': '', 'longname': 'putOnHold'} Either see why no data for these flags is generated, or check if there is no data, or both.
• 37 hours ago

  issue 143 (PyUI() fails with scriptedPanels with no window) Status changed by elrond79   -   added Panel/ScriptedPanel to the list of object types that we don't find parents for... seems to work

  Status: Fixed

  added Panel/ScriptedPanel to the list of object types that we don't find parents for... seems to work

  Status: Fixed
• 37 hours ago

  issue 143 (PyUI() fails with scriptedPanels with no window) reported by elrond79   -   If you open up a GUI maya, close any open graph editors, then do: cmds.lsUI(panels=True) ...you will see that one of the items is 'graphEditor1'. If you do cmds.objectTypeUI('graphEditor1') or cmds.scriptedPanel('graphEditor1', exists=True) ...you can see that it's type is scriptedPanel. However, if you do PyUI('graphEditor1') it fails, apparently when trying to find a parent for the panel. I'm guessing that, since scriptedPanels (and maybe panels in general?) can exist without a window, it may not actually have a parent...? If you try PyUI('graphEditor1') when a graph editor is open, it succeeds, but only because it's creating a ui item for a menuBarLayout which now also exists, with the same name... Also, if you do: graphEditor1Window|TearOffPane|graphEditor1|graphEditor1 ...with the graphEditor open, you get: graphEditor1Window|TearOffPane|graphEditor1 This is supposed to be the top-level control for this panel. However, TearOffPane is a paneLayout... meaning the top-level control's own parent is NOT the panel. This leads me to believe that panels exist sort of outside the normal parent chain, and have no parent... UPDATE: after more testing with 'outlinerPanel1', looks like the same is true of 'normal' panels.

  If you open up a GUI maya, close any open graph editors, then do: cmds.lsUI(panels=True) ...you will see that one of the items is 'graphEditor1'. If you do cmds.objectTypeUI('graphEditor1') or cmds.scriptedPanel('graphEditor1', exists=True) ...you can see that it's type is scriptedPanel. However, if you do PyUI('graphEditor1') it fails, apparently when trying to find a parent for the panel. I'm guessing that, since scriptedPanels (and maybe panels in general?) can exist without a window, it may not actually have a parent...? If you try PyUI('graphEditor1') when a graph editor is open, it succeeds, but only because it's creating a ui item for a menuBarLayout which now also exists, with the same name... Also, if you do: graphEditor1Window|TearOffPane|graphEditor1|graphEditor1 ...with the graphEditor open, you get: graphEditor1Window|TearOffPane|graphEditor1 This is supposed to be the top-level control for this panel. However, TearOffPane is a paneLayout... meaning the top-level control's own parent is NOT the panel. This leads me to believe that panels exist sort of outside the normal parent chain, and have no parent... UPDATE: after more testing with 'outlinerPanel1', looks like the same is true of 'normal' panels.
• 37 hours ago

  issue 142 (Multiple ui objects with same name getting incorrect ui type) reported by elrond79   -   If, when the graph editor is open, you do: foo = PyUI('graphEditor1') print foo print foo.__class__ print objectTypeUI(foo) you get: graphEditor1Window|TearOffPane|graphEditor1|graphEditor1 <class 'pymel.core.uitypes.MenuBarLayout'> formLayout ...which is clearly not so good. It seems that graphEditor1Window|TearOffPane|graphEditor1|graphEditor1 is a formLayout, whereas graphEditor1Window|TearOffPane|graphEditor1 is a menuBarLayout. Somehow the detection of ui-type when there's multiple objects with the same name is getting screwed up here

  If, when the graph editor is open, you do: foo = PyUI('graphEditor1') print foo print foo.__class__ print objectTypeUI(foo) you get: graphEditor1Window|TearOffPane|graphEditor1|graphEditor1 <class 'pymel.core.uitypes.MenuBarLayout'> formLayout ...which is clearly not so good. It seems that graphEditor1Window|TearOffPane|graphEditor1|graphEditor1 is a formLayout, whereas graphEditor1Window|TearOffPane|graphEditor1 is a menuBarLayout. Somehow the detection of ui-type when there's multiple objects with the same name is getting screwed up here
• 37 hours ago

  version_1_0_todo (road to 1.0) Wiki page edited by chadrik   -   Revision r1524 Edited wiki page through web user interface.

  Revision r1524 Edited wiki page through web user interface.
• 37 hours ago

  version_1_0_todo (road to 1.0) Wiki page edited by chadrik   -   Revision r1523 Edited wiki page through web user interface.

  Revision r1523 Edited wiki page through web user interface.
• 41 hours ago

  issue 138 (feature req: addAttr doesn't return an attribute) commented on by elrond79   -   I'm actually not sold on this, because of the compound attribute issue. While it would be nice, the inconsistent behavior of addAttr is going to lead to bugs in people's code. ie, people will get used to assuming that addAttr returns an attribute (since it does in most cases), and so - even if they're AWARE of the exception, which most people probably won't be - will inevitably forget it when they make a compound attribute. The shorthand syntax would help (and would be a nice idea, regardless of the return value issue), but isn't really a complete solution, as long as the other, "standard" way of creating attributes is there... which it will probably have to be Besides, as long as you've got access to the PyNode you're adding the attribute to (which you generally will - relying on the selection is generally a bad idea, programatically), it's not much extra work to do: myNode.myAttr or myNode.attr('myAttr') If we are going to go with this, though - or if we just add the ability to use a 'children' flag for compound attributes - I would recommend changing the syntax to: addAttr( longName='sampson', numberOfChildren=5, attributeType='compound', children=[ {longName='homeboy', attributeType='matrix', keyable=False}, {ln='midge', at='message'}, {longName='damien', dataType='double'}]) A little less shorthand, but easier to implement, more powerful/ flexible, a little more readable, and more consistent with existing syntax. (Sorta another feature, but if we're going to implement the ability to auto-detect whether an attribute's 'type' is a dataType, attributeType, might as well add that into the normal addAttr, as another flag... perhaps called 'type'? Only drawback with that name is it overrides a builtin...)

  I'm actually not sold on this, because of the compound attribute issue. While it would be nice, the inconsistent behavior of addAttr is going to lead to bugs in people's code. ie, people will get used to assuming that addAttr returns an attribute (since it does in most cases), and so - even if they're AWARE of the exception, which most people probably won't be - will inevitably forget it when they make a compound attribute. The shorthand syntax would help (and would be a nice idea, regardless of the return value issue), but isn't really a complete solution, as long as the other, "standard" way of creating attributes is there... which it will probably have to be Besides, as long as you've got access to the PyNode you're adding the attribute to (which you generally will - relying on the selection is generally a bad idea, programatically), it's not much extra work to do: myNode.myAttr or myNode.attr('myAttr') If we are going to go with this, though - or if we just add the ability to use a 'children' flag for compound attributes - I would recommend changing the syntax to: addAttr( longName='sampson', numberOfChildren=5, attributeType='compound', children=[ {longName='homeboy', attributeType='matrix', keyable=False}, {ln='midge', at='message'}, {longName='damien', dataType='double'}]) A little less shorthand, but easier to implement, more powerful/ flexible, a little more readable, and more consistent with existing syntax. (Sorta another feature, but if we're going to implement the ability to auto-detect whether an attribute's 'type' is a dataType, attributeType, might as well add that into the normal addAttr, as another flag... perhaps called 'type'? Only drawback with that name is it overrides a builtin...)
• 47 hours ago

  version_1_0_todo (road to 1.0) Wiki page edited by chadrik   -   Revision r1522 Edited wiki page through web user interface.

  Revision r1522 Edited wiki page through web user interface.

Last 7 days

• Jan 04, 2010

  issue 139 (setKeyable on compound attrs should propagate to child attrs) Labels changed by chadrik   -   since this is not currently supported by setAttr -keyable, this is being marked as an "enhancement", i.e. feature request. it most likely won't make it into 1.0.0, but can be included in a future release.

  Labels: Type-Enhancement Milestone-1.0.x

  since this is not currently supported by setAttr -keyable, this is being marked as an "enhancement", i.e. feature request. it most likely won't make it into 1.0.0, but can be included in a future release.

  Labels: Type-Enhancement Milestone-1.0.x
• Jan 04, 2010

  issue 138 (feature req: addAttr doesn't return an attribute) changed by chadrik   -  

  Status: Accepted

  Owner: chadrik

  Labels: Milestone-1.0.x

  Status: Accepted

  Owner: chadrik

  Labels: Milestone-1.0.x
• Jan 04, 2010

  issue 138 (feature req: addAttr doesn't return an attribute) Labels changed by chadrik   -   this appears to be slightly more complicated than one might assume, for a couple of reasons 1. an attribute can be created on more than node at a time: the result must be a list of Attributes 2. cmds.addAttr does not return the name of the attribute just created: we have to piece it together from the passed arguments/flags/selected nodes 3. compound attributes and their children are invalid until all children are created: are we comfortable with the inconsistency of not returning a result for compound types? the third is the biggest issue. for example: cmds.addAttr( 'persp', longName='rainbow', usedAsColor=True, attributeType='float3' ) PyNode( 'persp.rainbow' ) #<---- raises a MayaObjectError cmds.addAttr( 'persp', longName='redBow', attributeType='float', parent='rainbow' ) cmds.addAttr( 'persp', longName='greenBow', attributeType='float', parent='rainbow' ) cmds.addAttr( 'persp', longName='blueBow', attributeType='float', parent='rainbow' ) PyNode( 'persp.rainbow' ) #<---- works one potential solution, add a shorthand for creating compound types: addAttr( 'persp', longName='rainbow', usedAsColor=True, attributeType='float3', children=['redBow', 'greenBow', 'blueBow'] ) but this would also have to do mixed compound types: cmds.addAttr( longName='sampson', numberOfChildren=5, attributeType='compound' ) cmds.addAttr( longName='homeboy', attributeType='matrix', parent='sampson' ) cmds.addAttr( longName='midge', attributeType='message', parent='sampson' ) cmds.addAttr( longName='damien', attributeType='double', parent='sampson' ) cmds.addAttr( longName='elizabeth', attributeType='double', parent='sampson' ) cmds.addAttr( longName='sweetpea', attributeType='double', parent='sampson' ) perhaps: cmds.addAttr( longName='sampson', numberOfChildren=5, attributeType='compound', children=[ ( 'homeboy', 'matrix' ), ( 'midge', 'message'), ( 'damien', 'double'), ( 'elizabeth', 'double' ), ( 'sweetpea', 'double' ) ] ) this is something that will take a lot of testing to make sure we every combination works right.

  Labels: Type-Enhancement

  this appears to be slightly more complicated than one might assume, for a couple of reasons 1. an attribute can be created on more than node at a time: the result must be a list of Attributes 2. cmds.addAttr does not return the name of the attribute just created: we have to piece it together from the passed arguments/flags/selected nodes 3. compound attributes and their children are invalid until all children are created: are we comfortable with the inconsistency of not returning a result for compound types? the third is the biggest issue. for example: cmds.addAttr( 'persp', longName='rainbow', usedAsColor=True, attributeType='float3' ) PyNode( 'persp.rainbow' ) #<---- raises a MayaObjectError cmds.addAttr( 'persp', longName='redBow', attributeType='float', parent='rainbow' ) cmds.addAttr( 'persp', longName='greenBow', attributeType='float', parent='rainbow' ) cmds.addAttr( 'persp', longName='blueBow', attributeType='float', parent='rainbow' ) PyNode( 'persp.rainbow' ) #<---- works one potential solution, add a shorthand for creating compound types: addAttr( 'persp', longName='rainbow', usedAsColor=True, attributeType='float3', children=['redBow', 'greenBow', 'blueBow'] ) but this would also have to do mixed compound types: cmds.addAttr( longName='sampson', numberOfChildren=5, attributeType='compound' ) cmds.addAttr( longName='homeboy', attributeType='matrix', parent='sampson' ) cmds.addAttr( longName='midge', attributeType='message', parent='sampson' ) cmds.addAttr( longName='damien', attributeType='double', parent='sampson' ) cmds.addAttr( longName='elizabeth', attributeType='double', parent='sampson' ) cmds.addAttr( longName='sweetpea', attributeType='double', parent='sampson' ) perhaps: cmds.addAttr( longName='sampson', numberOfChildren=5, attributeType='compound', children=[ ( 'homeboy', 'matrix' ), ( 'midge', 'message'), ( 'damien', 'double'), ( 'elizabeth', 'double' ), ( 'sweetpea', 'double' ) ] ) this is something that will take a lot of testing to make sure we every combination works right.

  Labels: Type-Enhancement
• Jan 04, 2010

  issue 140 (return values from ikHandle command aren't PyNodes) changed by chadrik   -  

  Status: Fixed

  Labels: Milestone-1.0.x

  Status: Fixed

  Labels: Milestone-1.0.x
• Jan 03, 2010

  issue 135 (getUVAtPoint arg type error) Status changed by elrond79   -   Fixed in 2329a52108386bf45e43df38fe11ca7e015556a6 on master branch

  Status: Fixed

  Fixed in 2329a52108386bf45e43df38fe11ca7e015556a6 on master branch

  Status: Fixed
• Jan 02, 2010

  version_1_0_todo (road to 1.0) Wiki page edited by chadrik   -   Revision r1521 Edited wiki page through web user interface.

  Revision r1521 Edited wiki page through web user interface.
• Jan 02, 2010

  version_1_0_todo (road to 1.0) Wiki page edited by chadrik   -   Revision r1520 Edited wiki page through web user interface.

  Revision r1520 Edited wiki page through web user interface.
• Jan 02, 2010

  issue 141 (Pretty-print multi-dimensional component indices) reported by elrond79   -   Ie, should be able to get print output like: [mySphere.cv[1,2][1:30], mySphere.cv[3][7]] ...instead of a separate mySphere.cv[x][y] for all 61 different cvs.

  Ie, should be able to get print output like: [mySphere.cv[1,2][1:30], mySphere.cv[3][7]] ...instead of a separate mySphere.cv[x][y] for all 61 different cvs.
• Jan 01, 2010

  issue 140 (return values from ikHandle command aren't PyNodes) reported by macaronikazoo   -   pymel 0.9.2 pymel.ikHandle( ikHandle, q=True, jl=True ) the return value of this command is a list of unicode objects, not PyNodes similarly with pymel.ikHandle( ikHandle, q=True, ee=True )

  pymel 0.9.2 pymel.ikHandle( ikHandle, q=True, jl=True ) the return value of this command is a list of unicode objects, not PyNodes similarly with pymel.ikHandle( ikHandle, q=True, ee=True )
• Dec 31, 2009

  issue 139 (setKeyable on compound attrs should propagate to child attrs) commented on by macaronikazoo   -   sweet! thanks, I'll see if I can figure something out. incidentally, who do you get an account here? I guess I should probably learn how all the unit tests work and whatnot first - any data on that? I'm a bit of a unit test n00b... and should absolutely not be.

  sweet! thanks, I'll see if I can figure something out. incidentally, who do you get an account here? I guess I should probably learn how all the unit tests work and whatnot first - any data on that? I'm a bit of a unit test n00b... and should absolutely not be.
• Dec 31, 2009

  issue 139 (setKeyable on compound attrs should propagate to child attrs) commented on by elrond79   -   ...incidentally, there's a number of cases for which it would be nice to have propogation-type behavior for attributes... and not just for compound elements, but array attributes as well. Unfortunately, this behavior isn't built into the commands we wrap, and it's something we haven't gotten around yet to adding ourselves.

  ...incidentally, there's a number of cases for which it would be nice to have propogation-type behavior for attributes... and not just for compound elements, but array attributes as well. Unfortunately, this behavior isn't built into the commands we wrap, and it's something we haven't gotten around yet to adding ourselves.
• Dec 31, 2009

  issue 139 (setKeyable on compound attrs should propagate to child attrs) commented on by elrond79   -   setKeyable is (I believe) auto-wrapped from MFnAttribute.setKeyable... the auto-wrapping magic happens MetaMayaTypeWrapper, which is the metaclass for the pymel Attribute type. If you're looking to modify the behavior of Attribute.setKeyable, you can just add a new method directly to the Attribute class, and have that wrap the appropriate mel cmd (setAttr in this case, I think). If there's a hand-defined method, it will override any similarly named auto-wrapped command.

  setKeyable is (I believe) auto-wrapped from MFnAttribute.setKeyable... the auto-wrapping magic happens MetaMayaTypeWrapper, which is the metaclass for the pymel Attribute type. If you're looking to modify the behavior of Attribute.setKeyable, you can just add a new method directly to the Attribute class, and have that wrap the appropriate mel cmd (setAttr in this case, I think). If there's a hand-defined method, it will override any similarly named auto-wrapped command.
• Dec 31, 2009

  issue 139 (setKeyable on compound attrs should propagate to child attrs) commented on by macaronikazoo   -   where does the setKeyable code even exist?

  where does the setKeyable code even exist?
• Dec 31, 2009

  issue 139 (setKeyable on compound attrs should propagate to child attrs) reported by macaronikazoo   -   well, it'd be nice if it did anyway. so something like: PyNode( 'persp' ).translate.setKeyable( False ) would set keyable flag on tx, ty and tz to False.

  well, it'd be nice if it did anyway. so something like: PyNode( 'persp' ).translate.setKeyable( False ) would set keyable flag on tx, ty and tz to False.

Last 30 days

• Dec 31, 2009

  issue 138 (feature req: addAttr doesn't return an attribute) reported by macaronikazoo   -   would be nice if when I do: someNode.addAttr(...) pymel would return the attribute object - save me having to do a getattr( someNode ... )

  would be nice if when I do: someNode.addAttr(...) pymel would return the attribute object - save me having to do a getattr( someNode ... )
• Dec 30, 2009

  version_1_0_todo (road to 1.0) Wiki page edited by chadrik   -   Revision r1519 Edited wiki page through web user interface.

  Revision r1519 Edited wiki page through web user interface.
• Dec 27, 2009

  issue 132 (Seting Up PyMEL Autocompletion in Eclipse - not working for ...) commented on by lichiman   -   I've tried pymel 1.0.0b2 with the new eclipse tutorial and I get all the autocompletion except when I assign something to a new variable. So if I have: sphere = pm.sphere()[0] and I write: sphere. I don't get anything. Is it normal? or I'm doing something wrong. I've test it with wing too and works great in the wing's python shell but I doesn't in the file document. Thanks!

  I've tried pymel 1.0.0b2 with the new eclipse tutorial and I get all the autocompletion except when I assign something to a new variable. So if I have: sphere = pm.sphere()[0] and I write: sphere. I don't get anything. Is it normal? or I'm doing something wrong. I've test it with wing too and works great in the wing's python shell but I doesn't in the file document. Thanks!
• Dec 24, 2009

  issue 137 (PyMel 1.0 beta install) commented on by elrond79   -   John - what, exactly, about your maya launcher makes it difficult to order the python paths? Does it re-order existing entries already present in sys.path? Or does it simply find and add modules in effectively random order onto the start/end of the maya path? At what point in the load process does it do this? Did you try using a 'setuptools'-style .pth file? Ie, a .pth file with this code inserted into it: import sys; sys.__plen = len(sys.path) path/To/Pymel import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; sys.path[0:0]=new Alternatively, you can always simply overwrite the files that come with maya with the versions included in pymel; the pymel ones were written so that they should be completely compatible, even if pymel isn't loaded... they essentially just add some 'extra' capabilities/options, which pymel makes use of.

  John - what, exactly, about your maya launcher makes it difficult to order the python paths? Does it re-order existing entries already present in sys.path? Or does it simply find and add modules in effectively random order onto the start/end of the maya path? At what point in the load process does it do this? Did you try using a 'setuptools'-style .pth file? Ie, a .pth file with this code inserted into it: import sys; sys.__plen = len(sys.path) path/To/Pymel import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; sys.path[0:0]=new Alternatively, you can always simply overwrite the files that come with maya with the versions included in pymel; the pymel ones were written so that they should be completely compatible, even if pymel isn't loaded... they essentially just add some 'extra' capabilities/options, which pymel makes use of.
• Dec 23, 2009

  issue 137 (PyMel 1.0 beta install) commented on by chadrik   -   hi john, the new maya module fixes 3 things: * allows you to use PyMEL inside userSetup.py in python standalone * fixes a bug where certain commands don’t return a result the first time they are called * provides a shared root logger with status-line error and warning colorization proceeding without the custom maya package would be tricky. unless we hear the same complaint from many users i don't think that it will be a priority to edit pymel to work without it. however, you are welcome to fork pymel and make the modifications. our repo is here: http://github.com/LumaPictures/pymel. just be aware there is a *chance* we might change the location.

  hi john, the new maya module fixes 3 things: * allows you to use PyMEL inside userSetup.py in python standalone * fixes a bug where certain commands don’t return a result the first time they are called * provides a shared root logger with status-line error and warning colorization proceeding without the custom maya package would be tricky. unless we hear the same complaint from many users i don't think that it will be a priority to edit pymel to work without it. however, you are welcome to fork pymel and make the modifications. our repo is here: http://github.com/LumaPictures/pymel. just be aware there is a *chance* we might change the location.
• Dec 23, 2009

  issue 137 (PyMel 1.0 beta install) reported by tryptik   -   Hi, all. My name is John Hood and I am working at SONY Imageworks. I would like to evaluate the new beta for use here. Unfortunately, our Maya launcher makes it difficult to order the python paths properly so that the PyMel modules are sourced before the Maya site packages. Is there any way to get around this? A cursory examination of the assert indicates potential incompatibility with the logging module - can that be omitted? I apologize if this is the wrong place to present this issue - I wasn't sure how to contact you. Thanks -J What Version of Maya are you using? On what operating system? (Please be as specific as possible and include service packs, 64bit vs 32bit, etc) We are using Maya 2009 on linux 64-bit os. What Version of PyMEL are you using? Trying pymel-1.0.0b2.

  Hi, all. My name is John Hood and I am working at SONY Imageworks. I would like to evaluate the new beta for use here. Unfortunately, our Maya launcher makes it difficult to order the python paths properly so that the PyMel modules are sourced before the Maya site packages. Is there any way to get around this? A cursory examination of the assert indicates potential incompatibility with the logging module - can that be omitted? I apologize if this is the wrong place to present this issue - I wasn't sure how to contact you. Thanks -J What Version of Maya are you using? On what operating system? (Please be as specific as possible and include service packs, 64bit vs 32bit, etc) We are using Maya 2009 on linux 64-bit os. What Version of PyMEL are you using? Trying pymel-1.0.0b2.
• Dec 22, 2009

  pymel-1.0.0b2.zip (pymel 1.0.0 Beta 2 for Maya 2008, 2009, and 2010) file uploaded by chadrik
• Dec 22, 2009

  pymel-1.0.0b1.zip (pymel 1.0.0 Beta 1 for Maya 2008, 2009, and 2010) file uploaded by chadrik
• Dec 22, 2009

  pymel-0.9.3b1.zip (pymel 0.9.3 Beta 1 for Maya 2008, 2009, and 2010) file uploaded by chadrik
• Dec 22, 2009

  version_1_0_todo (road to 1.0) Wiki page edited by chadrik   -   Revision r1518 Edited wiki page through web user interface.

  Revision r1518 Edited wiki page through web user interface.
• Dec 21, 2009

  issue 136 (PyNode('persp').__class__ yields strange Script Editor resul...) reported by elrond79   -   If you enter this single line in the GUI Script Editor: PyNode('persp').__class__ ...then execute it, you will get: # Result: # Even more disturbing, if you execute it again, you get an error: # Error: unbound method __unicode__() must be called with Transform instance as first argument (got nothing instead) # Traceback (most recent call last): # File "<maya console>", line 1, in <module> # File "/Volumes/luma/_globalSoft/dev/paulm/python/pymel/pymel/core/general.py", line 1364, in __new__ # import nodetypes # TypeError: unbound method __unicode__() must be called with Transform instance as first argument (got nothing instead) # (This is in Linux 2009 x64.) str(PyNode('persp').__class__) will yield what we expect, so this is likely due to some weird processing of output on maya's end.... but would still like to investigate.

  If you enter this single line in the GUI Script Editor: PyNode('persp').__class__ ...then execute it, you will get: # Result: # Even more disturbing, if you execute it again, you get an error: # Error: unbound method __unicode__() must be called with Transform instance as first argument (got nothing instead) # Traceback (most recent call last): # File "<maya console>", line 1, in <module> # File "/Volumes/luma/_globalSoft/dev/paulm/python/pymel/pymel/core/general.py", line 1364, in __new__ # import nodetypes # TypeError: unbound method __unicode__() must be called with Transform instance as first argument (got nothing instead) # (This is in Linux 2009 x64.) str(PyNode('persp').__class__) will yield what we expect, so this is likely due to some weird processing of output on maya's end.... but would still like to investigate.
• Dec 20, 2009

  version_1_0_todo (road to 1.0) Wiki page edited by chadrik   -   Revision r1517 Edited wiki page through web user interface.

  Revision r1517 Edited wiki page through web user interface.
• Dec 20, 2009

  issue 131 (distance dimension function does not return a PyNode) changed by chadrik   -   in 1.0

  Status: Fixed

  Labels: Milestone-1.0.x

  in 1.0

  Status: Fixed

  Labels: Milestone-1.0.x
• Dec 19, 2009

  version_1_0_todo (road to 1.0) Wiki page edited by chadrik   -   Revision r1516 Edited wiki page through web user interface.

  Revision r1516 Edited wiki page through web user interface.
• Dec 19, 2009

  issue 132 (Seting Up PyMEL Autocompletion in Eclipse - not working for ...) commented on by tradigital   -   Thanks for the reply, and I will look forward to the new release. I downloaded something off Area I believe it was that is a pretty outstanding little js plugin for Eclipse to use it as an IDE. Works great for now.

  Thanks for the reply, and I will look forward to the new release. I downloaded something off Area I believe it was that is a pretty outstanding little js plugin for Eclipse to use it as an IDE. Works great for now.
• Dec 19, 2009

  issue 130 (pymel.tools.py2mel.py2melProc can't handle functions with ar...) Labels changed by chadrik   -  

  Labels: Milestone-1.0.x

  Labels: Milestone-1.0.x
• Dec 19, 2009

  issue 129 (Redo iterHistory) Labels changed by chadrik   -  

  Labels: Milestone-1.1.x

  Labels: Milestone-1.1.x
• Dec 19, 2009

  issue 77 (pymelScrollFieldReporter plugin steals window focus) Status changed by chadrik   -   i beat my head agains this at the time for longer than it was worth it. might as well close this.

  Status: WontFix

  i beat my head agains this at the time for longer than it was worth it. might as well close this.

  Status: WontFix
• Dec 19, 2009

  issue 132 (Seting Up PyMEL Autocompletion in Eclipse - not working for ...) Status changed by chadrik   -  

  Status: Fixed

  Status: Fixed
• Dec 19, 2009

  issue 133 (2011 not importing 0.9.2) commented on by chadrik   -   man o man. i really don't want to go there for pretty obvious reasons.

  man o man. i really don't want to go there for pretty obvious reasons.