Qt/Mac bugs
-
I keep programming my first Qt app (Mac/Win). I try to make the Mac version look as much “native” as possible.
I’ve came across 2 Qt/Mac bugs that bother me. If they bother you too, could you possible vote for my bug reports, so that they are fixed sooner?http://bugreports.qt.nokia.com/browse/QTBUG-15474
http://bugreports.qt.nokia.com/browse/QTBUG-15475 -
Good to know. So there is a hope that the bugs will be fixed :-)
I have an app in the iOS App Store. Many my users want to have a companion desktop app. Most of them have Windows on their desktop, so my app needs to be at least Win/Mac. I have chosen Qt and spent the last 6 months programming this app. I hope that I made the right choice.
As a bonus my app will run on MeeGo, and it may be easier to port it to Nokia smartphones in the future. But let's be realistic, if I want to be paid for programming this desktop app now, it needs to run on Win and Mac.
If you keep improving Qt for Win and Mac, you may interest thousands of iOS developers like myself. And later we will contribute to MeeGo and Nokia smartphones.
-
That's the point. We once used Delphi for (commercial) application and had no chance for a Mac version. So we eventually switched to Qt and got the Mac version for free. And if someone ever asks for a Linux version... :-)
It will be interesting if Apple accepts Qt based apps for the Mac app store. That would be a great opportunity.
-
I also used Delphi since the 1st version until 2 years ago... well, farewell to Delphi...
I use Java on the server side, but I don't like it on the desktop, and it looks like Apple doesn't like it neither.
I also hope that Apple accepts Qt based apps. I don't see anything in their requirements to prevent this, if the app includes Qt as a private framework, and look and behave like native Mac apps. There are things that make Qt apps look strange on Mac - I hope that they will be fixed...
Even if Apple rejects Qt apps, I still can advertise my desktop app in my iOS apps, so it will not the end of the world for me (my iOS apps are relatively successful, and many my current users will buy the desktop app). But this will definitely be a big minus for many other developers.
-
What would be the solution for 15475?
Scrollwheel works while date/time is in focus (it's in focus right?).
Should it only accept scrollwheel when mouse is hovering over the element on Mac?It doesn't sound that difficult if you want to delve in to Qt code ;) I don't have a Mac to test this on.
-
15475: when a QDateEdit or a QComboBox is in focus, but the mouse pointer is not above the widget, the widget reacts to the scrollwheel. A widget should not react to the scrollwheel when the mouse pointer is outside it (any widget).
A real life scenario:
- I open a dialog and change the value in a combobox.
- I move the mouse to the OK button and click it.
- I am using a MagicMouse. It generates scrollwheel signals every time when my finger slightly moves anywhere on the mouse. When I click the OK button, a split-second before clicking my finger slides a little, and the combobox changes its value. A split-second later the dialog is closed - I just entered a wrong value without even noticing this.
Every new Mac desktop comes with MagicMouse. This bug will happen quite often.
Microsoft makes a similar mouse for Windows. It's not that widespread as MagicMouse, but we will have the same problem on Windows if this kind of mice becomes popular on Windows.
Native Mac OS widgets do not react to scrollwheel when the mouse pointer is outside. In general they mostly ignore the scrollwheel. For example, a native tab widget ignores the scrollwheel altogether, but a Qt widget reacts to it. When I tested my app on Mac, I've noticed that I often selected a wrong tab. I select a tab, but when I move the mouse away, my finger slides a little horizontally, and the widget selects another tab. I ended up inheriting from QTabBar and cancelling scrollwheel events. If the bug with QDateEdit and QComboBox is not fixed, I will have to replace them too everywhere in my app...
-
Well it seems there is no doubt about it being the wrong functionality on Mac. I believe Windows works like this natively though.
It really wouldn't be too hard to change, I think. Have you looked at the Qt source responsible?
I don't have a Mac available. If you aren't good enough in C++, I can make a patch and have you try it if you want. But you'd still need to have the source and compile it anyway.Edit: If you have a workaround I guess it can wait.
-
I guess it could be worked around by using a mouse filter to discard scroll events if the mouse isn't hovering over the datetime edit?
-
Generally, Qt is Salvation for a Delphi developer, excellent alternative for good VCL, cross-platform as a bonus :)
-
serkol; but shouldn't you be able to work around it only one place? E.g. QApplication::notify, and discard the event if the widget doesn't contain the mouse? Requires mouse tracking however, which might slow you down. Alternatively, you unfocus them when the mouse leaves..