#pyqt | Logs for 2019-01-28

Back
[03:49:42] -!- anqxyr has joined #pyqt
[04:26:48] -!- Lauxley has joined #pyqt
[04:32:29] -!- kallesbar has joined #pyqt
[07:15:12] -!- anqxyr has quit [Ping timeout: 268 seconds]
[08:39:54] -!- nsizemor has joined #pyqt
[08:54:29] -!- Siecje has joined #pyqt
[09:36:30] -!- daegontaven has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
[09:38:07] -!- daegontaven has joined #pyqt
[10:05:46] -!- david_boddie has joined #pyqt
[10:45:17] -!- AbleBacon has joined #pyqt
[10:54:37] -!- daegontaven has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
[10:55:49] -!- daegontaven has joined #pyqt
[11:20:36] -!- agile_prg3 has joined #pyqt
[11:20:53] <agile_prg3> hi altendy, check out my awsome water game! https://github.com
[11:49:24] agile_prg3 is now known as agile_prg
[12:22:13] <david_boddie> Has anyone tried to build flatpaks of PyQt applications?
[12:26:20] <Siecje> altendky: I'm convinced you are in every IRC channel. :)
[14:25:30] -!- Bjander has joined #pyqt
[14:25:56] -!- Belxjander has quit [Ping timeout: 240 seconds]
[14:26:08] Bjander is now known as Belxjander
[15:48:27] -!- david_boddie has parted #pyqt
[16:17:12] -!- mintograde has joined #pyqt
[16:40:16] -!- nsizemor has quit [Remote host closed the connection]
[16:49:00] <altendky> Siecje: a few..., though only active in two or three.
[16:53:08] -!- BPL has joined #pyqt
[17:17:12] -!- Siecje has parted #pyqt
[17:36:00] -!- AbleBacon has quit [Quit: Leaving]
[17:49:13] <agile_prg> altendky did you see my game?
[18:02:22] -!- BPL has quit [Quit: Leaving]
[18:15:49] -!- Lauxley has quit [Remote host closed the connection]
[19:14:12] -!- kallesbar has quit [Quit: Konversation terminated!]
[19:44:05] <altendky> agile_prg: haven't gotten to it yet
[21:04:00] -!- ski7777 has quit [Ping timeout: 268 seconds]
[21:34:30] -!- mintograde has quit [Ping timeout: 250 seconds]
[21:34:39] -!- caveman has joined #pyqt
[21:36:03] <caveman> hi - any reason y QWebEngineView is not under PyQt5.* but instead under PyQt5.QtWebEngineWidgets? how can i know which class is under which thing?
[21:36:56] <altendky> caveman: the qmake: row in the table at the top http://doc.qt.io
[21:38:23] <caveman> altendky: where in that should i get that qwebengineview is under qtwebenginewidgets?
[21:39:50] <altendky> caveman: the other column in the qmake: row of that table is `QT += webenginewidgets`. The webenginewidgets there corresponds to PyQt5.QtWebEngineWidgets. i know it's not exact, but we can only expect the c++ docs to document the pyqt5 wrapper so well :]
[21:41:12] <caveman> altendky: so parent modules are based on qcmake prefixed with Qt?
[21:41:35] <altendky> caveman: i believe so
[21:43:48] <caveman> thx altendky.
[21:46:15] -!- Grange has joined #pyqt
[21:48:23] <Grange> Hi all. I got question regarding QTimer in QThreads. I subclassed QThreads and used it as a worker thread, it communicates with the GUI thread via a job queue and a output queue. I want to stop the worker thread if it can't finish the job within 3 seconds, I assume I have to create a QTimer inside the worker threads, right?
[21:49:18] <altendky> Grange: be aware that if you don't properly start the event loop in the thread you can't receive any signals. or, if your code is blocking it in the thread.
[21:49:22] <altendky> Grange: what are you threading?
[21:49:24] <Grange> Could anyone give some hints how to stop the worker thread with a timer? Thanks!
[21:49:48] <altendky> and maybe don't inherit from qthread, that's a bit of an 'optimization'/'laziness' often
[21:51:43] <altendky> Grange: to help stop a thread we'll need to know what the thread is doing.
[21:51:46] <Grange> altendky, let me craft a minimal working example
[21:51:57] <altendky> Grange: generally speaking, what are you doing in the thread?
[21:52:56] <Grange> parsing some meta data inside a pdf file, and returning a dict
[21:54:11] <altendky> Grange: afaik, generally that code will have to check if the time has elapsed and stop.
[21:57:11] <altendky> Grange: i'm guessing you are making some blocking library call that you want to timeout?
[21:58:00] <Grange> altendky, yes
[21:58:45] <altendky> Grange: can the result be easily serialized? such as to json. might want to use a QProcess.
[21:59:22] <altendky> it won't use up your limited python cpu time for the gui process and you'll be able to time it out and... no threads
[22:01:28] <Grange> altendky, oh dear. I'm overloaded with information.
[22:02:08] <altendky> Grange: what is the input and output? maybe a url in and a dict out or...
[22:03:20] <Grange> altendky, input is a file path, output is a dict
[22:03:35] <altendky> Grange: dict with what in it? string keys and values?
[22:04:06] <Grange> altendky, yes, all strings
[22:04:43] <altendky> Grange: so it's easy to json.dumps() and json.loads() that. what pdf library?
[22:05:03] <Grange> altendky, pdfminer
[22:06:52] <altendky> Grange: ok. so i'd consider writing a python script that does just that part. takes the url as a cli parameter and prints the json encoded dict to stdout. you can use QProcess to call it. QProcess will be all async like other qt stuff. time it out or collect the output from the subprocess and json decode it to get the dict back
[22:07:52] <altendky> Grange: since nobody else is chiming in here, you could ask over in #python as well. other than qprocess being nice if subprocessing, i don't think qt brings much use to this issue
[22:09:35] <Grange> altendky, Ok. I'll consider that. Since I'm half way through the MWE, could you help give it a look when it's done, using the QThread approach?
[22:10:18] <altendky> Grange: sure, i just don't have any tool in mind to either kill the thread against it's will, nor interrupt the blocking library call.
[22:10:21] <altendky> Grange: well, what os?
[22:10:33] <Grange> altendky, Linux
[22:10:45] <altendky> Grange: do you care about windows support at all?
[22:11:17] <altendky> Grange: there's https://docs.python.org which _might_ be useful. it's not really great i don't think though
[22:11:31] <altendky> Grange: and it might be process global
[22:11:33] <altendky> hmm
[22:11:52] <altendky> Grange: are you looking to do several of these at once?
[22:13:20] <Grange> altendky, ideally I'd like to support windows as well. You meant several worker threads? I don't know, maybe not necessary
[22:14:35] <altendky> Grange: i think subprocessing will be the most robust solution. perhaps someone else here will chime in at some point (not the busiest channel here...) or maybe someone in #python has an idea.
[22:16:19] <altendky> (i just asked anyways)
[22:31:40] <altendky> Grange: njs (author of trio, one of the big python async libraries) answered that yes, subprocess is basically the choice you have. luckily it's not a big hassle here since your data is pretty straightforward
[22:35:36] <Grange> altendky, it's so nice of you, I just read through the python channel. And yes my QThread approach is not working. I guess that while loop in worker is blocking everything? But here is what I got: https://paste.pound-python.org
[22:36:46] <altendky> Grange: are you trying to cancel a single parsing job? or a queue of them?
[22:37:24] <altendky> Grange: but yes, you overrode run which is where QThread normally starts it's event loop. plus, you have a while that'd keep the event loop from ever getting any time anyways.
[22:38:12] <altendky> Grange: basically may as well have been a threading.Thread. if you want a 'happy' qt thread you have to start the event loop. at which point you often may as well not inherit from QThread and just move a worker object into it
[22:38:33] <altendky> (i think that's the first example in the qt threading page, what you've got is the second example, iirc)
[22:42:56] <Grange> altendky, so a subclassed QThread doesn't start its own event loop in its run()?
[22:43:32] <altendky> Grange: you overrode it, it has no control of what happens when it calls run() anymore :]
[22:43:44] <Grange> altendky, I see
[22:44:17] <Grange> altendky, I've to do a bit more reading and searching
[22:44:58] <altendky> Grange: are you trying to cancel a single parsing job? or a queue of them?
[22:46:03] <Grange> altendky, a single one, because most of the time it finishes rather quickly, but occasionally some pdf takes minutes for some reason
[22:46:22] <altendky> Grange: yep, still sticking with subprocessing :]
[22:46:56] <altendky> Grange: at which point you can handle the queue all async in the main thread and even launch multiple parsing processes simultaneously
[22:47:25] <altendky> (well, you could do that with threads as well, but that'd get to bogging down your gui and the parsing probably)
[22:49:43] <Grange> altendky, ok I'm convinced now.
[22:51:25] <altendky> Grange: qt might have some process pool something, i don't know
[23:10:09] <altendky> so i've got a QStandardItemModel behind my own python modely thing. do i need to hold references to all the QStandardItems i create? doing so presently is a significant performance hit. my woefully incomplete test suite doesn't trigger a failure without explicitly holding references.