Re: PyQtForSoftimage vs Blur-dev
Hello, Steve, here you have the fork https://github.com/anuska/PyQtForSoftimageand I have also sent you a pull request. Jo, I think you are going to be disappointed :( I like what you suggest a lot but I fear that I have started with something easier. Probably most people will have already done a similar change. I'm going to take what you say into account for a second round. :D
Re: PyQtForSoftimage vs Blur-dev
thanks ana for your contributions, this is exactly what i hoped for by putting this plugin on github. On Wed, May 9, 2012 at 7:27 AM, Ana Gomez agomezalca...@gmail.com wrote: Hello, Steve, here you have the fork https://github.com/anuska/PyQtForSoftimageand I have also sent you a pull request. Jo, I think you are going to be disappointed :( I like what you suggest a lot but I fear that I have started with something easier. Probably most people will have already done a similar change. I'm going to take what you say into account for a second round. :D
Re: PyQtForSoftimage vs Blur-dev
see below... On Tue, May 8, 2012 at 4:48 AM, Ana Gomez agomezalca...@gmail.com wrote: Hello again! My concern was if some features have been lost in the process of exposing the pyqt implementation from the Blur tools. the plugin is no longer related to blur tools, nothing is lost... Or if someone has had problems by using this plugin. You told me that people is using it, more or less, without problem so I'm going to keep testing it. I don't really want to install the Blur tools just for PyQt. I don't need its rest of tools, nor the wrappers for the rest of softwares. exactly why i started the project, in the end jo's solution means no blur dependencies. I see that Steven has just made a new example that uses a ui file in response to the last issue. Thanks and thanks for pointing me the issue, I hadn't read it. On the other hand, I've rewritten some of the code in order to control the XSI events because I don't like the idea of having unecessary active events. I read that Steven doesn't like this idea (last comments in Issue #1) but if you like, i'll give you the changes (well, I haven't invented the wheel). i wouldn't mind seeing your changes... sign up for github, fork the repro, make the changes, push them to your repo and send me a pull request.
Re: PyQtForSoftimage vs Blur-dev
Hey Ana, I'm agreed with you about how softimage events are managed for now is not the best way to go ... Ideally, we should have QEvent subclasses for Softimage events and one and unique method with the following signature SoftimageWidget::softimageEvent(QEvent *event) to handle them (and fit the Qt design, events are not signals) and a method to register to them. There is also lot of other additions to think about to get everything's working fine. But as you guess, Steve or me have jobs and personal projects on the way which make our free time precious. As I told you, any additions or examples are welcomed to be commit to the github repo and would be greatly appreciated by Steve or me. In a wonderful world, it would be awesome if more people were jumping on Qt to let developers and artists having the same experience on the different platforms and 3d packages ... Thanks to have done that jump :) -jo 2012/5/8 Ana Gomez agomezalca...@gmail.com Hello again! My concern was if some features have been lost in the process of exposing the pyqt implementation from the Blur tools. Or if someone has had problems by using this plugin. You told me that people is using it, more or less, without problem so I'm going to keep testing it. I don't really want to install the Blur tools just for PyQt. I don't need its rest of tools, nor the wrappers for the rest of softwares. I see that Steven has just made a new example that uses a ui file in response to the last issue. Thanks and thanks for pointing me the issue, I hadn't read it. On the other hand, I've rewritten some of the code in order to control the XSI events because I don't like the idea of having unecessary active events. I read that Steven doesn't like this idea (last comments in Issue #1) but if you like, i'll give you the changes (well, I haven't invented the wheel). :)
Re: PyQtForSoftimage vs Blur-dev
Hi Ana, Qt on windows relies on the win32 api as well as Softimage (MFC). As they share a common base, both are hackable. So, whatever the strategy that is used, it still remains the same ... hooking a widget into the main softimage app by going thru the win32 api. The only main difference I would say by using pyQtSoftimage (except the source codes) is to not have to deal with all the overhead and extra layers Blur developers put over their modules/wrappers ... Those packages are both first steps considering more should be done by spending time on it and make things working better. I had lot of feedback around me saying studios are using this implementation ... so it should be solid enough to go with it. So feel free to make your own additions and come back here to share them with us ... :) -jo 2012/5/7 Ana Gomez agomezalca...@gmail.com Hello everybody! I'm trying PyQtForSoftimage and I'm wondering some questions. As far as I know, this plugin is based on Blur tools. So, which are the differences between them? Do they have the same features? (of course, from the point of view of PyQt) Thanks in advance and thanks to Steven Caron and Jo Benayoun for sharing it.
Re: PyQtForSoftimage vs Blur-dev
hey ana originally i planned on exposing blur's pyqt implementation and simplify it but its proved a lot harder (not impossible). then jo came along and showed us a much easier way to host a pyqt app inside softimage. so pyqtforsoftimage is a lot lighter than blur's implementation. the python key stroke rerouting is very similar, in fact is a near copy of it. as jo points out, blur's implementation has a lot of wrappers to provide cross platform (3dsmax, softimage, motionbuilder) functionality but that comes at a cost. outside that, they provide very similar functionality because they really just expose pyqt. with all that said, pyqtforsoftimage needs to be tested more and pushed harder. i would love to hear more about how people are using pyqt and provide example code and tutorials. there is one issue someone logged last week... https://github.com/caron/PyQtForSoftimage/issues/2 please test to see if this is an issue for you and if it is provide feedback on the github issues page. s On Mon, May 7, 2012 at 12:38 PM, jo benayoun jobenay...@gmail.com wrote: Hi Ana, Qt on windows relies on the win32 api as well as Softimage (MFC). As they share a common base, both are hackable. So, whatever the strategy that is used, it still remains the same ... hooking a widget into the main softimage app by going thru the win32 api. The only main difference I would say by using pyQtSoftimage (except the source codes) is to not have to deal with all the overhead and extra layers Blur developers put over their modules/wrappers ... Those packages are both first steps considering more should be done by spending time on it and make things working better. I had lot of feedback around me saying studios are using this implementation ... so it should be solid enough to go with it. So feel free to make your own additions and come back here to share them with us ... :) -jo 2012/5/7 Ana Gomez agomezalca...@gmail.com Hello everybody! I'm trying PyQtForSoftimage and I'm wondering some questions. As far as I know, this plugin is based on Blur tools. So, which are the differences between them? Do they have the same features? (of course, from the point of view of PyQt) Thanks in advance and thanks to Steven Caron and Jo Benayoun for sharing it.
Re: PyQtForSoftimage vs Blur-dev
i was looking into implementing PYQT at our studio for a while. I used both blur and PYQT for softimage and in the end decided to go with PYQTforSoftimage because it is much lighter. As jo and steven said, the blurcore has a lot of overhead, and I did not want to bloat our pipeline with tools that we might not use On Tue, May 8, 2012 at 3:44 AM, Steven Caron car...@gmail.com wrote: hey ana originally i planned on exposing blur's pyqt implementation and simplify it but its proved a lot harder (not impossible). then jo came along and showed us a much easier way to host a pyqt app inside softimage. so pyqtforsoftimage is a lot lighter than blur's implementation. the python key stroke rerouting is very similar, in fact is a near copy of it. as jo points out, blur's implementation has a lot of wrappers to provide cross platform (3dsmax, softimage, motionbuilder) functionality but that comes at a cost. outside that, they provide very similar functionality because they really just expose pyqt. with all that said, pyqtforsoftimage needs to be tested more and pushed harder. i would love to hear more about how people are using pyqt and provide example code and tutorials. there is one issue someone logged last week... https://github.com/caron/PyQtForSoftimage/issues/2 please test to see if this is an issue for you and if it is provide feedback on the github issues page. s On Mon, May 7, 2012 at 12:38 PM, jo benayoun jobenay...@gmail.com wrote: Hi Ana, Qt on windows relies on the win32 api as well as Softimage (MFC). As they share a common base, both are hackable. So, whatever the strategy that is used, it still remains the same ... hooking a widget into the main softimage app by going thru the win32 api. The only main difference I would say by using pyQtSoftimage (except the source codes) is to not have to deal with all the overhead and extra layers Blur developers put over their modules/wrappers ... Those packages are both first steps considering more should be done by spending time on it and make things working better. I had lot of feedback around me saying studios are using this implementation ... so it should be solid enough to go with it. So feel free to make your own additions and come back here to share them with us ... :) -jo 2012/5/7 Ana Gomez agomezalca...@gmail.com Hello everybody! I'm trying PyQtForSoftimage and I'm wondering some questions. As far as I know, this plugin is based on Blur tools. So, which are the differences between them? Do they have the same features? (of course, from the point of view of PyQt) Thanks in advance and thanks to Steven Caron and Jo Benayoun for sharing it.
