#pyqt | Logs for 2019-01-27

Back
[01:33:56] -!- Belxjander has quit [Ping timeout: 272 seconds]
[01:34:58] -!- Belxjander has joined #pyqt
[01:36:30] -!- Belxjander has quit [Max SendQ exceeded]
[01:36:56] -!- Belxjander has joined #pyqt
[04:40:31] -!- kallesbar has joined #pyqt
[04:41:42] -!- anqxyr has joined #pyqt
[05:02:25] -!- BPL has joined #pyqt
[06:41:48] -!- kallesbar has quit [Quit: Konversation terminated!]
[06:49:21] -!- kallesbar has joined #pyqt
[07:27:52] -!- mintograde has joined #pyqt
[08:38:20] <BPL> any pearls of wisdom about this one https://stackoverflow.com ? Thanks in advance
[09:03:53] <altendky> BPL: it seems like you are taking ownership of the window but never don't anything to release it. Just leaving it in a qt window that might be getting collected/deleted
[09:04:13] <altendky> BPL: and maybe there's CalcWindow instead of CalcFrame?
[09:15:03] <BPL> altendky: Sorry, I'm back, I was having lunch... mmm, that sounds plausible, in any case, did you spot anything very wrong in the posted code? I've posted that mcve after being almost the whole morning trying to figure out these little but annoying issues :/
[09:16:15] <altendky> BPL: I don't know this stuff. Above is what stood out to me, though it may not be valid.
[09:17:28] <BPL> altendky: ok, thanks anyway... I'll continue researching about it, although i've read the docs and I haven't catched anything that could help me out :/
[11:35:52] -!- tijensse has joined #pyqt
[12:23:16] <Avaris> BPL: try calling self._window.deleteLater()
[12:27:02] <BPL> Avaris: Where? Cos if I call it before `self._window.setParent(None)` I'll get a nice runtime crash :O
[12:30:00] <BPL> also you'll get a crash when used after self._window.setParent(None)... anyway, let me try to understand the reason of that crash reading what that function is all about
[12:35:13] <Avaris> does python quit after you close calc?
[12:35:33] <BPL> no
[12:36:07] <Avaris> what if you close it before closing the window?
[12:36:14] <BPL> i'm thinking... what does `self._widget = None` suggest to you?
[12:36:42] <BPL> that QWidget should be GC... right? but maybe that's not the case?
[12:36:57] <BPL> maybe it's holding some reference I'm missing?
[12:37:02] <Avaris> yeah, should be roughly same as deleteLayer
[12:37:11] <Avaris> *deleteLater
[12:37:16] <BPL> `what if you close it before closing the window?` => neither...
[12:38:01] <Avaris> hmm... store the Popen and terminate in closeEvent?
[12:38:14] <BPL> :D
[12:39:23] <BPL> not an option, the shown code is just a little example but in the real world scenario i'm able to attach/detach different apps to my pyqt app and I wouldn't like to kill detached process when closing my pyqt app
[12:39:32] <BPL> in any case, just for the sake of testing let me see...
[12:40:30] <Avaris> well, for this one you're spawning a process from python and os might be thinking that a child process is still active and not close python
[12:40:49] <BPL> mmmm... you're actually right :O , i hadn't considered that
[12:41:07] <BPL> in the real app i'm attaching detached processes, not child ones, tsk :P
[12:41:12] <BPL> good point
[12:49:50] <BPL> jeez, what a mess, i had like 25 opened orphan python processes... i've cleaned my processes tree and now I'm gonna test properly while tracking how the tree hierarchy is affected after each test :P
[12:50:49] <BPL> Ok, I'll be making a little report here with proper testing, consider the original mcve https://bpaste.net
[12:53:47] <BPL> 1 Test) If I close the mainwindow without attaching the calc at all https://dl.dropboxusercontent.com I'll get this https://dl.dropboxusercontent.com
[12:55:52] <BPL> mmm... actually, why isn't the closeEvent being fired when closing the mainWindow?
[12:59:59] <BPL> 2 test) I attach + I detach, I close calc (calc process is killed) and python process remains alive
[13:00:33] <BPL> and in this case if i force with ctrl+break I'll get `QObject::~QObject: Timers cannot be stopped from another thread` in the cmd
[13:03:05] <BPL> 3 test) If I attach and I close the mainwindow everything is OK, no orphan processes at all, everything clean
[13:05:10] <BPL> anyway, i'll stop here, this basically means my detach method is just broken... in fact, if you're doing `self.your_variable = None` and expecting everything will be cleaned magically you're too optimistic :(
[13:08:12] <altendky> Yeah, I wouldn't expect dropping a reference to do a good job of cleaning up a qt object and returning ownership of a native window to another process. :] Seems like the other application might need to support this maybe?
[13:09:11] <BPL> altendky: I've get rid of these funny `self.whatever = None` from my detach method and now I'm playing with the deleteLater method suggested by avaris, i think that could lead me to the right code, who knows :D
[13:10:13] <altendky> BPL: keeping a python reference but deleting the underlying qt object sounds bad too
[13:10:55] <BPL> altendky: Indeed, in any case, first I need to understand under which conditions closeEvent won't be fired, that's my first task in order to narrow down this one
[13:11:07] <altendky> Point is there are three or more layers, each unaware of those above it
[13:11:51] <altendky> I might go talk to windows, or at least qt, people about this transferring of window control
[13:12:07] <altendky> That's the core activity
[13:12:09] <BPL> I laughed a lot few hours ago when read, "The container takes over ownership of window. The window can be removed from the window container with a call to QWindow::setParent().
[13:12:09] <BPL> "
[13:12:22] <BPL> too optimistic comment there which doesn't explain anything :P
[13:13:25] <BPL> also says "The window container is attached as a native child window to the toplevel window it is a child of. When a window container is used as a child of a QAbstractScrollArea or QMdiArea, it will create a native window for every widget in its parent chain to allow for proper stacking and clipping in this use case."
[13:16:26] <altendky> I do actually want to be able to 'combine' windows from separate processes myself, albeit all pyqt applications
[13:16:33] <BPL> altendky: btw, you're gonna laugh... but this little experiment started because few days ago i decided to go with latest qscintilla+pyqt versions for x86 and giving up on the fact of compiling qtwebengine for it so I thought... ok, lets embedd directly chrome on my app and that's it :'D . If you don't go to mahomma... mahomma goes to you... :P
[13:16:44] <altendky> But I haven't gotten around to trying over the past couple years
[13:17:37] <BPL> actually, "if the mountain won't come to Muhammad, then Muhammad must go to the mountain"
[13:17:41] <BPL> :'D
[13:19:40] <BPL> but yeah, combining windows from separate processes is interesting per-se (if done properly), you just establish a good communication protocol in your host and you're done. You use multiprocessing plugabble apps for free
[13:22:02] <altendky> There would be minimal communication between the GUI stuff. Most comms would be between the GUI slaves and their Network processes
[14:19:52] -!- daegontaven has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
[14:21:11] -!- daegontaven has joined #pyqt
[15:11:48] -!- anqxyr has quit [Read error: Connection reset by peer]
[16:08:23] -!- TurBoss has parted #pyqt
[17:23:13] -!- kallesbar has quit [Quit: Konversation terminated!]
[19:00:19] -!- BPL has quit [Quit: Leaving]
[22:10:12] -!- mintograde has quit [Ping timeout: 246 seconds]