Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Digia Releases Qt 5.1 With Preliminary Support For Android and iOS

timothy posted about a year ago | from the file-formats-matter-more-than-os dept.

Android 86

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.'"

cancel ×

86 comments

Sorry! There are no comments related to the filter you selected.

Sounds promising (4, Insightful)

Sla$hPot (1189603) | about a year ago | (#44191479)

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

It's the promises you have to look out for (1)

fyngyrz (762201) | about a year ago | (#44194981)

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 applications are as extensively tested against the new version as compared to the old during the initial design and implementation phase.

On the one hand, Qt has enabled me to make apps that (mostly) work the same using the same code under Windows and OSX. But it also causes me a lot of angst trying to explain to my users why the OSX version works so much better than the Windows version. It's not that I want it to; the OSX version of Qt is simply better.

Qt isn't the only project or organization guilty of wanting to make new versions before fixing the existing version. The lure of new APIs and such is strong, and the urge to fix bugs apparently not so much, right across the software spectrum. Apple does it; bugs persist for many OS revisions while APIs come (and go... Apple is not shy about telling you to stop using something.) Microsoft does it: I remember the glyph rotation bug (CW on some platforms, CCW on others) and the how-many-files-you-can-multi-select bugs managing to survive over not only OS revisions, but different OS platforms when the MIPS and Alpha versions were being offered. In the interim, Microsoft changed a great deal about window metrics across various OS levels, affecting all manner of interface issues, while OSX inflicts such obnoxious "favors" as not supporting new cameras except with a new OS level (while still happily selling you a version of their image editing that will work on your older OS), and breaking such *NIX components as cron. UDP sockets still don't work correctly under OSX (broadcast reception sockets where only one can exist on a machine... yeah, that's a good idea... not.)

Basically what I'm bitching about and advocating is that if you produce software, you shouldn't somehow magically get to ignore the fact that it doesn't do what you told the end user it would do just because you've released a new version you want them to buy, or even just use. I have NO problem with charging for new features. I don't even have a problem with adding new features to the current version while also fixing bugs, as long as you take care to not break pre-existing functionality. 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.

And frankly... if we would just seriously commit to fix the stuff we have before we move on, moving on would be a much better experience overall; the codebase would be more stable, the customers happier, and if we could couple that with a sense of responsibility that left existing APIs in place (once you tell someone to use an API, I think it's just awful to tell them they have to stop), I think we'd have a better process, a better end user experience, and a great deal less agonized tech support. When your "it's-our-fault" buglist hits zero, that's when you should start thinking about changes that might involve moving on from the previous version. I see it as an obligation to the end user. Unfortunately, at least thus far, Qt does not.

Re:It's the promises you have to look out for (1)

morgauxo (974071) | about a year ago | (#44196197)

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 this option?

Re:It's the promises you have to look out for (1)

MasterPatricko (1414887) | about a year ago | (#44197077)

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 ...

Re:It's the promises you have to look out for (1)

Sla$hPot (1189603) | about a year ago | (#44204107)

"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 part of the equation.
Remember that when you are writing offers to your customers.
And make it clear too, that issues caused by new OS versions are the customers "problem". Cross platform is exponentially more expensive than single OS development.
I know that it is not easy, with competitors standing ready with their silver bullets, one rule em all development tools (jQuery, PhoneGap, Xmarin etc..), but let the customer decide what to do, based on all the pros and cons. Maybe they don't have to reach out to those potential 10 Windows mobile users, at the same cost, as to those potential 100.000 iOS and Android users out there.
In the long term the customer will learn. It is better to present the truth, even if it might hurt yourself, short term.

" "it's-our-fault" buglist "
That is only the bugs, defects and design flaws, introduced by you :)

I still bet on Qt as one of the must promising multiplatform contenders, if not the only serious one.

Confused (1)

msobkow (48369) | about a year ago | (#44191557)

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

Re:Confused (5, Informative)

Microlith (54737) | about a year ago | (#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 (0)

Anonymous Coward | about a year ago | (#44191879)

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.

From their website [android.com]

you should understand that the NDK will not benefit most apps.
....
Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on.

I guess you could say that the gaming would be under "physics simulation", but how intense are Android games anyway?

Re:Confused (1, Insightful)

stenvar (2789879) | about a year ago | (#44193021)

It "won't benefit most apps" in the sense that they don't run faster.

It benefits every app in the sense that you don't have to write them in Java, and using Android's weird APIs.

Re:Confused (1)

jones_supa (887896) | about a year ago | (#44193177)

What other downsides are there in using NDK? How much will it hurt portability? I'm generally excited about writing high-performance native games for Android.

Re:Confused (1)

TyFoN (12980) | about a year ago | (#44193277)

Just like all other native apps (including those on iphone os).
You can't run them on CPU architectures other than the ones you build for, so you would have to supply separate binaries for x86, ARM or MIPS systems.

Re:Confused (1)

stenvar (2789879) | about a year ago | (#44193315)

I have no idea what your comment has to do with mine.

Re:Confused (1)

AuMatar (183847) | about a year ago | (#44193525)

It helps portability to other OSes. The only language that runs on every platform are C and C++. You rewrite the UI layer, do a recompile, and you have an iOS app, or Win Phone app, or a PC app. That's why the NDK exists- so the large collection of cross platform apps and libraries written in C and C++ could run on Android.

Re: Confused (1)

Anonymous Coward | about a year ago | (#44191893)

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

Re: Confused (0)

Anonymous Coward | about a year ago | (#44192995)

Putting a fancy dress on a pig before kissing it is less about making it look better and more about love feelings.

Re:Confused (1)

Wootery (1087023) | about a year ago | (#44193213)

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.

Re:Confused (0)

Anonymous Coward | about a year ago | (#44193333)

JIT has its costs as well, in for example power usage. Particularly if you are memory-starved and thus would be likely to re-JIT the same code over and over and over.
Also Dalvik uses byte-code that is easier to interpret and also to JIT, so I expect they did see a long-term advantage. Not to mention that I'd consider the static memory allocation of the desktop JVM rather a no-go for mobile.

Re:Confused (1)

Wootery (1087023) | about a year ago | (#44199591)

Fair points, but I still think it was an awful decision to release Android using an interpreter for its recommended software stack.

I'm not suggesting just taking HotSpot and dumping it on a phone, and you're right that the JVM has its drawbacks, but they could have, say, adopted a system comparable to Mac's "universal binaries": apps ship with both Dalvik bytecode, and an ahead-of-time-compiled ARM-specific binary. In the future, when Android has a decent JIT compiler and may or may not still be running primarily on ARM, the shipped ARM binary could be ignored, and the Dalvik code used instead.

Or run an ahead-of-time compiler at app-installation time. Platform independence is preserved, performance will be good, but you'll have a lengthier installation process. C# does this I believe, and of course Unix has been shipping programs in source form forever.

Neither of my suggestions require starting from scratch with the compiler, as they don't depend on the Dalvik IR. Java->native code compilation can be done [excelsior-usa.com] ; Google could easily kick GCJ [gnu.org] back into life, or something similar using LLVM.

Re:Confused (1)

Medievalist (16032) | about a year ago | (#44197043)

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.

Re:Confused (1)

Wootery (1087023) | about a year ago | (#44199469)

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.

Re:Confused (1)

Medievalist (16032) | about a year ago | (#44283519)

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.

Re:Confused (1)

Wootery (1087023) | about a year ago | (#44285821)

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 roundly by C in certain other benchmarks, admittedly.

In the early days, Java performance was truly awful as it was interpreted. It was especially awful in GUI applications, as Swing was a total mess for quite a long time.

Re:Confused (1)

Anonymous Coward | about a year ago | (#44191625)

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:Confused (3, Informative)

rroman (2627559) | about a year ago | (#44191679)

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:Confused (1)

Trepidity (597) | about a year ago | (#44191665)

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 (2, Insightful)

ensignyu (417022) | about a year ago | (#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:Too bad we didn't have this 2-3 years ago (2)

rroman (2627559) | about a year ago | (#44191627)

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 (3, Insightful)

obarthelemy (160321) | about a year ago | (#44191751)

Apple would have kiboshed that in the blink of an eye.

Re:Too bad we didn't have this 2-3 years ago (1)

CODiNE (27417) | about a year ago | (#44191967)

How would QT be any different than using MonoTouch?

iOS apps were Objective-C only for two months (4, Informative)

tepples (727027) | about a year ago | (#44192217)

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:iOS apps were Objective-C only for two months (1)

JonJ (907502) | about a year ago | (#44192715)

But Qt is C++, so it would not have been banned?

Re:iOS apps were Objective-C only for two months (1)

tepples (727027) | about a year ago | (#44193853)

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".

Re:iOS apps were Objective-C only for two months (1)

multi io (640409) | about a year ago | (#44195071)

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:iOS apps were Objective-C only for two months (1)

am 2k (217885) | about a year ago | (#44193537)

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 developer, back when this was in effect, I had to explain this restriction to other programmers. I really struggled with that.

Re:Too bad we didn't have this 2-3 years ago (1)

boblaroc (1670576) | about a year ago | (#44192413)

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

Re:Too bad we didn't have this 2-3 years ago (0)

Anonymous Coward | about a year ago | (#44193371)

Sooner or later everybody will find a Windows Phone from their pockets. It's just a matter of time.

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

Michael Simpson (2902481) | about a year ago | (#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.

Re:One Framework to rule them all... (-1)

TrollstonButterbeans (2914995) | about a year ago | (#44192139)

I'm sorry captain, but QT is massively flawed in a great many ways. By being unaware of them, this means you are green.

Last time I checked we aren't living a Linux and Win32 world and that narrow 2004 definition of "cross-platform" is woefully inept in 2013. QT is a mish-mash library desperately fading into the sunset conceived from a world that thought desktop Linux was the future with Win32 being the player they needed to be compatible with.

In 2013, cross-platform does not mean Win32 and Linux. And the developers of QT broadcast this archaic viewpoint with an exclamation point.

Truth.

Re:One Framework to rule them all... (3, Insightful)

Psychotria (953670) | about a year ago | (#44192221)

You should read your signature.

Re:One Framework to rule them all... (2, Insightful)

Anonymous Coward | about a year ago | (#44192233)

"In 2013, cross-platform does not mean Win32 and Linux. "

What does it mean then? Windows, Linux, OSX, iOS, and Android are fully supported. A google search shows Qt also works on BSD.

What platforms are missing? (that more than 100 people actually use)

Re:One Framework to rule them all... (1)

TrollstonButterbeans (2914995) | about a year ago | (#44207423)

If QT is so awesome on OS X, Android and iOS why are:

A) No one using them on those platforms B) Why does the documentation suck on those platforms beyond belief

And for a bonus:

C) Every QT dev can flame me, mod me down but it is still 2013 and Qt is a dinosaur from 2004 because the quality of the experience on platforms other than Linux and Win32 are terrible.

Be mad. Get angry. Whatever. My experiences with Qt on Apple products has been well beyond terrible ---- and this experience to me is a reflection of the mindset (sorry --- I mean "narrow mindset") of the development team which must be some 2006 "Linux will rule the world \^/" mindset.

Sorry. I'm not from that fossilized crowd. I expect "cross-platform" to mean something beyond Linux and Qt is a flat-out disappointment from that point-of-view. I wanted to believe otherwise at the time --- another yesterday's failed idea of tomorrow.

Call me a troll, ignore me, whatever --- I don't care. It doesn't change the fact that Qt is out-of-date. Blame the messenger and see if I care. Clue: Guess if I care what you label me --- I'm not the one that has a let down of a product by any sane definition of 2013 --- it is Qt's dinosaur "Weee Linux and Win32 rule teh world --=== oh wait is not 2004 ... oh shit = useless".

Re:One Framework to rule them all... (4, Insightful)

caseih (160668) | about a year ago | (#44192237)

In what ways is Qt massively flawed? You claim those of us unaware of them are green, but then you say absolutely nothing to enlighten us.

Re:One Framework to rule them all... (1)

Grishnakh (216268) | about a year ago | (#44193765)

It's not, he's just a troll. Look at his username.

Re:One Framework to rule them all... (0)

TrollstonButterbeans (2914995) | about a year ago | (#44207449)

Find instructions that world to compile a Qt using project using Qt OS X on Lion or Mountain Lion. Oh yeah --- there aren't any. And it has been like that for at least 2 years. This means Qt is myopic Linux-nerds that don't really know what the F "cross-platform" actually would mean to a developer living in the year 2012 or 2013.

So by any sane means, I must conclude that the Qt are shit-fer-brains don't know what Apple is or never heard of mobile apps. This is why I don't feel Qt has any credibility --- you can't neglect the market as it has existed for 3-4 years ---- totally fail on emerging platforms and claim to know what fudge "cross-platform is". This is a fail on top of fail.

I'm not trying to be an ass --- but sheesh --- the marketing for Qt is flat-out offensive in the context of how much it fails to be what it claims in this modern world.

Re:One Framework to rule them all... (1)

dotancohen (1015143) | about a year ago | (#44192915)

Troll of the week! Nice!

Re:One Framework to rule them all... (2)

paugq (443696) | about a year ago | (#44193267)

In 2013, cross-platform does not mean Win32 and Linux. And the developers of QT broadcast this archaic viewpoint with an exclamation point.

Qt supports these platforms: Linux, Windows, Mac, BSD, OS/2, BeOS/Haiku, Amiga, Android, iOS, Blackberry 10, Symbian, MeeGo/Mer, Tizen, Windows CE/Mobile/Embedded, Embedded Linux, VxWorks, QNX, bare metal (Boot to Qt). In the past, it also supported Solaris, AIX, HP-UX, webOS and there was an experimental port to Amazon Kindle.

The only way to write a more portable application than with Qt is to use HTML, which is unfit for many applications.

Re:One Framework to rule them all... (1)

TrollstonButterbeans (2914995) | about a year ago | (#44207457)

OMG. Supports OS/2 --- hah! gee does it support DOS 3.2 too? BeOS? Wow! Windows CE???? Holy smokes! Amiga???? Add all those together and throw in free drinks and maybe you've got enough to fill a short school bus!

Apple? Android? There is not Qt working functionality there to speak of and there still isn't --- or don't you read the Qt websites and the Qt docs?

So congrats on being the king of Windows CE, Amiga, BeOS, DOS 3.2 or whatever ... my point is Qt doesn't even work on the actual "multi-platform" environments that anyone cares about.

I'm flaming because of this deficiency. Qt deserves this very negative feedback because the failure to support revelant and modern platforms is something that represents a reality disconnect.

But really --- I'm just pointing out what gets real clear and disappointing using Qt damn fast --- don't shoot me, a true cross-platform developer figures this out in less than 3 days and then tells their friends that Qt sucks because of X, Y, Z --- in that sense, I'm wasting my breath ---- no one needs me to identify the deficiencies of Qt, they discover them fast enough independently.

Peace out.

Re:One Framework to rule them all... (1)

Michael Simpson (2902481) | about a year ago | (#44195177)

In what way is it MASSIVELY flawed? Drama major? It works on OSX as well. The announced framework edition is adding Android and IOS support. I have found problems in the framework. Guess what. I have have the source code, modify it and then rebuild it. That is a whole lot better than starting from scratch. Another poster here talks about getting threading right. QT does a pretty good job with threading. QObjects are thread affinity aware and will let you know if you are executing an object in a thread in which it was not created. Very often, I find the limitations of the framework are imposed by the underlying OS. Calling me green just means you live up to your user name.

Re:One Framework to rule them all... (0)

Anonymous Coward | about a year ago | (#44206741)

Whatever flaws you found there, it's still the best of all cross-platform API for doing UI. There is no other viable option for android + iOS. (JavaFX claims to do be but it's never completed)

Re:One Framework to rule them all... (2)

Too Much Noise (755847) | about a year ago | (#44193145)

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:One Framework to rule them all... (1)

Anonymous Coward | about a year ago | (#44193453)

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 Nokia became a Microsoft subsidiary,

Re:One Framework to rule them all... (0)

Anonymous Coward | about a year ago | (#44195021)

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).

Actually, Nokia was never serious about deprecating Symbian until Windows Phone and Elop came in. The MeeGo project was from its inception to its very last days just a wild R&D offshot. It was never intended for mass markets, only for hobbyists. Although everyone outside Nokia, including major newspapers like Wall Street Journal and Reuters, were very keen on MeeGo and the public's interest seemed relentless, within Nokia the project was deemed inviable from the "business perspective" (whatever that means). They never understood why the public was so keen on it.

Just goes to show that management decisions are not always based on fact and reason, but skewed perceptions resulting in harmful and seemingly random conclusions.

Re:One Framework to rule them all... (1)

Michael Simpson (2902481) | about a year ago | (#44195201)

Where's the like button? You of course expressed that which I meant to.

Jump Ship (1)

Uncle Mark (AUS) (2973391) | about a year ago | (#44191739)

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:Jump Ship (3, Informative)

PurpleAlien (797797) | about a year ago | (#44191887)

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] )
This allows for optimized applications on low power devices, while still being able to use web technologies where it makes sense.

Re:Jump Ship (2)

GumphMaster (772693) | about a year ago | (#44191925)

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.

Re:Jump Ship (2)

PurpleAlien (797797) | about a year ago | (#44191953)

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).

Re:Jump Ship (0)

TrollstonButterbeans (2914995) | about a year ago | (#44192161)

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. .

Re:Jump Ship (0)

Anonymous Coward | about a year ago | (#44192541)

You should troll using some account that does not have "Troll" in its name. Just saying.

Re:Jump Ship (1)

stenvar (2789879) | about a year ago | (#44193027)

So in other words, QT is .NET

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

Re:Jump Ship (1)

fyngyrz (762201) | about a year ago | (#44195063)

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.

Re:Jump Ship (1)

Michael Simpson (2902481) | about a year ago | (#44195407)

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've made use of this feature on a commercial project that you have probably used. Android and IOS are the present. Networked embedded devices are the future. IOS not likely to be the platform of choice due to licensing fees. Android is unlikely to be the choice either. Android runs on a stripped down version on Linux. So an embedded device developer will probably skip the Android middle man and go directly to Linux. No UI, no need for Android. UI? Then Qt's Designer is a WHOLE lot better and faster at designing UIs than Androids widget set. I think you are stuck in the present. So let us call a Troll a Troll.

will Apple allow this? (0)

Anonymous Coward | about a year ago | (#44191977)

As Apple runs iOS with an iron fist, will QT be a permitted way to develop GUIs for it?

Re:will Apple allow this? (5, Informative)

pherthyl (445706) | about a year ago | (#44192567)

Yes. There are already Qt based apps on the app store.

Re:will Apple allow this? (0)

Anonymous Coward | about a year ago | (#44192931)

Which ones? I'd really like to know.

QT makes for big apps (1)

iplayfast (166447) | about a year ago | (#44193079)

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:QT makes for big apps (1)

Anonymous Coward | about a year ago | (#44193231)

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:QT makes for big apps (1)

paugq (443696) | about a year ago | (#44193317)

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.

Re:QT makes for big apps (0)

Anonymous Coward | about a year ago | (#44193341)

Well, 10 MB _per app_, that would certainly be around 1GB wasted on my phone, and I sure would mind that! Though I don't know where those 10 MB numbers come from, it should be long from that large if linking statically or such.

Re:QT makes for big apps (0)

Anonymous Coward | about a year ago | (#44193487)

Of course it's not per app. Qt isn't Java. Most of those "10 MB" are shared. If every single little Qt app used minimum 10 MB, for instance KDE would be impossible, as would stuff like all the embedded systems that *do* use Qt.

Re:QT makes for big apps (1)

AuMatar (183847) | about a year ago | (#44193543)

Except mobile phones generally don't allow you to share libraries between apps. The .so files come packaged as part of the download. The system has no way of knowing that the library that the 2 different apps use are really the same.

For example, an Android .apk file is just a signed zip. If you download an app, you have to download the whole apk anyway, so you *will* get a new copy for each app. And it will link to that version of the library, because it won't know that its the same as the .so file in another app (it could make the assumption by name, but they could be different incompatible versions so it won't).

The exception is if the file is prepackaged and updates as part of the OS. Which I could see Android doing someday, but it won't yet. And iOS likely won't.

Ministro (1)

paugq (443696) | about a year ago | (#44193555)

Na, you are wrong. You can of course package a private copy of Qt for Android/iOS/etc with your application but you can also use the shared copy provided by Ministro:

https://play.google.com/store/apps/details?id=org.kde.necessitas.ministro&hl=es [google.com]

Digia is already working on a "Ministro for iOS" to provide a shared Qt copy for all the apps.

Re:Ministro (0)

AuMatar (183847) | about a year ago | (#44193601)

And you'd then have to hope that its installed or get the user to install it. No app is going to do that, its going to confuse users who are used to 1 click installs, and risk breaking the app if an incompatible update (even if its just due to a bug) goes out.

Re:Ministro (1)

paugq (443696) | about a year ago | (#44194031)

It's called "dependency" and "dependency management". It's been working for decades on Linux.

Re:Ministro (1)

jones_supa (887896) | about a year ago | (#44194303)

It's still often clunky for any software which is acquired from outside the distribution's repository.

Re:Ministro (1)

AuMatar (183847) | about a year ago | (#44194473)

And it doesn't exist on mobile phones. And it has a hell of a lot of problems on linux as well. Nope, if I'm making my livelihood on a phone app I'm bundling everything with my app so I can be sure it works.

Re:Ministro (1)

fyngyrz (762201) | about a year ago | (#44195101)

And it doesn't exist on mobile phones.

That's a problem with mobile devices; not with Qt. Mobile phones are still pretty weak computing platforms; but give it time, and we'll be doing more and more serious things with them. We'll have higher resolution (and probably projected to holographic) displays, more compute power, more power supply available, better charging regimes, lots more memory of all kinds (working RAM and longer term storage), better input mechanisms (speech, for one) and so forth.

Mobile devices started out as pretty much weak platforms -- Palm, etc. Today, they're much more powerful, but they're not even *close* to a desktop, and pretending they are does no one any good. More to do; more to come. And that's a good thing, really.

Re:Ministro (0)

Anonymous Coward | about a year ago | (#44195109)

Nope, if I'm making my livelihood on a phone app I'm bundling everything with my app so I can be sure it works.

Are you making them? or software at all? I thought you just wanted to complain about something...

Re:QT makes for big apps (0)

Anonymous Coward | about a year ago | (#44197871)

You can even statically-compile the appliation to get a single executable if you pay an outrageous fee or release your program as GPL 2.

FTFY

Licensing problems... (1)

gabrygenoa (854128) | about a year ago | (#44193747)

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 :(

Re:Licensing problems... (1)

Ash-Fox (726320) | about a year ago | (#44194175)

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 :(

I think it's expected on the Apple platforms to pay for things, after all, the fee charged for access to publish on the app store etc.

Re:Licensing problems... (2)

tlhIngan (30335) | about a year ago | (#44195095)

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 you may ask why GPLv3 and LGPLv2 - that's because GPLv2 and GPLv3 are incompatible licenses. If QT remained LGPLv2, you couldn't use it in a GPLv3 project (it's not LGPLv2+).

In fact, there are many GPLv2 apps in the App Store. There were some unfortunate incidents with some GPLv2 apps due to the copyright holders differing interpretations (usually between the spirit vs. the letter), but for the most part, it's compatible.

Of all the app stores, only Microsoft calls out the GPLv3 - most usually just say you either hold copyright to, or have permission from copyright holders to redistribute. And yes, GPLv3 is fundamentally incompatible because of the Anti-TiVoization clause. (It is this clause that also makes it GPLv2 incompatible).

Re:Licensing problems... (1)

gabrygenoa (854128) | about a year ago | (#44195175)

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 source stuff). There are a few well-known opensource libraries that, given this restriction, made a "mobile platform" exception to their licensing. Other, like SDL, moved from LGPL to BSD.

Re:Licensing problems... (1)

vilanye (1906708) | about a year ago | (#44197891)

LGPL can be mixed with proprietary code as long as the LGPL parts are dynamically linked.

Qt Project, please (2)

suy (1908306) | about a year ago | (#44194199)

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.

Re:Qt Project, please (0)

Anonymous Coward | about a year ago | (#44195055)

This. Please mod parent up.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?