Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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.

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

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

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

They've made an effort over the past year to move Qt into becoming an independent project. See http://qt-project.org/ [qt-project.org] and http://wiki.qt-project.org/The_Qt_Governance_Model [qt-project.org] . In some respects, Nokia's already put all their eggs in Microsoft's basket (their abandoning of Meego and non Windows Phone mobile OSs), and it doesn't seem to have impacted Qt's development in any noticeable fashion.

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.

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.

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?

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.

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.

AutoIt is designed to work with native windows controls, so it wouldn't surprise me to learn it has problems with manipulating Qt applications, especially if Qt is handleless under Windows (I dunno if it is).

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

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.

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'

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

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.

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

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.

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.

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.

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

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.

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.

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.

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

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

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.

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.

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

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

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

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.

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.

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

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

that they have probably waited too late. Nokia is irrelevant now as far as QT is concerned and so what is MS buys them as some point out? MS is pretty much irrelevant as well. 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?

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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

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.

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