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:0)
KDE developers take it on?
Re:Nokia's fate? (Score:5, Informative)
Correct. I believe the QT foundation has a longstanding agreement in place to ensure that.
Re:Nokia's fate? (Score:1)
Notice it is Qt Labs releasing Qt and not Nokia?
Re:Nokia's fate? (Score:0)
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? (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:Nokia's fate? (Score:0)
See this comment [slashdot.org]. He explains it much better than I did.
Re:Nokia's fate? (Score:0)
Simple, gtk will go back to its original purpose i.e. The free qt.
Re:Nokia's fate? (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:Nokia's fate? (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:Nokia's fate? (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 good citizenship.
Re:Nokia's fate? (Score:5, Informative)
Re:Nokia's fate? (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 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? (Score:5, Informative)
Re:Nokia's fate? (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:Nokia's fate? (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.
One or two Questions... (Score:0, Offtopic)
... 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... (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:One or two Questions... (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:One or two Questions... (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:One or two Questions... (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:One or two Questions... (Score:0, Flamebait)
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... (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:One or two Questions... (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:One or two Questions... (Score:2)
QED
Re:One or two Questions... (Score:2)
Re:One or two Questions... (Score:2)
"QT created interfaces masks and by intent" Either say something that makes technical sense, or shut up. Thank you.
Re:One or two Questions... (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:One or two Questions... (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:One or two Questions... (Score:1)
looks like Autoit has the problem, look at their target audience...
Re:One or two Questions... (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't know the details about Wayland but I would be surprised if Wayland used a different approach.
The problem with the 1-window-per-widget approach is it causes a lot of unnecessary refreshes, which lead to flickering and a low performance over remote access protocols such as Remote Desktop, Citrix, etc. The reason is the graphics layer (GDI, X11, Quartz, etc) is responsible for refreshing the widgets and it will refresh the full widget even if only one pixel changed, or even if it didn't change at all and it was only the parent widget which changed.
Since version 4.4, Qt takes a new approach: create ONE (and only one) top level window for the application, then simulate all the other widgets by "drawing" them on screen. This allows the Qt painting system to have a finer-grained control over what needs to be repainted and translates into no flickering without the need for double-buffering.
Given that AutoIt is expecting full-fledged Window objects, it will fail with any application using Qt 4.4 because there is only ONE Window object.
Now that we know why AutoIt fails, we can try to find out what needs to be done.
The first approach is to just tell Qt to use native widgets, i. e. 1-window-per-widget. The Qt documentation, which you have not read, explains how to do this:
http://qt-project.org/doc/qt-4.8/qwidget.html#native-widgets-vs-alien-widgets [qt-project.org]
As you are very lazy, let me summarize that for you: set the QT_USE_NATIVE_WINDOWS environment variable to 1 and now you can use AutoIt. Performance will degrate a bit, though.
The proper approach, which needs to be implemented in AutoIt, would be to hook into the Qt painting system and "learn" about the internal representation of the emulated Window objects. That way AutoIt would be able to automate any Qt application, not matter if QT_USE_NATIVE_WINDOWS is used or not. This is what GUI testing automation tools such as TestComplete, Squish and others do: toolkit-specific plugins for Qt, Gtk, WPF, DevExpress, Telerik, etc.
That's of course only true for applications using QWidgets. For applications using Qt Quick, there is nothing like QT_USE_NATIVE_WINDOWS and the only possible approach is to create a toolkit-specific approach.
Screenshots? (Score:0)
Or does it just look too bad?
Re:Screenshots? (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 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 (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:Focus on Mobile development (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).
Comment removed (Score:4, Insightful)
Re:Why? (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:No. (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:No. (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:Why? (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:Why? (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:Why? (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:0)
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? (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:Why? (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:Why? (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 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? (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:Why? (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:Why? (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:0)
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? (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:Why? (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:Why? (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:Why? (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 control flow.
Re:Why? (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 will certainly have programmed many horrible abominations using the UI tools, like copying and pasting the same thing over and over, instead of doing it in an object-oriented fashion, and the C++ programmer will simply have to deal with it.
Personally, I have not seen a web designer that he or she could or would code. They avoid coding like a plague. They just do not like coding, and that is why they chose to be designers. On the other hand, C++ programmers do not like scripting languages much. I seriously doubt QML will be of any use to anyone in any project, other than for toy projects.
Fashion is a double edged sword. If you follow fashion, you will stay relevant and 'in'. But you may accidentally introduce problems, especially if you are a software company.
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:Why? (Score:3)
Qt isn't going for web apps.
http://qt-project.org/wiki/Qt_for_Google_Native_Client [qt-project.org]
Re:Why? (Score:2)
Everything will eventually be web/net apps, you can quote me on this 10 years from now...
Re:Why? (Score:0)
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? (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:Why? (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 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.
Comment removed (Score:3)
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:come on (Score:0)
Obligatory [imgur.com] umwelt.
Re:come on (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 SDK from google and apple and all of the support behind it? Just random thoughts
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:If they plan on going mobile then i'm afraid (Score:2)
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 (Score:2)
wxWidgets? GTK+? FLTK? I could go on.
Re:If they plan on going mobile then i'm afraid (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:If they plan on going mobile then i'm afraid (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:If they plan on going mobile then i'm afraid (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 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 (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:If they plan on going mobile then i'm afraid (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:If they plan on going mobile then i'm afraid (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:If they plan on going mobile then i'm afraid (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. 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 (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:If they plan on going mobile then i'm afraid (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 compilers aren't clever enough yet to leverage that fully.
Re:If they plan on going mobile then i'm afraid (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:If they plan on going mobile then i'm afraid (Score:2)
Re:If they plan on going mobile then i'm afraid (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:If they plan on going mobile then i'm afraid (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:If they plan on going mobile then i'm afraid (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 broken)
Re:If they plan on going mobile then i'm afraid (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:If they plan on going mobile then i'm afraid (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:If they plan on going mobile then i'm afraid (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 while statements in static languages are not nearly so complex.
QML (Score:2)
Re:QML (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++.
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.
V8 (Score:1)