#pyqt | Logs for 2019-02-02

Back
[00:04:18] -!- mintograde has quit [Ping timeout: 250 seconds]
[03:28:48] <Mrokii> altendky: Thanks, I'll take a look. I have looked into delegates some time ago but wasn't quite sure how to use them for my purposes. I'll try again.
[06:56:53] -!- mintograde has joined #pyqt
[09:46:34] -!- acwatt has joined #pyqt
[12:23:47] -!- acwatt has quit [Ping timeout: 256 seconds]
[14:16:30] -!- BPL has joined #pyqt
[16:54:19] -!- nilshi has joined #pyqt
[16:54:31] <nilshi> hello
[16:55:49] <nilshi> my window geomtry is always reported at position 0,0 even though that is clearly not the case. Does this super minimal problem give you the same output?
[16:55:51] <nilshi> https://0bin.net
[16:56:44] <nilshi> In another, more complex, application I have a python interpreter during runtime. If I print geometry out then it will be correct. So there seems to be a timing issue. But how could I ever receive the correct position of my window on the desktop after show?
[16:57:19] <nilshi> my initial problem was that QDialogs do not pop up at their parents center anymore but anywhere on the desktop (where the WM likes it).
[17:02:48] <BPL> nilshi: i've tried your mcve and here it reports PyQt5.QtCore.QRect(640, 280, 640, 480)
[17:02:48] <BPL> PyQt5.QtCore.QRect(632, 250, 656, 518)
[17:03:03] <nilshi> yeah, something is wrong here
[17:03:06] <nilshi> I get 0,0
[17:03:13] <nilshi> thank you
[17:03:29] <BPL> nilshi: did you read the docs? ie: "This property holds the geometry of the widget relative to its parent and excluding the window frame"
[17:04:03] <BPL> and frameGeometry --> "geometry of the widget relative to its parent including any window frame"
[17:04:05] <nilshi> I nearly know the docs by heart :/
[17:04:22] <nilshi> it also says if a widget is a window its position will be the desktop position
[17:04:31] <nilshi> and if I mapToGlobal it is the same 0,0 anywayx
[17:04:43] <BPL> in the example you're using QWidget
[17:05:59] <BPL> https://dl.dropboxusercontent.com
[17:06:17] <nilshi> yes, thanks.
[17:06:31] <nilshi> the point is that your output is coordinates and mine is 0,0 position
[17:06:51] <nilshi> that confirmed I have either a local problem or we have different qt versions and I have a bug
[17:07:53] <BPL> PyQt5==5.11.3 + py3.6.x(x86) + win7 over here
[17:08:06] <nilshi> PyQt 5.11 with Qt 5.12
[17:08:28] <nilshi> linux, different window managers. A friend of mine confirmed just now that he also sees good coordinates
[17:10:51] <BPL> did you read X11 peculiarities section?
[17:11:22] <BPL> http://doc.qt.io
[17:11:30] <nilshi> yes. I did not joke that I know the docs nearly by heart
[17:12:06] <BPL> ok :)
[17:27:08] -!- Mrokii has quit [Ping timeout: 268 seconds]
[17:38:40] <altendky> nilshi: did you try printing some time after the window is actually shown? There are lots of things that don't get properly updated until the event loop is going and had a chance to process activities
[17:39:15] <altendky> QTimer single shot for a second later as a test
[17:39:24] <nilshi> if I delay a 4ms timer it works
[17:39:32] <nilshi> what a coincidence, just tried that :)
[17:40:06] <nilshi> now I need to find a reliable test to make sure everything is ready. now guesswork
[17:40:16] <altendky> nilshi: that's pretty normal in my experience. And at least vaguely makes sense
[17:40:31] <altendky> nilshi: what are you actually trying to achieve?
[17:41:45] <nilshi> altendky: I am trying to find out why reparenting a QDialog does not lead to it being centered on the parent window
[17:42:01] <nilshi> if it is a timing issue then the dialog won't have the correct positional informations either
[17:42:04] <Avaris> nilshi: iirc, it doesn't automagically center
[17:42:15] <nilshi> it does, the docs say so
[17:42:17] <altendky> nilshi: reparenting when? And might be window manager dependent
[17:42:35] <nilshi> I tested with 3 different window managers. After mainwindow.show and dialog show
[17:42:52] <altendky> nilshi: I would set the parent before showing
[17:43:05] <altendky> On dialog creation for that matter
[17:43:08] <nilshi> that already happens in init
[17:43:18] <nilshi> I wrote "reparenting".
[17:43:24] <nilshi> in any case, nothing did work and now I know why
[17:43:26] <Avaris> nilshi: which docs?
[17:43:28] -!- Mrokii has joined #pyqt
[17:43:45] <nilshi> Avaris: http://doc.qt.io
[17:44:01] <nilshi> "its default location is centered on top of the parent's top-level widget (if it is not top-level itself)."
[17:44:42] <Avaris> hmm, can you show code?
[17:44:55] <altendky> nilshi: yes, you said reparenting. You are saying that the parent is set before showing the dialog
[17:45:09] <altendky> ?
[17:45:48] <altendky> It does center for me when I provide the parent at construction time
[17:46:25] <nilshi> altendky: the QDialog is subclassed and on calling super I give it the parent, as usual with all widgets. Since that did not work I made an additional reparenting after the dialog is shown, combined with some calculation based on window positions. That lead me to the fact that my windows are all at 0,0 at that time
[17:46:46] <nilshi> ironically for me it always was (just with giving the parent on init) but for my users it wasnt
[17:46:59] <nilshi> I didn't realize there was a problem.
[17:47:17] <nilshi> in any case, I now have the knowledge to force that on the right position, no matter the circumstances
[17:48:09] <altendky> nilshi: can you share code? Have you checked for a qt bug?
[17:48:53] <altendky> nilshi: it really seems wrong to need to use a timer and manually set the position.
[17:49:03] <nilshi> altendky: I got two confirmations from different systems with same pyqt versions at least.
[17:49:19] <altendky> nilshi: I'm not questioning you having a problem
[17:49:23] <nilshi> I know
[17:49:26] <Avaris> are you using .show or .exec?
[17:49:30] <nilshi> I don't like that solution at all
[17:49:39] <altendky> nilshi: maybe you are showing the dialog before the parent had been positioned?
[17:50:34] <nilshi> I use show() with setModal(True)
[17:50:49] <nilshi> altendky: the positions strongly hint at that, yes
[17:51:06] <altendky> nilshi: get into the event loop and work async asap...
[17:51:23] <altendky> Don't do lots of sync setup, especially not for window positions
[17:52:25] * Avaris is thinking that some (example) code would do wonders
[17:53:00] <altendky> Yup...
[17:53:11] <nilshi> not that easy
[17:53:42] <altendky> Work async...
[17:54:53] <nilshi> that is my about file https://pastebin.com
[17:55:50] <nilshi> in the main window init I basically do: self.about = About(self) [...] self.show() [...] self.about.show()
[17:56:45] <Avaris> are you able to reproduce the not-centered-dialog on your local system?
[17:56:57] <nilshi> yes, in multiple window managers
[17:57:16] <nilshi> except my main one, which apparently does some positioning itself.
[17:57:39] <Avaris> if you do `QTimer.singleShot(0, self.about.show)`, does that work?
[17:57:54] <nilshi> that does work, but as we all agreed earlier that is a bit hacky
[17:57:54] <Avaris> * instead self.about.show() ^
[17:58:05] <nilshi> not 0, but 4ms and up
[17:58:36] <nilshi> if I go the timer route I need to make sure the GUI is ready, not guessing a timer value
[17:59:10] <Avaris> what about overriding showEvent in mainwindow and showing dialog there?
[17:59:39] <altendky> nilshi: why are you launching your about dialog when you launch your main window
[17:59:40] <nilshi> wouldn't that be triggered by mainWindow.show() ?
[18:00:06] <nilshi> altendky: it doubles as greeting dialgo with "did you know" help tips
[18:00:57] <nilshi> Avaris: or no, show() is just the execution. The event happens later. I could try that
[18:01:04] <Avaris> not immediately, no. show event will happen by event loop
[18:02:56] <altendky> http://doc.qt.io Wow, I sure would have expected qwidget to have more than three signals
[18:03:00] <nilshi> yes, that has a different expect
[18:03:45] <nilshi> *effect
[18:08:31] <Avaris> altendky: there are a few from qobject
[18:11:11] <altendky> Avaris: yes, two. I expected dozens
[18:11:26] <nilshi> interestingly if I print the position or geometry in the mainWindows showEvent I still get the wrong numbers
[18:11:31] <Avaris> not much to signal i guess?
[18:11:50] <Avaris> nilshi: wrong how?
[18:13:18] <nilshi> 0,0
[18:13:39] <nilshi> it should be at 1918 or so
[18:16:33] <Avaris> if you don't mind, can you override `event` in mainwindow and `print(event.type())` and paste the result somewhere?
[18:17:02] <Avaris> * don't forget to call the super btw :)
[18:17:36] <nilshi> what does that return?
[18:17:38] <nilshi> bool for.. ?
[18:18:11] <Avaris> `return supert().event(event)`
[18:18:21] <Avaris> *super()
[18:18:33] <nilshi> of course...
[18:19:03] <nilshi> that is quite a long list
[18:19:09] <nilshi> even without mouse and keyboard event
[18:19:16] <Avaris> normal
[18:19:42] <nilshi> https://pastebin.com
[18:20:18] <nilshi> the QPoint is printed in the QDialog showEvent (with 4ms artificial timer latency)
[18:23:28] <Avaris> thanks
[18:27:23] <Avaris> that's odd. there is multiple move and resize events...
[18:28:30] <nilshi> that may be my tiling window manager
[18:28:38] <nilshi> but that is only noise. in xfce the problem is the same
[18:28:51] <nilshi> or openbox.
[18:33:11] <Avaris> hmm, i have a xfce vm. let me try
[18:34:12] <nilshi> on other peoples system it worked. BPL earlier and a linux friend of mine both confirmed that in my mini test program they got good positions, without any delay timer
[18:34:34] <nilshi> I don't know if you've seen that, that is really a minimal program. There is nothing to wait for
[18:34:44] <nilshi> https://0bin.net
[18:35:10] <Avaris> yeah, that works on my windows as well
[18:37:34] <Avaris> on xfce i get 0,0 like you
[18:38:38] <nilshi> def onStart(): print (widget.geometry()); QtCore.QTimer.singleShot(10, onStart)
[18:38:43] <nilshi> put that between show and exec
[18:40:11] <nilshi> by now I am ready just to use the timer for my program. Some problems are just not worth so many hours.
[18:40:16] <Avaris> yup, there is two `MoveEvent`s and the one after show is the actual one
[18:41:42] <Avaris> looks like this: https://dpaste.de
[18:42:08] <Avaris> (first is the old position, second is the new one)
[18:42:35] <nilshi> I need to make sure paint has happened
[18:42:46] <Avaris> hmm?
[18:43:29] <nilshi> it looks like PaintEvent is a good condition when to create the about dialog
[18:43:52] <Avaris> errr... it's also called *a lot*
[18:44:00] <nilshi> that is a problem, yes :)
[18:44:08] <nilshi> I'm not overriding paint event
[18:44:36] <nilshi> the question is if you can query if paint has happened
[18:45:04] <Avaris> i'd go with qtimer tbh. just put enough buffer. a few hundred ms isn't a big deal
[18:45:54] <nilshi> it is a musicians app, they are trained to notice below 20ms :)
[18:45:58] <nilshi> I'll do 100
[18:46:06] <altendky> How about something related to polishing? http://doc.qt.io
[18:46:30] <nilshi> altendky: that didn't work, tried that an hour ago. As we can see from the event list polish is called before the actual move
[18:46:38] <Avaris> altendky: i'd expect that to be in the order of paintevent
[18:47:09] <Avaris> oh ok. maybe not :)
[18:47:31] <altendky> I guess if there window manager is moving stuff then qt may have no way to directly know things are done
[18:48:40] <altendky> But this seems like something common that some qt person should just know how to handle :|
[18:52:37] <nilshi> while self.qtApp.hasPendingEvents(): self.qtApp.processEvents()
[18:53:52] <nilshi> interestingly calling it once is not enough, the while loop was needed.
[18:54:04] <nilshi> not sure if that is better or worse than a 100ms delay
[18:54:19] <Avaris> nilshi: what's that for?
[18:54:53] <Avaris> alternatively, you could just center the dialog wrt screen? :)
[18:55:05] <nilshi> it is worse. works unreliably.
[18:55:38] <nilshi> Avaris: that seemed to work at first (on one WM). It is the function to let qt handle its event loop.
[18:56:17] <nilshi> normally you can do that if you create blocking operations outside of qt. call it from time to time from your own operation to prevent a frozen GUI
[18:56:22] <nilshi> or advance a loading bar
[18:57:12] <Avaris> oh instead of qtimer, nah
[18:57:41] <altendky> Yeah, have to be careful with process events
[18:57:43] <nilshi> I had the hope that this is at least a real condition. Work until there is an opening, which would imply all queued events are done
[18:57:50] <nilshi> but since it doesnt work..
[18:58:25] <nilshi> 100ms timer it is. Just for a damn QDialog
[18:58:28] <Avaris> btw, does you gui take time to load?
[18:58:30] <altendky> nilshi: if the window manager is doing stuff it will be an unknown time 'later'
[18:59:12] <altendky> So... Yeah. Maybe a timer that you reset each time there's a move (or whatever...) until it times out
[18:59:14] <nilshi> Avaris: just the normal amount. There is no heavy computation going on
[18:59:36] <nilshi> "alternatively, you could just center the dialog wrt screen?"
[18:59:38] <nilshi> wrt?
[18:59:50] <Avaris> ok, i was going to suggest QSplashScreen for the tips/welcome otherwise
[18:59:57] <Avaris> "with respect to"
[19:00:49] <nilshi> that is a default behaviour if no parent. But if you have two screens it will be in the middle, one half on each screen :)
[19:00:54] <nilshi> that is not so pretty
[19:01:30] <Avaris> i meant manually centering it with qscreen
[19:02:12] <nilshi> but on which screen?
[19:02:29] <nilshi> the one the application is currently on. But that is the same info as position and not available at this point in time
[19:02:47] <nilshi> I'll leave the timer in until I receive another bug report
[19:02:56] <nilshi> thank you both very much for your help. Such an annoying problem... :)
[19:04:33] <Avaris> agreed
[19:07:17] <nilshi> that is the application btw. https://laborejo.org and https://laborejo.org
[19:10:01] <Avaris> looks nice
[19:10:18] <nilshi> one person didn't like it
[19:10:29] <nilshi> said the welcome about dialog was in the wrong position on start up :)
[19:11:32] <Avaris> can be annoying, yes :)
[19:12:41] <nilshi> I really like QGraphicsScene/View
[19:13:10] <nilshi> mostly my applications are a mainwindow with 1 or more of them
[19:13:55] <Avaris> yeah, i've been playing with QGraphics* package a lot lately, they can be really powerful
[19:47:30] -!- BPL has quit [Quit: Leaving]
[20:25:55] -!- minto has joined #pyqt
[20:27:00] -!- JanC has quit [Read error: Connection reset by peer]
[20:27:49] -!- JanC has joined #pyqt
[20:28:23] -!- mintograde has quit [Ping timeout: 245 seconds]
[20:29:07] -!- JanC has quit [Remote host closed the connection]
[20:29:29] -!- JanC has joined #pyqt
[20:37:24] -!- mintograde has joined #pyqt
[20:40:27] -!- minto has quit [Ping timeout: 240 seconds]
[22:02:56] -!- mintograde has quit [Ping timeout: 240 seconds]
[22:50:58] -!- Mrokii_ has joined #pyqt
[22:53:48] -!- Mrokii has quit [Ping timeout: 245 seconds]
[22:53:48] Mrokii_ is now known as Mrokii