From johan.rade at gmail.com Mon Feb 3 12:16:20 2014 From: johan.rade at gmail.com (=?ISO-8859-1?Q?Johan_R=E5de?=) Date: Mon, 03 Feb 2014 12:16:20 +0100 Subject: [PySide] Building Shiboken on Windows Message-ID: Hi, Is it possible to build Shiboken on Windows? I tried the following: 1. I downloaded and unzipped the shiboken source tree. 2. I ran CMake with the command cmake -G "Visual Studio 10" CMake ran without any errors or warnings. I have attached the ouput (CMake.log). 3. I opened up the generated solution file shiboken.sln with Visual Studio 2010. 4. I selected the configuration "Release". 5. I built the project ALL_BUILD. Four projects did not build. I have attached the output showing the errors (ALL_BUILD.log). 6. I ran the tests. 35 tests passed, 129 tests failed. I have attached the output (RUN_TESTS.log). Cheers, Johan Råde -------------- next part -------------- ------ Build started: Project: ZERO_CHECK, Configuration: Release Win32 ------ Build started 2014-02-03 12:03:54. InitializeBuildStatus: Creating "Win32\Release\ZERO_CHECK\ZERO_CHECK.unsuccessfulbuild" because "AlwaysCreate" was specified. FinalizeBuildStatus: Deleting file "Win32\Release\ZERO_CHECK\ZERO_CHECK.unsuccessfulbuild". Touching "Win32\Release\ZERO_CHECK\ZERO_CHECK.lastbuildstate". Build succeeded. Time Elapsed 00:00:00.09 ------ Build started: Project: sample, Configuration: Release Win32 ------ Build started 2014-02-03 12:03:54. InitializeBuildStatus: Touching "sample.dir\Release\sample.unsuccessfulbuild". CustomBuild: Building Custom Rule C:/Libraries/shiboken-1.2.1/tests/samplebinding/CMakeLists.txt CMake does not need to re-run because C:\Libraries\shiboken-1.2.1\tests\samplebinding\CMakeFiles\generate.stamp is up-to-date. Running generator for 'sample' test binding... 'C:\Libraries\shiboken-1.2.1\generator\shiboken' is not recognized as an internal or external command, operable program or batch file. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 9009. Build FAILED. Time Elapsed 00:00:00.18 ------ Build started: Project: shibokenmodule, Configuration: Release Win32 ------ Build started 2014-02-03 12:03:54. InitializeBuildStatus: Touching "shibokenmodule.dir\Release\shibokenmodule.unsuccessfulbuild". CustomBuild: Building Custom Rule C:/Libraries/shiboken-1.2.1/shibokenmodule/CMakeLists.txt CMake does not need to re-run because C:\Libraries\shiboken-1.2.1\shibokenmodule\CMakeFiles\generate.stamp is up-to-date. Running generator for 'shiboken'... 'C:\Libraries\shiboken-1.2.1\generator\shiboken' is not recognized as an internal or external command, operable program or batch file. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 9009. Build FAILED. Time Elapsed 00:00:00.10 ------ Build started: Project: other, Configuration: Release Win32 ------ Build started 2014-02-03 12:03:55. InitializeBuildStatus: Touching "other.dir\Release\other.unsuccessfulbuild". CustomBuild: Building Custom Rule C:/Libraries/shiboken-1.2.1/tests/otherbinding/CMakeLists.txt CMake does not need to re-run because C:\Libraries\shiboken-1.2.1\tests\otherbinding\CMakeFiles\generate.stamp is up-to-date. Running generator for 'other' test binding... 'C:\Libraries\shiboken-1.2.1\generator\shiboken' is not recognized as an internal or external command, operable program or batch file. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 9009. Build FAILED. Time Elapsed 00:00:00.11 ------ Build started: Project: minimal, Configuration: Release Win32 ------ Build started 2014-02-03 12:03:55. InitializeBuildStatus: Touching "minimal.dir\Release\minimal.unsuccessfulbuild". CustomBuild: Building Custom Rule C:/Libraries/shiboken-1.2.1/tests/minimalbinding/CMakeLists.txt CMake does not need to re-run because C:\Libraries\shiboken-1.2.1\tests\minimalbinding\CMakeFiles\generate.stamp is up-to-date. Running generator for 'minimal' test binding... 'C:\Libraries\shiboken-1.2.1\generator\shiboken' is not recognized as an internal or external command, operable program or batch file. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 9009. Build FAILED. Time Elapsed 00:00:00.11 ------ Build started: Project: ALL_BUILD, Configuration: Release Win32 ------ Build started 2014-02-03 12:03:55. InitializeBuildStatus: Creating "Win32\Release\ALL_BUILD\ALL_BUILD.unsuccessfulbuild" because "AlwaysCreate" was specified. CustomBuild: Build all projects FinalizeBuildStatus: Deleting file "Win32\Release\ALL_BUILD\ALL_BUILD.unsuccessfulbuild". Touching "Win32\Release\ALL_BUILD\ALL_BUILD.lastbuildstate". Build succeeded. Time Elapsed 00:00:00.90 ========== Build: 2 succeeded, 4 failed, 41 up-to-date, 0 skipped ========== -------------- next part -------------- Setting environment for using Microsoft Visual Studio 2010 x86 tools. C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>cd C:\Libraries\shiboken-1.2.1 C:\Libraries\shiboken-1.2.1>cmake -G "Visual Studio 10" -- The C compiler identification is MSVC 16.0.40219.1 -- The CXX compiler identification is MSVC 16.0.40219.1 -- Check for working C compiler using: Visual Studio 10 -- Check for working C compiler using: Visual Studio 10 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Visual Studio 10 -- Check for working CXX compiler using: Visual Studio 10 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - not found -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - found -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - not found -- Found Qt4: C:/Libraries/Qt/4.8.5/bin/qmake.exe (found suitable version "4.8.5", minimum required is "4.5.0") -- Found PythonLibs: C:/Python27/libs/python27.lib (found suitable version "2.7.6", minimum required is "2.6") -- Found PythonInterp: C:/Python27/python.exe (found version "2.7.6") -- Found LibXml2: C:/Libraries/libxml2-2.7.8/lib/libxml2.lib (found suitable version "2.7.8", minimum required is "2.6.32") -- Found LibXslt: C:/Libraries/libxslt-1.1.26/lib/libxslt.lib (found suitable version "1.1.26", minimum required is "1.1.19") -- sphinx-build - found -- Tests will be generated avoiding the protected hack! -- Configuring done -- Generating done -- Build files have been written to: C:/Libraries/shiboken-1.2.1 C:\Libraries\shiboken-1.2.1> -------------- next part -------------- ------ Build started: Project: RUN_TESTS, Configuration: Release Win32 ------ Build started 2014-02-03 12:05:38. InitializeBuildStatus: Creating "Win32\Release\RUN_TESTS\RUN_TESTS.unsuccessfulbuild" because "AlwaysCreate" was specified. PostBuildEvent: Test project C:/Libraries/shiboken-1.2.1 Start 1: testabstractmetaclass 1/164 Test #1: testabstractmetaclass .............................................. Passed 0.49 sec Start 2: testabstractmetatype 2/164 Test #2: testabstractmetatype ............................................... Passed 0.06 sec Start 3: testaddfunction 3/164 Test #3: testaddfunction .................................................... Passed 0.09 sec Start 4: testarrayargument 4/164 Test #4: testarrayargument .................................................. Passed 0.04 sec Start 5: testcodeinjection 5/164 Test #5: testcodeinjection .................................................. Passed 0.07 sec Start 6: testcontainer 6/164 Test #6: testcontainer ...................................................... Passed 0.04 sec Start 7: testconversionoperator 7/164 Test #7: testconversionoperator ............................................. Passed 0.07 sec Start 8: testconversionruletag 8/164 Test #8: testconversionruletag .............................................. Passed 0.06 sec Start 9: testctorinformation 9/164 Test #9: testctorinformation ................................................ Passed 0.03 sec Start 10: testdroptypeentries 10/164 Test #10: testdroptypeentries ................................................ Passed 0.05 sec Start 11: testdtorinformation 11/164 Test #11: testdtorinformation ................................................ Passed 0.04 sec Start 12: testenum 12/164 Test #12: testenum ........................................................... Passed 0.06 sec Start 13: testextrainclude 13/164 Test #13: testextrainclude ................................................... Passed 0.04 sec Start 14: testfunctiontag 14/164 Test #14: testfunctiontag .................................................... Passed 0.04 sec Start 15: testimplicitconversions 15/164 Test #15: testimplicitconversions ............................................ Passed 0.04 sec Start 16: testinserttemplate 16/164 Test #16: testinserttemplate ................................................. Passed 0.04 sec Start 17: testmodifyfunction 17/164 Test #17: testmodifyfunction ................................................. Passed 0.05 sec Start 18: testmultipleinheritance 18/164 Test #18: testmultipleinheritance ............................................ Passed 0.05 sec Start 19: testnamespace 19/164 Test #19: testnamespace ...................................................... Passed 0.04 sec Start 20: testnestedtypes 20/164 Test #20: testnestedtypes .................................................... Passed 0.04 sec Start 21: testnumericaltypedef 21/164 Test #21: testnumericaltypedef ............................................... Passed 0.03 sec Start 22: testprimitivetypetag 22/164 Test #22: testprimitivetypetag ............................................... Passed 0.03 sec Start 23: testrefcounttag 23/164 Test #23: testrefcounttag .................................................... Passed 0.04 sec Start 24: testreferencetopointer 24/164 Test #24: testreferencetopointer ............................................. Passed 0.04 sec Start 25: testremovefield 25/164 Test #25: testremovefield .................................................... Passed 0.03 sec Start 26: testremoveimplconv 26/164 Test #26: testremoveimplconv ................................................. Passed 0.03 sec Start 27: testremoveoperatormethod 27/164 Test #27: testremoveoperatormethod ........................................... Passed 0.03 sec Start 28: testresolvetype 28/164 Test #28: testresolvetype .................................................... Passed 0.03 sec Start 29: testreverseoperators 29/164 Test #29: testreverseoperators ............................................... Passed 0.04 sec Start 30: testtemplates 30/164 Test #30: testtemplates ...................................................... Passed 0.07 sec Start 31: testtoposort 31/164 Test #31: testtoposort ....................................................... Passed 0.02 sec Start 32: testvaluetypedefaultctortag 32/164 Test #32: testvaluetypedefaultctortag ........................................ Passed 0.04 sec Start 33: testvoidarg 33/164 Test #33: testvoidarg ........................................................ Passed 0.04 sec Start 34: testtyperevision 34/164 Test #34: testtyperevision ................................................... Passed 0.03 sec Start 35: testmodifydocumentation 35/164 Test #35: testmodifydocumentation ............................................***Exception: Other 0.03 sec Start 36: minimal_listuser 36/164 Test #36: minimal_listuser ...................................................***Failed 0.32 sec Start 37: minimal_minbool 37/164 Test #37: minimal_minbool ....................................................***Failed 0.08 sec Start 38: minimal_obj 38/164 Test #38: minimal_obj ........................................................***Failed 0.08 sec Start 39: minimal_val 39/164 Test #39: minimal_val ........................................................***Failed 0.09 sec Start 40: other_collector_external_operator 40/164 Test #40: other_collector_external_operator ..................................***Failed 0.08 sec Start 41: other_conversion_operator_for_class_without_implicit_conversions 41/164 Test #41: other_conversion_operator_for_class_without_implicit_conversions ...***Failed 0.08 sec Start 42: other_extended_multiply_operator 42/164 Test #42: other_extended_multiply_operator ...................................***Failed 0.08 sec Start 43: other_module_reload 43/164 Test #43: other_module_reload ................................................***Failed 0.14 sec Start 44: other_new_ctor_operator 44/164 Test #44: other_new_ctor_operator ............................................***Failed 0.08 sec Start 45: other_otherderived 45/164 Test #45: other_otherderived .................................................***Failed 0.08 sec Start 46: other_typediscovery 46/164 Test #46: other_typediscovery ................................................***Failed 0.08 sec Start 47: other_usersprimitivefromothermodule 47/164 Test #47: other_usersprimitivefromothermodule ................................***Failed 0.09 sec Start 48: other_wrongctor 48/164 Test #48: other_wrongctor ....................................................***Failed 0.08 sec Start 49: sample___del__ 49/164 Test #49: sample___del__ .....................................................***Failed 0.08 sec Start 50: sample_abstract 50/164 Test #50: sample_abstract ....................................................***Failed 0.08 sec Start 51: sample_addedfunction 51/164 Test #51: sample_addedfunction ...............................................***Failed 0.08 sec Start 52: sample_argumentmodifications 52/164 Test #52: sample_argumentmodifications .......................................***Failed 0.08 sec Start 53: sample_bug_554 53/164 Test #53: sample_bug_554 .....................................................***Failed 0.06 sec Start 54: sample_bug_704 54/164 Test #54: sample_bug_704 .....................................................***Failed 0.08 sec Start 55: sample_bytearray 55/164 Test #55: sample_bytearray ...................................................***Failed 0.08 sec Start 56: sample_child_return 56/164 Test #56: sample_child_return ................................................***Failed 0.08 sec Start 57: sample_class_fields 57/164 Test #57: sample_class_fields ................................................***Failed 0.08 sec Start 58: sample_collector 58/164 Test #58: sample_collector ...................................................***Failed 0.09 sec Start 59: sample_complex 59/164 Test #59: sample_complex .....................................................***Failed 0.08 sec Start 60: sample_conversion_operator 60/164 Test #60: sample_conversion_operator .........................................***Failed 0.08 sec Start 61: sample_copy 61/164 Test #61: sample_copy ........................................................***Failed 0.11 sec Start 62: sample_ctorconvrule 62/164 Test #62: sample_ctorconvrule ................................................***Failed 0.08 sec Start 63: sample_cyclic 63/164 Test #63: sample_cyclic ......................................................***Failed 0.08 sec Start 64: sample_date 64/164 Test #64: sample_date ........................................................***Failed 0.08 sec Start 65: sample_decisor 65/164 Test #65: sample_decisor .....................................................***Failed 0.08 sec Start 66: sample_deprecated 66/164 Test #66: sample_deprecated ..................................................***Failed 0.08 sec Start 67: sample_derived 67/164 Test #67: sample_derived .....................................................***Failed 0.08 sec Start 68: sample_duck_punching 68/164 Test #68: sample_duck_punching ...............................................***Failed 0.08 sec Start 69: sample_echo 69/164 Test #69: sample_echo ........................................................***Failed 0.08 sec Start 70: sample_enum 70/164 Test #70: sample_enum ........................................................***Failed 0.08 sec Start 71: sample_enumfromremovednamespace 71/164 Test #71: sample_enumfromremovednamespace ....................................***Failed 0.09 sec Start 72: sample_event_loop_call_virtual 72/164 Test #72: sample_event_loop_call_virtual .....................................***Failed 0.22 sec Start 73: sample_event_loop_thread 73/164 Test #73: sample_event_loop_thread ...........................................***Failed 0.14 sec Start 74: sample_filter 74/164 Test #74: sample_filter ......................................................***Failed 0.08 sec Start 75: sample_handleholder 75/164 Test #75: sample_handleholder ................................................***Failed 0.08 sec Start 76: sample_hashabletype 76/164 Test #76: sample_hashabletype ................................................***Failed 0.08 sec Start 77: sample_ignorederefop 77/164 Test #77: sample_ignorederefop ...............................................***Failed 0.08 sec Start 78: sample_implicitconv_numerical 78/164 Test #78: sample_implicitconv_numerical ......................................***Failed 0.08 sec Start 79: sample_implicitconv 79/164 Test #79: sample_implicitconv ................................................***Failed 0.08 sec Start 80: sample_inheritanceandscope 80/164 Test #80: sample_inheritanceandscope .........................................***Failed 0.08 sec Start 81: sample_injectcode 81/164 Test #81: sample_injectcode ..................................................***Failed 0.08 sec Start 82: sample_innerclass 82/164 Test #82: sample_innerclass ..................................................***Failed 0.08 sec Start 83: sample_intlist 83/164 Test #83: sample_intlist .....................................................***Failed 0.08 sec Start 84: sample_invalid_virtual_return 84/164 Test #84: sample_invalid_virtual_return ......................................***Failed 0.08 sec Start 85: sample_keep_reference 85/164 Test #85: sample_keep_reference ..............................................***Failed 0.08 sec Start 86: sample_list 86/164 Test #86: sample_list ........................................................***Failed 0.08 sec Start 87: sample_lock 87/164 Test #87: sample_lock ........................................................***Failed 0.08 sec Start 88: sample_map 88/164 Test #88: sample_map .........................................................***Failed 0.08 sec Start 89: sample_metaclass 89/164 Test #89: sample_metaclass ...................................................***Failed 0.06 sec Start 90: sample_mi_virtual_methods 90/164 Test #90: sample_mi_virtual_methods ..........................................***Failed 0.08 sec Start 91: sample_mixed_mi 91/164 Test #91: sample_mixed_mi ....................................................***Failed 0.08 sec Start 92: sample_modelindex 92/164 Test #92: sample_modelindex ..................................................***Failed 0.08 sec Start 93: sample_modelview 93/164 Test #93: sample_modelview ...................................................***Failed 0.08 sec Start 94: sample_modifications 94/164 Test #94: sample_modifications ...............................................***Failed 0.08 sec Start 95: sample_modified_constructor 95/164 Test #95: sample_modified_constructor ........................................***Failed 0.08 sec Start 96: sample_modifiedvirtualmethods 96/164 Test #96: sample_modifiedvirtualmethods ......................................***Failed 0.08 sec Start 97: sample_multi_cpp_inheritance 97/164 Test #97: sample_multi_cpp_inheritance .......................................***Failed 0.08 sec Start 98: sample_multiple_derived 98/164 Test #98: sample_multiple_derived ............................................***Failed 0.08 sec Start 99: sample_namespace 99/164 Test #99: sample_namespace ...................................................***Failed 0.08 sec Start 100: sample_newdivision 100/164 Test #100: sample_newdivision .................................................***Failed 0.06 sec Start 101: sample_nondefaultctor 101/164 Test #101: sample_nondefaultctor ..............................................***Failed 0.08 sec Start 102: sample_nonzero 102/164 Test #102: sample_nonzero .....................................................***Failed 0.08 sec Start 103: sample_numericaltypedef 103/164 Test #103: sample_numericaltypedef ............................................***Failed 0.08 sec Start 104: sample_numpy 104/164 Test #104: sample_numpy ....................................................... Passed 0.06 sec Start 105: sample_objecttype 105/164 Test #105: sample_objecttype ..................................................***Failed 0.08 sec Start 106: sample_objecttype_with_named_args 106/164 Test #106: sample_objecttype_with_named_args ..................................***Failed 0.08 sec Start 107: sample_objecttypebyvalue 107/164 Test #107: sample_objecttypebyvalue ...........................................***Failed 0.06 sec Start 108: sample_objecttypelayout 108/164 Test #108: sample_objecttypelayout ............................................***Failed 0.08 sec Start 109: sample_objecttypeoperators 109/164 Test #109: sample_objecttypeoperators .........................................***Failed 0.08 sec Start 110: sample_objecttypereferenceasvirtualmethodargument 110/164 Test #110: sample_objecttypereferenceasvirtualmethodargument ..................***Failed 0.08 sec Start 111: sample_oddbool 111/164 Test #111: sample_oddbool .....................................................***Failed 0.08 sec Start 112: sample_oldstyleclass_as_number 112/164 Test #112: sample_oldstyleclass_as_number .....................................***Failed 0.08 sec Start 113: sample_onlycopyclass 113/164 Test #113: sample_onlycopyclass ...............................................***Failed 0.08 sec Start 114: sample_overflow 114/164 Test #114: sample_overflow ....................................................***Failed 0.08 sec Start 115: sample_overload_sorting 115/164 Test #115: sample_overload_sorting ............................................***Failed 0.08 sec Start 116: sample_overload 116/164 Test #116: sample_overload ....................................................***Failed 0.08 sec Start 117: sample_overloadwithdefault 117/164 Test #117: sample_overloadwithdefault .........................................***Failed 0.08 sec Start 118: sample_ownership_argument_invalidation 118/164 Test #118: sample_ownership_argument_invalidation .............................***Failed 0.08 sec Start 119: sample_ownership_delete_child_in_cpp 119/164 Test #119: sample_ownership_delete_child_in_cpp ...............................***Failed 0.08 sec Start 120: sample_ownership_delete_child_in_python 120/164 Test #120: sample_ownership_delete_child_in_python ............................***Failed 0.10 sec Start 121: sample_ownership_delete_parent 121/164 Test #121: sample_ownership_delete_parent .....................................***Failed 0.08 sec Start 122: sample_ownership_invalidate_after_use 122/164 Test #122: sample_ownership_invalidate_after_use ..............................***Failed 0.08 sec Start 123: sample_ownership_invalidate_child 123/164 Test #123: sample_ownership_invalidate_child ..................................***Failed 0.08 sec Start 124: sample_ownership_invalidate_nonpolymorphic 124/164 Test #124: sample_ownership_invalidate_nonpolymorphic .........................***Failed 0.08 sec Start 125: sample_ownership_invalidate_parent 125/164 Test #125: sample_ownership_invalidate_parent .................................***Failed 0.08 sec Start 126: sample_ownership_reparenting 126/164 Test #126: sample_ownership_reparenting .......................................***Failed 0.08 sec Start 127: sample_ownership_transference 127/164 Test #127: sample_ownership_transference ......................................***Failed 0.08 sec Start 128: sample_pair 128/164 Test #128: sample_pair ........................................................***Failed 0.08 sec Start 129: sample_pen 129/164 Test #129: sample_pen .........................................................***Failed 0.08 sec Start 130: sample_point 130/164 Test #130: sample_point .......................................................***Failed 0.08 sec Start 131: sample_pointerholder 131/164 Test #131: sample_pointerholder ...............................................***Failed 0.08 sec Start 132: sample_pointf 132/164 Test #132: sample_pointf ......................................................***Failed 0.08 sec Start 133: sample_primitivereferenceargument 133/164 Test #133: sample_primitivereferenceargument ..................................***Failed 0.08 sec Start 134: sample_privatector 134/164 Test #134: sample_privatector .................................................***Failed 0.08 sec Start 135: sample_privatedtor 135/164 Test #135: sample_privatedtor .................................................***Failed 0.08 sec Start 136: sample_protected 136/164 Test #136: sample_protected ...................................................***Failed 0.08 sec Start 137: sample_pstrlist 137/164 Test #137: sample_pstrlist ....................................................***Failed 0.08 sec Start 138: sample_pystr 138/164 Test #138: sample_pystr .......................................................***Failed 0.08 sec Start 139: sample_python_thread 139/164 Test #139: sample_python_thread ...............................................***Failed 0.08 sec Start 140: sample_receive_null_cstring 140/164 Test #140: sample_receive_null_cstring ........................................***Failed 0.08 sec Start 141: sample_reference 141/164 Test #141: sample_reference ...................................................***Failed 0.08 sec Start 142: sample_referencetopointer 142/164 Test #142: sample_referencetopointer ..........................................***Failed 0.08 sec Start 143: sample_return_null 143/164 Test #143: sample_return_null .................................................***Failed 0.08 sec Start 144: sample_richcompare 144/164 Test #144: sample_richcompare .................................................***Failed 0.08 sec Start 145: sample_sample 145/164 Test #145: sample_sample ......................................................***Failed 0.08 sec Start 146: sample_simplefile 146/164 Test #146: sample_simplefile ..................................................***Failed 0.08 sec Start 147: sample_size 147/164 Test #147: sample_size ........................................................***Failed 0.08 sec Start 148: sample_static_nonstatic_methods 148/164 Test #148: sample_static_nonstatic_methods ....................................***Failed 0.08 sec Start 149: sample_str 149/164 Test #149: sample_str .........................................................***Failed 0.08 sec Start 150: sample_strlist 150/164 Test #150: sample_strlist .....................................................***Failed 0.08 sec Start 151: sample_templateinheritingclass 151/164 Test #151: sample_templateinheritingclass .....................................***Failed 0.08 sec Start 152: sample_time 152/164 Test #152: sample_time ........................................................***Failed 0.08 sec Start 153: sample_typeconverters 153/164 Test #153: sample_typeconverters ..............................................***Failed 0.08 sec Start 154: sample_typedealloc 154/164 Test #154: sample_typedealloc .................................................***Failed 0.08 sec Start 155: sample_typedtordoublefree 155/164 Test #155: sample_typedtordoublefree ..........................................***Failed 0.08 sec Start 156: sample_unsafe_parent 156/164 Test #156: sample_unsafe_parent ...............................................***Failed 0.08 sec Start 157: sample_useraddedctor 157/164 Test #157: sample_useraddedctor ...............................................***Failed 0.08 sec Start 158: sample_virtualdtor 158/164 Test #158: sample_virtualdtor .................................................***Failed 0.08 sec Start 159: sample_virtualmethods 159/164 Test #159: sample_virtualmethods ..............................................***Failed 0.08 sec Start 160: sample_visibilitychange 160/164 Test #160: sample_visibilitychange ............................................***Failed 0.08 sec Start 161: sample_voidholder 161/164 Test #161: sample_voidholder ..................................................***Failed 0.08 sec Start 162: sample_weakref 162/164 Test #162: sample_weakref .....................................................***Failed 0.08 sec Start 163: sample_writableclassdict 163/164 Test #163: sample_writableclassdict ...........................................***Failed 0.08 sec Start 164: shiboken_module 164/164 Test #164: shiboken_module ....................................................***Failed 0.06 sec 21% tests passed, 129 tests failed out of 164 Total Test time (real) = 13.29 sec The following tests FAILED: 35 - testmodifydocumentation (OTHER_FAULT) 36 - minimal_listuser (Failed) 37 - minimal_minbool (Failed) 38 - minimal_obj (Failed) 39 - minimal_val (Failed) 40 - other_collector_external_operator (Failed) 41 - other_conversion_operator_for_class_without_implicit_conversions (Failed) 42 - other_extended_multiply_operator (Failed) 43 - other_module_reload (Failed) 44 - other_new_ctor_operator (Failed) 45 - other_otherderived (Failed) 46 - other_typediscovery (Failed) 47 - other_usersprimitivefromothermodule (Failed) 48 - other_wrongctor (Failed) 49 - sample___del__ (Failed) 50 - sample_abstract (Failed) 51 - sample_addedfunction (Failed) 52 - sample_argumentmodifications (Failed) 53 - sample_bug_554 (Failed) 54 - sample_bug_704 (Failed) 55 - sample_bytearray (Failed) 56 - sample_child_return (Failed) 57 - sample_class_fields (Failed) 58 - sample_collector (Failed) 59 - sample_complex (Failed) 60 - sample_conversion_operator (Failed) 61 - sample_copy (Failed) 62 - sample_ctorconvrule (Failed) 63 - sample_cyclic (Failed) 64 - sample_date (Failed) 65 - sample_decisor (Failed) 66 - sample_deprecated (Failed) 67 - sample_derived (Failed) 68 - sample_duck_punching (Failed) 69 - sample_echo (Failed) 70 - sample_enum (Failed) 71 - sample_enumfromremovednamespace (Failed) 72 - sample_event_loop_call_virtual (Failed) 73 - sample_event_loop_thread (Failed) 74 - sample_filter (Failed) 75 - sample_handleholder (Failed) 76 - sample_hashabletype (Failed) 77 - sample_ignorederefop (Failed) 78 - sample_implicitconv_numerical (Failed) 79 - sample_implicitconv (Failed) 80 - sample_inheritanceandscope (Failed) 81 - sample_injectcode (Failed) 82 - sample_innerclass (Failed) 83 - sample_intlist (Failed) 84 - sample_invalid_virtual_return (Failed) 85 - sample_keep_reference (Failed) 86 - sample_list (Failed) 87 - sample_lock (Failed) 88 - sample_map (Failed) 89 - sample_metaclass (Failed) 90 - sample_mi_virtual_methods (Failed) 91 - sample_mixed_mi (Failed) 92 - sample_modelindex (Failed) 93 - sample_modelview (Failed) 94 - sample_modifications (Failed) 95 - sample_modified_constructor (Failed) 96 - sample_modifiedvirtualmethods (Failed) 97 - sample_multi_cpp_inheritance (Failed) 98 - sample_multiple_derived (Failed) 99 - sample_namespace (Failed) 100 - sample_newdivision (Failed) 101 - sample_nondefaultctor (Failed) 102 - sample_nonzero (Failed) 103 - sample_numericaltypedef (Failed) 105 - sample_objecttype (Failed) 106 - sample_objecttype_with_named_args (Failed) 107 - sample_objecttypebyvalue (Failed) 108 - sample_objecttypelayout (Failed) 109 - sample_objecttypeoperators (Failed) 110 - sample_objecttypereferenceasvirtualmethodargument (Failed) 111 - sample_oddbool (Failed) 112 - sample_oldstyleclass_as_number (Failed) 113 - sample_onlycopyclass (Failed) 114 - sample_overflow (Failed) 115 - sample_overload_sorting (Failed) 116 - sample_overload (Failed) 117 - sample_overloadwithdefault (Failed) 118 - sample_ownership_argument_invalidation (Failed) 119 - sample_ownership_delete_child_in_cpp (Failed) 120 - sample_ownership_delete_child_in_python (Failed) 121 - sample_ownership_delete_parent (Failed) 122 - sample_ownership_invalidate_after_use (Failed) 123 - sample_ownership_invalidate_child (Failed) 124 - sample_ownership_invalidate_nonpolymorphic (Failed) 125 - sample_ownership_invalidate_parent (Failed) 126 - sample_ownership_reparenting (Failed) 127 - sample_ownership_transference (Failed) 128 - sample_pair (Failed) 129 - sample_pen (Failed) 130 - sample_point (Failed) 131 - sample_pointerholder (Failed) 132 - sample_pointf (Failed) 133 - sample_primitivereferenceargument (Failed) 134 - sample_privatector (Failed) 135 - sample_privatedtor (Failed) 136 - sample_protected (Failed) 137 - sample_pstrlist (Failed) 138 - sample_pystr (Failed) 139 - sample_python_thread (Failed) 140 - sample_receive_null_cstring (Failed) 141 - sample_reference (Failed) 142 - sample_referencetopointer (Failed) 143 - sample_return_null (Failed) 144 - sample_richcompare (Failed) 145 - sample_sample (Failed) 146 - sample_simplefile (Failed) 147 - sample_size (Failed) 148 - sample_static_nonstatic_methods (Failed) 149 - sample_str (Failed) 150 - sample_strlist (Failed) 151 - sample_templateinheritingclass (Failed) 152 - sample_time (Failed) 153 - sample_typeconverters (Failed) 154 - sample_typedealloc (Failed) 155 - sample_typedtordoublefree (Failed) 156 - sample_unsafe_parent (Failed) 157 - sample_useraddedctor (Failed) 158 - sample_virtualdtor (Failed) 159 - sample_virtualmethods (Failed) 160 - sample_visibilitychange (Failed) 161 - sample_voidholder (Failed) 162 - sample_weakref (Failed) 163 - sample_writableclassdict (Failed) 164 - shiboken_module (Failed) Errors while running CTest C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: The command "setlocal C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: "C:\Program Files (x86)\CMake 2.8\bin\ctest.exe" --force-new-ctest-process -C Release C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :cmEnd C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :cmErrorLevel C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: exit /b %1 C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :cmDone C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" exited with code 8. Build FAILED. Time Elapsed 00:00:13.60 ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== From backup.rlacko at gmail.com Mon Feb 3 12:49:41 2014 From: backup.rlacko at gmail.com (Roman Lacko) Date: Mon, 3 Feb 2014 12:49:41 +0100 Subject: [PySide] Building Shiboken on Windows In-Reply-To: References: Message-ID: Shiboken binary is part of all windows distributions. But if you need to build the binary yourself and you don't want to change the shiboken source code, you can follow the instructions here [1] Roman [1] https://pypi.python.org/pypi/PySide#building-pyside-on-a-windows-system 2014-02-03 Johan Råde : > Hi, > > Is it possible to build Shiboken on Windows? > > I tried the following: > > 1. I downloaded and unzipped the shiboken source tree. > > 2. I ran CMake with the command > cmake -G "Visual Studio 10" > CMake ran without any errors or warnings. I have attached the ouput > (CMake.log). > > 3. I opened up the generated solution file shiboken.sln with Visual Studio > 2010. > > 4. I selected the configuration "Release". > > 5. I built the project ALL_BUILD. Four projects did not build. I have > attached the output showing the errors (ALL_BUILD.log). > > 6. I ran the tests. 35 tests passed, 129 tests failed. I have attached the > output (RUN_TESTS.log). > > Cheers, > Johan Råde > > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jumaroch.belpecajo at gmail.com Mon Feb 3 14:54:02 2014 From: jumaroch.belpecajo at gmail.com (Jumaroch Belpecajo) Date: Mon, 3 Feb 2014 14:54:02 +0100 Subject: [PySide] [Shiboken] Binding generation issues Message-ID: Hi, I'm using Shiboken to generate a python binding of a library based on C++/Qt. Currently, I'm using the 1.0.9 version of PySide (Shiboken 1.0.10) and I'm trying to update my bindings with the last version (1.2.1). However, I'm running into difficulties regarding the update: 1. It seems that the code parsing fails to correctly interpret the double right angle brakets >> with a space in between. Here is the C++ function signature: Curve(const QList > &) I get the following error (in shibokengenerator.cpp) "Types of receiver variable ('QPair') and %CONVERTTOCPP type system variable ('QPair **') differ." If I remove the space between the angle braket ('>>') the code is correctly generated (but '>>' is not valid for gcc). 2. I can't generate methods that are using QVector3D and QMatrix4x4 type as arguments (e.g. setPosition(const QVector3D &)). In Shiboken 1.0.10, I was using in my typesystem (otherwise the methods were rejected): Now, the generator complains that the conversion rules for QVector3D/QMatrix4x4 don't exist. If I remove the container-type definition from the typesystem, the methods are not generated (rejected because of unmatched argument type). Can someone give me some help on these two issues ? Thanks in advance, Romain -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.barrielle at m4x.org Mon Feb 3 17:42:31 2014 From: vincent.barrielle at m4x.org (Vincent Barrielle) Date: Mon, 03 Feb 2014 17:42:31 +0100 Subject: [PySide] PySide and the nuitka python compiler Message-ID: <2868723.CjkNUiXJOV@tesla> Hello, I'm using the nuitka python compiler (http://nuitka.net) in conjunction with PySide. However, this won't work with the current PySide version. According to Nuitka's main developper, this is a common problem when using nuitka with toolkit bindings, and requires some fix in the toolkits. For instance, he contributed patches fixing wxWdiget (http://trac.wxwidgets.org/ticket/14025) and PyQt4 (http://www.freelists.org/post/nuitka-dev/C-libraries-that-call-back-into-compiled-instance-methods,2). Following these examples, I've found some fixes that enable PySide to work correctly when run under Nuitka (patches attached). There were two issues that prevented PySide to run with Nuitka. The first one was that the slot registration mechanism was guarded by a PyFunction_Check which doesn't work with Nuitka's compiled functions, and the mechanism that added the "_slots" attribute to the slots was also making the assumption that it would be called on a PyFunctionObject. The second issue was in shiboken, the wrapping procedure was using PyMethod_Check. I hope these patches can get merged. If you feel these patches are not ready for merge yet, please let me know. Regards, Vincent Barrielle -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-slot-registration-when-running-under-the-Nuitka-.patch Type: text/x-patch Size: 2297 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Enable-wrapping-of-functions-compiled-by-Nuitka.patch Type: text/x-patch Size: 1411 bytes Desc: not available URL: From jpe at wingware.com Tue Feb 4 23:28:09 2014 From: jpe at wingware.com (John Ehresman) Date: Tue, 04 Feb 2014 15:28:09 -0700 Subject: [PySide] PySide and the nuitka python compiler In-Reply-To: <2868723.CjkNUiXJOV@tesla> References: <2868723.CjkNUiXJOV@tesla> Message-ID: <52F16979.6030800@wingware.com> On 2/3/14, 9:42 AM, Vincent Barrielle wrote: > Following these examples, I've found some fixes that enable PySide to work > correctly when run under Nuitka (patches attached). These look like worthwhile changes (though I haven't tried them yet). A couple questions: * Could you write tests for this functionality? I think you can use instances of classes with a __call__ method to simulate the behavior. * Does this change how methods are handled? In PySide (following how C++ Qt works) if a method of a QObject is connected as a callback, it is disconnected when the method's object is destroyed. I'm curious, does PySide's test suite work under Nuitka? Thanks, John From vasure at gmail.com Wed Feb 5 06:38:15 2014 From: vasure at gmail.com (Srini Kommoori) Date: Tue, 4 Feb 2014 21:38:15 -0800 Subject: [PySide] Support for 5.2 Message-ID: Hi Guys, Is anyone working on porting to Qt5.2? I just updated my mac to Mavericks and fonts are all messed up. I see that all of them are resolved in Qt5.2. thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.barrielle at m4x.org Wed Feb 5 10:57:02 2014 From: vincent.barrielle at m4x.org (Vincent Barrielle) Date: Wed, 05 Feb 2014 10:57:02 +0100 Subject: [PySide] PySide and the nuitka python compiler In-Reply-To: <52F16979.6030800@wingware.com> References: <2868723.CjkNUiXJOV@tesla> <52F16979.6030800@wingware.com> Message-ID: <16772053.1I9ra3XKyO@vinxyz-studio-xps-8100> Hello Jon, On Tuesday 04 February 2014 15:28:09 you wrote: > * Could you write tests for this functionality? I think you can use > instances of classes with a __call__ method to simulate the behavior. Sure, I can try and write some tests for that. I'll keep you posted. > * Does this change how methods are handled? In PySide (following how > C++ Qt works) if a method of a QObject is connected as a callback, it is > disconnected when the method's object is destroyed. I don't know yet, I guess it depends on whether the codepath that provides this functionality makes use of PyMethod_Check(). Is there a test for this? If yes, then I will run both with and without my patch, under CPython and Nuitka, and check if there's a fix needed. > I'm curious, does PySide's test suite work under Nuitka? I didn't try, but that can be done if there's a way to run PySide's test suite using a specified python implementation, then I guess I can try and run them using nuitka-run. Regards, Vincent From jpe at wingware.com Wed Feb 5 19:10:55 2014 From: jpe at wingware.com (John Ehresman) Date: Wed, 05 Feb 2014 11:10:55 -0700 Subject: [PySide] Support for 5.2 In-Reply-To: References: Message-ID: <52F27EAF.6070604@wingware.com> On 2/4/14, 10:38 PM, Srini Kommoori wrote: > Is anyone working on porting to Qt5.2? > > I just updated my mac to Mavericks and fonts are all messed up. I see > that all of them are resolved in Qt5.2. PySide only supports Qt4 right now. The workaround for the Mavericks font problem (or at least a problem with the system font) is to use: QFont.insertSubstitution(".Lucida Grande UI", "Lucida Grande") There's also another 4.8 release in the works. Cheers, John From vasure at gmail.com Wed Feb 5 21:10:43 2014 From: vasure at gmail.com (Srini Kommoori) Date: Wed, 5 Feb 2014 12:10:43 -0800 Subject: [PySide] Support for 5.2 In-Reply-To: <52F27EAF.6070604@wingware.com> References: <52F27EAF.6070604@wingware.com> Message-ID: Thanks John. I got that from search. My issue is not really with Lucida Grande support. I have custom font which is having issues. I have ton of these messages on the console. 2014-02-05 08:05:36.498 Python[25536:1107] CoreText performance note: Client called CTFontCreateWithName() using name "Open Sans" and got font with PostScript name "OpenSans". For best performance, only use PostScript names when calling this API. Seems like https://bugreports.qt-project.org/browse/QTBUG-32789 is fixed. We need to merge the fix or wait for 4.8.6 to be released. On Wed, Feb 5, 2014 at 10:10 AM, John Ehresman wrote: > On 2/4/14, 10:38 PM, Srini Kommoori wrote: > >> Is anyone working on porting to Qt5.2? >> >> I just updated my mac to Mavericks and fonts are all messed up. I see >> that all of them are resolved in Qt5.2. >> > > PySide only supports Qt4 right now. The workaround for the Mavericks font > problem (or at least a problem with the system font) is to use: > > QFont.insertSubstitution(".Lucida Grande UI", "Lucida Grande") > > There's also another 4.8 release in the works. > > Cheers, > > John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greatrgb at gmail.com Thu Feb 6 01:56:01 2014 From: greatrgb at gmail.com (Tony Barbieri) Date: Wed, 5 Feb 2014 19:56:01 -0500 Subject: [PySide] Shiboken Large Address Bug Message-ID: Hello! We had submitted a bug awhile back: https://bugreports.qt-project.org/browse/PYSIDE-103 If I find the time I'd like to work on it, but is there any chance someone can take a look at this one? It's bitten us a couple of times. Thanks so much for all the work! -- -tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.barrielle at m4x.org Thu Feb 6 09:40:15 2014 From: vincent.barrielle at m4x.org (Vincent Barrielle) Date: Thu, 06 Feb 2014 09:40:15 +0100 Subject: [PySide] PySide and the nuitka python compiler In-Reply-To: <16772053.1I9ra3XKyO@vinxyz-studio-xps-8100> References: <2868723.CjkNUiXJOV@tesla> <52F16979.6030800@wingware.com> <16772053.1I9ra3XKyO@vinxyz-studio-xps-8100> Message-ID: <39768029.KAp5Mdq62q@vinxyz-studio-xps-8100> On Wednesday 05 February 2014 10:57:02 Vincent Barrielle wrote: > > I'm curious, does PySide's test suite work under Nuitka? > > I didn't try, but that can be done if there's a way to run PySide's test suite > using a specified python implementation, then I guess I can try and run them > using nuitka-run. I ran the test suite under nuitka, and there are lots of tests not passing (~100). I hope these tests are mostly related, but I can't really tell now. Right now I suspect something is going wrong when handling multiple signal connections (as in tests/signals/multiple_connections_test.py). I'll come back to you when/if I figure out how to fix it. Regards, Vincent From rymg19 at gmail.com Thu Feb 6 21:04:35 2014 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Thu, 6 Feb 2014 14:04:35 -0600 Subject: [PySide] Shiboken Large Address Bug In-Reply-To: References: Message-ID: Well, on 64-bit systems, an unsigned long is equilavent in size to size_t(64 bits). Are you sure the Shiboken you compiled was using MSVC 64-bit? I believe Visual Studio does 32-bit by default, although I'm not sure(haven't worked with VS for a while). On Wed, Feb 5, 2014 at 6:56 PM, Tony Barbieri wrote: > Hello! > > We had submitted a bug awhile back: > > https://bugreports.qt-project.org/browse/PYSIDE-103 > > If I find the time I'd like to work on it, but is there any chance someone > can take a look at this one? It's bitten us a couple of times. > > Thanks so much for all the work! > > -- > -tony > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > > -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." -------------- next part -------------- An HTML attachment was scrubbed... URL: From greatrgb at gmail.com Thu Feb 6 21:10:47 2014 From: greatrgb at gmail.com (Tony Barbieri) Date: Thu, 6 Feb 2014 15:10:47 -0500 Subject: [PySide] Shiboken Large Address Bug In-Reply-To: References: Message-ID: Hey Ryan, Yes, size_t should be used. It looks like in the source code wrapinstance takes an unsigned long: https://qt.gitorious.org/pyside/shiboken/source/a527dd51e69b80c2d5be3a1d8cd60ab2b2616fa5:shibokenmodule/typesystem_shiboken.xml#L20 Maybe we are reading that wrong? Shouldn't wrapinstance be wrapinstance(size_t, PyObject)? I am not familiar enough with the source to say for sure. Thanks for your reply! -tony On Thu, Feb 6, 2014 at 3:04 PM, Ryan Gonzalez wrote: > Well, on 64-bit systems, an unsigned long is equilavent in size to > size_t(64 bits). Are you sure the Shiboken you compiled was using MSVC > 64-bit? I believe Visual Studio does 32-bit by default, although I'm not > sure(haven't worked with VS for a while). > > > On Wed, Feb 5, 2014 at 6:56 PM, Tony Barbieri wrote: > >> Hello! >> >> We had submitted a bug awhile back: >> >> https://bugreports.qt-project.org/browse/PYSIDE-103 >> >> If I find the time I'd like to work on it, but is there any chance >> someone can take a look at this one? It's bitten us a couple of times. >> >> Thanks so much for all the work! >> >> -- >> -tony >> >> _______________________________________________ >> PySide mailing list >> PySide at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/pyside >> >> > > > -- > Ryan > If anybody ever asks me why I prefer C++ to C, my answer will be simple: > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was > nul-terminated." > > -- -tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From greatrgb at gmail.com Thu Feb 6 21:31:38 2014 From: greatrgb at gmail.com (Tony Barbieri) Date: Thu, 6 Feb 2014 15:31:38 -0500 Subject: [PySide] Shiboken Large Address Bug In-Reply-To: References: Message-ID: Or if size_t isn't appropriate, shouldn't wrapinstance take an unsigned long long or uint64_t? I don't believe unsigned long will work for 64 bit as it's 32 bits on Windows. Should wrapinstance be changed to support all platforms? On Thu, Feb 6, 2014 at 3:10 PM, Tony Barbieri wrote: > Hey Ryan, > > Yes, size_t should be used. It looks like in the source code wrapinstance > takes an unsigned long: > > > https://qt.gitorious.org/pyside/shiboken/source/a527dd51e69b80c2d5be3a1d8cd60ab2b2616fa5:shibokenmodule/typesystem_shiboken.xml#L20 > > Maybe we are reading that wrong? Shouldn't wrapinstance be > wrapinstance(size_t, PyObject)? I am not familiar enough with the source > to say for sure. > > Thanks for your reply! > > -tony > > > On Thu, Feb 6, 2014 at 3:04 PM, Ryan Gonzalez wrote: > >> Well, on 64-bit systems, an unsigned long is equilavent in size to >> size_t(64 bits). Are you sure the Shiboken you compiled was using MSVC >> 64-bit? I believe Visual Studio does 32-bit by default, although I'm not >> sure(haven't worked with VS for a while). >> >> >> On Wed, Feb 5, 2014 at 6:56 PM, Tony Barbieri wrote: >> >>> Hello! >>> >>> We had submitted a bug awhile back: >>> >>> https://bugreports.qt-project.org/browse/PYSIDE-103 >>> >>> If I find the time I'd like to work on it, but is there any chance >>> someone can take a look at this one? It's bitten us a couple of times. >>> >>> Thanks so much for all the work! >>> >>> -- >>> -tony >>> >>> _______________________________________________ >>> PySide mailing list >>> PySide at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/pyside >>> >>> >> >> >> -- >> Ryan >> If anybody ever asks me why I prefer C++ to C, my answer will be simple: >> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was >> nul-terminated." >> >> > > > -- > -tony > -- -tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From mw_triad at users.sourceforge.net Thu Feb 6 21:26:08 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 06 Feb 2014 15:26:08 -0500 Subject: [PySide] Shiboken Large Address Bug In-Reply-To: References: Message-ID: On 2014-02-06 15:04, Ryan Gonzalez wrote: > Well, on 64-bit systems, an unsigned long is equilavent in size to > size_t(64 bits). Only on LP64 systems. Windows is not such a system. (Nor, in general, is there any guarantee about the relation between sizeof(long) and sizeof(void*).) On windows (eliding sizeof()), int == long <= void* <= long long, with the <= depending on 32- vs. 64-bit mode. -- Matthew From mw_triad at users.sourceforge.net Thu Feb 6 21:44:38 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 06 Feb 2014 15:44:38 -0500 Subject: [PySide] Shiboken Large Address Bug In-Reply-To: References: Message-ID: On 2014-02-06 15:31, Tony Barbieri wrote: > Or if size_t isn't appropriate, shouldn't wrapinstance take an unsigned > long long or uint64_t? I don't believe unsigned long will work for 64 bit > as it's 32 bits on Windows. Should wrapinstance be changed to support all > platforms? [u]intptr_t is the only "correct" type if you need to represent a pointer as an integer. Fortunately, unlike other types from C99¹ stdint.h, it looks like these are well supported (as far back as VS 2005 anyway, according to MSDN). (¹ ...which Microsoft has never made any serious effort to support prior to it being mandated in C++11.) -- Matthew From greatrgb at gmail.com Thu Feb 6 22:04:44 2014 From: greatrgb at gmail.com (Tony Barbieri) Date: Thu, 6 Feb 2014 16:04:44 -0500 Subject: [PySide] Shiboken Large Address Bug In-Reply-To: References: Message-ID: Thanks Matthew! It would be great if we could get this fixed. It's kind of a biggie for us. I would help out but I really don't know where to start. If I find the time I'll try to take a crack at it. -tony On Thu, Feb 6, 2014 at 3:44 PM, Matthew Woehlke < mw_triad at users.sourceforge.net> wrote: > On 2014-02-06 15:31, Tony Barbieri wrote: > > Or if size_t isn't appropriate, shouldn't wrapinstance take an unsigned > > long long or uint64_t? I don't believe unsigned long will work for 64 > bit > > as it's 32 bits on Windows. Should wrapinstance be changed to support > all > > platforms? > > [u]intptr_t is the only "correct" type if you need to represent a > pointer as an integer. > > Fortunately, unlike other types from C99¹ stdint.h, it looks like these > are well supported (as far back as VS 2005 anyway, according to MSDN). > > (¹ ...which Microsoft has never made any serious effort to support prior > to it being mandated in C++11.) > > -- > Matthew > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > -- -tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From mw_triad at users.sourceforge.net Thu Feb 6 22:37:36 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 06 Feb 2014 16:37:36 -0500 Subject: [PySide] Shiboken Large Address Bug In-Reply-To: References: Message-ID: On 2014-02-06 16:04, Tony Barbieri wrote: > It would be great if we could get this fixed. It's kind of a biggie for > us. I would help out but I really don't know where to start. If I find > the time I'll try to take a crack at it. Alas, the same (both your knowledge and time points) is true for me :-). At least, I might have a better /general/ knowledge of the code base, but not these specifics. That said, my main concern would be what (if any) compatibility implications a change will have (e.g. I think it may require that existing bindings are regenerated and rebuild, or else they will have runtime errors), and to what extent that's a concern vs. acceptable to address the issue. (Maybe leaving the old function, marked deprecated, and adding an overload with the correct signature could fix the issue without a BIC.) -- Matthew From greatrgb at gmail.com Fri Feb 7 00:52:30 2014 From: greatrgb at gmail.com (Tony Barbieri) Date: Thu, 6 Feb 2014 18:52:30 -0500 Subject: [PySide] Shiboken Large Address Bug In-Reply-To: References: Message-ID: Not the most elegant solution but it seems that unsigned long long is already an acceptable primitive supported by shiboken. I really have no clue how to add in new primitive types or the implications that involves. Would this be a suitable solution for the next official release until more time can be devoted to fixing it properly? On Thu, Feb 6, 2014 at 4:37 PM, Matthew Woehlke < mw_triad at users.sourceforge.net> wrote: > On 2014-02-06 16:04, Tony Barbieri wrote: > > It would be great if we could get this fixed. It's kind of a biggie for > > us. I would help out but I really don't know where to start. If I find > > the time I'll try to take a crack at it. > > Alas, the same (both your knowledge and time points) is true for me :-). > At least, I might have a better /general/ knowledge of the code base, > but not these specifics. > > That said, my main concern would be what (if any) compatibility > implications a change will have (e.g. I think it may require that > existing bindings are regenerated and rebuild, or else they will have > runtime errors), and to what extent that's a concern vs. acceptable to > address the issue. (Maybe leaving the old function, marked deprecated, > and adding an overload with the correct signature could fix the issue > without a BIC.) > > -- > Matthew > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > -- -tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucericml at gmail.com Fri Feb 7 03:59:28 2014 From: lucericml at gmail.com (Luc-Eric Rousseau) Date: Thu, 6 Feb 2014 21:59:28 -0500 Subject: [PySide] Shiboken Large Address Bug In-Reply-To: References: Message-ID: we have used unsigned long long in our build (Autodesk Maya), as stated here: https://bugreports.qt-project.org/browse/PYSIDE-191 you could make that signature ifdef'ed to only occur on windows x64 if you're worried about binary compatibility. There are very few 64-bit python/qt/pyside users on Windows, as proven by how long this code has been around. Nobody else is affected. But on windows x64, it's totally broken and the bug will happen all the time on WIndows 8, because it's started to allocate memory above the 4 gig fold by default. On Thu, Feb 6, 2014 at 6:52 PM, Tony Barbieri wrote: > Not the most elegant solution but it seems that unsigned long long is > already an acceptable primitive supported by shiboken. I really have no > clue how to add in new primitive types or the implications that involves. > Would this be a suitable solution for the next official release until more > time can be devoted to fixing it properly? > > > On Thu, Feb 6, 2014 at 4:37 PM, Matthew Woehlke > wrote: >> >> On 2014-02-06 16:04, Tony Barbieri wrote: >> > It would be great if we could get this fixed. It's kind of a biggie for >> > us. I would help out but I really don't know where to start. If I find >> > the time I'll try to take a crack at it. >> >> Alas, the same (both your knowledge and time points) is true for me :-). >> At least, I might have a better /general/ knowledge of the code base, >> but not these specifics. >> >> That said, my main concern would be what (if any) compatibility >> implications a change will have (e.g. I think it may require that >> existing bindings are regenerated and rebuild, or else they will have >> runtime errors), and to what extent that's a concern vs. acceptable to >> address the issue. (Maybe leaving the old function, marked deprecated, >> and adding an overload with the correct signature could fix the issue >> without a BIC.) From greatrgb at gmail.com Fri Feb 7 15:09:57 2014 From: greatrgb at gmail.com (Tony Barbieri) Date: Fri, 7 Feb 2014 09:09:57 -0500 Subject: [PySide] Shiboken Large Address Bug In-Reply-To: References: Message-ID: Thanks for your response Luc-Eric! I think that's what we'll do for the time being in our build, but it would be great if it could make it into one of the upcoming releases officially. Best, -tony On Thu, Feb 6, 2014 at 9:59 PM, Luc-Eric Rousseau wrote: > we have used unsigned long long in our build (Autodesk Maya), as stated > here: > https://bugreports.qt-project.org/browse/PYSIDE-191 > > you could make that signature ifdef'ed to only occur on windows x64 if > you're worried about binary compatibility. There are very few 64-bit > python/qt/pyside users on Windows, as proven by how long this code has > been around. Nobody else is affected. But on windows x64, it's > totally broken and the bug will happen all the time on WIndows 8, > because it's started to allocate memory above the 4 gig fold by > default. > > On Thu, Feb 6, 2014 at 6:52 PM, Tony Barbieri wrote: > > Not the most elegant solution but it seems that unsigned long long is > > already an acceptable primitive supported by shiboken. I really have no > > clue how to add in new primitive types or the implications that involves. > > Would this be a suitable solution for the next official release until > more > > time can be devoted to fixing it properly? > > > > > > On Thu, Feb 6, 2014 at 4:37 PM, Matthew Woehlke > > wrote: > >> > >> On 2014-02-06 16:04, Tony Barbieri wrote: > >> > It would be great if we could get this fixed. It's kind of a biggie > for > >> > us. I would help out but I really don't know where to start. If I > find > >> > the time I'll try to take a crack at it. > >> > >> Alas, the same (both your knowledge and time points) is true for me :-). > >> At least, I might have a better /general/ knowledge of the code base, > >> but not these specifics. > >> > >> That said, my main concern would be what (if any) compatibility > >> implications a change will have (e.g. I think it may require that > >> existing bindings are regenerated and rebuild, or else they will have > >> runtime errors), and to what extent that's a concern vs. acceptable to > >> address the issue. (Maybe leaving the old function, marked deprecated, > >> and adding an overload with the correct signature could fix the issue > >> without a BIC.) > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > -- -tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From mw_triad at users.sourceforge.net Fri Feb 7 17:07:00 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 07 Feb 2014 11:07:00 -0500 Subject: [PySide] Shiboken Large Address Bug In-Reply-To: References: Message-ID: On 2014-02-06 21:59, Luc-Eric Rousseau wrote: > we have used unsigned long long in our build (Autodesk Maya), as stated here: > https://bugreports.qt-project.org/browse/PYSIDE-191 > > you could make that signature ifdef'ed to only occur on windows x64 if > you're worried about binary compatibility. Actually, that (or better, having a conditional tree to select an appropriate type whose size == sizeof(void*)) isn't a bad idea. So all platforms *except* Windows x64 will continue to use 'long' and be unchanged. If anyone has patches, do please share them... -- Matthew From jpe at wingware.com Fri Feb 7 17:57:27 2014 From: jpe at wingware.com (John Ehresman) Date: Fri, 07 Feb 2014 09:57:27 -0700 Subject: [PySide] Shiboken Large Address Bug In-Reply-To: References: Message-ID: <52F51077.90409@wingware.com> On 2/7/14, 9:07 AM, Matthew Woehlke wrote: > On 2014-02-06 21:59, Luc-Eric Rousseau wrote: >> we have used unsigned long long in our build (Autodesk Maya), as stated here: >> https://bugreports.qt-project.org/browse/PYSIDE-191 >> >> you could make that signature ifdef'ed to only occur on windows x64 if >> you're worried about binary compatibility. > > Actually, that (or better, having a conditional tree to select an > appropriate type whose size == sizeof(void*)) isn't a bad idea. > > So all platforms *except* Windows x64 will continue to use 'long' and be > unchanged. > > If anyone has patches, do please share them... I think this is a bug on Windows x64 and can be fixed without preserving the old behavior. It could be done through an ifdef, conditional tree, or using unsigned long long with an additional range check on 32 bit systems. Arguably this could also accept PyCObject or PyCapsule instances. The best way to move a fix like this forward is to submit a change into the Gerrit code integration system for pyside. John From salvatore at iovene.com Sat Feb 8 15:55:14 2014 From: salvatore at iovene.com (Salvatore Iovene) Date: Sat, 8 Feb 2014 16:55:14 +0200 Subject: [PySide] PySide/QtCore.so: undefined symbol: _ZN8Shiboken6Object4hashEP7_object Message-ID: Hi, I'm using PySide 1.1.1. I know it's old, but newer versions cause a segmentation fault somewhere in my stack. 1.1.1 works well on my production server, but now that I was setting up a new development environment, I ran into a problem installing PySide. It's installed via `pip` in a Ubuntu 12.04 chroot environment, with Python 2.7.4. This shows the error that I'm getting: Python 2.7.4 (default, Apr 19 2013, 18:32:33) [GCC 4.7.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from PySide import QtCore Traceback (most recent call last): File "", line 1, in ImportError: /usr/local/lib/python2.7/dist-packages/PySide/QtCore.so: undefined symbol: _ZN8Shiboken6Object4hashEP7_object The same error is shown during the build process, near the end. I've seen a few references to this when searching with Google, but I couldn't solve the problem. Can anyone please help me figure out what's missing? Thank you! -- Salvatore Iovene Personal website: http://iovene.com/ Founder of AstroBin: http://astrobin.com/ From backup.rlacko at gmail.com Sun Feb 9 09:05:34 2014 From: backup.rlacko at gmail.com (Roman Lacko) Date: Sun, 9 Feb 2014 09:05:34 +0100 Subject: [PySide] PySide/QtCore.so: undefined symbol: _ZN8Shiboken6Object4hashEP7_object In-Reply-To: References: Message-ID: Dňa 8.2.2014 15:55 používateľ "Salvatore Iovene" napísal: > > Hi, > I'm using PySide 1.1.1. I know it's old, but newer versions cause a > segmentation fault somewhere in my stack. > 1.1.1 works well on my production server, but now that I was setting > up a new development environment, I ran into a problem installing > PySide. > > It's installed via `pip` in a Ubuntu 12.04 chroot environment, with > Python 2.7.4. hi, Can you send here the pip build output log ? thanks Roman > > This shows the error that I'm getting: > > Python 2.7.4 (default, Apr 19 2013, 18:32:33) > [GCC 4.7.3] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> from PySide import QtCore > Traceback (most recent call last): > File "", line 1, in > ImportError: /usr/local/lib/python2.7/dist-packages/PySide/QtCore.so: > undefined symbol: _ZN8Shiboken6Object4hashEP7_object > > The same error is shown during the build process, near the end. > > I've seen a few references to this when searching with Google, but I > couldn't solve the problem. > > Can anyone please help me figure out what's missing? > > Thank you! > > -- > Salvatore Iovene > > Personal website: http://iovene.com/ > Founder of AstroBin: http://astrobin.com/ > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside -------------- next part -------------- An HTML attachment was scrubbed... URL: From greatrgb at gmail.com Mon Feb 10 02:46:25 2014 From: greatrgb at gmail.com (Tony Barbieri) Date: Sun, 9 Feb 2014 20:46:25 -0500 Subject: [PySide] Odd Build Issue PySide 1.2.1 CentOS 6.2 Message-ID: Having a strange issue: File "", line 1 from distutils import sysconfig; \ ^ SyntaxError: unexpected character after line continuation character When running setup.py. Appears to point to how the CMakeLists.txt are setup. Not sure why I am hitting this but it seems like no one else has? -- -tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From greatrgb at gmail.com Mon Feb 10 03:12:29 2014 From: greatrgb at gmail.com (Tony Barbieri) Date: Sun, 9 Feb 2014 21:12:29 -0500 Subject: [PySide] Odd Build Issue PySide 1.2.1 CentOS 6.2 In-Reply-To: References: Message-ID: Got it. It appears the tar.gz on PyPi ( https://pypi.python.org/packages/source/P/PySide/PySide-1.2.1.tar.gz) contains Windows line endings. If anyone else hits this just change the FindPythonInterpWithDebug.cmake and CMakeLists.txt files to have Unix line-endings. On Sun, Feb 9, 2014 at 8:46 PM, Tony Barbieri wrote: > Having a strange issue: > > File "", line 1 > from distutils import sysconfig; \ > ^ > SyntaxError: unexpected character after line continuation character > > When running setup.py. Appears to point to how the CMakeLists.txt are > setup. Not sure why I am hitting this but it seems like no one else has? > > -- > -tony > -- -tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From greatrgb at gmail.com Mon Feb 10 04:34:13 2014 From: greatrgb at gmail.com (Tony Barbieri) Date: Sun, 9 Feb 2014 22:34:13 -0500 Subject: [PySide] (no subject) Message-ID: Hello, I've build PySide 1.2.1 on CentOS 6.2 with Qt 4.7.4 and python 2.6 using: python setup.py build --qmake=~/qt/4.7.4/bin/qmake --standalone Everything built fine but when I run: from PySide import QtCore, QtGui I get the following error: ImportError: libpyside-python2.6.so.1.2: cannot open shared object file: No such file or directory Any clue as to what would cause this? Any help is appreciated, -- -tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From greatrgb at gmail.com Mon Feb 10 04:36:31 2014 From: greatrgb at gmail.com (Tony Barbieri) Date: Sun, 9 Feb 2014 22:36:31 -0500 Subject: [PySide] libpyside-python2.6.so.1.2 ImportError Message-ID: I apologize for sending that last email out without a subject. I included a subject in this so it could be searched later if needed. I've build PySide 1.2.1 on CentOS 6.2 with Qt 4.7.4 and python 2.6 using: python setup.py build --qmake=~/qt/4.7.4/bin/qmake --standalone Everything built fine but when I run: from PySide import QtCore, QtGui I get the following error: ImportError: libpyside-python2.6.so.1.2: cannot open shared object file: No such file or directory Any clue as to what would cause this? Any help is appreciated, -- -tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From greatrgb at gmail.com Mon Feb 10 06:09:39 2014 From: greatrgb at gmail.com (Tony Barbieri) Date: Mon, 10 Feb 2014 00:09:39 -0500 Subject: [PySide] libpyside-python2.6.so.1.2 ImportError In-Reply-To: References: Message-ID: I'm guessing this happened because I did not run setup.py install which I assume would run patchelf and update the RPATH? If so, could running patchelf be part of the build process for the libs that are in the pyside_package folder? It would seem they only need RPATH=$ORIGIN since the pyside_package folder is a flat list of all of the libraries PySide uses. On Sun, Feb 9, 2014 at 10:36 PM, Tony Barbieri wrote: > I apologize for sending that last email out without a subject. I included > a subject in this so it could be searched later if needed. > > > I've build PySide 1.2.1 on CentOS 6.2 with Qt 4.7.4 and python 2.6 using: > > python setup.py build --qmake=~/qt/4.7.4/bin/qmake --standalone > > Everything built fine but when I run: > > from PySide import QtCore, QtGui I get the following error: > > ImportError: libpyside-python2.6.so.1.2: cannot open shared object file: > No such file or directory > > Any clue as to what would cause this? > > Any help is appreciated, > > -- > -tony > -- -tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From salvatore at iovene.com Mon Feb 10 07:17:32 2014 From: salvatore at iovene.com (Salvatore Iovene) Date: Mon, 10 Feb 2014 08:17:32 +0200 Subject: [PySide] PySide/QtCore.so: undefined symbol: _ZN8Shiboken6Object4hashEP7_object In-Reply-To: References: Message-ID: Hi Roman, On Sun, Feb 9, 2014 at 10:05 AM, Roman Lacko wrote: > > Dňa 8.2.2014 15:55 používateľ "Salvatore Iovene" > napísal: > > >> >> Hi, >> I'm using PySide 1.1.1. I know it's old, but newer versions cause a >> segmentation fault somewhere in my stack. >> 1.1.1 works well on my production server, but now that I was setting >> up a new development environment, I ran into a problem installing >> PySide. >> >> It's installed via `pip` in a Ubuntu 12.04 chroot environment, with >> Python 2.7.4. > > hi, > Can you send here the pip build output log ? Let me include just the final part at first, because I have it at hand. Later I'll do another build if you require. This seems to be relevant: changing mode of build/scripts-2.7/pyside_postinstall.py from 644 to 755 File "/usr/local/lib/python2.7/dist-packages/pysideuic/port_v3/proxy_base.py", line 26 class ProxyBase(metaclass=ProxyType): ^ SyntaxError: invalid syntax changing mode of /usr/local/bin/pyside_postinstall.py to 755 Installing pyside-uic script to /usr/local/bin Executing post install script '/usr/bin/pyside_postinstall.py'... Traceback (most recent call last): File "/usr/bin/pyside_postinstall.py", line 84, in install_linux from PySide import QtCore ImportError: /usr/local/lib/python2.7/dist-packages/PySide/QtCore.so: undefined symbol: _ZN8Shiboken6Object4hashEP7_object PySide package found in /usr/local/lib/python2.7/dist-packages/PySide... Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtHelp.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtWebKit.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtCore.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtGui.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtOpenGL.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtUiTools.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/shiboken to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtDeclarative.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtNetwork.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtScriptTools.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtSql.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtXmlPatterns.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtScript.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtXml.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtTest.so to /usr/local/lib/python2.7/dist-packages/PySide. Patched rpath in /usr/local/lib/python2.7/dist-packages/PySide/QtSvg.so to /usr/local/lib/python2.7/dist-packages/PySide. The PySide package not installed: None Successfully installed PySide Cleaning up... In the rest of the build process I didn't notice any error, save the occasional warning. Thanks, Salvatore. -- Salvatore Iovene Personal website: http://iovene.com/ Founder of AstroBin: http://astrobin.com/ From backup.rlacko at gmail.com Mon Feb 10 08:47:19 2014 From: backup.rlacko at gmail.com (Roman Lacko) Date: Mon, 10 Feb 2014 08:47:19 +0100 Subject: [PySide] libpyside-python2.6.so.1.2 ImportError In-Reply-To: References: Message-ID: 2014-02-10 6:09 GMT+01:00 Tony Barbieri : > I'm guessing this happened because I did not run setup.py install which I > assume would run patchelf and update the RPATH? If so, could running > patchelf be part of the build process for the libs that are in the > pyside_package folder? It would seem they only need RPATH=$ORIGIN since > the pyside_package folder is a flat list of all of the libraries PySide > uses. > Hi Tony, The patchelf should be called only at install time. The pyside_package is temporary build folder and running patchelf at build time will change the pyside libraries so the RPATH will point to temporary build folder which will be deleted. Can you explain why you need import PySide from temporary build folder ? Thanks Roman [1] https://github.com/PySide/pyside-setup > > > On Sun, Feb 9, 2014 at 10:36 PM, Tony Barbieri wrote: > >> I apologize for sending that last email out without a subject. I >> included a subject in this so it could be searched later if needed. >> >> >> I've build PySide 1.2.1 on CentOS 6.2 with Qt 4.7.4 and python 2.6 using: >> >> python setup.py build --qmake=~/qt/4.7.4/bin/qmake --standalone >> >> Everything built fine but when I run: >> >> from PySide import QtCore, QtGui I get the following error: >> >> ImportError: libpyside-python2.6.so.1.2: cannot open shared object file: >> No such file or directory >> >> Any clue as to what would cause this? >> >> Any help is appreciated, >> >> -- >> -tony >> > > > > -- > -tony > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.barrielle at m4x.org Mon Feb 10 11:43:17 2014 From: vincent.barrielle at m4x.org (Vincent Barrielle) Date: Mon, 10 Feb 2014 11:43:17 +0100 Subject: [PySide] PySide and the nuitka python compiler In-Reply-To: <52F16979.6030800@wingware.com> References: <2868723.CjkNUiXJOV@tesla> <52F16979.6030800@wingware.com> Message-ID: <1430657.pUSjlCtDkI@vinxyz-studio-xps-8100> Hello, On Tuesday 04 February 2014 15:28:09 you wrote: > I'm curious, does PySide's test suite work under Nuitka? Running the tests using my previous patches resulted in lots of failed tests, so I've been rewritting my patches in order to fix these. You'll find attached patches replacing the precedent ones, that solve some troubles under nuitka (not all of them though), but do not affect the normal path too much (there are one shiboken and one pyside tests that no longer pass). I intend to to investigate these non-passing tests, but this makes this set of patches more reliable than the previous one. These patches also include the possibility to run PySide's tests under nuitka, so anyone willing to test is welcome. The current status is that 50% of pyside tests pass when run under nuitka. Even though this looks like a bad score, it enabled me to run a moderately complicated GUI app under nuitka. Best, Vincent -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-use-of-the-shiboken-s-method-checking-code.patch Type: text/x-patch Size: 7795 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-method-function-checking-methods-compatible-wi.patch Type: text/x-patch Size: 6096 bytes Desc: not available URL: From greatrgb at gmail.com Mon Feb 10 15:38:43 2014 From: greatrgb at gmail.com (Tony Barbieri) Date: Mon, 10 Feb 2014 09:38:43 -0500 Subject: [PySide] libpyside-python2.6.so.1.2 ImportError In-Reply-To: References: Message-ID: Hi Roman, I didn't want to use the temp directory but I also didn't want to use the typical install method either. I was hoping to have a fully portable PySide build after building with --standalone so I could manually move it to our shared network installation directory all of our Linux machines have access too. Setting RPATH=$ORIGIN seems to allow for this but if I run the install method it would have set RPATH to the absolute installation path, correct? It seems running patchelf manually and setting RPATH=$ORIGIN allows me to manually deploy PySide anywhere I choose, I wrongly assumed that running --standalone wouldn't require running the install and allow me to freely decide where to put the PySide build. Anyhow, everything appears to be working fine. Thanks for your time! -tony On Mon, Feb 10, 2014 at 2:47 AM, Roman Lacko wrote: > 2014-02-10 6:09 GMT+01:00 Tony Barbieri : > > I'm guessing this happened because I did not run setup.py install which I >> assume would run patchelf and update the RPATH? If so, could running >> patchelf be part of the build process for the libs that are in the >> pyside_package folder? It would seem they only need RPATH=$ORIGIN since >> the pyside_package folder is a flat list of all of the libraries PySide >> uses. >> > > Hi Tony, > > The patchelf should be called only at install time. The pyside_package is > temporary build folder and running patchelf at build time will change the > pyside libraries so the RPATH will point to temporary build folder which > will be deleted. Can you explain why you need import PySide from temporary > build folder ? > > Thanks > Roman > > [1] https://github.com/PySide/pyside-setup > > >> >> >> On Sun, Feb 9, 2014 at 10:36 PM, Tony Barbieri wrote: >> >>> I apologize for sending that last email out without a subject. I >>> included a subject in this so it could be searched later if needed. >>> >>> >>> I've build PySide 1.2.1 on CentOS 6.2 with Qt 4.7.4 and python 2.6 using: >>> >>> python setup.py build --qmake=~/qt/4.7.4/bin/qmake --standalone >>> >>> Everything built fine but when I run: >>> >>> from PySide import QtCore, QtGui I get the following error: >>> >>> ImportError: libpyside-python2.6.so.1.2: cannot open shared object file: >>> No such file or directory >>> >>> Any clue as to what would cause this? >>> >>> Any help is appreciated, >>> >>> -- >>> -tony >>> >> >> >> >> -- >> -tony >> >> _______________________________________________ >> PySide mailing list >> PySide at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/pyside >> >> > -- -tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From harold.mills at gmail.com Tue Feb 11 16:56:59 2014 From: harold.mills at gmail.com (Harold Mills) Date: Tue, 11 Feb 2014 10:56:59 -0500 Subject: [PySide] QListWidget problem Message-ID: I'm having a problem with the PySide QListWidget class, described in detail in the example program below. Briefly, a list configured to allow contiguous selections (but not single selections) always scrolls to the top when I delete an item from it using the takeItem method. If this is happening because I'm doing something wrong, or if there is a simple workaround for the problem, please let me know. Should I file a bug report somewhere? Thanks, Harold Mills ''' This program demonstrates a problem I've encountered with the PySide QListWidget class, using PySide 1.2.1, Qt 4.8.5, and Mac OS X 10.8.5. To see the problem: 1. Run the program. 2. Scroll down the list. 3. Click on a list item to select it. 4. Press the "Delete" button. When the item is deleted, the list scrolls to the top. I believe that it should not scroll to the top. The problem appears to have something to do with setting the selection mode of the list to QAbstractItemView.ContiguousSelection. If one instead sets the selection mode to QAbstractItemView.SingleSelection, the problem does not occur. Harold Mills 11 February 2014 ''' import sys from PySide.QtGui import ( QAbstractItemView, QApplication, QListWidget, QMainWindow, QPushButton, QVBoxLayout, QWidget) class TestWindow(QMainWindow): def __init__(self): super(TestWindow, self).__init__() self.setWindowTitle('PySide QListWidget Problem') self._list = QListWidget(self) self._list.insertItems(0, [str(i + 1) for i in xrange(50)]) # This line seems to be the problem. Change "Contiguous" to "Single" # and item deletion does not cause the list to scroll to the top. self._list.setSelectionMode(QAbstractItemView.ContiguousSelection) button = QPushButton('Delete', self) button.clicked.connect(self._on_button_clicked) box = QVBoxLayout() box.addWidget(self._list) box.addWidget(button) widget = QWidget() widget.setLayout(box) self.setCentralWidget(widget) def _on_button_clicked(self): l = self._list for item in l.selectedItems(): l.takeItem(l.row(item)) def _main(): app = QApplication(sys.argv) window = TestWindow() window.show() window.raise_() app.exec_() sys.exit() if __name__ == '__main__': _main() -------------- next part -------------- An HTML attachment was scrubbed... URL: From akabaila at pcug.org.au Wed Feb 12 09:00:10 2014 From: akabaila at pcug.org.au (Algis Kabaila) Date: Wed, 12 Feb 2014 19:00:10 +1100 Subject: [PySide] Simple PySide GUI for Python Program Message-ID: <1505294.DVRXntWaRp@supremo> On January 24 started a thread, entitled "using QProcess to run a python function." It was a discussion about communication between an extant CLI python program and a GUI to be developed for it. I found it interesting, but was disappointed that in the end no coded examples were offered. In the simplicissimus bunch of elementary tutorials that I wrote, ref: http://qt-project.org/wiki/PySide-Newbie-Tutorials there is one tutorial, named "Engineering Application", ref: http://qt-project.org/wiki/PySide_Engineering_Application which is an example of a simple interface between a CLI style Python program (ncrunch.py) and its GUI (truss.py). Whilst the text of these tutorials has not been updated yet, the programs have been updated and placed in one repository on "github", named "tuts4pyside" ("Owner" OldAl). All the blobs in the repository can be cloned by anybody with the git command: git clone https://github.com/OldAl/tuts4pyside To run the programs one needs to install numpy (python-numpy) in addition to pyside. The CLI program can be run, after changing the work directory to "tuts4pyside/truss" in your local repository, with the command python ncrunch.py Alternatively, the GUI version can be run by python truss.py Refer to README.md in the same directory for further information. The "secret" of this dual entry to the program is a little function "printline". When the ncrunch.py is started from CLI, printline prints on stdout. When ncrunch.py is used as a module of "truss.py", printline is passed as a parameter to ncrunch.py, where it prints on the "Solution Page" of the GUI. Simple, when one thinks about it. It seems to me that many users of python programs are interested in graphical tools, such as PySide or PyQt, mainly because they want to be able to provide GUIs for their python programs. For that reason alone, it is a topic worthy of discussion. If required or desired, I can be contacted by email on this list or by private email. All feedback is appreciated. I live in Canberra, Australia, where I can also be contacted directly. Last, but not least, I want to thank Aaron Richiger who was so generous with his time and his expert advice before I was put out of action by a stroke some 6 months ago. Yes, I have mostly recovered. Also, I wish to thank "github" for hosting free of charge repositories for open source programs, including "tuts4pyside". OldAl (Al. Kabaila) From andyfaff at gmail.com Fri Feb 14 10:07:36 2014 From: andyfaff at gmail.com (Andrew Nelson) Date: Fri, 14 Feb 2014 20:07:36 +1100 Subject: [PySide] Qabstracttablemodel supplying multiple Qtableviews. Message-ID: Dear list, I have a single dataset that I want to display subsets of in three different Qtableview's. At the moment I have 3 different model classes, one for each Qtableview, that extend Qabstracttablemodel. However, editing these Qtableview's causes the model (dataset) to grow and I have to insert rows. It is not a problem to grow the model that underlies that Qtableview, but how do I inform the two other model classes/table views that the dataset has grown? It seems wasteful to me to have three different Qabstracttablemodel's, when a single Qabstracttablemodel should suffice for all three Qtableview's. The dataset that is displayed in each of the datasets is the same, it's just that the views are looking at different subsets of the same thing. It seems to me that if I could know which Qtableview is querying the Qabstracttablemodel, then I would only need to have one model class. It would then be easy to grow the models when the dataset is edited. Can anyone provide suggestions of the cleanest way of implementing this system? cheers, Andrew. -- _____________________________________ Dr. Andrew Nelson _____________________________________ From sean at seanfisk.com Fri Feb 14 20:01:25 2014 From: sean at seanfisk.com (Sean Fisk) Date: Fri, 14 Feb 2014 14:01:25 -0500 Subject: [PySide] Support for 5.2 In-Reply-To: References: <52F27EAF.6070604@wingware.com> Message-ID: We are having an issue where embedded fonts (i.e., from a QRC file) are not loading properly on OS X Mavericks. Srini, I can't tell for certain based on your description, but it might be the issue you are having too. We are using py2app to distribute our application. Although this is not a solution to the bug, we were able to work around the issue by including the fonts as data files with py2app. This works because it loads the font from an "external" file instead of an embedded resource. If that is an option for you and you would like to adapt our code, I would be happy to provide it. Cheers, -- Sean Fisk On Wed, Feb 5, 2014 at 3:10 PM, Srini Kommoori wrote: > Thanks John. I got that from search. My issue is not really with Lucida > Grande support. I have custom font which is having issues. I have ton of > these messages on the console. > > 2014-02-05 08:05:36.498 Python[25536:1107] CoreText performance note: > Client called CTFontCreateWithName() using name "Open Sans" and got font > with PostScript name "OpenSans". For best performance, only use PostScript > names when calling this API. > > Seems like https://bugreports.qt-project.org/browse/QTBUG-32789 is fixed. > We need to merge the fix or wait for 4.8.6 to be released. > > > > > On Wed, Feb 5, 2014 at 10:10 AM, John Ehresman wrote: > >> On 2/4/14, 10:38 PM, Srini Kommoori wrote: >> >>> Is anyone working on porting to Qt5.2? >>> >>> I just updated my mac to Mavericks and fonts are all messed up. I see >>> that all of them are resolved in Qt5.2. >>> >> >> PySide only supports Qt4 right now. The workaround for the Mavericks >> font problem (or at least a problem with the system font) is to use: >> >> QFont.insertSubstitution(".Lucida Grande UI", "Lucida Grande") >> >> There's also another 4.8 release in the works. >> >> Cheers, >> >> John >> >> > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasure at gmail.com Fri Feb 14 21:54:18 2014 From: vasure at gmail.com (Srini Kommoori) Date: Fri, 14 Feb 2014 12:54:18 -0800 Subject: [PySide] Support for 5.2 In-Reply-To: References: <52F27EAF.6070604@wingware.com> Message-ID: Sean, Thanks for reaching out. I am also in the process of building QFontDatabase manually. Yes. It would great if you could share your code snippet on how you are handling this. thanks, -Srini On Fri, Feb 14, 2014 at 11:01 AM, Sean Fisk wrote: > We are having an issue where embedded fonts (i.e., from a QRC file) are > not loading properly on OS X Mavericks. Srini, I can’t tell for certain > based on your description, but it might be the issue you are having too. > > We are using py2app to distribute our > application. Although this is not a solution to the bug, we were able to > work around the issue by including the fonts as data files with py2app. > This works because it loads the font from an “external” file instead of an > embedded resource. > > If that is an option for you and you would like to adapt our code, I would > be happy to provide it. > > Cheers, > > > -- > Sean Fisk > > > On Wed, Feb 5, 2014 at 3:10 PM, Srini Kommoori wrote: > >> Thanks John. I got that from search. My issue is not really with Lucida >> Grande support. I have custom font which is having issues. I have ton of >> these messages on the console. >> >> 2014-02-05 08:05:36.498 Python[25536:1107] CoreText performance note: >> Client called CTFontCreateWithName() using name "Open Sans" and got font >> with PostScript name "OpenSans". For best performance, only use PostScript >> names when calling this API. >> >> Seems like https://bugreports.qt-project.org/browse/QTBUG-32789 is >> fixed. We need to merge the fix or wait for 4.8.6 to be released. >> >> >> >> >> On Wed, Feb 5, 2014 at 10:10 AM, John Ehresman wrote: >> >>> On 2/4/14, 10:38 PM, Srini Kommoori wrote: >>> >>>> Is anyone working on porting to Qt5.2? >>>> >>>> I just updated my mac to Mavericks and fonts are all messed up. I see >>>> that all of them are resolved in Qt5.2. >>>> >>> >>> PySide only supports Qt4 right now. The workaround for the Mavericks >>> font problem (or at least a problem with the system font) is to use: >>> >>> QFont.insertSubstitution(".Lucida Grande UI", "Lucida Grande") >>> >>> There's also another 4.8 release in the works. >>> >>> Cheers, >>> >>> John >>> >>> >> >> _______________________________________________ >> PySide mailing list >> PySide at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/pyside >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at seanfisk.com Mon Feb 17 01:55:33 2014 From: sean at seanfisk.com (Sean Fisk) Date: Sun, 16 Feb 2014 19:55:33 -0500 Subject: [PySide] Support for 5.2 In-Reply-To: References: <52F27EAF.6070604@wingware.com> Message-ID: Hi Srini, I am waiting for members of my team to test out my solution to make sure I didn't break anything on platforms other than Mac OS X. That should happen tomorrow, and I will be able to send you the snippet. I don't want to give you broken code :) Cheers, -- Sean Fisk On Fri, Feb 14, 2014 at 3:54 PM, Srini Kommoori wrote: > Sean, > > Thanks for reaching out. I am also in the process of building > QFontDatabase manually. > > Yes. It would great if you could share your code snippet on how you are > handling this. > > thanks, > -Srini > > > On Fri, Feb 14, 2014 at 11:01 AM, Sean Fisk wrote: > >> We are having an issue where embedded fonts (i.e., from a QRC file) are >> not loading properly on OS X Mavericks. Srini, I can't tell for certain >> based on your description, but it might be the issue you are having too. >> >> We are using py2app to distribute our >> application. Although this is not a solution to the bug, we were able to >> work around the issue by including the fonts as data files with py2app. >> This works because it loads the font from an "external" file instead of an >> embedded resource. >> >> If that is an option for you and you would like to adapt our code, I >> would be happy to provide it. >> >> Cheers, >> >> >> -- >> Sean Fisk >> >> >> On Wed, Feb 5, 2014 at 3:10 PM, Srini Kommoori wrote: >> >>> Thanks John. I got that from search. My issue is not really with Lucida >>> Grande support. I have custom font which is having issues. I have ton of >>> these messages on the console. >>> >>> 2014-02-05 08:05:36.498 Python[25536:1107] CoreText performance note: >>> Client called CTFontCreateWithName() using name "Open Sans" and got font >>> with PostScript name "OpenSans". For best performance, only use PostScript >>> names when calling this API. >>> >>> Seems like https://bugreports.qt-project.org/browse/QTBUG-32789 is >>> fixed. We need to merge the fix or wait for 4.8.6 to be released. >>> >>> >>> >>> >>> On Wed, Feb 5, 2014 at 10:10 AM, John Ehresman wrote: >>> >>>> On 2/4/14, 10:38 PM, Srini Kommoori wrote: >>>> >>>>> Is anyone working on porting to Qt5.2? >>>>> >>>>> I just updated my mac to Mavericks and fonts are all messed up. I see >>>>> that all of them are resolved in Qt5.2. >>>>> >>>> >>>> PySide only supports Qt4 right now. The workaround for the Mavericks >>>> font problem (or at least a problem with the system font) is to use: >>>> >>>> QFont.insertSubstitution(".Lucida Grande UI", "Lucida Grande") >>>> >>>> There's also another 4.8 release in the works. >>>> >>>> Cheers, >>>> >>>> John >>>> >>>> >>> >>> _______________________________________________ >>> PySide mailing list >>> PySide at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/pyside >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at seanfisk.com Tue Feb 18 23:38:39 2014 From: sean at seanfisk.com (Sean Fisk) Date: Tue, 18 Feb 2014 17:38:39 -0500 Subject: [PySide] Support for 5.2 In-Reply-To: References: <52F27EAF.6070604@wingware.com> Message-ID: Hi Srini, Here is our py2app configuration dictionary: 'py2app': { # ... 'resources': [ # Part of a workaround for # 'resources/fonts', # project directory which contains our fonts ] } Here is our module responsible for font loading. # fonts.py"""Initialize fonts embedded using the Qt resource system.""" import sysimport loggingfrom glob import iglobimport platform from PySide import QtCore, QtGui logger = logging.getLogger(__name__) def _load_font(font_path): """Load a font from a path. :param font_path: path to the font; can be a filesystem or resource path :type font_path: :class:`str` """ # It's a tough deciding what to do when a font can't be loaded. If it # can't, it's an error because we are writing the application to work with # our own custom fonts. However, custom fonts are not necessary for the # application to achieve its purpose. Because the application will still be # useful without custom fonts loaded, we are choosing to report this as an # error but still let the program continue running. font_id = QtGui.QFontDatabase.addApplicationFont(font_path) if font_id == -1: logger.error('Could not load font from path: ' + font_path) return # It's possible that a font can be loaded correctly (i.e., it has a # font_id) but cannot be used correctly. In my opinion, this # constitutes a bug in Qt. The workaround is to add this extra check to # make sure that font can /actually/ be used by calling exactMatch(). for font_family in QtGui.QFontDatabase.applicationFontFamilies(font_id): if not QtGui.QFont(font_family).exactMatch(): logger.error( 'Font family is loaded but cannot be used: ' + font_family) def init(): """Initialize fonts.""" if platform.system() == 'Darwin': # Workaround for # py2app sets sys.frozen = 'macosx_app' when bundled. if hasattr(sys, 'frozen'): # When the app bundle is loaded, the current directory will be # 'OurApp.app/Content/Resources'. There should be a fonts/ # directory there. fonts_prefix = 'fonts' else: # For development only fonts_prefix = 'resources/fonts' for font_path in iglob(fonts_prefix + '/*.[to]tf'): _load_font(font_path) else: font_dir_resource = QtCore.QResource(':/fonts') font_dir_resource_path = font_dir_resource.absoluteFilePath() for font_filename in font_dir_resource.children(): # DON'T use `os.path.join()' here because Qt always uses UNIX-style # paths. On Windows `os.sep' is '\\'. font_resource_path = '/'.join( [font_dir_resource_path, font_filename]) _load_font(font_resource_path) >From our main, we simply call: from our_package import fonts fonts.init() Hope this helps! -- Sean Fisk On Sun, Feb 16, 2014 at 7:55 PM, Sean Fisk wrote: > Hi Srini, > > I am waiting for members of my team to test out my solution to make sure I > didn't break anything on platforms other than Mac OS X. That should happen > tomorrow, and I will be able to send you the snippet. I don't want to give > you broken code :) > > Cheers, > > > -- > Sean Fisk > > > On Fri, Feb 14, 2014 at 3:54 PM, Srini Kommoori wrote: > >> Sean, >> >> Thanks for reaching out. I am also in the process of building >> QFontDatabase manually. >> >> Yes. It would great if you could share your code snippet on how you are >> handling this. >> >> thanks, >> -Srini >> >> >> On Fri, Feb 14, 2014 at 11:01 AM, Sean Fisk wrote: >> >>> We are having an issue where embedded fonts (i.e., from a QRC file) are >>> not loading properly on OS X Mavericks. Srini, I can't tell for certain >>> based on your description, but it might be the issue you are having too. >>> >>> We are using py2app to distribute our >>> application. Although this is not a solution to the bug, we were able to >>> work around the issue by including the fonts as data files with py2app. >>> This works because it loads the font from an "external" file instead of an >>> embedded resource. >>> >>> If that is an option for you and you would like to adapt our code, I >>> would be happy to provide it. >>> >>> Cheers, >>> >>> >>> -- >>> Sean Fisk >>> >>> >>> On Wed, Feb 5, 2014 at 3:10 PM, Srini Kommoori wrote: >>> >>>> Thanks John. I got that from search. My issue is not really with Lucida >>>> Grande support. I have custom font which is having issues. I have ton of >>>> these messages on the console. >>>> >>>> 2014-02-05 08:05:36.498 Python[25536:1107] CoreText performance note: >>>> Client called CTFontCreateWithName() using name "Open Sans" and got font >>>> with PostScript name "OpenSans". For best performance, only use PostScript >>>> names when calling this API. >>>> >>>> Seems like https://bugreports.qt-project.org/browse/QTBUG-32789 is >>>> fixed. We need to merge the fix or wait for 4.8.6 to be released. >>>> >>>> >>>> >>>> >>>> On Wed, Feb 5, 2014 at 10:10 AM, John Ehresman wrote: >>>> >>>>> On 2/4/14, 10:38 PM, Srini Kommoori wrote: >>>>> >>>>>> Is anyone working on porting to Qt5.2? >>>>>> >>>>>> I just updated my mac to Mavericks and fonts are all messed up. I see >>>>>> that all of them are resolved in Qt5.2. >>>>>> >>>>> >>>>> PySide only supports Qt4 right now. The workaround for the Mavericks >>>>> font problem (or at least a problem with the system font) is to use: >>>>> >>>>> QFont.insertSubstitution(".Lucida Grande UI", "Lucida Grande") >>>>> >>>>> There's also another 4.8 release in the works. >>>>> >>>>> Cheers, >>>>> >>>>> John >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> PySide mailing list >>>> PySide at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/pyside >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbzhang800 at gmail.com Wed Feb 19 09:27:11 2014 From: dbzhang800 at gmail.com (1+1=2) Date: Wed, 19 Feb 2014 16:27:11 +0800 Subject: [PySide] Qabstracttablemodel supplying multiple Qtableviews. In-Reply-To: References: Message-ID: Hi, you can give a try to QAbstractProxyModel On Fri, Feb 14, 2014 at 5:07 PM, Andrew Nelson wrote: > Dear list, > I have a single dataset that I want to display subsets of in three > different Qtableview's. At the moment I have 3 different model > classes, one for each Qtableview, that extend Qabstracttablemodel. > However, editing these Qtableview's causes the model (dataset) to grow > and I have to insert rows. It is not a problem to grow the model that > underlies that Qtableview, but how do I inform the two other model > classes/table views that the dataset has grown? > It seems wasteful to me to have three different Qabstracttablemodel's, > when a single Qabstracttablemodel should suffice for all three > Qtableview's. The dataset that is displayed in each of the datasets > is the same, it's just that the views are looking at different subsets > of the same thing. It seems to me that if I could know which > Qtableview is querying the Qabstracttablemodel, then I would only need > to have one model class. It would then be easy to grow the models > when the dataset is edited. > > Can anyone provide suggestions of the cleanest way of implementing this > system? > > cheers, > Andrew. > -- > _____________________________________ > Dr. Andrew Nelson > > > _____________________________________ > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > -------------- next part -------------- An HTML attachment was scrubbed... URL: From salvatore at iovene.com Wed Feb 19 09:28:42 2014 From: salvatore at iovene.com (Salvatore Iovene) Date: Wed, 19 Feb 2014 10:28:42 +0200 Subject: [PySide] PySide/QtCore.so: undefined symbol: _ZN8Shiboken6Object4hashEP7_object In-Reply-To: References: Message-ID: Hi, sorry to bump the message, but did you have time to take a look? Thanks! Salvatore. On Mon, Feb 10, 2014 at 8:17 AM, Salvatore Iovene wrote: > Hi Roman, > > On Sun, Feb 9, 2014 at 10:05 AM, Roman Lacko wrote: >> >> Dňa 8.2.2014 15:55 používateľ "Salvatore Iovene" >> napísal: >> >> >>> >>> Hi, >>> I'm using PySide 1.1.1. I know it's old, but newer versions cause a >>> segmentation fault somewhere in my stack. >>> 1.1.1 works well on my production server, but now that I was setting >>> up a new development environment, I ran into a problem installing >>> PySide. >>> >>> It's installed via `pip` in a Ubuntu 12.04 chroot environment, with >>> Python 2.7.4. >> >> hi, >> Can you send here the pip build output log ? > > Let me include just the final part at first, because I have it at > hand. Later I'll do another build if you require. > > This seems to be relevant: > > changing mode of build/scripts-2.7/pyside_postinstall.py from 644 to 755 > File "/usr/local/lib/python2.7/dist-packages/pysideuic/port_v3/proxy_base.py", > line 26 > class ProxyBase(metaclass=ProxyType): > ^ > SyntaxError: invalid syntax > > changing mode of /usr/local/bin/pyside_postinstall.py to 755 > Installing pyside-uic script to /usr/local/bin > Executing post install script '/usr/bin/pyside_postinstall.py'... > Traceback (most recent call last): > File "/usr/bin/pyside_postinstall.py", line 84, in install_linux > from PySide import QtCore > ImportError: > /usr/local/lib/python2.7/dist-packages/PySide/QtCore.so: undefined > symbol: _ZN8Shiboken6Object4hashEP7_object > PySide package found in /usr/local/lib/python2.7/dist-packages/PySide... > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtHelp.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtWebKit.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtCore.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtGui.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtOpenGL.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtUiTools.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/shiboken to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtDeclarative.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtNetwork.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtScriptTools.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtSql.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtXmlPatterns.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtScript.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtXml.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtTest.so to > /usr/local/lib/python2.7/dist-packages/PySide. > Patched rpath in > /usr/local/lib/python2.7/dist-packages/PySide/QtSvg.so to > /usr/local/lib/python2.7/dist-packages/PySide. > The PySide package not installed: None > Successfully installed PySide > Cleaning up... > > > In the rest of the build process I didn't notice any error, save the > occasional warning. > > Thanks, > Salvatore. > > > -- > Salvatore Iovene > > Personal website: http://iovene.com/ > Founder of AstroBin: http://astrobin.com/ -- Salvatore Iovene Personal website: http://iovene.com/ Founder of AstroBin: http://astrobin.com/ From vasure at gmail.com Wed Feb 19 09:44:38 2014 From: vasure at gmail.com (Srini Kommoori) Date: Wed, 19 Feb 2014 00:44:38 -0800 Subject: [PySide] Support for 5.2 In-Reply-To: References: <52F27EAF.6070604@wingware.com> Message-ID: Thanks a lot. This helps. On Tue, Feb 18, 2014 at 2:38 PM, Sean Fisk wrote: > Hi Srini, > > Here is our py2app configuration dictionary: > > 'py2app': { > # ... > 'resources': [ > # Part of a workaround for > # > 'resources/fonts', # project directory which contains our fonts > ] > } > > Here is our module responsible for font loading. > > # fonts.py"""Initialize fonts embedded using the Qt resource system.""" > import sysimport loggingfrom glob import iglobimport platform > from PySide import QtCore, QtGui > > logger = logging.getLogger(__name__) > def _load_font(font_path): > """Load a font from a path. > > :param font_path: path to the font; can be a filesystem or resource path > :type font_path: :class:`str` > """ > # It's a tough deciding what to do when a font can't be loaded. If it > # can't, it's an error because we are writing the application to work with > # our own custom fonts. However, custom fonts are not necessary for the > # application to achieve its purpose. Because the application will still be > # useful without custom fonts loaded, we are choosing to report this as an > # error but still let the program continue running. > font_id = QtGui.QFontDatabase.addApplicationFont(font_path) > if font_id == -1: > logger.error('Could not load font from path: ' + font_path) > return > # It's possible that a font can be loaded correctly (i.e., it has a > # font_id) but cannot be used correctly. In my opinion, this > # constitutes a bug in Qt. The workaround is to add this extra check to > # make sure that font can /actually/ be used by calling exactMatch(). > for font_family in QtGui.QFontDatabase.applicationFontFamilies(font_id): > if not QtGui.QFont(font_family).exactMatch(): > logger.error( > 'Font family is loaded but cannot be used: ' + font_family) > def init(): > """Initialize fonts.""" > if platform.system() == 'Darwin': > # Workaround for > > # py2app sets sys.frozen = 'macosx_app' when bundled. > if hasattr(sys, 'frozen'): > # When the app bundle is loaded, the current directory will be > # 'OurApp.app/Content/Resources'. There should be a fonts/ > # directory there. > fonts_prefix = 'fonts' > else: > # For development only > fonts_prefix = 'resources/fonts' > for font_path in iglob(fonts_prefix + '/*.[to]tf'): > _load_font(font_path) > else: > font_dir_resource = QtCore.QResource(':/fonts') > font_dir_resource_path = font_dir_resource.absoluteFilePath() > for font_filename in font_dir_resource.children(): > # DON'T use `os.path.join()' here because Qt always uses UNIX-style > # paths. On Windows `os.sep' is '\\'. > font_resource_path = '/'.join( > [font_dir_resource_path, font_filename]) > _load_font(font_resource_path) > > From our main, we simply call: > > from our_package import fonts > fonts.init() > > Hope this helps! > > > -- > Sean Fisk > > > On Sun, Feb 16, 2014 at 7:55 PM, Sean Fisk wrote: > >> Hi Srini, >> >> I am waiting for members of my team to test out my solution to make sure >> I didn't break anything on platforms other than Mac OS X. That should >> happen tomorrow, and I will be able to send you the snippet. I don't want >> to give you broken code :) >> >> Cheers, >> >> >> -- >> Sean Fisk >> >> >> On Fri, Feb 14, 2014 at 3:54 PM, Srini Kommoori wrote: >> >>> Sean, >>> >>> Thanks for reaching out. I am also in the process of building >>> QFontDatabase manually. >>> >>> Yes. It would great if you could share your code snippet on how you are >>> handling this. >>> >>> thanks, >>> -Srini >>> >>> >>> On Fri, Feb 14, 2014 at 11:01 AM, Sean Fisk wrote: >>> >>>> We are having an issue where embedded fonts (i.e., from a QRC file) are >>>> not loading properly on OS X Mavericks. Srini, I can’t tell for certain >>>> based on your description, but it might be the issue you are having too. >>>> >>>> We are using py2app to distribute >>>> our application. Although this is not a solution to the bug, we were able >>>> to work around the issue by including the fonts as data files with py2app. >>>> This works because it loads the font from an “external” file instead of an >>>> embedded resource. >>>> >>>> If that is an option for you and you would like to adapt our code, I >>>> would be happy to provide it. >>>> >>>> Cheers, >>>> >>>> >>>> -- >>>> Sean Fisk >>>> >>>> >>>> On Wed, Feb 5, 2014 at 3:10 PM, Srini Kommoori wrote: >>>> >>>>> Thanks John. I got that from search. My issue is not really with >>>>> Lucida Grande support. I have custom font which is having issues. I have >>>>> ton of these messages on the console. >>>>> >>>>> 2014-02-05 08:05:36.498 Python[25536:1107] CoreText performance note: >>>>> Client called CTFontCreateWithName() using name "Open Sans" and got font >>>>> with PostScript name "OpenSans". For best performance, only use PostScript >>>>> names when calling this API. >>>>> >>>>> Seems like https://bugreports.qt-project.org/browse/QTBUG-32789 is >>>>> fixed. We need to merge the fix or wait for 4.8.6 to be released. >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 5, 2014 at 10:10 AM, John Ehresman wrote: >>>>> >>>>>> On 2/4/14, 10:38 PM, Srini Kommoori wrote: >>>>>> >>>>>>> Is anyone working on porting to Qt5.2? >>>>>>> >>>>>>> I just updated my mac to Mavericks and fonts are all messed up. I see >>>>>>> that all of them are resolved in Qt5.2. >>>>>>> >>>>>> >>>>>> PySide only supports Qt4 right now. The workaround for the Mavericks >>>>>> font problem (or at least a problem with the system font) is to use: >>>>>> >>>>>> QFont.insertSubstitution(".Lucida Grande UI", "Lucida Grande") >>>>>> >>>>>> There's also another 4.8 release in the works. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> John >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> PySide mailing list >>>>> PySide at qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/pyside >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chigga101 at gmail.com Wed Feb 19 13:47:42 2014 From: chigga101 at gmail.com (Matthew Ngaha) Date: Wed, 19 Feb 2014 12:47:42 +0000 Subject: [PySide] (no subject) Message-ID: I was following a QML tutorial that had this import statement: import QtMultimedia 5.0 I was told that i would need http://doc.qt.digia.com/qtmobility-1.2.0/multimedia.html and that if i didnt download the Qt Sdk i would have to compile it myself. But when i look at my Pyside installation, it includes: QtMultimedia.pyd From chigga101 at gmail.com Wed Feb 19 13:50:41 2014 From: chigga101 at gmail.com (Matthew Ngaha) Date: Wed, 19 Feb 2014 12:50:41 +0000 Subject: [PySide] (no subject) In-Reply-To: References: Message-ID: Sorry this is a repost. On my previous post i pressed tab and the message sent. Sorry I was following a QML tutorial that had this import statement: import QtMultimedia 5.0 I was told that i would need http://doc.qt.digia.com/qtmobility-1.2.0/multimedia.html and that if i didnt download the Qt Sdk i would have to compile it myself. But when i look at my Pyside installation, it includes: QtMultimedia.pyd QtMultimedia4.dll Shouldnt i have access? Ive tried import QtMultimedia QtMultimedia4 with versions 1.0 and 4.7 but nothing works From backup.rlacko at gmail.com Wed Feb 19 15:22:28 2014 From: backup.rlacko at gmail.com (Roman Lacko) Date: Wed, 19 Feb 2014 15:22:28 +0100 Subject: [PySide] PySide/QtCore.so: undefined symbol: _ZN8Shiboken6Object4hashEP7_object In-Reply-To: References: Message-ID: Hi Salvatore, 2014-02-19 9:28 GMT+01:00 Salvatore Iovene : > Hi, sorry to bump the message, but did you have time to take a look? > sorry i have not. I'm out of my free time. Could you try to build latest version of PySide just to be sure the problem is with PySide 1.1.1 ? Thanks Roman > > Thanks! > Salvatore. > > > On Mon, Feb 10, 2014 at 8:17 AM, Salvatore Iovene > wrote: > > Hi Roman, > > > > On Sun, Feb 9, 2014 at 10:05 AM, Roman Lacko > wrote: > >> > >> Dňa 8.2.2014 15:55 používateľ "Salvatore Iovene" > >> napísal: > >> > >> > >>> > >>> Hi, > >>> I'm using PySide 1.1.1. I know it's old, but newer versions cause a > >>> segmentation fault somewhere in my stack. > >>> 1.1.1 works well on my production server, but now that I was setting > >>> up a new development environment, I ran into a problem installing > >>> PySide. > >>> > >>> It's installed via `pip` in a Ubuntu 12.04 chroot environment, with > >>> Python 2.7.4. > >> > >> hi, > >> Can you send here the pip build output log ? > > > > Let me include just the final part at first, because I have it at > > hand. Later I'll do another build if you require. > > > > This seems to be relevant: > > > > changing mode of build/scripts-2.7/pyside_postinstall.py from 644 to > 755 > > File > "/usr/local/lib/python2.7/dist-packages/pysideuic/port_v3/proxy_base.py", > > line 26 > > class ProxyBase(metaclass=ProxyType): > > ^ > > SyntaxError: invalid syntax > > > > changing mode of /usr/local/bin/pyside_postinstall.py to 755 > > Installing pyside-uic script to /usr/local/bin > > Executing post install script '/usr/bin/pyside_postinstall.py'... > > Traceback (most recent call last): > > File "/usr/bin/pyside_postinstall.py", line 84, in install_linux > > from PySide import QtCore > > ImportError: > > /usr/local/lib/python2.7/dist-packages/PySide/QtCore.so: undefined > > symbol: _ZN8Shiboken6Object4hashEP7_object > > PySide package found in > /usr/local/lib/python2.7/dist-packages/PySide... > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtHelp.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtWebKit.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtCore.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtGui.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtOpenGL.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtUiTools.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/shiboken to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtDeclarative.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtNetwork.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtScriptTools.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtSql.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtXmlPatterns.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtScript.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtXml.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtTest.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > Patched rpath in > > /usr/local/lib/python2.7/dist-packages/PySide/QtSvg.so to > > /usr/local/lib/python2.7/dist-packages/PySide. > > The PySide package not installed: None > > Successfully installed PySide > > Cleaning up... > > > > > > In the rest of the build process I didn't notice any error, save the > > occasional warning. > > > > Thanks, > > Salvatore. > > > > > > -- > > Salvatore Iovene > > > > Personal website: http://iovene.com/ > > Founder of AstroBin: http://astrobin.com/ > > > > -- > Salvatore Iovene > > Personal website: http://iovene.com/ > Founder of AstroBin: http://astrobin.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From salvatore at iovene.com Wed Feb 19 15:54:04 2014 From: salvatore at iovene.com (Salvatore Iovene) Date: Wed, 19 Feb 2014 16:54:04 +0200 Subject: [PySide] PySide/QtCore.so: undefined symbol: _ZN8Shiboken6Object4hashEP7_object In-Reply-To: References: Message-ID: On 19 Feb 2014 16:22, "Roman Lacko" wrote: >Could you try to build latest version of PySide just to be sure the problem is with PySide 1.1.1 ? This error is not reproducible with PySide > 1.1.1, but I'm interested in working with that version. > > Thanks > Roman > >> >> >> Thanks! >> Salvatore. >> >> >> On Mon, Feb 10, 2014 at 8:17 AM, Salvatore Iovene wrote: >> > Hi Roman, >> > >> > On Sun, Feb 9, 2014 at 10:05 AM, Roman Lacko wrote: >> >> >> >> Dňa 8.2.2014 15:55 používateľ "Salvatore Iovene" >> >> napísal: >> >> >> >> >> >>> >> >>> Hi, >> >>> I'm using PySide 1.1.1. I know it's old, but newer versions cause a >> >>> segmentation fault somewhere in my stack. >> >>> 1.1.1 works well on my production server, but now that I was setting >> >>> up a new development environment, I ran into a problem installing >> >>> PySide. >> >>> >> >>> It's installed via `pip` in a Ubuntu 12.04 chroot environment, with >> >>> Python 2.7.4. >> >> >> >> hi, >> >> Can you send here the pip build output log ? >> > >> > Let me include just the final part at first, because I have it at >> > hand. Later I'll do another build if you require. >> > >> > This seems to be relevant: >> > >> > changing mode of build/scripts-2.7/pyside_postinstall.py from 644 to 755 >> > File "/usr/local/lib/python2.7/dist-packages/pysideuic/port_v3/proxy_base.py", >> > line 26 >> > class ProxyBase(metaclass=ProxyType): >> > ^ >> > SyntaxError: invalid syntax >> > >> > changing mode of /usr/local/bin/pyside_postinstall.py to 755 >> > Installing pyside-uic script to /usr/local/bin >> > Executing post install script '/usr/bin/pyside_postinstall.py'... >> > Traceback (most recent call last): >> > File "/usr/bin/pyside_postinstall.py", line 84, in install_linux >> > from PySide import QtCore >> > ImportError: >> > /usr/local/lib/python2.7/dist-packages/PySide/QtCore.so: undefined >> > symbol: _ZN8Shiboken6Object4hashEP7_object >> > PySide package found in /usr/local/lib/python2.7/dist-packages/PySide... >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtHelp.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtWebKit.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtCore.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtGui.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtOpenGL.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtUiTools.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/shiboken to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtDeclarative.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtNetwork.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtScriptTools.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtSql.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtXmlPatterns.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtScript.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtXml.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtTest.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > Patched rpath in >> > /usr/local/lib/python2.7/dist-packages/PySide/QtSvg.so to >> > /usr/local/lib/python2.7/dist-packages/PySide. >> > The PySide package not installed: None >> > Successfully installed PySide >> > Cleaning up... >> > >> > >> > In the rest of the build process I didn't notice any error, save the >> > occasional warning. >> > >> > Thanks, >> > Salvatore. >> > >> > >> > -- >> > Salvatore Iovene >> > >> > Personal website: http://iovene.com/ >> > Founder of AstroBin: http://astrobin.com/ >> >> >> >> -- >> Salvatore Iovene >> >> Personal website: http://iovene.com/ >> Founder of AstroBin: http://astrobin.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at seanfisk.com Sun Feb 23 19:55:32 2014 From: sean at seanfisk.com (Sean Fisk) Date: Sun, 23 Feb 2014 13:55:32 -0500 Subject: [PySide] Support for 5.2 In-Reply-To: References: <52F27EAF.6070604@wingware.com> Message-ID: No problem. Let me know if you find any better ways. -- Sean Fisk On Wed, Feb 19, 2014 at 3:44 AM, Srini Kommoori wrote: > Thanks a lot. This helps. > > > On Tue, Feb 18, 2014 at 2:38 PM, Sean Fisk wrote: > >> Hi Srini, >> >> Here is our py2app configuration dictionary: >> >> 'py2app': { >> # ... >> 'resources': [ >> # Part of a workaround for >> # >> 'resources/fonts', # project directory which contains our fonts >> ] >> } >> >> Here is our module responsible for font loading. >> >> # fonts.py"""Initialize fonts embedded using the Qt resource system.""" >> import sysimport loggingfrom glob import iglobimport platform >> from PySide import QtCore, QtGui >> >> logger = logging.getLogger(__name__) >> def _load_font(font_path): >> """Load a font from a path. >> >> :param font_path: path to the font; can be a filesystem or resource path >> :type font_path: :class:`str` >> """ >> # It's a tough deciding what to do when a font can't be loaded. If it >> # can't, it's an error because we are writing the application to work with >> # our own custom fonts. However, custom fonts are not necessary for the >> # application to achieve its purpose. Because the application will still be >> # useful without custom fonts loaded, we are choosing to report this as an >> # error but still let the program continue running. >> font_id = QtGui.QFontDatabase.addApplicationFont(font_path) >> if font_id == -1: >> logger.error('Could not load font from path: ' + font_path) >> return >> # It's possible that a font can be loaded correctly (i.e., it has a >> # font_id) but cannot be used correctly. In my opinion, this >> # constitutes a bug in Qt. The workaround is to add this extra check to >> # make sure that font can /actually/ be used by calling exactMatch(). >> for font_family in QtGui.QFontDatabase.applicationFontFamilies(font_id): >> if not QtGui.QFont(font_family).exactMatch(): >> logger.error( >> 'Font family is loaded but cannot be used: ' + font_family) >> def init(): >> """Initialize fonts.""" >> if platform.system() == 'Darwin': >> # Workaround for >> >> # py2app sets sys.frozen = 'macosx_app' when bundled. >> if hasattr(sys, 'frozen'): >> # When the app bundle is loaded, the current directory will be >> # 'OurApp.app/Content/Resources'. There should be a fonts/ >> # directory there. >> fonts_prefix = 'fonts' >> else: >> # For development only >> fonts_prefix = 'resources/fonts' >> for font_path in iglob(fonts_prefix + '/*.[to]tf'): >> _load_font(font_path) >> else: >> font_dir_resource = QtCore.QResource(':/fonts') >> font_dir_resource_path = font_dir_resource.absoluteFilePath() >> for font_filename in font_dir_resource.children(): >> # DON'T use `os.path.join()' here because Qt always uses UNIX-style >> # paths. On Windows `os.sep' is '\\'. >> font_resource_path = '/'.join( >> [font_dir_resource_path, font_filename]) >> _load_font(font_resource_path) >> >> From our main, we simply call: >> >> from our_package import fonts >> fonts.init() >> >> Hope this helps! >> >> >> -- >> Sean Fisk >> >> >> On Sun, Feb 16, 2014 at 7:55 PM, Sean Fisk wrote: >> >>> Hi Srini, >>> >>> I am waiting for members of my team to test out my solution to make sure >>> I didn't break anything on platforms other than Mac OS X. That should >>> happen tomorrow, and I will be able to send you the snippet. I don't want >>> to give you broken code :) >>> >>> Cheers, >>> >>> >>> -- >>> Sean Fisk >>> >>> >>> On Fri, Feb 14, 2014 at 3:54 PM, Srini Kommoori wrote: >>> >>>> Sean, >>>> >>>> Thanks for reaching out. I am also in the process of building >>>> QFontDatabase manually. >>>> >>>> Yes. It would great if you could share your code snippet on how you are >>>> handling this. >>>> >>>> thanks, >>>> -Srini >>>> >>>> >>>> On Fri, Feb 14, 2014 at 11:01 AM, Sean Fisk wrote: >>>> >>>>> We are having an issue where embedded fonts (i.e., from a QRC file) >>>>> are not loading properly on OS X Mavericks. Srini, I can't tell for certain >>>>> based on your description, but it might be the issue you are having too. >>>>> >>>>> We are using py2app to distribute >>>>> our application. Although this is not a solution to the bug, we were able >>>>> to work around the issue by including the fonts as data files with py2app. >>>>> This works because it loads the font from an "external" file instead of an >>>>> embedded resource. >>>>> >>>>> If that is an option for you and you would like to adapt our code, I >>>>> would be happy to provide it. >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> -- >>>>> Sean Fisk >>>>> >>>>> >>>>> On Wed, Feb 5, 2014 at 3:10 PM, Srini Kommoori wrote: >>>>> >>>>>> Thanks John. I got that from search. My issue is not really with >>>>>> Lucida Grande support. I have custom font which is having issues. I have >>>>>> ton of these messages on the console. >>>>>> >>>>>> 2014-02-05 08:05:36.498 Python[25536:1107] CoreText performance note: >>>>>> Client called CTFontCreateWithName() using name "Open Sans" and got font >>>>>> with PostScript name "OpenSans". For best performance, only use PostScript >>>>>> names when calling this API. >>>>>> >>>>>> Seems like https://bugreports.qt-project.org/browse/QTBUG-32789 is >>>>>> fixed. We need to merge the fix or wait for 4.8.6 to be released. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 5, 2014 at 10:10 AM, John Ehresman wrote: >>>>>> >>>>>>> On 2/4/14, 10:38 PM, Srini Kommoori wrote: >>>>>>> >>>>>>>> Is anyone working on porting to Qt5.2? >>>>>>>> >>>>>>>> I just updated my mac to Mavericks and fonts are all messed up. I >>>>>>>> see >>>>>>>> that all of them are resolved in Qt5.2. >>>>>>>> >>>>>>> >>>>>>> PySide only supports Qt4 right now. The workaround for the >>>>>>> Mavericks font problem (or at least a problem with the system font) is to >>>>>>> use: >>>>>>> >>>>>>> QFont.insertSubstitution(".Lucida Grande UI", "Lucida Grande") >>>>>>> >>>>>>> There's also another 4.8 release in the works. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> PySide mailing list >>>>>> PySide at qt-project.org >>>>>> http://lists.qt-project.org/mailman/listinfo/pyside >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mko0815 at gmail.com Mon Feb 24 17:39:10 2014 From: mko0815 at gmail.com (Manuel Koch) Date: Mon, 24 Feb 2014 17:39:10 +0100 Subject: [PySide] PySide application crashes when getting closed, related to QAction menu item Message-ID: Hi I have a strange problem related to menu actions in my PySide application: PySide 1.2.1, Python 2.7 32bit, Windows 7 My main window uses QAction to setup menu structure. One of the menu items seems to cause a crash when the application is closed. Following small snippet seems to trigger app to crash immediately after hitting the close button of main window !? I'm I doing something wrong when connecting signals/slots related to QAction ? The code: class MainWindow(QMainWindow): def __init__(self,parent=None): super(MainWindow,self).__init__(parent) ..... menubar = self.menuBar() fooMenu = menubar.addMenu("&Foo") # commenting out the following two lines avoids my app to crash self._barAct = QAction("Bar", self, checkable=True, statusTip="Do bar", triggered=self._onBar) fooMenu.addAction(self._barAct) def _onBar(self): "Handle toggling of bar checkbox" print "_onBar" -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at seanfisk.com Mon Feb 24 20:06:51 2014 From: sean at seanfisk.com (Sean Fisk) Date: Mon, 24 Feb 2014 14:06:51 -0500 Subject: [PySide] PySide application crashes when getting closed, related to QAction menu item In-Reply-To: References: Message-ID: Hi Manuel, I tried your code on [Mac OS 10.9 Mavericks, PySide 1.2.1, Python 2.7.5] and it worked fine. Would you mind posting the error that you get? Thanks, -- Sean Fisk On Mon, Feb 24, 2014 at 11:39 AM, Manuel Koch wrote: > Hi > > I have a strange problem related to menu actions in my PySide application: > PySide 1.2.1, Python 2.7 32bit, Windows 7 > > My main window uses QAction to setup menu structure. > One of the menu items seems to cause a crash when the application is > closed. > Following small snippet seems to trigger app to crash immediately after > hitting the close button of main window !? > > I'm I doing something wrong when connecting signals/slots related to > QAction ? > > The code: > > class MainWindow(QMainWindow): > > def __init__(self,parent=None): > super(MainWindow,self).__init__(parent) > ..... > menubar = self.menuBar() > fooMenu = menubar.addMenu("&Foo") > # commenting out the following two lines avoids my app to crash > self._barAct = QAction("Bar", self, checkable=True, statusTip="Do > bar", triggered=self._onBar) > fooMenu.addAction(self._barAct) > > def _onBar(self): > "Handle toggling of bar checkbox" > print "_onBar" > > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at seanfisk.com Mon Feb 24 20:15:32 2014 From: sean at seanfisk.com (Sean Fisk) Date: Mon, 24 Feb 2014 14:15:32 -0500 Subject: [PySide] PySide Version Script Message-ID: Hi everyone, Many people come to the list asking for help on platform-specific issues, or have issues that eventually turn out to be platform-specific. To help everyone ascertain just what version of everything they are running, I created this PySide version script to mine this information using Python. Here is an example: $ wget -q -O - https://gist.githubusercontent.com/seanfisk/9194547/raw/pyside_version.py | python - Platform: Darwin-13.0.0-x86_64-i386-64bit Specific platform info tuple: ('10.9.1', ('', '', ''), 'x86_64') Python compiler: GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79) Python version: CPython 2.7.5 PySide version: 1.2.1 PySide version tuple: (1, 2, 1, 'final', 0) Compiled with Qt: 4.8.6 Running with Qt: 4.8.6 You can find the script on the PySide version script gist. If people like it, I'll add it to the wiki; though I'm not quite sure where to add it. Thanks! -- Sean Fisk -------------- next part -------------- An HTML attachment was scrubbed... URL: From mko0815 at gmail.com Mon Feb 24 20:30:41 2014 From: mko0815 at gmail.com (Manuel Koch) Date: Mon, 24 Feb 2014 20:30:41 +0100 Subject: [PySide] PySide application crashes when getting closed, related to QAction menu item In-Reply-To: References: Message-ID: <677FCBE7-1C63-4E41-85DD-1C2A35F365E4@gmail.com> Hi Sean The program ( i.e. Python interpreter just crashes ) and Windows shows a popup "Python.exe has stopped working." and offers means to attach Visual Studio debugger. I attached a debugger, but the callstack did not pin point to a specific issue, it just seems to have accessed memory that is not valid (anymore). The strange think is that I have almost stripped down my program ( from several thousand lines ) to just a view widgets and it runs ok when I dont include this particular QAction and it crashes everytime I include it ?! kind regards Manuel > Am 24.02.2014 um 20:06 schrieb Sean Fisk : > > Hi Manuel, > > I tried your code on [Mac OS 10.9 Mavericks, PySide 1.2.1, Python 2.7.5] and it worked fine. Would you mind posting the error that you get? > > Thanks, > > > -- > Sean Fisk > > >> On Mon, Feb 24, 2014 at 11:39 AM, Manuel Koch wrote: >> Hi >> >> I have a strange problem related to menu actions in my PySide application: >> PySide 1.2.1, Python 2.7 32bit, Windows 7 >> >> My main window uses QAction to setup menu structure. >> One of the menu items seems to cause a crash when the application is closed. >> Following small snippet seems to trigger app to crash immediately after hitting the close button of main window !? >> >> I'm I doing something wrong when connecting signals/slots related to QAction ? >> >> The code: >> >> class MainWindow(QMainWindow): >> >> def __init__(self,parent=None): >> super(MainWindow,self).__init__(parent) >> ..... >> menubar = self.menuBar() >> fooMenu = menubar.addMenu("&Foo") >> # commenting out the following two lines avoids my app to crash >> self._barAct = QAction("Bar", self, checkable=True, statusTip="Do bar", triggered=self._onBar) >> fooMenu.addAction(self._barAct) >> >> def _onBar(self): >> "Handle toggling of bar checkbox" >> print "_onBar" >> >> >> _______________________________________________ >> PySide mailing list >> PySide at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/pyside > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at seanfisk.com Mon Feb 24 21:00:38 2014 From: sean at seanfisk.com (Sean Fisk) Date: Mon, 24 Feb 2014 15:00:38 -0500 Subject: [PySide] PySide application crashes when getting closed, related to QAction menu item In-Reply-To: <677FCBE7-1C63-4E41-85DD-1C2A35F365E4@gmail.com> References: <677FCBE7-1C63-4E41-85DD-1C2A35F365E4@gmail.com> Message-ID: Hi Manuel, I would guess that it is a C++ scoping issue. I have had similar issues in the past and it is usually due to a C++ object that needs to stick around being dropped out of scope and then garbage-collected by Python. Can you try storing menubar and fooMenu as attributes of self? E.g., #!/usr/bin/env python import sys from PySide import QtGui class MainWindow(QtGui.QMainWindow): def __init__(self, parent=None): super(MainWindow, self).__init__(parent) self._menubar = self.menuBar() self._fooMenu = self._menubar.addMenu("&Foo") # commenting out the following two lines avoids my app to crash self._barAct = QtGui.QAction("Bar", self, checkable=True, statusTip="Do bar", triggered=self._onBar) self._fooMenu.addAction(self._barAct) def _onBar(self): "Handle toggling of bar checkbox" print "_onBar" if __name__ == '__main__': app = QtGui.QApplication(sys.argv) w = MainWindow() w.show() app.exec_() This will ensure that these objects aren't garbage-collected. -- Sean Fisk On Mon, Feb 24, 2014 at 2:30 PM, Manuel Koch wrote: > Hi Sean > > The program ( i.e. Python interpreter just crashes ) and Windows shows a > popup "Python.exe has stopped working." and offers means to attach Visual > Studio debugger. I attached a debugger, but the callstack did not pin point > to a specific issue, it just seems to have accessed memory that is not > valid (anymore). > > The strange think is that I have almost stripped down my program ( from > several thousand lines ) to just a view widgets and it runs ok when I dont > include this particular QAction and it crashes everytime I include it ?! > > kind regards > Manuel > > Am 24.02.2014 um 20:06 schrieb Sean Fisk : > > Hi Manuel, > > I tried your code on [Mac OS 10.9 Mavericks, PySide 1.2.1, Python 2.7.5] > and it worked fine. Would you mind posting the error that you get? > > Thanks, > > > -- > Sean Fisk > > > On Mon, Feb 24, 2014 at 11:39 AM, Manuel Koch wrote: > >> Hi >> >> I have a strange problem related to menu actions in my PySide application: >> PySide 1.2.1, Python 2.7 32bit, Windows 7 >> >> My main window uses QAction to setup menu structure. >> One of the menu items seems to cause a crash when the application is >> closed. >> Following small snippet seems to trigger app to crash immediately after >> hitting the close button of main window !? >> >> I'm I doing something wrong when connecting signals/slots related to >> QAction ? >> >> The code: >> >> class MainWindow(QMainWindow): >> >> def __init__(self,parent=None): >> super(MainWindow,self).__init__(parent) >> ..... >> menubar = self.menuBar() >> fooMenu = menubar.addMenu("&Foo") >> # commenting out the following two lines avoids my app to crash >> self._barAct = QAction("Bar", self, checkable=True, statusTip="Do >> bar", triggered=self._onBar) >> fooMenu.addAction(self._barAct) >> >> def _onBar(self): >> "Handle toggling of bar checkbox" >> print "_onBar" >> >> >> _______________________________________________ >> PySide mailing list >> PySide at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/pyside >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schampailler at skynet.be Tue Feb 25 08:49:28 2014 From: schampailler at skynet.be (Stefan Champailler) Date: Tue, 25 Feb 2014 08:49:28 +0100 Subject: [PySide] PySide application crashes when getting closed, related to QAction menu item In-Reply-To: References: Message-ID: <530C4B08.7020003@skynet.be> not sure but you may have an onwership issue on fooMenu which gets destroyed when you leave __init__ Solution : make fooMenu persistent, i.e. use an attribute in MainWindow, self.fooMenu stF On 02/24/2014 05:39 PM, Manuel Koch wrote: > Hi > > I have a strange problem related to menu actions in my PySide application: > PySide 1.2.1, Python 2.7 32bit, Windows 7 > > My main window uses QAction to setup menu structure. > One of the menu items seems to cause a crash when the application is closed. > Following small snippet seems to trigger app to crash immediately after > hitting the close button of main window !? > > I'm I doing something wrong when connecting signals/slots related to > QAction ? > > The code: > > class MainWindow(QMainWindow): > > def __init__(self,parent=None): > super(MainWindow,self).__init__(parent) > ..... > menubar = self.menuBar() > fooMenu = menubar.addMenu("&Foo") > # commenting out the following two lines avoids my app to crash > self._barAct = QAction("Bar", self, checkable=True, statusTip="Do > bar", triggered=self._onBar) > fooMenu.addAction(self._barAct) > > def _onBar(self): > "Handle toggling of bar checkbox" > print "_onBar" > > > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside -- Timeo Danaos et dona ferentes Twitter @Arakowa1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mko0815 at gmail.com Tue Feb 25 09:13:06 2014 From: mko0815 at gmail.com (Manuel Koch) Date: Tue, 25 Feb 2014 09:13:06 +0100 Subject: [PySide] PySide application crashes when getting closed, related to QAction menu item In-Reply-To: References: <677FCBE7-1C63-4E41-85DD-1C2A35F365E4@gmail.com> Message-ID: Hi Sean I tried your suggestion ( uses member variables to keep refs to menubar/menu/actions ) but it still crashes. I noticed something else that triggers the crash : My main window uses a menu action to enable WhatsThis mode. self._helpMenu = self._menubar.addMenu("&Help") Commeting out the following line avoids the crash too : self._helpMenu.addAction("&Whats this...",QWhatsThis.enterWhatsThisMode) Instead the following seems to work ( using my own receiver method ) : self._helpMenu.addAction("&Whats this...",self._onWhatsThis) And a new method for the main window def _onWhatsThis(self): QWhatsThis.enterWhatsThisMode() kind regards Manuel 2014-02-24 21:00 GMT+01:00 Sean Fisk : > Hi Manuel, > > I would guess that it is a C++ scoping issue. I have had similar issues in > the past and it is usually due to a C++ object that needs to stick around > being dropped out of scope and then garbage-collected by Python. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hoppy at gnurdle.com Tue Feb 25 20:10:37 2014 From: hoppy at gnurdle.com (Clay Hopperdietzel) Date: Tue, 25 Feb 2014 13:10:37 -0600 Subject: [PySide] State of Things for building pyside with mingw? Message-ID: <530CEAAD.7030107@gnurdle.com> Unable to find much info on this topic, aside from it being deemed "a work in progress" since 2012. Anybody know that status of this? Is there some help needed getting it done? Thanks, C From rymg19 at gmail.com Tue Feb 25 21:39:02 2014 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Tue, 25 Feb 2014 14:39:02 -0600 Subject: [PySide] State of Things for building pyside with mingw? In-Reply-To: <530CEAAD.7030107@gnurdle.com> References: <530CEAAD.7030107@gnurdle.com> Message-ID: Well, I built my own Shiboken modules using MinGW, and they all work fine. On Tue, Feb 25, 2014 at 1:10 PM, Clay Hopperdietzel wrote: > Unable to find much info on this topic, aside from it being deemed "a > work in progress" since 2012. > > Anybody know that status of this? Is there some help needed getting it > done? > > Thanks, > C > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerome at jolimont.fr Fri Feb 28 18:32:27 2014 From: jerome at jolimont.fr (=?UTF-8?Q?J=C3=A9r=C3=B4me?=) Date: Fri, 28 Feb 2014 18:32:27 +0100 Subject: [PySide] Form dialog subclassing QDialog Message-ID: Hi everyone. I know Python and have been playing a bit with PyGTK. Now, I am discovering Qt and PySide and I'm having a hard time trying to implement a form dialog. I have a main window displaying a list of items with a few attributes. Aside from the TableView, I added three buttons : Add, Edit, Remove. When clicking Add, I want a new window to popup, containing a form to enter the values of the new item. Basically, I want the dialog to have an OK and a Cancel button. When the user clicks OK, the dialog closes, and in the main window, the new item is added to the list. (I realize this may be a subcase of Edit with default values, but I'm beginning simple with Add, and I'll figure out Edit afterwards.) I'm therefore creating a dialog subclassing QDialog. Both main window and dialog window are designed with QtDesigner. I need a design hint and the examples I found didn't help. Here's my dialog class (the items happen to be buildings in this case, hence the name), with only an __init__() function: class buildingDialog(QtGui.QDialog): def __init__(self, parent=None): super(buildingDialog, self).__init__(parent) self.ui = dialogBuilding.Ui_Dialog() self.ui.setupUi(self) And here is the call: def addPushButtonClicked(self): dialog = bui.buildingDialog(self) print(dialog.exec_()) The print is here for debug purposes and prints 0 or 1 depending on which button was pressed. What I want is to get the form values from the dialog and use them in the add_item() function in the caller, like this: if the return value is made of item attributes (i.e. the user pressed OK) add_item(attributes = return value) else (the user pressed cancel) nothing... I could modify the return value of the dialog, to return a list of item attributes. But I suppose it's better to keep 0 and 1 as return values and return the values another way. Besides I don't know how to do this anyway. I could return a couple like [values, returnvalue], with returnvalue being 0 or 1, but again, the return values would not be 0 or 1 anymore. I could let the caller read the values in an attribute of the dialog (or through a getter) before the dialog gets closed/destroyed, but I don't know how to do that. It looks like a nicer way would be to reproduce the behaviour of the QColorDialog, for instance. The caller only does color = QtGui.QColorDialog.getColor() if color.isValid(): do stuff But I don't know how to handle this from my custom dialog. I'm pretty sure this is a very common design problem. My questions are - Am I right about trying to copy QColorDialog ? - If yes, do you have a hint about how to do that ? - If no, then what would you suggest ? - The program I'm working on is an interface to enter data about a set of buildings. This mechanism will be reproduced all along: a projet has buildings with attributes (size, age,...), buildings have boiler rooms with attributes (name, manager,...), boiler rooms have boilers with attributes (age, efficiency,...), etc. Do you think I'm going in the wrong direction ? Is subclassing QDialog a bad idea in the first place ? - Most PySide examples I found were about using common dialogs. Should I seek C++ examples and try to adapt them ? Thank you very much for any pointer. Have a nice week-end. -- Jérôme From a.richi at bluewin.ch Fri Feb 28 18:37:34 2014 From: a.richi at bluewin.ch (Aaron Richiger) Date: Fri, 28 Feb 2014 18:37:34 +0100 Subject: [PySide] Form dialog subclassing QDialog In-Reply-To: References: Message-ID: <5310C95E.8000905@bluewin.ch> Hello Jerome! Welcome in the PySide world... Would it be possible, to send us the code (source files). It's always great to run the code, a UI or a error message often says more than many words... Cheers Aaron Am 28.02.2014 18:32, schrieb Jérôme: > Hi everyone. > > I know Python and have been playing a bit with PyGTK. Now, I am > discovering Qt and PySide and I'm having a hard time trying to implement > a form dialog. > > I have a main window displaying a list of items with a few attributes. > Aside from the TableView, I added three buttons : Add, Edit, Remove. > When clicking Add, I want a new window to popup, containing a form to > enter the values of the new item. Basically, I want the dialog to have > an OK and a Cancel button. When the user clicks OK, the dialog closes, > and in the main window, the new item is added to the list. > > (I realize this may be a subcase of Edit with default values, but I'm > beginning simple with Add, and I'll figure out Edit afterwards.) > > I'm therefore creating a dialog subclassing QDialog. Both main window > and dialog window are designed with QtDesigner. > > I need a design hint and the examples I found didn't help. > > Here's my dialog class (the items happen to be buildings in this case, > hence the name), with only an __init__() function: > > class buildingDialog(QtGui.QDialog): > > def __init__(self, parent=None): > super(buildingDialog, self).__init__(parent) > self.ui = dialogBuilding.Ui_Dialog() > self.ui.setupUi(self) > > And here is the call: > > def addPushButtonClicked(self): > > dialog = bui.buildingDialog(self) > print(dialog.exec_()) > > The print is here for debug purposes and prints 0 or 1 depending on > which button was pressed. > > What I want is to get the form values from the dialog and use them in > the add_item() function in the caller, like this: > > if the return value is made of item attributes (i.e. the user pressed > OK) > add_item(attributes = return value) > else (the user pressed cancel) > nothing... > > I could modify the return value of the dialog, to return a list of item > attributes. But I suppose it's better to keep 0 and 1 as return values > and return the values another way. Besides I don't know how to do this > anyway. > > I could return a couple like [values, returnvalue], with returnvalue > being 0 or 1, but again, the return values would not be 0 or 1 anymore. > > I could let the caller read the values in an attribute of the dialog (or > through a getter) before the dialog gets closed/destroyed, but I don't > know how to do that. > > It looks like a nicer way would be to reproduce the behaviour of the > QColorDialog, for instance. > > The caller only does > > color = QtGui.QColorDialog.getColor() > > if color.isValid(): > do stuff > > But I don't know how to handle this from my custom dialog. > > I'm pretty sure this is a very common design problem. > > My questions are > > - Am I right about trying to copy QColorDialog ? > > - If yes, do you have a hint about how to do that ? > > - If no, then what would you suggest ? > > - The program I'm working on is an interface to enter data about a set > of buildings. This mechanism will be reproduced all along: a projet has > buildings with attributes (size, age,...), buildings have boiler rooms > with attributes (name, manager,...), boiler rooms have boilers with > attributes (age, efficiency,...), etc. Do you think I'm going in the > wrong direction ? Is subclassing QDialog a bad idea in the first place ? > > - Most PySide examples I found were about using common dialogs. Should I > seek C++ examples and try to adapt them ? > > Thank you very much for any pointer. > > Have a nice week-end. > From jerome at jolimont.fr Fri Feb 28 18:47:34 2014 From: jerome at jolimont.fr (=?UTF-8?Q?J=C3=A9r=C3=B4me?=) Date: Fri, 28 Feb 2014 18:47:34 +0100 Subject: [PySide] Form dialog subclassing QDialog In-Reply-To: <5310C95E.8000905@bluewin.ch> References: <5310C95E.8000905@bluewin.ch> Message-ID: <559c40a34e4a59c062ece5377ce4daf3@jolimont.fr> Le 2014-02-28 18:37, Aaron Richiger a écrit : > Hello Jerome! Hi. > Welcome in the PySide world... Thank you ! > Would it be possible, to send us the code > (source files). It's always great to run the code, a UI or a error > message often says more than many words... I deliberately stripped the relevant parts in my former message, as the rest might be confusing. Here are the files I'm running. This is just a test, so don't be surprised to see stupid or hardcoded stuff. -- Jérôme -------------- next part -------------- A non-text attachment was scrubbed... Name: dialogBuilding.py Type: text/x-c++ Size: 4287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dialogBuilding.ui Type: application/xml Size: 3234 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mainwindow.py Type: text/x-c++ Size: 4084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mainwindow.ui Type: application/xml Size: 2543 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: building.py Type: text/x-c++ Size: 798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: buildingSurvey.py Type: text/x-c++ Size: 2328 bytes Desc: not available URL: From mw_triad at users.sourceforge.net Fri Feb 28 19:03:14 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 28 Feb 2014 13:03:14 -0500 Subject: [PySide] Form dialog subclassing QDialog In-Reply-To: References: Message-ID: On 2014-02-28 12:32, Jérôme wrote: > What I want is to get the form values from the dialog and use them in > the add_item() function in the caller, like this: [snip] > > I could let the caller read the values in an attribute of the dialog (or > through a getter) before the dialog gets closed/destroyed, but I don't > know how to do that. That's the usual way in Qt/C++. Probably something like: # in your dialog class def value(self): return self._ui.widget.value() ...and at the call site: dlg = Dialog() if (dlg.exec_() == QDialog.Accepted) value = dlg.value() else: ...canceled... > It looks like a nicer way would be to reproduce the behaviour of the > QColorDialog, for instance. > > The caller only does > > color = QtGui.QColorDialog.getColor() This is still implemented in terms of the above. To do something like this, you could add a class method to your dialog class, e.g.: @classmethod def getValue(cls): dlg = cls() if dlg.exec_() == QDialog.Accepted: return dlg.value() # implicit return None if canceled (As a bonus, because it is Python, you can return None on cancel rather than an invalid value.) -- Matthew From a.richi at bluewin.ch Fri Feb 28 19:59:49 2014 From: a.richi at bluewin.ch (Aaron Richiger) Date: Fri, 28 Feb 2014 19:59:49 +0100 Subject: [PySide] Form dialog subclassing QDialog In-Reply-To: <559c40a34e4a59c062ece5377ce4daf3@jolimont.fr> References: <5310C95E.8000905@bluewin.ch> <559c40a34e4a59c062ece5377ce4daf3@jolimont.fr> Message-ID: <5310DCA5.3000000@bluewin.ch> Hello Jerome While I waited for your code, I just implemented a hello world application with classical ModelViewController structure that does what you want. Have a look at the NewPersonDialog class to see how it is implemented... I will have a look at your code now... Have a nice evening! Aaron ##################################import sys from PySide.QtGui import * from PySide.QtCore import * class Person(object): '''Model for a person''' def __init__(self, name, age): self.name = name self.age = age class PersonTableModel(QStandardItemModel): '''TableModel for multiple persons.''' def __init__(self, persons, parent = None): super(PersonTableModel, self).__init__(parent) self.persons = persons for i in xrange(len(self.persons)): person = self.persons[i] self.setItem(i, 0, QStandardItem(person.name)) self.setItem(i, 1, QStandardItem(str(person.age))) self.setHeaderData(0, Qt.Horizontal, "Name") self.setHeaderData(1, Qt.Horizontal, "Age") def add_person(self, person): self.persons.append(person) self.appendRow([QStandardItem(person.name), QStandardItem(str(person.age))]) class PersonTableView(QTableView): def __init__(self, model, parent = None): super(PersonTableView, self).__init__(parent) self.setModel(model) class MainWindow(QWidget): '''UI definition of the main window.''' def __init__(self, model): super(MainWindow, self).__init__() self.model = model self.setupUi() def setupUi(self): '''Initialize the GUI with different types of clickable labels''' self.layoutGeneral = QVBoxLayout(self) self.table_view = PersonTableView(self.model, self) self.pb_add = QPushButton("Add person") self.pb_delete = QPushButton("Delete person") self.layoutGeneral.addWidget(self.table_view) self.layoutGeneral.addWidget(self.pb_add) self.layoutGeneral.addWidget(self.pb_delete) class NewPersonDialog(QDialog): '''Dialog to show a form for a new person.''' def __init__(self): super(NewPersonDialog, self).__init__() self.setupUi() self.name = None self.age = None self.connectSignals() def setupUi(self): self.grid = QGridLayout(self) self.lbName = QLabel('Name:', self) self.lbAge = QLabel('Age:', self) self.leName = QLineEdit(self) self.leAge = QLineEdit(self) self.pbCancel = QPushButton("Cancel", self) self.pbOk = QPushButton("OK", self) self.pbOk.setDefault(True) self.grid.addWidget(self.lbName, 0, 0) self.grid.addWidget(self.lbAge, 1, 0) self.grid.addWidget(self.leName, 0, 1) self.grid.addWidget(self.leAge, 1, 1) self.grid.addWidget(self.pbCancel, 2, 0) self.grid.addWidget(self.pbOk, 2, 1) def connectSignals(self): self.pbOk.clicked.connect(self.on_ok) self.pbCancel.clicked.connect(self.reject) def on_ok(self): self.name = self.leName.text() self.age = int(self.leAge.text()) self.accept() class Controller(QObject): '''Controls interaction between model and view''' def __init__(self): super(Controller, self).__init__() self.model = PersonTableModel([Person("Guido", 42), Person("Bill", 55)]) self.view = MainWindow(self.model) self.connectSignals() def start(self): '''Start application''' self.view.show() def connectSignals(self): '''Connect the buttons with the corresponding slot''' self.view.pb_add.clicked.connect(self.on_add_person) self.view.pb_delete.clicked.connect(self.on_delete_person) def on_add_person(self): '''A label was clicked, show the text of the label in the display''' dialog = NewPersonDialog() if dialog.exec_(): self.model.add_person(Person(dialog.name, dialog.age)) def on_delete_person(self): '''To be implemented.''' pass def main(): app = QApplication(sys.argv) controller = Controller() controller.start() sys.exit(app.exec_()) if __name__ == '__main__': main() ################################################### Am 28.02.2014 18:47, schrieb Jérôme: > Le 2014-02-28 18:37, Aaron Richiger a écrit : >> Hello Jerome! > Hi. > >> Welcome in the PySide world... > Thank you ! > >> Would it be possible, to send us the code >> (source files). It's always great to run the code, a UI or a error >> message often says more than many words... > I deliberately stripped the relevant parts in my former message, as the > rest might be confusing. Here are the files I'm running. This is just a > test, so don't be surprised to see stupid or hardcoded stuff. > > > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.richi at bluewin.ch Fri Feb 28 20:20:02 2014 From: a.richi at bluewin.ch (Aaron Richiger) Date: Fri, 28 Feb 2014 20:20:02 +0100 Subject: [PySide] Form dialog subclassing QDialog In-Reply-To: References: Message-ID: <5310E162.7030806@bluewin.ch> Hello Jerome Find the answers to your questions below: Am 28.02.2014 18:32, schrieb Jérôme: > Hi everyone. > > I know Python and have been playing a bit with PyGTK. Now, I am > discovering Qt and PySide and I'm having a hard time trying to implement > a form dialog. > > I have a main window displaying a list of items with a few attributes. > Aside from the TableView, I added three buttons : Add, Edit, Remove. > When clicking Add, I want a new window to popup, containing a form to > enter the values of the new item. Basically, I want the dialog to have > an OK and a Cancel button. When the user clicks OK, the dialog closes, > and in the main window, the new item is added to the list. > > (I realize this may be a subcase of Edit with default values, but I'm > beginning simple with Add, and I'll figure out Edit afterwards.) > > I'm therefore creating a dialog subclassing QDialog. Both main window > and dialog window are designed with QtDesigner. > > I need a design hint and the examples I found didn't help. > > Here's my dialog class (the items happen to be buildings in this case, > hence the name), with only an __init__() function: > > class buildingDialog(QtGui.QDialog): > > def __init__(self, parent=None): > super(buildingDialog, self).__init__(parent) > self.ui = dialogBuilding.Ui_Dialog() > self.ui.setupUi(self) > > And here is the call: > > def addPushButtonClicked(self): > > dialog = bui.buildingDialog(self) > print(dialog.exec_()) > > The print is here for debug purposes and prints 0 or 1 depending on > which button was pressed. > > What I want is to get the form values from the dialog and use them in > the add_item() function in the caller, like this: > > if the return value is made of item attributes (i.e. the user pressed > OK) > add_item(attributes = return value) > else (the user pressed cancel) > nothing... > > I could modify the return value of the dialog, to return a list of item > attributes. But I suppose it's better to keep 0 and 1 as return values > and return the values another way. Besides I don't know how to do this > anyway. > > I could return a couple like [values, returnvalue], with returnvalue > being 0 or 1, but again, the return values would not be 0 or 1 anymore. > > I could let the caller read the values in an attribute of the dialog (or > through a getter) before the dialog gets closed/destroyed, but I don't > know how to do that. > > It looks like a nicer way would be to reproduce the behaviour of the > QColorDialog, for instance. > > The caller only does > > color = QtGui.QColorDialog.getColor() > > if color.isValid(): > do stuff > > But I don't know how to handle this from my custom dialog. > > I'm pretty sure this is a very common design problem. > > My questions are > > - Am I right about trying to copy QColorDialog ? I would say no. You can try to implement the usage comfort (the exampe you gave above), but copying QColorDialog would mean subclass and remove all the color stuff, add your input widgets, etc, which is much more work than just subclass QDialog and implement your dialog there... > > - If yes, do you have a hint about how to do that ? > > - If no, then what would you suggest ? Implement your own Dialog class which is a subclass of QDialog. If you want to work with QtDesigner, you could also subclass the autogenerated dialog class to add some additional sugar to it (e.g. usage comfort like in ColorDialog). You could do this in your class buildingDialog. Alternatively if you don't like sugar, this line shows how to access some inputs after your dialog.exec_() print dialog.ui.nameLineEdit.text() > > - The program I'm working on is an interface to enter data about a set > of buildings. This mechanism will be reproduced all along: a projet has > buildings with attributes (size, age,...), buildings have boiler rooms > with attributes (name, manager,...), boiler rooms have boilers with > attributes (age, efficiency,...), etc. Do you think I'm going in the > wrong direction ? Is subclassing QDialog a bad idea in the first place ? > > - Most PySide examples I found were about using common dialogs. Should I > seek C++ examples and try to adapt them ? This is always a good possibility if you really can't find python examples, because the Qt-C++ community is larger and therefore, there are more examples in C++ flying around... Translating C++ is usually quite easy, but takes some time... > > Thank you very much for any pointer. > > Have a nice week-end. > Hope this helps. Aaron From jerome at jolimont.fr Fri Feb 28 21:48:30 2014 From: jerome at jolimont.fr (=?UTF-8?B?SsOpcsO0bWU=?=) Date: Fri, 28 Feb 2014 21:48:30 +0100 Subject: [PySide] Form dialog subclassing QDialog In-Reply-To: <5310DCA5.3000000@bluewin.ch> References: <5310C95E.8000905@bluewin.ch> <559c40a34e4a59c062ece5377ce4daf3@jolimont.fr> <5310DCA5.3000000@bluewin.ch> Message-ID: <20140228214830.74e7ad86@bouzin.lan> Fri, 28 Feb 2014 19:59:49 +0100 Aaron Richiger a écrit: > def on_add_person(self): > '''A label was clicked, show the text of the label in the > display''' > dialog = NewPersonDialog() > if dialog.exec_(): > self.model.add_person(Person(dialog.name, dialog.age)) Thank you both for your answers. I wrongly assumed the dialog was destroyed at the end of the execution of its exec_() method, and therefore it was too late to get its values. This is why I was willing to provide those values as return value of exec_(). Thank you also Aaron for the extensive example. It is a true MVC design lesson. -- Jérôme From mw_triad at users.sourceforge.net Fri Feb 28 23:02:25 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 28 Feb 2014 17:02:25 -0500 Subject: [PySide] Form dialog subclassing QDialog In-Reply-To: <20140228214830.74e7ad86@bouzin.lan> References: <5310C95E.8000905@bluewin.ch> <559c40a34e4a59c062ece5377ce4daf3@jolimont.fr> <5310DCA5.3000000@bluewin.ch> <20140228214830.74e7ad86@bouzin.lan> Message-ID: On 2014-02-28 15:48, Jérôme wrote: > I wrongly assumed the dialog was destroyed at the end of the execution of its > exec_() method, and therefore it was too late to get its values. Ah... nope, just hidden :-). In fact you can call show() or even exec_() again if you like (on the same dialog). It's not destroyed until it goes out of scope, same as most classes. -- Matthew From evancoe at yahoo.com Tue Feb 18 16:07:57 2014 From: evancoe at yahoo.com (evan) Date: Tue, 18 Feb 2014 07:07:57 -0800 (PST) Subject: [PySide] QDeclarativeComponent createObject error Message-ID: <1392736077.93203.YahooMailBasic@web140704.mail.bf1.yahoo.com> Hi, I'm trying to port the simple tutorials you have written in javascript to pyside from the following links: http://qt-project.org/wiki/PySide_QML_Tutorial_Advanced_1 http://qt-project.org/wiki/PySide_QML_Tutorial_Advanced_2 http://qt-project.org/wiki/PySide_QML_Tutorial_Advanced_3 http://qt-project.org/wiki/PySide_QML_Tutorial_Advanced_4 And am having difficulty calling the createObject() method of a QDeclarativeComponent object that gets called whenever it is time to make a new block for this "samegame" example (a direct result of porting the javascript code line for line). Here's the error: TypeError: Unknown type used to call meta function (that may be a signal): QScriptValue any ideas how I'm misusing this createObject method? I understand the parent must be a QObject (which I'm complying with) and that it is not optional. Otherwise, I'm not entirely able to understand from the docs what more it should constitute and am begining to wonder if this could be a bug?: http://srinikom.github.io/pyside-docs/PySide/QtDeclarative/QDeclarativeComponent.html Thanks! Here is my pyside game logic module (normally java script in the above tutorial). All necessary QML files use QtQuick 1.0 and are identical to the tutorial so I dont repeat them here. import sys from PySide.QtCore import * from PySide.QtGui import * from PySide.QtDeclarative import * from math import floor class MainWindow(QDeclarativeView): def __init__(self, parent=None): super(MainWindow, self).__init__(parent) self.setWindowTitle("Main Window") # Renders 'view.qml' self.setSource(QUrl.fromLocalFile('game.qml')) # QML resizes to main window self.setResizeMode(QDeclarativeView.SizeRootObjectToView) self.blockSize = 40 self.maxColumn = 10 self.maxRow = 15 self.maxIndex = self.maxColumn * self.maxRow self.board = [] self.component = None #Index function used instead of a 2D array def index(self, column, row): return column + (row * self.maxColumn) @Slot() def startNewGame(self): #Delete blocks from previous game for b in self.board: b.destroy() bgnd = self.rootObject().findChild(QDeclarativeItem, name="background") width = QDeclarativeProperty(bgnd, "width") height = QDeclarativeProperty(bgnd, "height") #Calculate board size self.maxColumn = int(floor(width.read() / self.blockSize)) self.maxRow = int(floor(height.read() / self.blockSize)) self.maxIndex = self.maxColumn * self.maxRow #Initialize Board self.board = [None for _ in range(self.maxIndex)] for column in range(self.maxColumn): for row in range(self.maxRow): self.createBlock(column, row) def createBlock(self, column, row): if self.component is None: engine = QDeclarativeEngine() self.component = QDeclarativeComponent(engine, QUrl.fromLocalFile("Block.qml")) # Note that if Block.qml was not a local file, component.status would be # Loading and we should wait for the component's statusChanged() signal to # know when the file is downloaded and ready before calling createObject(). if self.component.isReady(): bgnd = self.rootObject().findChild(QDeclarativeItem, name="background") print bgnd dynamicObject = self.component.createObject(bgnd) if dynamicObject is None: print "error creating block" return False dynamicObject.x = column * self.blockSize dynamicObject.y = row * self.blockSize dynamicObject.width = self.blockSize dynamicObject.height = self.blockSize self.board[self.index(column, row)] = dynamicObject else: print "error loading block component" return False return True if __name__ == '__main__': # Create the Qt Application app = QApplication(sys.argv) # Create and show the main window window = MainWindow() context = window.rootContext() context.setContextProperty("tester",window) window.show() # Run the main Qt loop sys.exit(app.exec_())