Qt 5 Alpha Released 117
After nine
months of effort, Nokia's Qt Lab has announced the availability of
the alpha
release of Qt 5. Goals achieved for this release include a new platform
abstraction layer, a re-architected graphics stack, and the
inclusion of Qt Quick as a first-class citizen (hitting version 2.0, and using Google's V8 Javascript engine to boot). Quoting Lars Knoll:
"'Qt 5 should be the foundation for a new way of developing
applications. While offering all of the power of native Qt using C++,
the focus should shift to a model, where C++ is mainly used to
implement modular backend functionality for Qt Quick.' I can say that
we came a good way closer to this vision with Qt 5.0. The model is
working nicely on the embedded side of Qt where UIs are full
screen. On the desktop, we have laid most of the foundations required
for this model, but it’ll take us until 5.1 or 5.2 to really take this
into use."
Nokia has posted the the source and detailed release
notes on the Qt wiki.
Nokia's fate? (Score:3)
What's going to happen with Qt if/when Nokia goes down the drain and gets swallowed by (probably) Microsoft?
Re:Nokia's fate? (Score:5, Informative)
Correct. I believe the QT foundation has a longstanding agreement in place to ensure that.
Re: (Score:1)
Notice it is Qt Labs releasing Qt and not Nokia?
Re: (Score:1)
And? Qt Labs is part of Nokia hence why you scroll to the bottom and see all the mentions about Nokia and its copyrights.
Re:Nokia's fate? (Score:4, Informative)
Qt is open source. Nokia could make all future iterations closed source, and then open source version gets forked like OpenOffice and LibreOffice.
Re: (Score:1)
Qt would remain open source, and ripe pickings for someone willing to use it.
Nokia has already delivered massive value and r&d effort on Qt5; it wouldn't go silently into the night, regardless of what happens with Nokia.
That's part of the beauty of open source: technology is not anchored to a publicly traded company, a competitor can quickly poach a developer team if it sees a need for one.
Re: (Score:3, Informative)
In the event Qt Labs/Nokia don't maintain the Qt framework anymore the code gets passed over to the KDE developers. I believe the code would then be either under the BSD license of a dual BSD/GPL license. You can find the details here: http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php
Re: (Score:3)
QT is already licensed under LGPL and GPL v3 which answers the question of who has the right to continue developing and distributing QT libraries. The answer is: you, me and everybody.
Furthemore, there is an agreement in place the ensure that QT continues to be licensed under LGPL. Here it is. [kde.org] Additionally, there is an open governance [kde.org] framework in place to guide ongoing development, which frankly places the QT project head and shoulders above Android in terms of community engagement, open development and go
Re:Nokia's fate? (Score:5, Informative)
Re: (Score:2)
I wouldn't put too much faith in that agreement if it came down to hostilities, as long as there's one "important" release each year which Nokia claims is good enough and the qt foundation isn't and then put a lawyer on it to drag it out it'll be tied up for years. Also it explicitly says "For the avoidance of doubt, the aforementioned definition does not cover the Qt toolkit for other platforms (e.g. MS Windows, Macintosh, Symbian)" so they can strip out many platform-specific files. Most likely there'll j
Re:Nokia's fate? (Score:5, Informative)
Re: (Score:1)
Well it seems they plan to release some low cost linux based phones for 100€ or so? Dunno probably burning platforms is just a hobby of them. But i really hope that qt is getting stronger out of this.
Re:Nokia's fate? (Score:5, Informative)
They've been moving resources around for a while now to ensure that QT isn't tied to Nokia's success.
Commercial support contracts have been sold to Digia. They've been the drivers behind several patch level releases already, including 4.8.1 a couple days ago.
The QT project has adopted an open governance model, with members outside of Nokia. They've moved their web presence off of Nokia's servers. They switched to LGPL licensing from QPL over a year ago.
If Nokia diverts resources progress may slow, but QT is not going anywhere. It will almost certainly outlast Nokia.
Re: (Score:1)
http://wiki.qt-project.org/The_Qt_Governance_Model
http://qt-project.org/
Re:Nokia's fate? (Score:4, Informative)
Why not read the QT Promise?
QT is under a dual development and the source code is held in escrow by the FOSS foundation to be released under GPL should QT Labs go under.
Re: (Score:2)
Whoah there... QT is far more popular than Autoit. Autoit is proprietary software, whereas QT is free. If Autoit doesn't work with it, they should work together with QT developers to find a solution that works for both.
Re: (Score:1)
Autoit may be closed source but its freely available and its not the fault of autoit that QT masks the interface you create with it. You cannot use autoit with any application using a QT interface. And in that sense who is closed?
Re: (Score:3)
Its not just open source, its an open community. If it doesn't work for you, work with the community to change it to work for you. Its not rocket science. You can't blame people who are open to suggustions and participation for not doing things you want, if you don't talk with them and explain your use cases.
Re: (Score:2)
... Does QT still break Autoit?
Are you a broken record [slashdot.org]? Submit a bug or Submit a patch. Complaining to Slashdot about some proprietary automation software is a complete waste time for everyone.
Re: (Score:2)
Re:One or two Questions... (Score:4, Informative)
Question is "have they changed this?"
Whats the bug number where they were notified. Why did they refuse to fix it?
AutoIt:
AutoIt has been designed to work on Microsoft Windows 2000/XP/2003, Microsoft Windows Vista, Microsoft Windows Server 2008/2008 R2, Microsoft Windows 7.
So you are complaining about an open-source development toolkit that supports every major OS and several Mobile OSs against a Windows-Only, proprietary application. I really don't think you are going to find many sympathizers here.
Re: (Score:2)
FYI, I took a look at his link. This isn't the most rational or easily understood poster you'll find. Not worth pursuing any line of argument with him.
Re: (Score:2)
QED
Re: (Score:2)
Re: (Score:2)
"QT created interfaces masks and by intent" Either say something that makes technical sense, or shut up. Thank you.
Re: (Score:2)
And that's my problem how exactly? You're claiming that Qt is making it intentionally hard for autoit. I'd think you know exactly what the problem is. You know, with your repeated claims that it's Qt's fault...
Re: (Score:2)
Qt supports UI automation via its accessibility framework.
So either it is completely broken or autoit doesn't support it.
And unless someone shows me an official bug report, I think that autoit is more likely to be the problem.
I think the problem is that Qt, like most GUI toolkits, uses its own widgets instead of the windows API. There are pros and cons. And one of the cons is that programs designed only for built-in windows widgets may not work properly. It is probably the case with autoit.
Re: (Score:1)
looks like Autoit has the problem, look at their target audience...
Re: (Score:2)
The reason Qt 4.4+ applications do not work with AutoIt, or any other WinSpy-like application, is the so-called "alien widgets":
http://labs.qt.nokia.com/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/ [nokia.com]
The normal behavior of an application is to create a Window object for every widget (window, button, combobox, etc) on screen. Usually that is done at the very low level, therefore most users (and even developers) do not know about it. This is true for every platform I know: Windows, X11 and Mac. I don'
Re: (Score:2)
QT is among the prettiest and most capable of all widget sets, open source or proprietary. It's not much at the moment, but here is the beginnings of an interface I cooked up [phunq.net] for an upcoming project. See, four independently navigable OpenGL windows, plus a few gratuitous native button widgets, which don't actually do anthing yet. Things to note about this code: it's clear and concise; it was easy to write; it's nice and robust. I managed to bypass the MOC so new widgets and actions can be hooked up on the f
Focus on Mobile development (Score:1)
Looks like more and more focus on mobile development (Qt Quick, Javascript as your UI) and less and less targeting for desktop systems. Which is too bad, and if they are *publicly* announcing that it won't be until 5.2 that the desktop becomes usable again, it looks like it's time to either fork the 4.8 version or start over with some other product.
Re:Focus on Mobile development (Score:4, Informative)
My interpretation is that Qt Quick is not yet suitable for desktop use, while the 'old-style' C++ objects should remain as usable as they are now.
While I'd love to see how Quick could help with improving my workflow, since I only work on desktop interfaces I guess I'll have to wait.
Re: (Score:3)
Why Qt Quick is "focusing on mobile"? From what I've read about it, it looks like a (long overdue) open source alternative to WPF to me - it espouses largely the same principles with separation of UI markup and code and a convenient syntax to bind two together, with the only difference being that it's backed by C++ rather than .NET (and it's much faster).
Why? (Score:4, Insightful)
Why is everyone heading to this "everything is a web app" model? A scripting languages embedded into an app is find but it should be used for quick mods and customization instead of core functionality, and should be layered on top of the application and not the base that the application is built from.
Re: (Score:1)
Because they are struggling for relevance in the mobile market. They somehow think that foisting Javascript into apps is that path whilst alienating their desktop developers. The problem is that none of the truly relevant mobile OSes these days have an official Qt port. Maybe in a couple of years they understand their folly and return to their c++ roots rather than this bastardized Javascript junk.
Re:Why? (Score:5, Insightful)
You don't have a clue what you're talking about. QML greatly simplifies 90% of the UI development while making it significantly easier to target multiple devices with the same UI, regardless of screen size or aspect ratio. A desktop-focused, c++-based UI model is hardly the better way to do it.
No. (Score:3)
When your core users are using your software SPECIFICALLY for desktop C++ development, bastardizing the software in some schizophrenic, hopeless pursuit of an area few of them want is quite the wrong way to do it.
Re: (Score:2)
It's odd that Nokia is *still* pushing this QML stuff, although it did make sense (to Nokia at least, if not to most Qt developers) while they has been pursuing a Qt-based smartphone strategy.
Re: (Score:2)
It makes interface designer tools easier to create. That said, I will stick with the on-the-metal c++ QT interface, it's easy enough to work with. The designer is nice for quick mockups.
Re: (Score:2)
Can anyone point to a good example of a Qt Quick/Declarative/QML (What exactly is the correct terminology?) application for the desktop environment. As a Qt dev with traditional Qt widget desktop apps I'd like to see a good example, preferably open source, of a non-trivial desktop application using the mobile-oriented Qt Quick/QML/Declarative. I suspect I'll be waiting a while.
Re: (Score:2)
This is just Google's way of destroying Qt. Just like Microsoft did to javascript(javascript, j++, j#) which still hasn't recovered. The funny thing is Google is trying to use their bastard version of javascript to destroy the competition just like Microsoft. Javascript needs to be treated like the virus it is. Fuck Google(spying cocksuckers).
You need either more or less drugs, I'm not sure which. Google doesn't have anything to do with Qt...
Re: (Score:2)
This is just Google's way of destroying Qt...
You need either more or less drugs, I'm not sure which.
A tranquilizer dart should do it.
Re:Why? (Score:5, Informative)
QML2 is pretty cool. I had the same attitude to QML1, but QML2 is a pretty good language to program the GUI in, while doing still all the real work in C++. Essentially QML is to Qt Designer what LaTex is to Word.
Re:Why? (Score:4, Insightful)
Of course if you've never worked with a document description language like Tex, you probably won't grasp the significance of that statement.
I like the C++ object model Qt uses. It reminds me of the "Elements" environment from the company formerly known as Neuron Data. I was surprised to hear they're still around, and there are still production applications written with it that need maintenance and updates because they're not ready to be retired yet.
But Qt is brought up to date with modern C++ features like template programming; I don't know if Elements has been similarly reworked. GTK is a pretty nice layer as well, but it's a portable graphics layer rather than a graphics abstraction like Qt or Elements. You can write custom widgets in Qt or Elements and have them work on multiple platforms, sort of like Java/Swing for C++. I'm not so sure about how to do so with GTK.
It was refreshing to see them being honest that it's not really going to be ready for production use until 5.2 or thereabouts.
Re: (Score:3)
It was refreshing to see them being honest that it's not really going to be ready for production use until 5.2 or thereabouts.
Indeed. It's important to note that QT 4.x is already nice to work with, stable and mature. I would like to see QT foundation really take their time getting 5 right, there is no good reason to push it out in a hurry.
Re: (Score:3)
Because it's the closest thing to a true write-once / run-anywhere model that's working. A web app will run on the desktop, tablets, e-readers, consoles (Wii has Opera), phones (even many of the average-intelligence phones). Mac, Linux, PC. Sure, there are some browser issues, but those can generally be overcome by switching browsers when that is an option. I still think we need native apps, but not everything needs direct access to hardware or complex calculations that would call for it.
The biggest pro
Re: (Score:2)
the problem is that you can't magically make a web app look metro-y on windows 8 and ios-y on ios using THE SAME CODE BASE.
by the time you do the relevant coding to polish it up well enough you might as well do a native app.
write-once, run-anywhere is the biggest load of bullshit to ever appear in computing.
it's a sham, it's a joke, it's a lie, it's a hoax, it's a scam, and anyone who pushes for it should be ashamed of themselves for basically *LYING* to whoever's paying them.
Re: (Score:1)
That's not necessarily a problem imho.
You can make nice non-standardized UIs to (I prefer a button working as a button, a scrollbar to work as a good scrollbar (Fuck you Facebook (yeah and an 'x' to work like close and edit to 'work' like edit ...) and menus to be on the top but I'm fine with for instance the look of Lightroom, Photoshop, that new Office .. what are they calling it? Gaming interfaces, ...)
Re: (Score:2)
write-once, run-anywhere is the biggest load of bullshit to ever appear in computing
write-once, run anywhere obviously does work the website you are on is a good example of that. Windows, OSX, and Linux users all experience roughly the same thing. The issue is that this application is of fairly limited complexity. As application complexity increases platform specific features become desirable. However, the vast majority, possibly overwhelming majority of applications are simple.
Re:Why? (Score:4, Interesting)
Why is everyone heading to this "everything is a web app" model?
Qt isn't going for web apps. It's going for Qt Declarative / Qt Quick. Just write some GUI apps with classic Qt and with Qt Quick, then you'll quickly realize how much more powerful it is to write GUIs declaratively instead of imperatively.
Re: (Score:3)
So what is the case for declarative GUI programming?
I'm a big fan of pure functional languages, but it's not obvious to me why declarative languages are especially suited to GUI's.
Re:Why? (Score:5, Informative)
That's a perfectly valid question, and the answer is not obvious at first.
When you come from a programming background, you have a very powerful hammer, and everything ends up looking like a nail, including GUIs. The problem with this approach is that you can never have either a non-programmer or a GUI tool help design your user interface. For trivial applications this isn't a problem, but it quickly becomes limiting on larger projects.
Microsoft had an interesting hack to make GUI design work with imperative languages -- split class files. One file would contain only a strict subset of the imperative language that the GUI designer could handle, the other matching file would contain the real code. This solution was fragile and would often result in the designer failing to open. This was already half way there to a declerative domain specific language, because the subset of the imperative language that the designer coud parse forbade any control flow. I first had the "lightbulb" moment when I saw Microsoft's next-gen XAML designers, where they basically formalized the GUI language into an explicitly declerative document format with a strict grammar. It allowed more complex GUI designs with well defined parsers, object models, design-time appearance, etc... All the problems just vanished.
This is by no means a Microsoft invention, declerative visual languages have always been more successful, flexible, and interoperable. A case in point is HTML, which is a purely declerative language, which has lots of advantages that has contributed to its success. Try putting yourself into the shoes of a search engine developer and imagine if instead of declerative SGML-derived pages, you had index imperative PostScript? Not just any old automatically generated PostScript intended for printing, but developer authored PostScript with as much complexity as a typical JavaScript library! How would you go about writing a designer for a language like that? You'd start by restricting the problem to some strict subset...
Re: (Score:2)
The problem with this approach is that you can never have either a non-programmer or a GUI tool help design your user interface.
So then Qt Designer and Interface Builder, two tools for GUI design, don't exist?
Re: (Score:3)
Less than a minute of Googling later: Qt Designer's UI File Format [qt-project.org]
Your counter-example to my point uses an XML-based declarative UI file format with a strict validating schema.
I'm not sure what you mean by Interface Builder you mean the Apple tool, which uses .NIB or XIB files. Those formats are -- if anything -- closer to XAML than even the QT format, as they contain XML representations of the GUI document object model.
As far as I can see, neither format supports imperative concepts such as loops or other
Re: (Score:2)
As far as I can see, neither format supports imperative concepts such as loops or other control flow.
Right, loops and other control flow belong in slots (program action code in case anyone doesn't know) not in the interface definition.
A non-programmer will not touch QML either. (Score:3)
QML will seem like Chinese to anyone without some programming experience, so, if they are going to produce anything interesting, they will do it with UI designer applications, not by programming directly in QML.
Poor unsuspecting C++ programmers will then be given the QML code produced by the UI designer tool and try to dhoehorn it to the C++ application. They will feel tortured, because the QML fed to them will be not that readable (most automated code production tools produce awful code), the UI designers
Re:Why? (Score:4, Insightful)
So what is the case for declarative GUI programming?
Describing UI in markup is plainly more convenient than writing verbose code to construct widget trees. And declarative property bindings are much more concise than the usual OO way to plumb together model and views.
Basically, it lets you focus on writing code where it's the best way to solve a problem - in your model - and use a more convenient DSL (in the case of Qt Quick, QML for markup and JS for bindings) for view-related stuff and plumbing between the two.
Re: (Score:3)
Qt isn't going for web apps.
http://qt-project.org/wiki/Qt_for_Google_Native_Client [qt-project.org]
Re: (Score:2)
Everything will eventually be web/net apps, you can quote me on this 10 years from now...
Re: (Score:2)
Why is everyone heading to this "everything is a web app" model? A scripting languages embedded into an app is find but it should be used for quick mods and customization instead of core functionality, and should be layered on top of the application and not the base that the application is built from.
Because some people are more concerned about actually making things than meeting your standards of application development.
Re: (Score:2)
Computers are getting more and more powerful, with more and more computation and storage resources readily available. So the performance hit of an interpreted language running on top of a native language is not as big of a deal nowadays.
It's far easier for many people to code in something they're familiar with (JS, web technology), instead of in something completely new (QT's API). Thus, to drive adoption rates, as well as to make life easy for many people, they put web technology on top of the API and let
Re: (Score:3)
Not all computers are bigger and more powerful. Some computers are still relatively tiny, some need to pull back on the horsepower to save cost, power, battery life, etc. There is more to computing than desktops. Can people let their smart phones run all week without charging? Probably not and part of this reason is that no one bothers much with efficiency anymore.
Now for programming familiarity you're right. However the vast majority of Qt programmers are probably far more familiar with C/C++ than wit
come on (Score:5, Funny)
How can you start that sentence but not finish it thusly:
"After nine months of effort, Nokia's Qt Lab has given birth to..."
Re: (Score:1)
If they plan on going mobile then i'm afraid (Score:2)
QT was nice - but I would like to know what would prompt anyone, any business or anyone else to be compelled to work with QT when you have the
Well (Score:3)
On the desktop, it is an extremely fluid, extensible, quick yet powerful way of developing visual applications in a language that many love (C++).
I would quite like it if I could build applications for the core mobile devices under that exact same setup.
But that isn't what they are aiming for, and you're right, their sights seem set on irrelevancy and failure.
Re: (Score:2)
So, what exactly would you use to target Windows, OS X, common Unices, and some embedded devices, all from one codebase?
Re: (Score:2)
wxWidgets? GTK+? FLTK? I could go on.
Re: (Score:3)
They have nowhere near the functionality of Qt. Never mind the handwritten introspections in GTK. You'd think people could use, you know, computers to do the mundane for them. The distaste for using tools other than the holy compiler is awful. You've got all those beautiful resources, yet you choose to be confined to the expressiveness (rather, lack thereof) of C. Yay.
Re: (Score:2)
Never mind the handwritten introspections in GTK. You'd think people could use, you know, computers to do the mundane for them. The distaste for using tools other than the holy compiler is awful. You've got all those beautiful resources, yet you choose to be confined to the expressiveness (rather, lack thereof) of C. Yay.
Ever heard of GObject introspection and Vala?
Re: (Score:2)
With plain GObject, you had to handwrite all that crap! In Qt, you write a method signature once, you declare it as a signal or a slot, and you're done. IIRC with GObject you have to tell the framework about everything: the name of the method, what arguments it takes, all that other crap, it's insane that anyone would still be expecting application developers to handle this crap by hand. Of course Vala changes all that, and it provides more functionality than Qt's moc, I give them that. But it's a work in p
Re: (Score:2)
With plain GObject, you had to handwrite all that crap! In Qt, you write a method signature once, you declare it as a signal or a slot, and you're done. IIRC with GObject you have to tell the framework about everything: the name of the method, what arguments it takes, all that other crap, it's insane that anyone would still be expecting application developers to handle this crap by hand.
Of course not, the GObject introspection compiler can extract basic types from the source. It needs extra annotations for semantics that cannot be reflected in plain C.
Of course Vala changes all that, and it provides more functionality than Qt's moc, I give them that. But it's a work in progress, so it's not really on equal footing to Qt.
It's quite stable and is used for things such as Folks, the GNOME contact information storage.
Re:If they plan on going mobile then i'm afraid (Score:4, Interesting)
GObject introspection tool seems to be a recent thing -- that's what I glean from what passes for their documentation. Never mind that the tool itself is not documented within GObject documentation, so don't blame someone who refers to official documentation (not the live crapfest) for not finding it. Various anti-Qt-fanbois have been whining for the longest time about the fact that Qt uses an extra tool (like if that was hard, gimme a break). It was GTK's supposed win factor that you could do everything manually; of course if you feel so inclined you can code up QObject metadata by hand too, what moc does isn't magic.
Suddenly --- boom, GTK has not one but two brand-new tools that generate C code: the introspection compiler, akin to moc, and Vala, a whole new language. I'd hardly call the GObject introspection project innovative in any way, I mean come on, moc has been with us for 15 years or so. Yes, they finally realized that not everyone is a masochist even if they write in C, so good for them, but IMHO it's a bit too little, too late. Oh, and good luck finding it if you don't know it's already there.
As a professional developer, I would not really bother even looking at their stuff, the documentation is so bad. From my viewpoint, the fact that the Gnome project is cut up into so many libraries doesn't help at all, nor does it instill any confidence. The individual libraries are all a crapshoot from integration viewpoint: some use GObject, some don't, the API conventions differ, it seems like a loosely bound mess. When you work with a monolithic framework like Qt, at least you can count on some measure of self-consistency.
Re: (Score:2)
C++ is C with RAII and some code generation added. It helps with reducing the verbosity of the code. Properly designed C++ applications and frameworks don't have to be any slower than C. My main gripe with C is that it's just such a low-level language. It's not very expressive, it uses very low-level abstractions. It's a very crude tool.
Re: (Score:3)
Properly designed C++ applications and frameworks don't have to be any slower than C.
Faster even, because of additional optimization possibilities in cases like method calls and lambdas. Speaking as an inveterate C hacker.
Re: (Score:2)
True, but I think that in practice some code bloat and resultant cache pressure seems to compensate for some optimization gain if the latter result in code bloat. Of course there are times when C++ lets you optimize quite well -- just look at compile-time vectorization in the eigen linear algebra library. Quite clever yet today it's pretty much idiomatic C++.
To me, higher-level languages are more about programmer productivity and their promise to aid me in writing better, more correct code with less effort.
Re: (Score:2)
I think that in practice some code bloat and resultant cache pressure seems to compensate for some optimization gain if the latter result in code bloat.
What code bloat? Gnu C and C++ use the same code generator. It is entirely up to you if you want to use the bloaty STL stuff or not. A disciplined programmer can create code that is just as tight in C++ as C. File this under "answers to common misconceptions" please.
Re: (Score:2)
Nope. It's not about the code generator, it's about compiler generated code, such as template instantiations. STL is not supposed to be bloaty, it's a standard library that you are supposed to use, after all. Yet there are plenty of template instantiations that result in identical intermediate code (or identical code were the template parameter class constructors virtual), yet they are dumped multiple times by the compiler. Templatized code is often used solely as compile-time type carrier. C++ ABI and comp
Re: (Score:2)
Your solution is to know what templates you are instantiating. That is just discipline. I don't know about you, but when I am writing performance critical code I write my own templates.
Re: (Score:2)
Re: (Score:2)
Glade is a RAD tool to enable quick & easy development of user interfaces for the GTK+ toolkit and the GNOME desktop environment.
So, Glade is akin to Qt Designer. So Glade is not a framework, GTK is.
Re: (Score:1)
Waited too late? My Sharp Zaurus SL-5600 shipped from the factory running Qt a decade ago. That's five years before the iPhone was released. Qt is not a newcomer. It is one of the most ancient toolkits in this market.
Re: (Score:2)
Waited too late? My Sharp Zaurus SL-5600 shipped from the factory running Qt a decade ago. That's five years before the iPhone was released. Qt is not a newcomer. It is one of the most ancient toolkits in this market.
that's exactly the thing that makes nokias qt effort look like they wasted a lot of money to the tune of 100millions+ with this endeavor. you see, their qt for mobile took a horrible amount of time until it wasn't so badly broken that you could write actual apps with it(it's "ok" now, but wasn't when they were making the big push to companies about it being the future model for all nokia development).
(too much money == too many people is probably the reason too why it got delayed and delayed and shipped bro
Re: (Score:2)
We have to remember that the mobile market is in its infancy and Apple and Google are the only ones poised for growth in this market. Just imagine what its going to be like in 3 or 4 years?
That's a goofy statement. 4 years ago Nokia and RIM were on top of the world, what makes you think that Google and Apple won't see the same fate?
I think it is far from infancy... closer to saturation.
Re: (Score:2)
Nokia is irrelevant now as far as QT is concerned
Not entirely. Please correct me if I'm wrong, but Nokia still has fulltime QT devs on staff. And it looks like QT has pretty much landed on the N900 [nokia.com], about the only Nokia product that actually has legs in spite of Elop's efforts to kill it.
Re: (Score:2)
QT has binding to widget sets from many languages as does GDK. If you want to use a non standard language, particularly one where you want non standard primitives (i.e. you want thing other than integer, string... to be first class objects) QT makes it easy. Interesting enough one of the obvious areas that this sort of application makes sense is programming language GUIs. For example the dynamic language GUI problem hasn't been solved since "evaluatable statements" is a complex context specific idea whil
QML (Score:2)
Re: (Score:2)
QML is as close to JSON as it can be while still supporting all the features that are needed for the concept to work. I'm not sure in what way you would like for it to be closer to JSON? I suppose the most major difference is that where JSON is weak typed QML is stronger typed. Properties are pretty strong typed, whereas the included JavaScript in signal handlers and other places is (obviously) completely weak-typed. But even the stronger-typed properties are not as strongly typed as they would be in C++.
Fo
V8 (Score:1)