These are chat archives for PySide/pyside2

May 2017
Padraig O Cuinn
May 02 2017 09:03
it could so with a change but for now we cant use it in studio as its not competable with any DCC
From IRC (bridge bot)
May 02 2017 09:42
<alcroito> am i suddenly the maintainer of the cmake stuff, because everybody else just +1s :⁠D
<fkleint> alcroito: Exactly ;⁠-)
<fkleint> alcroito: Actuallly I am hoping forCOIN this week, so we can try the stuff
From IRC (bridge bot)
May 02 2017 10:23
<alcroito> fkleint: i don't, stuff still fails
From IRC (bridge bot)
May 02 2017 10:33
<lqi> alcroito: any hint for bind a type to ctypes?
<alcroito> lqi: more details please?
<lqi> alcroito: " for those types in system, could we reuse ctypes? like ctypes.wintypes.HBITMAP for that purpose?"
<alcroito> lqi: i'm stil not sure what you're after. Last stime I said yes iirc. If you mean how to bind c++ types to the respective ctypes HBITMAP type, you need to write conversion rules in the xml.
<lqi> alcroito: yes, "how to bind c++ types to the respective ctypes HBITMAP type"
From IRC (bridge bot)
May 02 2017 10:41
<alcroito> lqi: the general idea you can see in sources/shiboken/tests/samplebinding/typesystem_sample.xml , you define a primitive type and specify conversion rules to and from
<alcroito> lqi: I don't think we have any examples on how to do it specifically for ctypes
From IRC (bridge bot)
May 02 2017 10:55
<lqi> alcroito: reading
<ctismer> fkleint: Actually, I fear that COIN cannot handle this, because a change is needed both in Shiboken and in PySide to run without errors.
<fkleint> Argh ;-(
<alcroito> which is why I asked, why don't we merge the repos..
From IRC (bridge bot)
May 02 2017 11:14
<ctismer> I thought it was a licensing issue? But actually we could use an inofficially merged repo, just for the tests alone.
<alcroito> the licensing issues was with the repos like tools, examples. afaik the qt company has the rights for shiboken and pyside2.
<ctismer> waah! Then do it :⁠-)))
<ctismer> Question: Is there a Qt constant for C++11? Or do I need something like "#define IS_CPP11_OR_BETTER (__cplusplus >= 201103L)"
<alcroito> we can bring it up one more time at the meeting
From IRC (bridge bot)
May 02 2017 11:20
<ctismer> alcroito: do You maybe know if C++11 and "Avoid the hack" works on Linux? Om macOS it doesn't.
<alcroito> ctismer: i haven't tried yet
<alcroito> ctismer: what's your usecase for is_cpp11_or_better?
<ctismer> alcroito: If a compiler is at C++11 and it needs to handle private destructors, then I must create a destructor for the wrapper. Only the declaration!
<ctismer> right now I did that with MSCC, but that is not the real reason.
<ctismer> Q_CC_MSVC
<alcroito> ctismer: we require c++11 for 5.9 / dev branches, so you can assume that is always on, thus you don't really need a define
From IRC (bridge bot)
May 02 2017 11:25
<ctismer> an, ok!
<alcroito> ctismer: if you really want to, you could query CXX_STANDARD or similar from cmake, and pass a C++ define on the compiler command line, but afaik that is discouraged
<ctismer> the __cplusplus is currently much used. The cmake variable btw. is great, I could not find that for hours!
From IRC (bridge bot)
May 02 2017 11:38
<ctismer> alcroito and why is the __cplusplus variable not recommended?
<alcroito> ctismer: because released compilers do not implement the whole standard, some features are missing. Thus it is recommended to use feature tests, aka check if the feature that you want to use is actually available.