[Development] Puzzled by desktop development priorities, Mac OS specifically

[Rutledge Shawn]

On 26 Jul 2013, at 11:01 AM, Jan Farø wrote:

> Hi all,
> 
> I posted this on qt-project forums (http://qt-project.org/forums/viewthread/29888/), and was told this mailing list was a better audience. About 2 weeks ago I tried to post the same post as an anonymous user, but it has not yet been handled, hence I decided to become a member of the list.
> 
> I am in the final stages of rewriting a somehow complex (at least for me) application to Qt from Java Swing. The time has come to focus on UI details, and this is where Qt gives me grey hairs. I started out developing in Qt 4.8, and experienced several issues that didn’t work on the Mac (From the top of my head: Overlays on video widgets), or just looked plain wrong in Mac OS context (For example: Table rows with alternate row colors does not extend to the bottom if only containing a few rows; list view items does not scroll properly if setting an item widget).
> 
> Hoping that Qt5 would solve some of these problems (apart from reaping benefit from the great added features like JSON and serial device support), I have patiently waited for Qt5 to evolve from beta to 5.1 at the current point. Still, I’m seeing the same issues. Still. On top of that, classes like QtSingleApplication are not yet there. The unified toolbar on the Mac is gone, externalized to qtmacextras, which is still not ready. Compiling the latest version is not possible because of errors.
> 
> Bottom line is that creating a professionally looking/behaving application on the Mac is not yet possible with Qt 5.1, and not with Qt 4.8 either if requiring certain features – unless you know how to fix the underlying problems, and I certainly don’t.

I'm sorry that we have been slow to fix certain issues.  Please make sure that your pet peeves all have Jira bugs, and then when you write an email like this, you can name specific bugs, tell us why they are important for you and ask for them to be prioritized.  But I see from the forum post that you listed

https://bugreports.qt-project.org/browse/QTBUG-27043

Is that 4.x only or do you still have the problem in 5.x?

https://bugreports.qt-project.org/browse/QTBUG-2876

same question

https://bugreports.qt-project.org/browse/QTBUG-30248

You are asking for a new feature on QTableView, and got a reply that exposing QTableViewPrivate::drawCell() as a virtual method in the public QTableView API would break binary compatibility.  It sounds like a good idea conceptually to have separate vertical and horizontal lines though.  QtQuick should already give you better opportunities to customize the appearance of a table; does the QtQuick Controls table give you enough features for your application?

http://doc-snapshot.qt-project.org/qt5-stable/qtquickcontrols/qml-qtquick-controls1-tableview.html

Yes qtmacextras is not done yet, and the unified toolbar will be especially nice to have.  It builds with the current git dev branch, but not with release or stable branches (5.1.x).  It could be ready to ship with 5.2 if we spend enough time on it before then (I'm not sure if that's been promised previously), so depending on your own schedule, maybe you can develop with dev branch for now and plan to ship after 5.2?  Anyway AFAIK it's certain that we will not add a module in the 5.1 series.

I don't know of any plan about QtSingleApplication; it was never a mainstream Qt feature.  If the user purposely starts two instances of your application, is that really so bad?  I would think the main thing would be to make sure that when the user opens another document from Finder, it opens in any existing instance if there is one, assuming your app handles multiple documents.

We have not forgotten the Mac; several of us are spending a large percentage of our time on it.  Progress gets a little slower during the summer when people tend to take vacations though.  And our priority is 5.x, so only the worst 4.8 bugs are getting fixed, in practice.  But bugfix patches are welcome as long as they don't break compatibility.