#pyqt | Logs for 2019-01-04
Back
[01:14:27] -!- agile_prg has quit [Read error: Connection reset by peer]
[01:15:51] -!- mandeep has joined #pyqt
[01:25:12] <russw> altendky: finally got pyqt5qmlplugin.dll working
[01:27:52] <russw> I had to compile pyqt5 myself. I wiped vs2017 and installed vs2015 32-bit. Then built sip and pyqt5 (needed to disable QtNfc). Then snagged the pyqt5qmlplugin.dll from that build and put it in the Charts dir (just as on linux), and it worked right away
[01:28:59] <russw> QML2_IMPORT_PATH was set to the parent dir with (Charts/ as a subdir) and the PATH had the dir with all the Qt DLLs in it (C:\Qt\5.11.3\msvc2015\bin)
[01:29:21] <russw> calling it a night now... can reconvene tomorrow
[02:11:05] -!- russw has quit [Read error: Connection reset by peer]
[02:38:05] -!- kallesbar has joined #pyqt
[03:11:43] -!- Belxjander has quit [Ping timeout: 245 seconds]
[03:12:21] -!- Belxjander has joined #pyqt
[03:26:09] -!- BPL has joined #pyqt
[04:12:33] -!- anqxyr has joined #pyqt
[04:17:05] -!- anqxyr has quit [Ping timeout: 250 seconds]
[05:25:28] -!- kallesbar has quit [Read error: Connection reset by peer]
[05:25:52] -!- kallesbar has joined #pyqt
[07:32:28] -!- Belxjander has quit [Quit: AmigaOSv4.1.6+//PowerPC native]
[07:32:59] -!- Belxjander has joined #pyqt
[08:46:37] -!- Belxjander has quit [Quit: AmigaOSv4.1.6+//PowerPC native]
[08:47:03] -!- Belxjander has joined #pyqt
[09:09:10] -!- Belxjander has quit [Quit: AmigaOSv4.1.6+//PowerPC native]
[09:09:38] -!- Belxjander has joined #pyqt
[10:53:57] -!- russw has joined #pyqt
[11:19:05] <russw> altendky: more info... your pyqt5qmlplugin.dll seems fine. the problem seems to be your qmlscene.exe (or how it searches paths)
[11:20:10] <altendky> russw: i noticed you said qt 5.11.3 not 5.11.2. but yeah, i'll probably have to pull up a tree and compare and fiddle
[11:20:47] <russw> I took my functional environment where I used 1) the "pure" Qt 5.11.3 qmlscene.exe and 2) my compiled pyqt5qmlplugin.dll, and swapped out both 1 and 2 with the exe and dll from pyqt5_tools. dll was ok. exe was noe.
[11:20:49] <russw> *not
[11:20:57] <altendky> russw: just adding site-packages\pyqt5_tools to PATH wasn't enough, right?
[11:21:18] <russw> I believe not
[11:21:47] <altendky> so it's probably kinda misreporting Qt5Quick.dll not finding something as if it hadn't found the dll at all
[11:22:32] <russw> Notes I took from scratch (using powershell): https://bpaste.net
[11:23:47] <russw> where "scratch" includes dropping the pyqt5qmlplugin.dll file into the ./Charts/ dir
[11:25:26] <altendky> russw: so i need to figure out that last part for Qt5Quick.dll to work. i need to adjust the PATH to include the directory with python.exe. make an auto-copy for pyqt5qmlplugin.dll or such. the QML2_IMPORT_PATH note is something it makes sense for the user to do though? or maybe i should add that based on the path of the .qml they pass.
[11:25:55] <russw> the "resolved by getting python dll into the path" bit was determined by watching operations with processmonitor (seems to be the best strace-like thing in windows). Couldn't figure out the failed QtQuick import this way, though.
[11:26:45] <russw> to be nitpicky, the PATH bit needs the python3.dll, not the exe
[11:26:59] <altendky> russw: nitpicky is good
[11:27:13] <russw> as for auto-copying the pyqt5qmlplugin.dll, I wouldn't do that. Docs do indicate there are a few ways to handle that dll inclusion. Forcing a copy might be weird.
[11:27:17] <altendky> especially since env and system install layouts aren't quite the same
[11:27:52] <altendky> russw: i figured it'd default to copying with an option to not (or the other way, maybe)
[11:27:54] <russw> for QML2_IMPORT_PATH, that shoudl probably be left to the user as well, as you say
[11:28:08] <russw> but... I dunno. maybe.
[11:28:19] <russw> not, it would be confusing to change that
[11:28:23] <altendky> russw: maybe. i mean you specify a file, do you really want to have to specify the directory the file is in every time?
[11:28:59] <altendky> i mean the point of the pyqt5qmlscene wrapper is to add nice things. the point of qmlscene is to just give access to the existing program
[11:29:17] <altendky> (of my qmlscene created in scripts by the entry_points)
[11:29:46] <russw> creating python plugins to work with qml is tricky as it is. I have multiple dirs in a tree with qmldir specs (like __init__.py, basically). QML2_IMPORT_DIR is important to be correct, so tampering with it could be weird.
[11:30:25] <altendky> russw: adding the dir that the passed .qml file is in?
[11:30:27] <russw> if you *did* change it... what would it be changed to? There is no good answer I can think of.
[11:31:07] <altendky> russw: instead of having to type `pyqt5qmlscene -p blue blue/red.qml` the -p blue would be automatically added (with a parameter to not do that)
[11:31:34] <altendky> russw: any existing QML2_IMPORT_DIR would be retained just as it is now
[11:31:58] <russw> just thinking through my use cases (qhich are mostly for qmltestrunner and Qt Creator integration, fwiw)
[11:32:01] <altendky> and the full value would be printed as now so you can see what is actually being used
[11:32:40] <altendky> maybe move the prints to a verbose mode or somesuch but... somehow easily available
[11:34:18] <russw> the import dir is only relevant when you've done a few things... 1) made the pyqt5qmlplugin.dll available in that dir, and 2) written foo_plugin.py that support qml plugins, and 3) created a qmldir file in that dir
[11:34:48] <altendky> oh, _DIR vs _PATH
[11:34:56] <altendky> missed there were two :[
[11:35:10] <russw> implicitly assuming that those things were done in the same dir as the qml file you are trying to execute doesn't seem like it would be good to me... but I'm not sure
[11:36:04] <altendky> russw: are you talking about _DIR or _PATH? xx:29 was the first reference to _DIR from what i see
[11:36:05] <russw> for the dll location (1) there are some other options than direct dll inclusion I recall... but not sure if possible in Windows like in linux
[11:36:15] <russw> not sure what you mean
[11:36:23] <russw> oh
[11:36:49] <altendky> i don't and we hadn't discussed tampering with QML2_IMPORT_DIR so... :] not sure why that came up
[11:37:30] <russw> checking docs... I didn't think there were two. Might be just typing/memory mistakes.
[11:37:32] <altendky> on $PATH, i already add sys.executable's parent in pyqt5designer https://github.com
[11:37:51] <altendky> so i should probably do that as well in pyqt5qmlscene, might cover the path thing
[11:38:10] <altendky> you could try copy/pasting that if you want in the installed entrypoints.py file
[11:38:14] <russw> QML2_IMPORT_DIR isn't a thing. it is QML2_IMPORT_PATH
[11:38:50] <russw> qmltestrunner needs it, too
[11:39:10] <altendky> russw: i'll make a function to help out with this garbage i've been copy/pasting
[11:39:39] <russw> but the main thing seems to be that the qmlscene.exe you scoop doesn't work (at least as-is). Remember that using it raw can't even import QtQuick in qml.
[11:39:57] <altendky> russw: right, i'm ignoring the hard part for the moment. :]
[11:40:10] <altendky> it won't get worked on right now, the other stuff might get slipped in
[11:41:58] <russw> I don't get why your qmlscene.exe wouldn't work, but other stuff would... so I suspect it is a local path lookup thing somehow. i.e. the functional qmlscene.exe from my "real" Qt dir has adjacent files that it needs.
[11:42:50] <altendky> russw: yeah. i just plan to setup the failure, pull up a qt installed bin dir and compare with my thing and manually copy files over to explore
[11:42:54] <altendky> or move them around or...
[11:43:08] <altendky> and maybe find a tool to help, if i'm super lucky
[11:43:13] <russw> I'm experimenting... gimme a minute
[11:43:29] <altendky> you'd think just dependency walker or dependencies or such directly on qt5quick.dll would do it but...
[11:46:38] <russw> altendky: ok, so files adjacent to qmlscene.exe definitely matter...
[11:46:40] <russw> https://bpaste.net
[11:47:00] <russw> not sure what was missing, but something sure was
[11:47:44] <altendky> russw: sure. the first layer is that i use windeployqt to get files that it thinks the qmlscene.exe needs. but apparently it doesn't get enough
[11:47:52] <altendky> or puts it in the wrong place, or...
[11:48:14] <russw> never heard of windeployqt... have to look that up
[11:48:15] <altendky> https://ci.appveyor.com
[11:48:46] <altendky> i was very happy to find it for this
[11:49:36] <altendky> russw: maybe copy the whole bin directory from your qt install somewhere and see if that qmlscene works. if so, start deleting files until it breaks. :]
[11:56:35] <russw> altendky: so... ??? I just copied the full Qt bin directory to do that... and the resulting qmlscene.exe doesn't actually work!!? can't import Quick?!!
[11:57:00] <russw> I sure hope there is not a .. in the search paths somewhere
[11:57:09] <altendky> it would seem there is...
[11:57:24] <altendky> or an absolute path
[11:57:42] <altendky> copy the parent i guess and try again
[12:01:24] <russw> no surprise that that worked, since it was the whole \Qt\msvc2015\ dir
[12:01:37] <russw> this is painful
[12:01:47] <altendky> and no for the fun deleting
[12:01:50] <altendky> *now for
[12:05:23] -!- Belxjander has quit [Quit: AmigaOSv4.1.6+//PowerPC native]
[12:05:47] -!- Belxjander has joined #pyqt
[12:05:59] <altendky> also, that use there is it clarifies it is a relative path
[12:07:02] <russw> got it
[12:07:21] * altendky anticipates
[12:07:33] <russw> there is a "qml" dir beside the "bin" dir... that needs to be there for qml stuff
[12:07:44] <russw> looking inside it it is unsurprising. it has all the imports.
[12:08:10] <russw> verified by just copying the bin and qml dirs adjacent to each other and using the qmlscene.exe inside that
[12:08:15] <russw> works
[12:08:15] <altendky> fun. so i shouldn't be shortcutting the bin/
[12:08:32] <altendky> russw: thanks for all this
[12:08:39] <russw> it's anotehr 30 MB
[12:08:43] <russw> altendky: np :)
[12:08:48] <altendky> golly gee
[12:09:28] <altendky> looks like i'll still be around 90mb worst case for the wheels (minus any compression) so under the 100mb or whatever limit
[12:10:33] <russw> hold up... those files might already be in phil's release... checking
[12:10:42] <russw> might just need some path tweaking or symlinking
[12:10:53] <altendky> so far i'm duplicating
[12:11:12] <altendky> symlinking is probably out, that requires elevated privileges on windows afaik
[12:11:41] <altendky> but if you found another way to reuse... i guess there are namespace packages but... eh
[12:12:56] <russw> Not sure, but they are definitely there
[12:13:02] <russw> on my system, for example:
[12:13:04] <russw> C:\Users\Russ\AppData\Local\Programs\Python\Python37-32\Lib\site-packages\PyQt5\Qt\qml\
[12:13:53] <altendky> russw: i'll at least look at matching that structure.
[12:14:27] <russw> Best bet would probably be finding where the heck there is a ../qml/ search in whatever qmlscene.exe is doing
[12:14:44] <russw> if you are going to duplicate, you can probably just use the qmlc files... much smaller
[12:15:03] <altendky> let's get it working first, optimize later. :]
[12:15:32] <russw> I'm also lying, apparently... they are bigger
[12:15:59] <russw> phil has both in there. I wonder if he includes both or if they compile after install?
[12:16:31] <altendky> wheels are zips...
[12:17:08] <russw> and yet I can see directly inside here, as a random example:
[12:17:08] <russw> C:\Users\Russ\AppData\Local\Programs\Python\Python37-32\Lib\site-packages\PyQt5\Qt\qml\QtQuick\Dialogs
[12:18:38] <russw> it is *so annoying* to be looking at the pyqt5 wheel deployment and see the bin/ dir sitting RIGHT THERE, with the required qml dir beside it, but no exe files in sight inside the bin dir... grr
[12:24:29] <russw> altendky: just pinged #qt-quick to see if that requirement on ../qml/ can be tuned somehow
[12:24:49] <altendky> russw: i really don't mind the extra directories
[12:25:27] <russw> ok
[12:25:46] <russw> I'm still curious, as I find a hard-coded requirement for a ../qml/ path to be very odd
[12:33:24] -!- Belxjander has quit [Quit: AmigaOSv4.1.6+//PowerPC native]
[12:33:49] -!- Belxjander has joined #pyqt
[12:51:02] <russw> altendky: if you specify that ../qml/ dir as a -I option to qmlscene.exe it works
[12:51:40] <altendky> russw: hmm... don't care within pyqt5-tools but that would enable sharing with pyqt5
[12:52:26] <altendky> though i'll have to think through how many things that'd make sense for. not sure how helpful it is to become totally dependent and have to pass parameters to every program
[12:59:13] <russw> yep. I consider it as another learning point and another mystery solved. :)
[13:26:17] <russw> For future note, setting `QT_DEBUG_PLUGINS=1` helps trace some of the searching that Qt does for plugins
[13:26:44] <altendky> thanks
[13:48:36] -!- Belxjander has quit [Quit: AmigaOSv4.1.6+//PowerPC native]
[13:48:59] -!- Belxjander has joined #pyqt
[14:05:45] -!- kallesbar has quit [Quit: Konversation terminated!]
[14:42:38] -!- thomasross has quit [Remote host closed the connection]
[14:43:04] -!- thomasross has joined #pyqt
[16:05:14] <russw> altendky: also, while trying to replay all of this to make sure it works for me, I was running into problems with debug/release builds of Qt libs
[16:05:25] <russw> specifically (one example): "The plugin 'C:/Qt/5.11.3/msvc2015/plugins/platforms/qdirect2dd.dll' uses incompatible Qt library. (Cannot mix debug and release libraries.)"
[16:06:01] <russw> without QT_DEBUG_PLUGINS=1 that resulted in a silent failure where I had no idea what was going on
[16:06:37] <altendky> russw: i've got some changes in place, working through the kinks in the appveyor build
[16:06:38] <russw> in short: make sure the stuff you are pulling is compatible with what phil is dong. I wonder if this was some of the problem before I compiled it myself? Dunno.
[16:07:12] <russw> being slave to the appveyor build would make me a bit nervous
[16:07:20] <russw> any reason you don't compile it yourself?
[16:08:06] <altendky> russw: i mean it's just kinks in the build :] not appveyor's fault. but i think it's my crappy build setup at the moment. i don't even remember if i'm building in an env or not
[16:17:46] <altendky> russw: and you can rdp into the build. but sure, yeah, it's not a great place to be that you can _only_ build there
[16:18:31] <russw> I'm also in a "not a great place to be"... can't get anything working anymore for some reason
[16:18:32] <russw> argh
[16:18:34] <russw> why is this so hard
[16:19:31] <russw> my "nervous" statement earlier was reagrding scooping their Qt build binaries, vs you building them yourself. Not relying on their build machine.
[16:20:43] <altendky> russw: afaik phil does the same
[16:21:05] <russw> altendky: with appveyor, even?
[16:21:17] <altendky> russw: i assume not that, but who knows
[16:21:30] <altendky> russw: that's the secret world of pyqt
[16:21:42] <altendky> open source, but you can't look behind the reinforced concrete wall
[16:32:15] -!- mintograde has joined #pyqt
[16:33:21] <altendky> russw: uh... yeah. 162mb now. :] gonna have to trim
[17:32:46] -!- Belxjander has quit [Quit: AmigaOSv4.1.6+//PowerPC native]
[17:33:21] -!- Belxjander has joined #pyqt
[17:58:36] -!- TunaLobster has joined #pyqt
[18:58:12] -!- TunaLobster has quit [Ping timeout: 258 seconds]
[19:02:59] -!- BPL has quit [Quit: Leaving]
[19:23:37] -!- TechSmurf has quit [Ping timeout: 250 seconds]
[19:25:29] -!- TechSmurf has joined #pyqt
[19:30:26] -!- Belxjander has quit [Quit: AmigaOSv4.1.6+//PowerPC native]
[19:30:51] -!- Belxjander has joined #pyqt
[22:39:51] -!- kallesbar has joined #pyqt
[22:57:47] -!- mintograde has quit [Ping timeout: 258 seconds]
[23:09:17] -!- thomasross has quit [Ping timeout: 258 seconds]