[PySide] PySide in Maya (parent widget under main window)
Carlo Giesa
I would like to use Pyside inside Maya, a 3D package from Autodesk.
I could compile and even create my first little "Hello World!" window without too much problems. :)
But when I create a window with Pyside, it is never parented under the application's main window, but appears in the tool bar (yes I use Windows) as a separate window. This is not the same behavior than when creating windows with the built in commands of the application. I cam across this post (http://nathanhorne.com/?p=298) where a workaround of the same problem is explained, but for the PyQt package, so I wondered, if there is a similar trick that could be used with PySide.
Just for your information:
The method "
apiUI.MQtUtil.mainWindow()"
returns
a
<Swig Object of type 'QWidget *'> and we can cast its
memory address with long().Thanks for any help!
Greets,
Carlo
Thomas Perl
2011/6/27 Carlo Giesa <car...@nwavedigital.com>:
> [...] I cam across this
> post (http://nathanhorne.com/?p=298) where a workaround of the same problem
> is explained, but for the PyQt package, so I wondered, if there is a similar
> trick that could be used with PySide.
>
> Just for your information:
> The method "apiUI.MQtUtil.mainWindow()" returns a <Swig Object of type
> 'QWidget *'> and we can cast its memory address with long().
AFAICT, you are looking for the Shiboken equivalent to
"sip.wrapinstance()". On the C++ side, I think it's
"Shiboken::Converter<QObject*>::toPython()", I'm not sure if this is
exposed on the Python level. Maybe it should be? Otherwise you could
write your own little wrapper module using e.g. SWIG to expose this
conversion function to Python.
Related thread: http://lists.pyside.org/pipermail/pyside/2011-June/002562.html
HTH :)
Thomas
_______________________________________________
PySide mailing list
PyS...@lists.pyside.org
http://lists.pyside.org/listinfo/pyside
Hugo Parente Lima
We don't have any equivalent way of doing what sip.wrapinstance does. Although
if you are compiling your own PySide you can write an small code injection on
PySide typesystem to add this function.
I didn't test the code bellow but if you throw it inside PySide QtCore
typesystem it may work =]
<add-function signature="wrapInstance(unsigned long, PyType)">
<inject-code>
if (Shiboken::ObjectType::checkType(%2)) {
%PYARG_0 = Shiboken::Object::newObject(
(SbkObjectType*)%1,
(void*)%2, false);
}
</inject-code>
</add-function>
You may ask, why you didn't add this code to PySide already? simple... because
QtCore isn't the right place for it, but a separated module probably called
"shiboken" and we didn't it yet.
Regards
--
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia
Thomas Perl
2011/6/27 Hugo Parente Lima <hugo...@openbossa.org>:
> We don't have any equivalent way of doing what sip.wrapinstance does. Although
> if you are compiling your own PySide you can write an small code injection on
> PySide typesystem to add this function.
> [...]
> You may ask, why you didn't add this code to PySide already? simple... because
> QtCore isn't the right place for it, but a separated module probably called
> "shiboken" and we didn't it yet.
Nice :) So, is there a wiki page or a bug report that collects ideas
and features that should go into that "shiboken" module?
Thanks,
Hugo Parente Lima
> Hi,
>
> 2011/6/27 Hugo Parente Lima <hugo...@openbossa.org>:
> > We don't have any equivalent way of doing what sip.wrapinstance does.
> > Although if you are compiling your own PySide you can write an small
> > code injection on PySide typesystem to add this function.
> > [...]
> > You may ask, why you didn't add this code to PySide already? simple...
> > because QtCore isn't the right place for it, but a separated module
> > probably called "shiboken" and we didn't it yet.
>
> Nice :) So, is there a wiki page or a bug report that collects ideas
> and features that should go into that "shiboken" module?
Not yet, but would be nice to have one, maybe a bug report pointing to a wiki
page, at the moment what comes to my mind is:
# returns true if the python object is valid
shiboken.isValid(obj)
# create an instance based on the given address and type
shiboken.wrapInstance(long, type)
# prints internal information about the object to stderr,
# just for debugging purposes.
shiboken.printInfo(obj)
> Thanks,
> Thomas
Thomas Perl
2011/6/27 Hugo Parente Lima <hugo...@openbossa.org>:
> On Monday 27 June 2011 12:42:40 Thomas Perl wrote:
>> Nice :) So, is there a wiki page or a bug report that collects ideas
>> and features that should go into that "shiboken" module?
>
> Not yet, but would be nice to have one, maybe a bug report pointing to a wiki
> page, at the moment what comes to my mind is: [...]
Added a feature request:
http://bugs.pyside.org/show_bug.cgi?id=902
Matti Airas
> You may ask, why you didn't add this code to PySide already? simple... because
> QtCore isn't the right place for it, but a separated module probably called
> "shiboken" and we didn't it yet.
I might sound like a broken record, but I think this is again an API
design decision and we should have a PSEP for defining such content.
Also, would "shiboken" be a good name for a module having such
functionality? To me it sounds awfully lot just like exposing our
internal implementation details to Python. How about using just the
top-level PySide module instead?
ma.
Hugo Lima
> On 27.06.2011 17:50, ext Hugo Parente Lima wrote:
>>
>> You may ask, why you didn't add this code to PySide already? simple...
>> because
>> QtCore isn't the right place for it, but a separated module probably
>> called
>> "shiboken" and we didn't it yet.
>
> I might sound like a broken record, but I think this is again an API design
> decision and we should have a PSEP for defining such content.
>
> Also, would "shiboken" be a good name for a module having such
> functionality? To me it sounds awfully lot just like exposing our internal
> implementation details to Python. How about using just the top-level PySide
> module instead?
Hi
Matti, I think we don't need a PSEP, PSEPs are for PySide things, this
is specific to Shiboken based bindings, PySide is included as well but
it isn't the focus, I mean, this module is not made to access PySide
internal stuff, but Shiboken internal stuff, it's highly tied to
Shiboken, if we create a PSEP and change the PySide backend from
Shiboken to something else in an unknown future the PSEP could turn
into a non sense PSEP.
This also explain why to name the module "shiboken" instead of put it
into PySide module, there's no technical reasons to make this module
depend on PySide and being a separate module all Shiboken based
bindings can have gain.
Regards
P.S.: Suggestions about the module implementation, what functions it
need to have, etc could be made here or on the bug report[1], I'll
read both anyway.
[1] http://bugs.pyside.org/show_bug.cgi?id=902
matti....@nokia.com
>
>Matti, I think we don't need a PSEP, PSEPs are for PySide things, this
>is specific to Shiboken based bindings, PySide is included as well but
>it isn't the focus, I mean, this module is not made to access PySide
>internal stuff, but Shiboken internal stuff, it's highly tied to
>Shiboken, if we create a PSEP and change the PySide backend from
>Shiboken to something else in an unknown future the PSEP could turn
>into a non sense PSEP.
OK, but Shiboken is developer under the PySide umbrella, and hence our
commitments to an open-governance process and the PSEP design approach
apply here too. The proposed module would be a non-trivial Python API
closely related to PySide, and therefore would still require an open
design process, IMO.
Also, the PSEP also works as a specification and documentation for new
featuers, and they would be required in any case for a new module, even if
the PSEP wasn't done.
There are no plans to replace Shiboken in PySide, so that's a moot point.
But even if that would happen, there would be absolutely no harm done. The
PSEP would just become obsolete then.
>This also explain why to name the module "shiboken" instead of put it
>into PySide module, there's no technical reasons to make this module
>depend on PySide and being a separate module all Shiboken based
>bindings can have gain.
Point taken. This I can live with.
>P.S.: Suggestions about the module implementation, what functions it
>need to have, etc could be made here or on the bug report[1], I'll
>read both anyway.
>
>[1] http://bugs.pyside.org/show_bug.cgi?id=902
No need for commenting on the bug - we have the well-defined PSEP process
for defining implementations anyway. ;-)
Hugo Parente Lima
> On 5.8.2011 1.28, "ext Hugo Lima" <hugo...@openbossa.org> wrote:
> >Matti, I think we don't need a PSEP, PSEPs are for PySide things, this
> >is specific to Shiboken based bindings, PySide is included as well but
> >it isn't the focus, I mean, this module is not made to access PySide
> >internal stuff, but Shiboken internal stuff, it's highly tied to
> >Shiboken, if we create a PSEP and change the PySide backend from
> >Shiboken to something else in an unknown future the PSEP could turn
> >into a non sense PSEP.
>
> OK, but Shiboken is developer under the PySide umbrella, and hence our
> commitments to an open-governance process and the PSEP design approach
> apply here too. The proposed module would be a non-trivial Python API
> closely related to PySide, and therefore would still require an open
> design process, IMO.
>
> Also, the PSEP also works as a specification and documentation for new
> featuers, and they would be required in any case for a new module, even if
> the PSEP wasn't done.
>
> There are no plans to replace Shiboken in PySide, so that's a moot point.
> But even if that would happen, there would be absolutely no harm done. The
> PSEP would just become obsolete then.
I'm still not convinced about the need of a PSEP for this but I can (will)
write one if it is required. PSEP means open design process, but the absence
of an PSEP doesn't mean a closed design process, it can be open as it is at
the moment, just with less bureaucracy.
I'm also *not* against the PSEP idea, it's a good idea, I just have the
opinion that PSEPs should take care of PySide Python API only, not the
internal ecosystem surrounding the bindings generation/runtime.
> >This also explain why to name the module "shiboken" instead of put it
> >into PySide module, there's no technical reasons to make this module
> >depend on PySide and being a separate module all Shiboken based
> >bindings can have gain.
>
> Point taken. This I can live with.
>
> >P.S.: Suggestions about the module implementation, what functions it
> >need to have, etc could be made here or on the bug report[1], I'll
> >read both anyway.
> >
> >[1] http://bugs.pyside.org/show_bug.cgi?id=902
>
> No need for commenting on the bug - we have the well-defined PSEP process
> for defining implementations anyway. ;-)
>
> ma.
--
matti....@nokia.com
>
>I'm still not convinced about the need of a PSEP for this but I can
>(will)
>write one if it is required. PSEP means open design process, but the
>absence
>of an PSEP doesn't mean a closed design process, it can be open as it is
>at
>the moment, just with less bureaucracy.
If you omit doing the PSEP and work in a "non-bureaucracy" mode, you still
need to write proper documentation for the APIs, so in the end you save no
work.
Also, from the openness point of view, there's a definite difference
between the PSEP mode, in which you need to have the discussion in the
public and reach a concensus before something is done, and you collecting
suggestions and then making the design decisions among the core dev team.
>I'm also *not* against the PSEP idea, it's a good idea, I just have the
>opinion that PSEPs should take care of PySide Python API only, not the
>internal ecosystem surrounding the bindings generation/runtime.
But the module we're discussing _would_, for all intents and purposes, be
a PySide Python API, and not about the internal ecosystem.