5 ms·

More features in the Qt for iOS port

38 points by guruz 15y ago

generators 15y ago
I was about to ask what are the notable software made in Qt apart from kde ? , and than I came across http://en.wikipedia.org/wiki/Category:Software_that_uses_Qt http://en.wikipedia.org/wiki/Category:Software_that_uses_Qt wiki page. ( notably kindle ?? )
potatolicious 15y ago
No. No. As a developer this is interesting and cool. As someone who loves good UX, and as an iPhone user, I sincerely this doesn't catch on. The look and feel of iOS is an incredibly core part of the user experience of the platform (as it is with any platform), the wholesale replacement of these stock widgets with completely custom ones breaks user expectation, generates inconsistencies, and if the goal of cross-platform write-once-compile-anywhere is being sought, will simply create lowest common denominator UI - i.e., leverages none of the strengths of any platform, leaving only the most bland, mundane, and uninspiring intersection of all its target OSes. To be clear, I'm not at all opposed to innovating with custom widgets and UI elements (the drag-down-to-refresh is one of the more ingenuous new UI patterns that's come from the community instead of one of the big companies), but this is trying to completely build a completely parallel UI layer beside the native OS one. It's the same reason why I oppose Java-based UIs. No matter which platform you use it on, it never really behaves like the native widgets, and there are inconsistencies big and small that drive users up the wall. The core theme of consumer software in the past few years has been that superior UX trumps everything, up to and including having inferior features to your competition. Have we learned nothing? Why are we still so lazy with our UIs?
- tomjen3 15y ago
  I understand your reluctance, but from a developer time perspective it may make sense to use a cross-platform toolkit even if the users isn't going to enjoy it as much. Ultimatively it comes down to economics: are you willing to pay five dollars for a native app or 1 for a cross-platform one?
  - schrototo 15y ago
    As a developer, I would much rather write a more expensive high-quality app than some bargain bin POS.
    - ovi256 15y ago
      That's indeed the Mac way, or more correctly the Apple way. It's the reason why the Mac was dominated by highly polished not-cross platform apps.
      - zileazy 15y ago
        As far as I can see, every platform is dominated by not-cross-platform apps.
  - potatolicious 15y ago
    That's precisely my point though - I think the software market has reached a point where developer laziness like this simply won't fly. There was a time when the functionality of our products compared to the status quo (e.g., word processing vs. typewriters) was so ridiculously skewed that we could get away with bloody murder. And we did. We invented insipid modal UIs that jerked users around the app. We invented gigantic toolbars with hundreds of vague icons because we were too lazy figure out how to let users access their most used functions quickly. We created unforgiving apps where just glancing at it wrong resulted in data loss. We abdicated our responsibility to make features accessible, and instead printed large manuals and tear-out cheat-sheets, and made fun of people who couldn't handle the information overload. That era's long gone. Look at the App Store - it's a parade of failed apps eviscerated by users for bad UI. It's a gallery of obscure apps that never made it out of the gate because they didn't put thought into their UX. Now look at any of the top apps (in whatever way you define it: top grossing, most downloaded, highest reviewed, whatever), and you will see that one main common thread that connects is that their UI doesn't suck. People's tolerance for bad UI has decreased rapidly for years, continues to decrease, and the number of places where you can get away with it is rapidly shrinking. On the desktop you might still have that much breathing room - on the hyper-competitive winner-takes-all arena of the App Store, you have no chance. As a side note - I highly doubt Qt will save a developer enough time to make the difference between a $1 app price vs. a $5 app price. There are so many low-level fundamental UX differences between iOS, Android, and any of the other mobile platforms that full abstraction is simply not possible in the way that we have been able to do on the desktop.
- veeti 15y ago
  > It's the same reason why I oppose Java-based UIs. No matter which platform you use it on, it never really behaves like the native widgets, and there are inconsistencies big and small that drive users up the wall. Although Eclipse drives users up the wall in every other way, it uses SWT [1], which uses native controls. [1] http://www.eclipse.org/swt/ http://www.eclipse.org/swt/
  - natesm 15y ago
    Qt also "uses native widgets". It doesn't matter, it's still wrong. Yes, the buttons have the right pixels, but nothing behaves exactly right. I think it's actually worse feeling than a toolkit like GTK+, which is more of a Linux toolkit that "happens to work" on Mac OS. Qt apps feel like they're trying to sneak something past me (except on KDE, of course), and there's a very uncanny valley-esque effect. A GTK+ application is more "upfront" about it, so at least I understand what to expect immediately. Cyberduck, a file transfer application, is written in Java, but I had no idea because it uses actual bindings to Cocoa. If you want to provide the best user experience in a Java application, that's the way to go, write swappable front ends for each operating system with the native toolkit bindings.
    - nabilt 15y ago
      I wonder if that is why scrolling in Cyberduck is extremely slow. http://trac.cyberduck.ch/ticket/3799 http://trac.cyberduck.ch/ticket/3799 I don't have a problem with using different UI toolkits as long as they look like native apps. The problem is these toolkits are always a step behind in exposing features of the platform you are developing for.
    - veeti 15y ago
      Qt doesn't actually "use native widgets". However, it's capable of using native API's to draw native-looking widgets pixel-perfectly, which is more than enough on GNOME, KDE and Windows. In addition, it takes care of many cross-platform details such as button order and native dialogs, etc. On OS X I'd consider using native API's instead since I've heard so many complaints about Qt there. SWT, however, does actually use native widgets. Try out an app that uses it - it will behave the way you would expect an app to behave.
- rryan 15y ago
  Qt is a lot more than just a UI toolkit, so I'm very glad to see the iOS port progressing. You can write a native UI on top of a cross-platform codebase a lot easier than re-writing the whole thing from scratch, so having QtCore and friends on iOS would be a huge boon for desktop developers who want to port their apps to mobile platforms.
- zokier 15y ago
  What features of the target OS does a widget set need to utilize? It needs to capture input (multi-touch in this case which all mobile platforms provide) and display the widgets on screen (which obviously all platforms also provide). What "strengths" are there to leverage? I understand you fear that the widgets will be inconsistent compared to native widgets, but I don't understand why custom widget set would need to be any lower quality (or "bland, mundane and uninspiring") than the native counterparts.
  - Someone 15y ago
    Widgets must also play nice with accessibility features of the OS. I do not know whether doing that is possible on iOS without using native controls.
- deleted 15y ago
  [deleted]
demallien 15y ago
Does this mean that Nokia is keeping Meego going as a skunkworks project? It would certainly help with leverage when negociating OS supplier contracts.
- pavlov 15y ago
  When Nokia announced the switch to Windows Phone, they relegated MeeGo to "research project" status. According to Elop, the work done on MeeGo is supposed to anticipate the next disruptive technologies, rather than aiming to compete in the current smartphone market. Nokia also has said that they intend to use Qt on their Series 40 operating system, which powers the hundreds of millions "dumbphones" that Nokia sells each year.

38 points by guruz 15y ago

I was about to ask what are the notable software made in Qt apart from kde ? , and than I came across http://en.wikipedia.org/wiki/Category:Software_that_uses_Qt http://en.wikipedia.org/wiki/Category:Software_that_uses_Qt wiki page. ( notably kindle ?? )

potatolicious 15y ago

No. No. As a developer this is interesting and cool. As someone who loves good UX, and as an iPhone user, I sincerely this doesn't catch on. The look and feel of iOS is an incredibly core part of the user experience of the platform (as it is with any platform), the wholesale replacement of these stock widgets with completely custom ones breaks user expectation, generates inconsistencies, and if the goal of cross-platform write-once-compile-anywhere is being sought, will simply create lowest common denominator UI - i.e., leverages none of the strengths of any platform, leaving only the most bland, mundane, and uninspiring intersection of all its target OSes. To be clear, I'm not at all opposed to innovating with custom widgets and UI elements (the drag-down-to-refresh is one of the more ingenuous new UI patterns that's come from the community instead of one of the big companies), but this is trying to completely build a completely parallel UI layer beside the native OS one. It's the same reason why I oppose Java-based UIs. No matter which platform you use it on, it never really behaves like the native widgets, and there are inconsistencies big and small that drive users up the wall. The core theme of consumer software in the past few years has been that superior UX trumps everything, up to and including having inferior features to your competition. Have we learned nothing? Why are we still so lazy with our UIs?

tomjen3 15y ago
I understand your reluctance, but from a developer time perspective it may make sense to use a cross-platform toolkit even if the users isn't going to enjoy it as much. Ultimatively it comes down to economics: are you willing to pay five dollars for a native app or 1 for a cross-platform one?
- schrototo 15y ago
  As a developer, I would much rather write a more expensive high-quality app than some bargain bin POS.
  - ovi256 15y ago
    That's indeed the Mac way, or more correctly the Apple way. It's the reason why the Mac was dominated by highly polished not-cross platform apps.
    - zileazy 15y ago
      As far as I can see, every platform is dominated by not-cross-platform apps.
- potatolicious 15y ago
  That's precisely my point though - I think the software market has reached a point where developer laziness like this simply won't fly. There was a time when the functionality of our products compared to the status quo (e.g., word processing vs. typewriters) was so ridiculously skewed that we could get away with bloody murder. And we did. We invented insipid modal UIs that jerked users around the app. We invented gigantic toolbars with hundreds of vague icons because we were too lazy figure out how to let users access their most used functions quickly. We created unforgiving apps where just glancing at it wrong resulted in data loss. We abdicated our responsibility to make features accessible, and instead printed large manuals and tear-out cheat-sheets, and made fun of people who couldn't handle the information overload. That era's long gone. Look at the App Store - it's a parade of failed apps eviscerated by users for bad UI. It's a gallery of obscure apps that never made it out of the gate because they didn't put thought into their UX. Now look at any of the top apps (in whatever way you define it: top grossing, most downloaded, highest reviewed, whatever), and you will see that one main common thread that connects is that their UI doesn't suck. People's tolerance for bad UI has decreased rapidly for years, continues to decrease, and the number of places where you can get away with it is rapidly shrinking. On the desktop you might still have that much breathing room - on the hyper-competitive winner-takes-all arena of the App Store, you have no chance. As a side note - I highly doubt Qt will save a developer enough time to make the difference between a $1 app price vs. a $5 app price. There are so many low-level fundamental UX differences between iOS, Android, and any of the other mobile platforms that full abstraction is simply not possible in the way that we have been able to do on the desktop.
veeti 15y ago
> It's the same reason why I oppose Java-based UIs. No matter which platform you use it on, it never really behaves like the native widgets, and there are inconsistencies big and small that drive users up the wall. Although Eclipse drives users up the wall in every other way, it uses SWT [1], which uses native controls. [1] http://www.eclipse.org/swt/ http://www.eclipse.org/swt/
- natesm 15y ago
  Qt also "uses native widgets". It doesn't matter, it's still wrong. Yes, the buttons have the right pixels, but nothing behaves exactly right. I think it's actually worse feeling than a toolkit like GTK+, which is more of a Linux toolkit that "happens to work" on Mac OS. Qt apps feel like they're trying to sneak something past me (except on KDE, of course), and there's a very uncanny valley-esque effect. A GTK+ application is more "upfront" about it, so at least I understand what to expect immediately. Cyberduck, a file transfer application, is written in Java, but I had no idea because it uses actual bindings to Cocoa. If you want to provide the best user experience in a Java application, that's the way to go, write swappable front ends for each operating system with the native toolkit bindings.
  - nabilt 15y ago
    I wonder if that is why scrolling in Cyberduck is extremely slow. http://trac.cyberduck.ch/ticket/3799 http://trac.cyberduck.ch/ticket/3799 I don't have a problem with using different UI toolkits as long as they look like native apps. The problem is these toolkits are always a step behind in exposing features of the platform you are developing for.
  - veeti 15y ago
    Qt doesn't actually "use native widgets". However, it's capable of using native API's to draw native-looking widgets pixel-perfectly, which is more than enough on GNOME, KDE and Windows. In addition, it takes care of many cross-platform details such as button order and native dialogs, etc. On OS X I'd consider using native API's instead since I've heard so many complaints about Qt there. SWT, however, does actually use native widgets. Try out an app that uses it - it will behave the way you would expect an app to behave.
rryan 15y ago
Qt is a lot more than just a UI toolkit, so I'm very glad to see the iOS port progressing. You can write a native UI on top of a cross-platform codebase a lot easier than re-writing the whole thing from scratch, so having QtCore and friends on iOS would be a huge boon for desktop developers who want to port their apps to mobile platforms.
zokier 15y ago
What features of the target OS does a widget set need to utilize? It needs to capture input (multi-touch in this case which all mobile platforms provide) and display the widgets on screen (which obviously all platforms also provide). What "strengths" are there to leverage? I understand you fear that the widgets will be inconsistent compared to native widgets, but I don't understand why custom widget set would need to be any lower quality (or "bland, mundane and uninspiring") than the native counterparts.
- Someone 15y ago
  Widgets must also play nice with accessibility features of the OS. I do not know whether doing that is possible on iOS without using native controls.
deleted 15y ago
[deleted]

demallien 15y ago

Does this mean that Nokia is keeping Meego going as a skunkworks project? It would certainly help with leverage when negociating OS supplier contracts.

pavlov 15y ago
When Nokia announced the switch to Windows Phone, they relegated MeeGo to "research project" status. According to Elop, the work done on MeeGo is supposed to anticipate the next disruptive technologies, rather than aiming to compete in the current smartphone market. Nokia also has said that they intend to use Qt on their Series 40 operating system, which powers the hundreds of millions "dumbphones" that Nokia sells each year.