Beta

Slashdot: News for Nerds

×

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!

Qt 5 Alpha Released

Unknown Lamer posted more than 2 years ago | from the trolls-with-advanced-technology dept.

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

cancel ×

117 comments

Nokia's fate? (2)

rrohbeck (944847) | more than 2 years ago | (#39564073)

What's going to happen with Qt if/when Nokia goes down the drain and gets swallowed by (probably) Microsoft?

Re:Nokia's fate? (0)

Anonymous Coward | more than 2 years ago | (#39564091)

KDE developers take it on?

Re:Nokia's fate? (4, Informative)

Daniel Phillips (238627) | more than 2 years ago | (#39568325)

Correct. I believe the QT foundation has a longstanding agreement in place to ensure that.

Re:Nokia's fate? (1)

Anonymous Coward | more than 2 years ago | (#39564189)

Notice it is Qt Labs releasing Qt and not Nokia?

Re:Nokia's fate? (0)

Anonymous Coward | more than 2 years ago | (#39564273)

Notice it is Qt Labs releasing Qt and not Nokia?

Uh... maybe? The best I can guess you're implying that "Qt Labs" isn't part of Nokia. Now that could well be true, I've never heard of them before, but if that is what you want to say then can't you just say it?

Re:Nokia's fate? (1)

Desler (1608317) | more than 2 years ago | (#39564311)

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

Enderandrew (866215) | more than 2 years ago | (#39564511)

Qt is open source. Nokia could make all future iterations closed source, and then open source version gets forked like OpenOffice and LibreOffice.

Re:Nokia's fate? (0)

Anonymous Coward | more than 2 years ago | (#39564801)

See this comment [slashdot.org] . He explains it much better than I did.

Re:Nokia's fate? (0)

Anonymous Coward | more than 2 years ago | (#39564197)

Simple, gtk will go back to its original purpose i.e. The free qt.

Re:Nokia's fate? (1)

Anonymous Coward | more than 2 years ago | (#39564203)

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:Nokia's fate? (3, Informative)

Anonymous Coward | more than 2 years ago | (#39564221)

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:Nokia's fate? (2)

Daniel Phillips (238627) | more than 2 years ago | (#39568375)

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

Re:Nokia's fate? (5, Informative)

harry1701 (1553093) | more than 2 years ago | (#39564245)

Then the KDE Free Qt Foundation kicks in: http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php [kde.org]

Re:Nokia's fate? (1)

Kjella (173770) | more than 2 years ago | (#39565407)

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 just be a LGPL fork which you can do at any time - even now - and the KDE core libraries are under the LGPL too. It was a much bigger deal when Qt was only under the GPL+commercial license, not LGPL.

Re:Nokia's fate? (5, Informative)

transmetal (904896) | more than 2 years ago | (#39564375)

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.

Re:Nokia's fate? (1)

Anonymous Coward | more than 2 years ago | (#39564435)

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? (5, Informative)

noahwh (1545231) | more than 2 years ago | (#39564547)

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:Nokia's fate? (1)

diego.viola (1104521) | more than 2 years ago | (#39564945)

Isn't Qt under an open governance now?

http://wiki.qt-project.org/The_Qt_Governance_Model
http://qt-project.org/

Re:Nokia's fate? (3, Informative)

fast turtle (1118037) | more than 2 years ago | (#39566899)

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.

Happy Tuesday! (-1)

Anonymous Coward | more than 2 years ago | (#39564081)

Thank you for being a friend
Traveled down the road and back again
Your heart is true, you're a pal and a cosmonaut.

And if you threw a party
Invited everyone you ever knew
You would see the biggest gift would be from me
And the card attached would say, thank you for being a friend.

One or two Questions... (-1, Offtopic)

3seas (184403) | more than 2 years ago | (#39564129)

... Does QT still break Autoit? http://www.autoitscript.com/site/autoit/ [autoitscript.com] Or is it maintaining programmer arrogance by preventing the users from using computers to automate complexity ... in essence maintaining the dumb downing of the user base by hiding what computers are for????. I'd imagine the Roman Numeral accountants argued only a fool would think nothing has value, so to maintain their high position in society (re: zero place holder of the Hindu-Arabic decimal system.)

Why is there always something in the way of user ease and simplicity in automation?

http://abstractionphysics.net/ [abstractionphysics.net]

Re:One or two Questions... (1)

Bill, Shooter of Bul (629286) | more than 2 years ago | (#39564459)

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:One or two Questions... (0)

3seas (184403) | more than 2 years ago | (#39564799)

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:One or two Questions... (2)

Bill, Shooter of Bul (629286) | more than 2 years ago | (#39565159)

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:One or two Questions... (1)

INeededALogin (771371) | more than 2 years ago | (#39564813)

... 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:One or two Questions... (-1, Flamebait)

3seas (184403) | more than 2 years ago | (#39564961)

The story topic is QT not slashdot and it is QT that is masking and thats not very "open", thought autoit is freely available.

Maybe you should have said QT is a broken record as there have been other stories of it too.

Quite honestly I was very interested in QT on both Linux and Windows....until I discovered this. Is Open half way?

Re:One or two Questions... (1)

INeededALogin (771371) | more than 2 years ago | (#39565003)

Qt is open-source. You or Autoit can fix whatever problem is hurting it and submit the patch. Your crusade against Qt because of Autoit is misplaced, trolling and off-topic on slashdot.

Re:One or two Questions... (-1)

3seas (184403) | more than 2 years ago | (#39565153)

Certainly the QT devs know QT created interfaces masks and by intent.

Question is "have they changed this?"

You want to play slashdot cop? You must be new here.

Re:One or two Questions... (3, Informative)

INeededALogin (771371) | more than 2 years ago | (#39565351)

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:One or two Questions... (1)

Bill, Shooter of Bul (629286) | more than 2 years ago | (#39565849)

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:One or two Questions... (-1, Troll)

3seas (184403) | more than 2 years ago | (#39566203)

But can you show your intelligence of yourself and match up the fictional wish list of the Nebuchadnezzar crew killings with the action constants that in reality cannot be killed off?
http://threeseas.net/vicprint/VIC-basic.html [threeseas.net]

What is programming but writing a word = definition in one form or another?

And everyone does it. So why the false constraints?

Re:One or two Questions... (1)

Bill, Shooter of Bul (629286) | more than 2 years ago | (#39566277)

QED

Re:One or two Questions... (1)

tibit (1762298) | more than 2 years ago | (#39565855)

"QT created interfaces masks and by intent" Either say something that makes technical sense, or shut up. Thank you.

Re:One or two Questions... (-1, Troll)

3seas (184403) | more than 2 years ago | (#39566135)

Its so simply its probably beyond you.

Take any program created with a QT interface and try to automate it with Autoit.
I don't have to say anything when you can try it out for yourself, see it for yourself, and then you can write the words to describe it.

Re:One or two Questions... (1)

tibit (1762298) | more than 2 years ago | (#39566665)

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:One or two Questions... (0)

Anonymous Coward | more than 2 years ago | (#39567773)

ur problem is u r a stupid noob since u ask.

Re:One or two Questions... (0)

Anonymous Coward | more than 2 years ago | (#39566291)

Disregard the new 7 digit account troll tibit. He's a noob.

Re:One or two Questions... (2)

GuB-42 (2483988) | more than 2 years ago | (#39567899)

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.

Screenshots? (0)

Anonymous Coward | more than 2 years ago | (#39564149)

Or does it just look too bad?

Re:Screenshots? (1)

Daniel Phillips (238627) | more than 2 years ago | (#39568445)

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 fly, no need to recompile. I suppose QT 5 provides a similar capability, but I'm doing this already, with QT 4, and it's without any thick new layer of abstraction.

In general I really like QT, I just don't like the MOC. I mean, it isn't the most clumsy interface builder I've ever seen. It's fine for interfaces that don't change on the fly but it really gets in the way if you want to do dynamic things like create widgets in response to user actions or loaded data. And it's too cavalier about getting in the way of the C++ compiler and linker, not to mention the additional build complexity. Now that I've gotten past that I don't have any complaints at all.

Focus on Mobile development (1)

Anonymous Coward | more than 2 years ago | (#39564151)

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

Nyeerrmm (940927) | more than 2 years ago | (#39564755)

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:Focus on Mobile development (2)

shutdown -p now (807394) | more than 2 years ago | (#39566991)

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

Darinbob (1142669) | more than 2 years ago | (#39564193)

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

Anonymous Coward | more than 2 years ago | (#39564297)

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

Anonymous Coward | more than 2 years ago | (#39564325)

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.

Re:Why? (-1)

Anonymous Coward | more than 2 years ago | (#39564475)

QMl is junk. It only simplifies things for idiots but makes things much more complex for writing something beyond toy apps. Also, I didn't say to use the old desktop widgets on mobile, but to entirely ditch C++ for UI for some Javascript-based abortion whilst alienating your core developers is extremely dumb. There is no reason they couldn't have implemented their new mobile-friendly framework using C++ other than being incompotent and buying into web app hype waaay too much.

Re:Why? (0)

Anonymous Coward | more than 2 years ago | (#39565251)

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

Re:Why? (1)

Kjella (173770) | more than 2 years ago | (#39565811)

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

Daniel Phillips (238627) | more than 2 years ago | (#39568457)

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? (0)

Anonymous Coward | more than 2 years ago | (#39568983)

This is just Google's way of destroying Qt. Just like Microsoft did to javascript(javascript, j++, j#) which still hasn't recovered.

J++ and J# are similar to Java not to Javascript - maybe you're confusing them with JScript which is used for WSH scripts.

No. (2)

AdamJS (2466928) | more than 2 years ago | (#39564493)

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

SpinyNorman (33776) | more than 2 years ago | (#39567295)

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

Daniel Phillips (238627) | more than 2 years ago | (#39568465)

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

GumphMaster (772693) | more than 2 years ago | (#39565547)

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:Why? (0)

Anonymous Coward | more than 2 years ago | (#39566527)

There isn't any. That's the major problem. Even the toy examples are noticeably more laggy and slow compared to QWidget apps even with less complex displays and showing less data than the more complex widget app. QML is a toy for "designers" who don't know how to program.

Re:Why? (0)

Anonymous Coward | more than 2 years ago | (#39564589)

maybe it's because gobject-introspection in current glib allows gtk programs to be written in multiple languages, including javascript. And QT wants in.

But they're doing it wrong, as always. Gnome has always been about small libraries rewritten over and over until they get it right. gobject-introspection is the Holy Grail that people have been seeking for the past 20 years

Re:Why? (4, Informative)

Carewolf (581105) | more than 2 years ago | (#39564411)

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

msobkow (48369) | more than 2 years ago | (#39566713)

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:Why? (2)

Daniel Phillips (238627) | more than 2 years ago | (#39568479)

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:Why? (2)

SQLGuru (980662) | more than 2 years ago | (#39564445)

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 problem with non-native apps is that they don't model the host environment -- but that's more about the designer being lazy than it is a technological hurdle (it isn't "easy", but it can be done). If a web app looked like Metro on MS devices and iOS on Apple devices, who would care whether it was a web app or a native app?

Re:Why? (1)

user32.ExitWindowsEx (250475) | more than 2 years ago | (#39567463)

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

aliquis (678370) | more than 2 years ago | (#39567913)

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:Why? (0)

Anonymous Coward | more than 2 years ago | (#39564451)

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.

Wasn't Hypercard like that?

Re:Why? (4, Interesting)

harry1701 (1553093) | more than 2 years ago | (#39564455)

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:Why? (2)

DoofusOfDeath (636671) | more than 2 years ago | (#39565091)

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? (4, Informative)

bertok (226922) | more than 2 years ago | (#39566279)

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

Lunix Nutcase (1092239) | more than 2 years ago | (#39566553)

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:Why? (2)

bertok (226922) | more than 2 years ago | (#39566903)

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

Re:Why? (1)

Daniel Phillips (238627) | more than 2 years ago | (#39568497)

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.

Re:Why? (3, Insightful)

shutdown -p now (807394) | more than 2 years ago | (#39567025)

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

Lussarn (105276) | more than 2 years ago | (#39564477)

Everything will eventually be web/net apps, you can quote me on this 10 years from now...

Re:Why? (0)

Anonymous Coward | more than 2 years ago | (#39564531)

I think it's a productive idea to write the entire UI logic in JavaScript since execution speed isn't really a concern and it often takes less code to accomplish things. Also more users would be able to make changes to the code and optimally you should be able to for example view the source of a badly designed file open dialog, make changes and immediately see the effect.

Re:Why? (1)

Korin43 (881732) | more than 2 years ago | (#39564553)

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

steelfood (895457) | more than 2 years ago | (#39565829)

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 people run wild.

Make no mistake, real development will still heavily rely on C++. But there's a place for quick and dirty, proof of concept stuff, and that's where this comes in.

Re:Why? (2)

Darinbob (1142669) | more than 2 years ago | (#39566629)

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 with Javascript and web stuff. Maybe it'll appeal to management better though.

I don't mind quick and dirty proof of concept, if done right. But markup languages doesn't seem to be the same thing. Proof of concept apps also have a big tendency to turn into a shipping apps...

come on (5, Funny)

Anonymous Coward | more than 2 years ago | (#39564199)

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:come on (0)

Anonymous Coward | more than 2 years ago | (#39564383)

Obligatory [imgur.com] umwelt.

Re:come on (1)

Anonymous Coward | more than 2 years ago | (#39567293)

That's labored...

If they plan on going mobile then i'm afraid (1)

Cutting_Crew (708624) | more than 2 years ago | (#39564329)

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 SDK from google and apple and all of the support behind it? Just random thoughts

Well (2)

AdamJS (2466928) | more than 2 years ago | (#39564567)

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:If they plan on going mobile then i'm afraid (1)

tibit (1762298) | more than 2 years ago | (#39565889)

So, what exactly would you use to target Windows, OS X, common Unices, and some embedded devices, all from one codebase?

Re:If they plan on going mobile then i'm afraid (-1)

Anonymous Coward | more than 2 years ago | (#39566331)

Look at the new 7 digit account noob trying to play smart, lol!

Re:If they plan on going mobile then i'm afraid (1)

Lunix Nutcase (1092239) | more than 2 years ago | (#39566569)

wxWidgets? GTK+? FLTK? I could go on.

Re:If they plan on going mobile then i'm afraid (2)

tibit (1762298) | more than 2 years ago | (#39566635)

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:If they plan on going mobile then i'm afraid (0)

Anonymous Coward | more than 2 years ago | (#39567761)

C is extremely fast. OS are largely written in it, you amateur noob.

Re:If they plan on going mobile then i'm afraid (1)

tibit (1762298) | more than 2 years ago | (#39568087)

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:If they plan on going mobile then i'm afraid (2)

Daniel Phillips (238627) | more than 2 years ago | (#39568553)

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:If they plan on going mobile then i'm afraid (1)

tibit (1762298) | more than 2 years ago | (#39568977)

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. They don't have to perform better than Algol-style C code would, except for hot spots (DSP, image processing, etc) -- in those hot spots C++ seems to be gaining ground due to synergy of better compilers and better understood C++ programming techniques.

Re:If they plan on going mobile then i'm afraid (1)

Daniel Phillips (238627) | more than 2 years ago | (#39569025)

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:If they plan on going mobile then i'm afraid (1)

21mhz (443080) | more than 2 years ago | (#39568041)

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:If they plan on going mobile then i'm afraid (1)

tibit (1762298) | more than 2 years ago | (#39568153)

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 progress, so it's not really on equal footing to Qt. What Vala does is akin to early C++-to-C implementations, but the language it implements is what C++ ought to be. I like it so far, but it's not ready for prime time.

Re:If they plan on going mobile then i'm afraid (1)

DCFusor (1763438) | more than 2 years ago | (#39566989)

Perl, Glade. Already do.

Re:If they plan on going mobile then i'm afraid (1)

tibit (1762298) | more than 2 years ago | (#39568077)

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:If they plan on going mobile then i'm afraid (1)

jessehager (713802) | more than 2 years ago | (#39566651)

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:If they plan on going mobile then i'm afraid (1)

Formalin (1945560) | more than 2 years ago | (#39567565)

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:If they plan on going mobile then i'm afraid (1)

Daniel Phillips (238627) | more than 2 years ago | (#39568527)

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.

QML (1)

TheNinjaroach (878876) | more than 2 years ago | (#39565213)

I just took a look at QML on Wikipedia and the code examples aren't exactly awesome. I wish they would have stuck closer to JSON syntax.

Re:QML (2)

djfreestyler (2579333) | more than 2 years ago | (#39566939)

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

For example, objects use introspection to resolve functions, meaning that I can call any exposed method on that object. The same goes for properties on objects. Where the strong typing appears is when you want to assign something to that property - an object property will throw an error when you try to assign an int and vice versa. While I personally appreciate it, I believe this was mainly done to ease the integration between QML and C++, since it becomes easier to optimise method calls if you do not need to parse the type at every call.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...