Nominate our 2022 Qt Champions!

Desktop app ported to multi-touch mobile: menu items too small for fingers.

  • I nievely ported a Qt app from desktops to mobile (iOS on an iPad). Problem: menu items are too small for fingers. (The iOS HIG discusses that buttons should be larger to accomodate fingers.) Is there an easy solution?

    I don't think it is a problem with high-resolution. From what I read, Qt should automatically take care of the fact that the iPad resolution might be about twice the resolution of my desktop screen. The buttons on both devices are about half the width of my finger, say 1 cm.

    I suppose that Qt is NOT automatically taking care of the fact that buttons for fingers need to be larger than buttons for a mouse.

    (There is another issue: a context menu might not be supported by Qt on iOS. On iOS for phones, context menus are native 'action sheets' that animatedly slide up from the bottom (which is not really 'in context'). I don't know whether a 'pop-up' context menu that my app (using Qt) provides will be allowed on the App Store even for iPads. And it behaves a little different than the "edit menu' on the iPad. Is there a 'context-menu' that is entirely portable across desktop, tablets, and phones? But that's another question.)

  • It seems that Qt uses the Fusion stylesheet for QtWidgets iOS since iOS doesn't expose an API for Qt to implement a QIOSStyle (a QStyle for iOS.) It might work better for QML. See the thread on Qt dev list aobut "Qt for iOS - iosStyle": There's a very long discussion why QWidgets may never be appropriate fo mobile platforms. Also notice that the mobile platform portable Qt example 'Weather App' uses QML.

  • I had a similar issue with toolbars. Many (but not all) icons were much to small, which was a big issue with toolbars.

    I found a solution, you might copy over. Take a look at my "ActionBar":

    The size of the icons in the action bar is controlled by stylesheets, relative to the font size. The size of the smaller icons in the menu lists is controlled by a C++ class (not possible via stylesheets, unfortunately). If you remove my proxy style class, you will see that these icons become very very small.

  • There’s a very long discussion why QWidgets may
    never be appropriate fo mobile platforms.

    Yes, peoply who like QML write that repeatedly. But hey, QML is not the solution of the world problems. Indeed QML brings its own new problems that the widhets dont have.

    I an satisfied with Widgets.

  • Thanks, I will also be happy with widgets if your solution works on iOS and will be accepted into app store.

    QML brings its own new problems

    Please provide a hint or a reference. I am considering switching to QML, but I will not if there is a downside or pitfalls.

    It is not just toolbars whose style is bad, but also Font Picker and File Chooser Dialog. I hope that QML will be better since those will be native.

    But both QML and QtWidgets are missing a 'Share' sheet or view, that is Intent.createChooser() on Android and UIActivityViewController in iOS.

  • Qt Champions 2016

    By the way , if you want your application to be published on the App Store. You are required to make your application looks like an native iOS application. It is is a time consuming task.

  • Right, that's my main concern. My understanding is that QML will meet that requirement on both iOS and Android and WinRT (with little effort), but that Qt Widgets will not (since iOS API does not expose the platform style to Qt's machinery as discussed in the Qt dev mail list.)

    It's almost a secret that Qt Widgets has this deficiency. It's no secret that there is much work involved in porting from desktop to mobile. Thats why I'm wondering if there are any secrets to QML, as s.fring74 suggests. By calling them secrets, I'm not judging: I appreciate Qt and its open discussions. The lack of iosStyle caught me by surprise, I assumed it was there but I should have researched it in advance.

  • Qt Champions 2016

    I have already given up to use widget approach for mobile application development. There are 2 reasons:

    1. Difficult to modify the look and feel of widget
    2. Single GUI code for multiple mobile platform is not a good idea

    Mobile platform unlikes desktop platform. The user experience and expectation can be totally different. An single and unique interface for multiple platform will be a disaster for user.

    So I wish to have a platform which can keep the core code (e.g data model , networking protocol) be unchanged and develop different interface based on the size and OS of the device quickly.

    QML is seem to be the best solution. But... no any news for iOS style yet and the Android style will be released on next major release. (No exact date yet)

    Instead of waiting for Qt team ( I know they are busy) , why don't we just develop the component required and share on Github? One of the advantage of QML is quick prototyping. Making a component is much easier then any other platform.

    I have started the project for making Android component , I know somebody is working iOS too.

  • QML brings its own new problems
    Please provide a hint or a reference.

    Simply run the demo application that come with Qt. Every other of them shows flickering pixels and distorted text on all of my android devices.

    But both QML and QtWidgets are missing a ‘Share’
    sheet or view, that is Intent.createChooser() on Android
    and UIActivityViewController in iOS.

    Yes, that's the bad site of single-source on multiple platforms. If these details are important to you, then you should better use the development kits that belong to the devices.

    Mobile operating system come and go so quickly that frameworks like Qt will always be somewhat late or ugly. Java (swing) has the same problem.

    Its not only the style of input elements. It's also the functionality. For example, Android devices usually have 3 buttons below the screen while Apple has only one button. And Linux/Windows have a keyboard.

    Android users expect to see the home screen of the OS when they press the back button repeatedly. Linux and Windows Users never expect that the application closes when you press the backspace key or esc key repeatedly.

    There are many small differences, but all together make the whole picture. All cross-platform frameworks do not provide a complete solution for this. You can use cross-platform frameworks to create working apps. But they will not look and feel 100% native (as Apple requires) unless you spend lots of effort into their development. The effort is possibly less when you write the same application 5 times for 5 different OS, specially when the application is supported by a server over network that runs the major part of the business logic.

    Have you noticed that most apps (except games) are not nuch more than a web viewer with a customised frame around it? They are kept as simple as possible and do only contain the view layer of the application.

  • About the QML versus Widgets topic:

    My understanding is that Widgets are not under development anymore. They were targeted to desktop computers and they have been made available to mobile devices. Widgets will remain part of Qt in future, but the developers aare now focusing on QML. So don't expect new widgets or new widget styles.

    QML is under development a lot, new styles will get added as well as new input elements. However, nobody knows when we will be able to imitate the native look and feel completely. Progress is slow here, obviously slower than the native development kits evolve.

    As long Qt does not really USE the native dialog elements, it will never look 100% native - that's my opinion. This issue has also never been resolved completely on Linux and Windows.

    Qt has its own look and feel, and I dont expect that this will ever change in future. So we either have to accept that or dont Qt for the GUI.

    By the way: I had great success using Qt in the backend without GUI.

Log in to reply