Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Android GUI IOS Programming

Digia Releases Qt 5.1 With Preliminary Support For Android and iOS 86

Posted by timothy from the file-formats-matter-more-than-os dept.
An anonymous reader writes "Finnish software and services firm Digia, which bought Qt from Nokia back in August, has released version 5.1 of the cross-platform application framework. Among the changes are 'significant improvements' to Qt Quick and preliminary support for Android and iOS. The latter means Qt on Android and iOS are both considered Technology Previews, letting developers start building for the two mobile operating systems and porting apps from other platforms by reusing the same code base. Although most of the Qt functionality and tool integration is already in place to start developing mobile apps, Digia promises complete ports to Android and iOS will come with the release of Qt 5.2 'later this year.'"
This discussion has been archived. No new comments can be posted.

Digia Releases Qt 5.1 With Preliminary Support For Android and iOS More

Digia Releases Qt 5.1 With Preliminary Support For Android and iOS

Comments Filter:

  • Sounds promising (Score:3, Insightful)

    by Sla$hPot ( 1189603 ) on Thursday July 04, 2013 @08:05PM (#44191479)

    Can't wait for that.
    Qt could be the answer to rich internet cross platform apps

    • I use Qt extensively, and while there are numerous reasons to sing its praises, the project has a severe problem in the form of not fixing bugs (like file open dialogs dumping huge amounts of console errors) or limitations (like a windows audio sample rate of 48 khz) before proceeding to new versions.

      What that causes is applications that are unstable either because the existing bug hasn't been fixed, or unstable because they get moved to an arbitrary new version with many changes -- and very few application

      • Does Qt readily accept patch submissions? Can you patch the bugs?

        I am not saying it is your responsibility to fix their mess for them. But... obviously there is something you like about Qt vs alternatives. If the bugs are unacceptable then what is worse for you; fixing their bugs, moving to some other platform or just living with it. I suppose this is a valid question individually for each bug. If an honest evaluation of the situation leads to you fixing some of the bugs then so be it! Have you considered

        • Qt is publicly developed on Gitorious (https://qt.gitorious.org/), accepting merge requests (with code review). Even if you can't get them to accept patches into the 'official' codebase, you could always just branch it and fix the bugs for yourself ...

      • "I have a HUGE problem with charging to fix something that was supposed to be working in the first place, or even, as is the case with Qt, not charging, but simply abandoning in place software that is significantly less than it was purported to be. I find adding new features to be insufficient cause to excuse leaving known bugs in place."

        A good rule of thumb is:
        Always charge for the time you spend. If you are self employed, you are the one that pays for the mistakes that you make. Else it's your boss. It's

  • Aren't Android apps written in Java syntax with a Google version of the JVM?

    • Re:Confused (Score:5, Informative)

      by Microlith ( 54737 ) on Thursday July 04, 2013 @08:29PM (#44191617)

      Google released the NDK (Native Development Kit) not long after Android was introduced because they finally clued in that Java simply isn't fast enough on slower processors to do gaming.

      • Re: Confused (Score:1)

        by Anonymous Coward

        The ndk is less about speed and more about reusing existing code/libraries.

      • they finally clued in that Java simply isn't fast enough on slower processors to do gaming.

        To be fair, Java is pretty damn fast in the right context. HotSpot running on a heavyweight server should give performance comparable to C.

        Google decided not to leverage the existing Java implementations, and instead start over - their first release of Dalvik didn't even include a JIT compiler; it was purely interpretive. Back to square one of the 'See, Java is so slow' battle, and on mobiles, where performance is actually relevant.

        • To be fair, Java is pretty damn fast in the right context. HotSpot running on a heavyweight server should give performance comparable to C.

          I bet COBOL would run pretty fast if you could build a mainframe the size of Yankee Stadium.

          • No. Bad strawman; no biscuit.

            I put "performance comparable to C". I did not put "It runs fast if you throw enough hardware at it". Ruby, for example, would never approach the performance of C, no matter how big your supercomputer. This is not true of Java. Heavyweight computers that can cope with Java's JIT compilation/multiple background threads/etc can run Java code at approaching C speed.

            • Tom-ate-to To-MAH-toe.

              You cannot run an interpreted language faster than a compiled language on the same hardware unless you cheat. You're cheating semantically; anything is rhetorically "comparable" to anything else.

              Java is slower than C and you know it. "Approaching C speed?" Hey, a snail bathed in salt approaches C speed. Semantics.

              • You cannot run an interpreted language faster than a compiled language on the same hardware unless you cheat.

                I'm going to assume you are honestly ignorant, and not trolling, despite that I even mentioned JIT compilation in my previous comment.

                HotSpot, the canonical JVM, has had a JIT compiler (i.e. has not been a purely interpretive VM) since 1998 [wikipedia.org].

                You're cheating semantically; anything is rhetorically "comparable" to anything else.

                No. I meant what I wrote. They really are comparable. If we look at the shootout [debian.org], where benchmarks are generally very short-running and thus considerably penalise Java compared to C, we see Java still beats C performance in two of the benchmarks.

                It gets outpaced pretty r

    • Re: (Score:1)

      by Anonymous Coward
      I think it means that Qt 5.1 can now be built to run natively on the Android platform. This is good news, since most Qt apps would probably require minimal porting (maybe just a recompile).

      • Re: (Score:3, Informative)

        by rroman ( 2627559 )
        It has been possible for some time via necessitas [sourceforge.net]. Now they only added it to the official package. Most Qt apps are written on desktop using QtWidgets. When you are developing for mobile devices, you should use QtQuick. QtWidgets aren't designed for mobile devices.

    • Re: (Score:2)

      by Trepidity ( 597 )

      That's the standard way of writing an app, but you can also write native-code apps [android.com], and therefore you can also use alternative frameworks (like Qt).

  • Too bad we didn't have this 2-3 years ago (Score:3, Insightful)

    by ensignyu ( 417022 ) on Thursday July 04, 2013 @08:25PM (#44191589)

    Nokia could have made a compelling cross-platform play. Write one app, have it run on iOS, Android, and Meego -- and others. Like what HTML5-on-mobile was supposed to do, but without the performance and compatibility headaches.

    It wouldn't necessarily have a native look-and-feel on each platform but there are plenty of apps that use non-standard themes anyways.

    • Re: (Score:2)

      by rroman ( 2627559 )
      It is a bit late, but it is not too late. There is still no alternative to this. I think Qt will eventually become kind of standard for cross platform mobile development.

    • Re:Too bad we didn't have this 2-3 years ago (Score:4, Insightful)

      by obarthelemy ( 160321 ) on Thursday July 04, 2013 @08:58PM (#44191751)
      Apple would have kiboshed that in the blink of an eye.

      • Re: (Score:2)

        by CODiNE ( 27417 )

        How would QT be any different than using MonoTouch?

        • There was a time in April 2010 [slashdot.org] when Apple changed the App Store Review Guidelines to ban all languages other than Objective-C and C++ as an effort to keep Adobe from offering AIR, its tool to package Flash applications as iPhone apps. When this policy was in effect, MonoTouch would have been banned, and the developers of Unity 3D were even porting the library to allow writing a game in Objective-C [mindthecube.com]. Such a game would share no code with the same game for other platforms, making it yet another DRY violation [wikipedia.org] induced by a platform gatekeeper. Apple reversed this policy two months later [slashdot.org] after it became clear that this banned the use of Lua for game logic and dropped all language restrictions the following September [apple.com].

          • Re: (Score:2)

            by JonJ ( 907502 )
            But Qt is C++, so it would not have been banned?

            • Re: (Score:2)

              by tepples ( 727027 )
              The policy at that time stated: "Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited." Qt would probably have been deemed an "intermediary translation or compatibility layer".
            • I think Apple's (or SJob's specifically) issue was more with the toolkit, not with the programming language. They wanted (and still want) people to code the UI (for non-"immersive" apps) in Cocoa Touch, so it looks and feels native in iOS. It doesn't matter so much which programming language is used -- ObjC would be the natural choice, but if you're using some Python, Javascript or Ruby binding for the framework, that's OK too.

          • Re: (Score:2)

            by am 2k ( 217885 )

            From a computer science point of view (e.g. everyone working on the iOS platform except the armchair managers who came up with this shit), this also didn't make any sense. For example, there's no conceptional difference between loading XML or any other format like Word documents and interpreting a scripting language. This is even more vague with scene description files used in games, since these instantiate game objects and build connections between them.

            Where should the line be drawn?

            Since I'm an iOS devel

    • Been done already See Xamarin.com (except for the meego bit)

  • One Framework to rule them all... (Score:4, Interesting)

    by Michael Simpson ( 2902481 ) on Thursday July 04, 2013 @08:54PM (#44191731)
    I've been a QT developer for a number of years. Over the last few years, I've done some Linux embedded. A few months ago, I even built and ran a QT app on the Raspberry Pi. Everything worked except for animation. Nokia messed up by not staying the course. And now they announced they are happy being the challenger. Seriously? You were the world dominater several years ago. One thing not mentioned is the Blackberry port. The framework is well done and it just works.

    • Nokia messed up by not staying the course. And now they announced they are happy being the challenger. Seriously?

      It's understandable that one does not have time to keep up with the news [reuters.com], but at least RTF summary TITLE. Digia releases Qt 5.1. Nokia has had nothing to do with Qt for the last year or so, which is a Good Thing for the toolkit's evolution.

      • Re: (Score:1)

        by Anonymous Coward

        It's perfectly congruent, if you think about it. Nokia did have a plan, using Qt to span between the old (Symbian) and the new (Meego). This is obviously the course referred to, the pre-Elop one, you know the one which actually gave Nokia something unique and actually had a hope in hell if they had actually stayed with it. They didn't stay that course, thanks to that Microsoft torpedo and the massive incompetence of the board.

        Digia buying what was once Trollech from Nokia was something that happened after N

  • I can see a lot of potential to seamlessly develop native (fast) apps which are ALSO cross platform. It sounds like a win-win for me with the user's usability experience being faster as well as a familiar environment for app developers. As long as they can keep up to speed with the core platform features and changes..

    • Re: (Score:3, Informative)

      by PurpleAlien ( 797797 )
      Not only that, but it allows integration of Web technologies and native code, having the best of both worlds. For example, on the desktop side, you could call Javascript code in Webkit from the C++ side of things, and vice versa. I actually just uploaded a video showing this on the Raspberry Pi (starts at ~50 seconds in): http://youtu.be/JOkks0oVsp8 [youtu.be] In case you're wondering what that is, it's a GPS Mapping application for our trackers (for more info, see our Indiegogo page: http://igg.me/p/424464/x/3476322 [igg.me])
      • QtWebKit does not fly on iOS though because Apple insists you use the system's WebKit library. It is all moving in the right direction though.
        • That's true, but keep in mind Qt for iOS and Android is very, very new and who knows what the furute will bring. Baby steps :-)
          QtWebKit on desktop platforms (Linux, FreeBSD, Windows) is fast by the way. We did some tests on a Raspberry Pi and QtWebkit is faster than e.g., Midori (also Webkit based, and the default on the R-Pi).
          • Android and iOS *are* the future. So let us call a duck, a duck. QT is a really great platform for the world as conceived 10 years ago. Groovy. So in other words, QT is .NET. .

            • So in other words, QT is .NET

              I'm sorry, I'm confused. Is that supposed to be a bad thing?

              • Re: (Score:2)

                by fyngyrz ( 762201 )

                it's not a bad thing, but it's not even accurate. .NET isn't going to produce cross-plaform apps. Qt will (with some limitations, but it's like 98% there. I write some *big* apps in Qt, and have been fairly successful at the cross-platform thing, though I do all my development under OSX.)

                Mr. Troll is, to be blunt, bewildered.

            • Your ignorance is showing. C# rocks for doing the things that .Net is suited for. Quick enterprise applications where size of executable and ASP .Net, again on the enterprise network where bandwidth isn't a problem. Other than code metadata, I fail to see the congruence between .Net and Qt? Qt and Webkit are tightly integrated. You can accomplish in short order, applications that have the characteristics of a web application but also contains high performing cross platform native components. Hint, I'v

  • I'm sorry to say that in trying out QT a hello world app involves over 10 megabytes. (I remember doing it in Dos with only 16 or so bytes). Of course it's doing a lot of graphics etc, but if you've got to port the qt system and all the supporting libraries over it will be substantial.

    Please correct me if I'm wrong. (I would love to be mistaken about this).

    • Re: (Score:1)

      by Anonymous Coward

      If you count the Qt libraries, then yes. But that would be like complaining that writing a hello world app for Android or iOS requires the platform OS to run. We can hope that there will be a re-distributable package for the libs like on sane platforms like N900 and N9 so the cost would be a one time thing.

    • Re: (Score:2)

      by paugq ( 443696 )

      Fortunately, Hello World apps are rarely distributed. Adding Qt to your application, any real world application, is usually perfectly acceptable. You can even statically-compile the appliation to get a single executable.

      I really wonder why people complain about 10 MB when we are using operating systems that take gigabytes of hard disk space and RAM.

  • I'm quite sure, given the "free" license of QT is based on LGPL, that a developer will need a commercial license from Digia to publish an iOS app on the App Store :(
    • Comment removed based on user account deletion

    • Re: (Score:3)

      by tlhIngan ( 30335 )

      I'm quite sure, given the "free" license of QT is based on LGPL, that a developer will need a commercial license from Digia to publish an iOS app on the App Store :(

      Not really. It's triple licensed - GPLv3, LGPLv2, and commercial.

      LGPLv2 means that it's perfectly compatible with App Stores - just you have to release the source to the QT library. The App Store effectively "TiVoizes" the app, but for the most part, there is no license issues between (L)GPLv2 and app stores.

      (A|L)GPLv3 is incompatible though.

      And

      • I have a pair of GPL apps on the AppStore myself (one of which, Eat the Whistle, is not free), but if you want to build a closed source app it may be problematic. LGPL requires dynamic linkage, or object code redistribution, you cannot dynamic link libraries not present in the iOS sdk on the Apple App Store, or your app is rejected. So you can publish to the App Store, but only if you build an opensource app, or if you distribute the object files for "relink" (not practical nor acceptable for closed sourc
    • LGPL can be mixed with proprietary code as long as the LGPL parts are dynamically linked.

  • Qt Project, please (Score:3)

    by suy ( 1908306 ) on Friday July 05, 2013 @09:56AM (#44194199) Homepage

    Thank you for insulting the other companies and the individuals that work hard on Qt. Digia maybe owns the trademark and the right/obligation to relicense, but is not the owner of Qt, and certainly not the only contributor. See the statistics about Qt [macieira.org] created by Thiago Macieira.

    The Android port started as a community only project, by the way.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close