PyQt4 issues under OS X (10.7-10.9)
Hi. I have a few questions. I should preface them by saying I'm new to Qt and am doing what I can to catch up on how to use it, what does what, etc. I have plenty of C/C++ experience an am rapidly getting up to speed on Python.
Now then, I work on a cross-platform, open source project that runs primarily on Python (with some C++ via SWIG) and uses Qt4/PyQt. For the OS X build, we download various components into a sandbox of sorts, compile our code against the sandboxed components, and pack up everything we need in the app. It's messy and a bit bloated, but it allows users to be self-sufficient and avoid using brew or compiling a lot of stuff on their own.
Anyway, the team has talked about switching to Qt5 at some point. That day may be here. On OS X 10.9 (Mavericks), our code compiles against an unaltered Qt 4.8.5 checkout from Git. However, there are several weird quirks I've noticed so far, some of which I've fixed and others I'm not sure what to do. Most seem to apply to 10.7-10.9, but at least one may be Mavericks-only.)
-Fixed font is variable-width. (FIXED: I just needed to set the fixed font to "Menlo" for OS X.)
-Printing doesn't work. (FIXED: I updated various third-party downloads (source and binary) used to get the code to run on OS X, with most marked as being Mavericks-friendly and/or compiled on Mavericks. I guess one did the trick.)
-The font looks fine when you start the program. However, when the program loses focus (e.g., you switch over to Firefox), the font switches. In addition, text in a box may because too large for the box, and part of it will become unreadable at that point. (FIXED: Active Qt bug tracked by https://bugreports.qt-project.org/browse/QTBUG-5469 - Required a workaround as mentioned at http://sourceforge.net/p/texstudio/bugs/594/?limit=10&page=1#8d76 and adopted by TeXstudio.)
-When doing a long, fast swipe on a mouse or trackpad, text in a scrollable window will "bounce" in weird ways. It gets to the bottom, decides it wants to go back to the top, and then goes right back to the bottom again, sometimes repeating multiple times. (FIXED: A verticalScrollBar ("vbar") would always reset and go back to the top any time you tried to move it. Applied a workaround by not calling vbar.setValue(vbar.setMinimum()), which seems to work on Windows and Linux.)
-If you open a sub-window, then open a sub-sub-window from that sub-window (i.e., Window 1 -> Window 2 -> Window 3), you'll lose control of the program and have to force close it if the sub-sub-window loses focus. This is because the sub-sub-window and the sub-window both close without being resolved. It's like the main program's waiting for something to happen in these windows, but nothing will because they've disappeared. If you just open a sub-window, this doesn't happen. (APPARENTLY FIXED: May have been resolved by the font fix. Haven't banged on the code enough yet to be certain, and I've definitely never reproduced it anywhere other than Mavericks.)
I haven't been able to find any answers online other than one for the font issue. So, I have a few questions.
-Do any of these bugs sound like bugs that are fixable on my side, like the font one?
-Do any of the remaining bugs (#3-5) seem like things that are beyond the control of the code I'm writing, i.e., will I need to upgrade from 4.8.5 to 5.2.1 to get underlying code that's Mavericks-friendly?
-If any of these problems are fixable, what should I look for in the code? I don't need or want a solution, just a general idea of where to look (e.g., "On a redraw, QtWidget::redraw() gets called, which translates to QtWidgetRedraw() in PyQt").
-Any significant Qt4 -> Qt5 gotchas that tend to be glossed over in the various online tutorials?
EDIT 1: Renamed the topic to better reflect the problem I've talked about the most in subsequent posts.
EDIT 2: Renamed the topic again and updated the master post to reflect my findings.
Hi and welcome to devnet,
Mavericks has indeed brought a lot of quirks with Apple doing some more or less subtle modifications. These are being worked on and most fixed in 5.2. AFAIK they should have been back ported to 4.8 (if not, then do please tell)
For Qt 4.8, you should rather try Qt 4.8.6. Currently only available through git but with a release planned in the next few weeks. If some of the bugs you encounter are still present with that version you are very welcome to check/open bug reports "here":http://bugreports.qt-project.org (a minimal compilable example is always appreciated).
You are encouraged to port to Qt 5 when possible but if you are locked to Qt 4, rest assured it's not dead at all.
You can find the guide to port Qt 4 to Qt 5 in the documentation, one of the most important thing is that the widgets have been moved to their own module so you would need to add
@QT += widgets@
To your pro file.
Hope it helps
Hello. Thank you so much for your reply. I really appreciate it. I've also done some more exploring and think I'm getting a grip on what might be happening. Some further help would be most appreciated, though, as I feel like I'm getting into some advanced features that I'd ideally encounter after several months of study and less advanced development. (That said, I'm trying to get through Summerfield's "Rapid GUI Programming" as quickly as possible.)
First off, let me back up and provide some more details. For the OS X build, we're actually pulling the latest Qt4 from Git. So, to be technical, I suppose we are at 4.8.6. A switch to Qt5 is what I'd prefer. For various reasons, this may not happen for a little while longer. We're still discussing that internally. (We have to support some people for whom upgrades are potentially painful.)
Now, after doing further research and running the code on 10.7 and 10.8 VMs, it appears that bugs 3 & 4 (font resizing and window bouncing) are Mac-specific. Bug 5 is Mavericks-specific, and seems to be part of a larger set of problems that cause all kinds of bad behavior on 10.9. For now, I'm going to focus on bugs 3 & 4.
Font resizing: I'm stumped, and so's the guy who originally wrote the code. The font resizing appears to be limited to certain objects, including but possibly not limited to QLabel, QRichLabel, QPushButton, and QStringList (via QVariant). It appears that QTabWidget tabs, QProgressBar (text set via setFormat()), QStatusBar, and QRadioButton aren't affected. I've tried a couple of tricks, like hard-coding the QLabel font size (via setStyleSheet()), but they don't seem to work. The font will start at what I presume is the correct font size and will still resize as mentioned before. I don't think a default font size being set elsewhere, but perhaps there's a default style or other setting is getting called and resizing everything? Any help would be greatly appreciated.
Text box: I just found an answer a minute ago. At one point in the code, we get the verticalScrollBar from a QScrollArea object. setValue() is then used on the bar and set to minimum(). This appears to be fine for Windows and Linux, but not for OS X. The solution I found is to just not call it. This seems to do the trick. If anybody has a better solution, I'd love to hear it.
Thanks again for all the help!
Okay. I'm closer to understanding the font bug, yet remaining unclear about the root problem. The QLabel objects and such were getting set up with Tahoma at a font size provided by a function caller (usually 9-10 pt.). Upon regaining focus, the fonts were switched to 13 pt. Lucida Grande. LG never gets mentioned in the code. I'm assuming that something's happening that causes the fonts and font size to switch to the system default. Any idea why this would happen? Perhaps some of the objects aren't properly storing their fonts, and the code's reverting to the system default?
Indeed the current git version is Qt 4.8.6
If you can reproduce the bugs with a minimal example program, you should report them (don't forget to check first) on "the bug report system":http://bugreports.qt-project.org
Qt 4.8 is still getting bug fixes
Hello. Thanks again for replying. You're right, I'll report what I can on the Mavericks bug. The rest, as best I can tell, are known Qt bugs where there hasn't been any movement. Turns out https://bugreports.qt-project.org/browse/QTBUG-5469 is the font culprit. All I can do for now is upvote the bugs and apply workarounds.
(In the font case, I do what TeXstudio does: call setDesktopSettingsAware(False) before the QApplication is created. It works, although now I must be mindful of other possible GUI bugs.)
Thanks again for the patience, everyone. I'll go back and clean up the initial post some more. Hopefully this thread will spare at least one person the gruntwork I've done the past few days! :)