Qt 5.0 Released

I use it so it's relevant to me. by Anonymous Coward · 2012-12-19 05:39 · Score: 1

It's mature and has all the bells and whistles. Only other alternative is WxWidgets...

What else did you have in mind ?

Re:I use it so it's relevant to me. by Anonymous Coward · 2012-12-19 06:18 · Score: 2, Insightful

He probably means that because the brain damage management at Nokia couldn't get it going on a phone that it's doomed. Android and Apple won and if you buy into the "Desktop is Dead" idiocy then you think that mobile is the only target that matters. We won't tell the fuck head that 9 out of 10 times those "Desktop is Dead" articles are viewed from a desktop. It's confusing to them. No those are real numbers. Go look at all the sites you use to decide who's winning the browser war. They may disagree on which one is the absolute victor but they all agree that mobile browsers only account for about 10% of the total market. (Hint people are buying mobile phones because they are mobile phones more than because they come with a browser that will drive your data plan into ob$cenity. Almost no one but the hard core geek uses their mobile browser as much as the voice or texting services they purchased the phone for in the first place.)
Now if you don't buy into the hoopla and realize that the desktop isn't dieing then Qt is relevant, useful, alive and kicking. It takes more than Nokia shooting itself in the foot with Microsoft's gun to kill Qt.
Re:I use it so it's relevant to me. by marcosdumay · 2012-12-19 06:49 · Score: 2

Almost no one but the hard core geek uses their mobile browser as much as the voice or texting services they purchased the phone for in the first place.
It's email (I'm resisting the temptation to finish that setence with "stupid", because you really doesn't deserve that label).
People use smartphones for email and things similar to it, like twiter and facebook updates. Not for the web, not for complex work, but for communication.
I used to think it was just me, but then, all the studies I've seen recently about how people read email point to that.

--
Rethinking email
Re:I use it so it's relevant to me. by TemporalBeing · 2012-12-19 08:33 · Score: 3, Informative
It's mature and has all the bells and whistles. Only other alternative is WxWidgets...
What else did you have in mind ?
Here's the basic group that Qt belongs as part of:
- Qt
- Gtk
- WxWidgets (WxWindows)
- SDL
WxWidgets is public domain; and was the first (AFAIK) to do both Signals/Slots and Message Maps for inter-object comms.

Gtk was originally just MessageMaps, and now also does Signals/Slots; but it also tends to be heavily GNOME centric and rather largely ignored by GNOME in maintaining it - it moves along, but at a snails pace because they're not really paying attention to it (to my understanding from talking to someone in the GNOME community).

SDL isn't quite as feature complete as any of the others, but can get the job done.

Qt is really the only first class library in that group, and now reaches even more platforms than ever before. And with Qt embedded, it runs in many devices that you may never have thought of as having run Qt (Microwaves, TVs, Refrigerators, etc.). Qt really is to multi-platform development what Linux is to processors in that respect.

So in the sense that nothing else is really as feature complete and professional as Qt - yes, it's in its own category. But in reality there are several other major competitors - and all from the FLOSS community at that.
--
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Re:I use it so it's relevant to me. by Psychotria · 2012-12-19 09:20 · Score: 4, Informative

Small correction: wxWidgets isn't public domain. It's licensed under the wxWindows Licence which, as their page states, is like the LGPL but with a few differences.
Re:I use it so it's relevant to me. by byuu · 2012-12-19 09:25 · Score: 4, Informative

SDL isn't quite as feature complete as any of the others, but can get the job done.

That's ... a bit of an understatement. SDL is a frame buffer, audio buffer, and input poller. For writing GUIs, it's about as feature-complete as QPainter. Sure, you can write your own GUI widget library on top of it, but that won't be pleasant for you or your users.

SDL is more suited for abstracting the platform video/audio/input APIs, and can be used nicely in conjunction with Qt, GTK+, etc.
Re:I use it so it's relevant to me. by lengau · 2012-12-19 09:30 · Score: 3, Informative

Most people don't know what Qt is, though. They don't realise how much of the software they use uses it.

--
I really wanted to change my sig to something witty, but all I could come up with is this.
Re:I use it so it's relevant to me. by TemporalBeing · 2012-12-19 09:50 · Score: 2

Small correction: wxWidgets isn't public domain. It's licensed under the wxWindows Licence which, as their page states, is like the LGPL but with a few differences.
Interesting. I hadn't looked at in in a few years (2004,2005). So they've changed their license since it use to be public domain. I was surprised at the time, but oh well. Good to see them using a nicer license though.

--
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)

Re:A good example of a bad summary by mark-t · 2012-12-19 05:41 · Score: 3, Insightful

...or, they could just follow the link and see for themselves.

Oh right, this is slashdot.

But it's not even like you have to read anything. It's a video demonstration.

--
File under 'M' for 'Manic ranting'

Re:A good example of a bad summary by Anonymous Coward · 2012-12-19 05:41 · Score: 5, Insightful

... hence thousands of non-programmers continue to talk about how superior it is to GTK+

Having done a small amount of Qt programming, it's also one of the most pleasant APIs I've worked with, both in its C++ form and in PyQt.

Re:A good example of a bad summary by jeffmeden · 2012-12-19 05:44 · Score: 1

If you don't know exactly what QT is/does since the first time you compiled it in order to run kvirc back in 1998... Then I don't know what you are even doing here.

Re:A good example of a bad summary by matunos · 2012-12-19 05:49 · Score: 5, Insightful

If you didn't already know what Qt was, then you're probably not going to be particularly interested that version 5.0 is out.

C++ Standards by joelholdsworth · 2012-12-19 05:54 · Score: 3, Interesting

Did they make any moves towards using standard C++ features rather than the MOC ugliness? What with Boost::Signals, sigcxx and C++11, I see no reason why they have to bastardise the language to provide signals.

Re:C++ Standards by joelholdsworth · 2012-12-19 05:58 · Score: 1

RTFA: They have made some good progress on this - but I can't tell if MOC is dead yet.
Re:C++ Standards by Desler · 2012-12-19 06:02 · Score: 2

They aren't eliminating MOC. For one thing, they support a number of compilers that don't have and probably never will have full C++11 support.
Re:C++ Standards by N3Roaster · 2012-12-19 06:04 · Score: 5, Informative

Yes and no. The signals and slots mechanism is still there and it's still using moc, but there's a new connection syntax available that's a lot more C++ like, allows C++11 lambdas in place of slots, and offers compile-time checking of connections that previously would just fail at run time. Won't please the purists, but it's a step in the right direction.

--
Remember RFC 873!
Re:C++ Standards by Anonymous Coward · 2012-12-19 06:13 · Score: 1

Moc provides nice introspection features not available in normal C++. Why remove that? They are needed to integrate QML (declarative language for UI design) with C++.
You can use template-based signals and slots in Qt5 and even connect signals to lambdas.
Re:C++ Standards by stenvar · 2012-12-19 06:14 · Score: 2

You don't need C++11 to replace MOC. MOC was obsoleted by C++ features many years ago.
Re:C++ Standards by Noughmad · 2012-12-19 06:30 · Score: 1

Yes, they did. See the wiki page.

--
PlusFive Slashdot reader for Android. Can post comments.
Re:C++ Standards by loufoque · 2012-12-19 07:06 · Score: 1, Informative

Let me add that In this particular instance, many is 15 years.
Re:C++ Standards by Urkki · 2012-12-19 07:55 · Score: 1

Let me add that In this particular instance, many is 15 years.
How do you call a C++ method by it's name from QML or javascript or C++ plugin without some kind of pre-prosessing step which actually stores the method names and argument types somehow to make invocation possible?
Re:C++ Standards by loufoque · 2012-12-19 08:10 · Score: 1

dlsym(h, "my_method")
There is no need to store it, it's already in the symbol table.
If you do want to store it, there is no need to use an external preprocessor anyway.
Re:C++ Standards by TemporalBeing · 2012-12-19 08:44 · Score: 1

dlsym(h, "my_method") There is no need to store it, it's already in the symbol table.
If you do want to store it, there is no need to use an external preprocessor anyway.
That works for functions, but not Class Methods that require an instance of the class. And, even more so, how do you do it in a multi-platform environment in a uniform way? (http://en.wikipedia.org/wiki/Dynamic_loading). Windows doesn't use dlopen/dlsym/dlclose but has its own Win32 functions to do something similar. You're also relying on RTTI; and not every compiler or environment supported by Qt supports RTTI. (RTTI also has its own run-time overhead which is bad in embedded environments like what Qt supports.)

--
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Re:C++ Standards by loufoque · 2012-12-19 08:48 · Score: 1

It works for any symbol, regardless of its type.
This has nothing to do with RTTI.
The API for plug-ins is platform-specific since there is no standard interface for C++ plug-ins.
Re:C++ Standards by TemporalBeing · 2012-12-19 09:44 · Score: 4, Informative

It works for any symbol, regardless of its type. This has nothing to do with RTTI.
The API for plug-ins is platform-specific since there is no standard interface for C++ plug-ins.
Yes, you could use dlsym() when building the table MOC builds for the connector calls. That's it. That's also a very very small part of what MOC does. That could be done as part of the object constructor...except now you need to store both static compile-time information (the functions you want to add) and dynamic run-time information instead of just the static compile time stuff that MOC generates (in the moc_*.cpp files).

RTTI does a good bit of the rest of what MOC does. In neither case are they both supported by all platform+compiler combinations that Qt supports.

Qt5 now allows C++11 lambas in signal/slots; but only if you enable C++11 functionality when you build it - they still support compilers that don't support C++11 lambas.

--
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Re:C++ Standards by shutdown+-p+now · 2012-12-19 09:55 · Score: 1

It works for any symbol, regardless of its type.
You're still missing the point. How exactly, given a QObject*, can you ask it to give you some wrapper encapsulating a method named "foo"? Even if you're willing to do C++ name mangling yourself in a platform-specific way, you still need to know the actual type of the object to which you have the pointer, meaning that you need RTTI.
Re:C++ Standards by shutdown+-p+now · 2012-12-19 09:56 · Score: 1

Can you explain what Qt slots/signals give you (apart from the need to do extra preprocessing) that Boost.Signal does not?
Re:C++ Standards by loufoque · 2012-12-19 11:03 · Score: 1

I simply replied to the question "how do you call a C++ method by its name from a C++ plugin".
I don't see what this has to do with MOC.
There is no need to build any table either. There is no need to store anything, nor to use RTTI.
If you really wanted to generate tables of data (which again, I repeat, is not needed to do this), you still wouldn't need MOC anyway. You can just use macros and potentially templates to do that.
Re:C++ Standards by loufoque · 2012-12-19 11:04 · Score: 1

Calling a member function through a pointer to base bound to a derived object works fine assuming the function is virtual.
Re:C++ Standards by EvanED · 2012-12-19 11:07 · Score: 1

I simply replied to the question "how do you call a C++ method by its name from a C++ plugin".
You replied with an answer that works in some, but not all, cases -- even on the platforms on which it works at all.
Re:C++ Standards by loufoque · 2012-12-19 11:11 · Score: 1

It does work in all cases.
Re:C++ Standards by Unknown+Lamer · 2012-12-19 14:23 · Score: 1

The problem is that the moc implements something more like the Common Lisp Object System's metaobject protocol for C++; resolving symbols at runtime is a tiny portion of what it does. dlsym and analogues on other platforms are also horrendously unsafe; a one way ticket to strange segfault bugs when you cast the result to the wrong type. And since C/C++ types are not first class, you can't even construct the casts at runtime! (Ok, maybe C++11 has some new foo_cast template, I'll admit my C++ is a bit rusty). You're also ignoring issues of syntax — unfortunately C++ doesn't provide the needed tools to construct embedded grammars in the language, and performing the tasks moc automates can be incredibly awkward otherwise.

--

HAL 7000, fewer features than the HAL 9000, but just as homicidal!
Re:C++ Standards by scorp1us · 2012-12-19 16:45 · Score: 1

Qt signals are modeled after boost signals. I can't say what other than syntax is different (Qt begin easier to read), but signals/slots are supported in all paradigms - PyQt/PySide, QtQuick (JavaScript) and in threads. I don't think Boost has support for JS and Python. Functionally though, they are the same.
http://www.richelbilderbeek.nl/CppFromQtSignalToBoostSignal.htm

--
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Re:C++ Standards by scorp1us · 2012-12-19 16:56 · Score: 3, Informative

First, it's not bastardized. C++11 is the bastardization, because it results in code fragmentation. That wonderful cross platform C++11 function you write can only be targeted by C++11 compilers. Meanwhile in Qt land everything keeps working on your legacy compiler. The fact that it uses compiler macros to accomplish cross-platform cross-compiler interoperability does not lend itself to "bastardization"
MOC is not ugly, though I would prefer a C# approach of not having to separate it into a H file, but this is more a C++ thing than a Qt thing. I love the QMeta* that allows me to have introsepction at run time (again x-platform) and I can even dynamically create classes. Can C++11 do that? (Well i guess it can if it's using Qt) But they are adding C++11 syntax if you are using a C++11 compiler and want to limit your portability.

--
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Re:C++ Standards by shutdown+-p+now · 2012-12-19 17:07 · Score: 1

Qt signals are modeled after boost signals.
That would be impossible, given that Qt signals appeared much earlier than Boost.Signals. Indeed, I don't think Boost itself existed at that time - the effort for that began in 1998, while the first release of Qt was in 1992 (and, if I remember correctly, it had signals/slots since inception).

can't say what other than syntax is different (Qt begin easier to read),

Boost.Signals is a pure C++ solution that relies on templates and does not need any kind of preprocessor. It works out of the box on vast majority of C++ compilers, including g++ and MSVC.

I don't think Boost has support for JS and Python.
Well, Boost is a C++ library. That said, you don't really need any special support for signals in JS or Python, because they already have functions as first-class types.
Re:C++ Standards by Urkki · 2012-12-19 17:35 · Score: 1

dlsym(h, "my_method")
There is no need to store it, it's already in the symbol table.
If you do want to store it, there is no need to use an external preprocessor anyway.
Sorry, wrong answer. C++ method name symbols are mangled to include class name and parameters. Worse, this mangling is not standardized, it is compiler specific. In other words, that is not a method name, that is a C function name in the example you gave.
But it's even worse than just generating the symbol name. With virtual methods, you have to determine at runtime, what is the real class of the object pointer, because you need to call differently named method based on that. So, could be done with RTTI and compiler specific helper function to generate the mangled symbol name, but I don't remember anybody ever doing it...
Re:C++ Standards by Urkki · 2012-12-19 19:36 · Score: 1

I don't think Boost has support for JS and Python.
Well, Boost is a C++ library. That said, you don't really need any special support for signals in JS or Python, because they already have functions as first-class types.
I think he meant, he doesn't think it's easy to create bindings for emitting Boost signals from javascript or Python, like you can do from javascript engine running in Qt app, or from PySide/PyQt application.
While this doesn't make sense for Boost alone, without context, it becomes relevant and even critical, if you have a library/framework using Boost as core signal/slot mechanism. If you do that, how easy is it to emit such signals from an interpreted language? Or, to put it other way, are Boost signals a realistic option at all, if you want to leave open the option to interface with a scripting language?
I don't know.
Re:C++ Standards by shutdown+-p+now · 2012-12-19 19:41 · Score: 1

Well, Boost signals are just function objects. So long as whatever bridge you use to call C++ from a scripting language lets you invoke operator() on arbitrary stuff, it can emit a signal. I think Boost.Python would be able to do that, for example.
Re:C++ Standards by loufoque · 2012-12-19 22:47 · Score: 1

It's a symbol name. Finding the symbol name of a particular member function is not a problem. You don't need the type either, the base type is enough.
Re:C++ Standards by loufoque · 2012-12-19 22:51 · Score: 1

If you want to do duck typing, which is probably a bad idea, you'll indeed need to generate some runtime reflection data.
I don't see how generating that data is awkward using standard mechanisms.
Re:C++ Standards by TemporalBeing · 2012-12-20 03:08 · Score: 1

It does work in all cases.
Only for functions, not for non-static class members; and (as I pointed out) not efficiently enough for how Qt manages signals/slots; not likely sufficiently enough for how Boost handles them either.

--
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Re:C++ Standards by loufoque · 2012-12-20 05:26 · Score: 1

It works fine for any symbol, including non-static class members or whatever else you've put in your binary. dlsym does not care about the type of the symbol or the calling convention to call it, that's up to you to handle.
Now then, what you can argue is that this isn't a nice programming interface. It isn't, it's just how the platform does dynamic linking.
Re:C++ Standards by TemporalBeing · 2012-12-20 10:22 · Score: 1

Now then, what you can argue is that this isn't a nice programming interface. It isn't, it's just how the platform does dynamic linking.
It's also not portable. dlopen()/etc are not on Windows - which has its own unique interface for doing the same thing.

--
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Re:C++ Standards by scorp1us · 2012-12-21 02:13 · Score: 1

The point I was trying to make was that via the preprocessor approach, it becomes trivial for all these wrappers and interop between languages to happen. I've hacked MOC to produce alternate output as needed to automate some other tasks for me. I prefer having that step as it is useful, however C++ "purists" rather fragment the language than make use of such a tool. And I find that incredibly ironic.

--
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Re:C++ Standards by sjames · 2012-12-25 12:44 · Score: 1

I'm a bit late to the conversation, but I really want to know, how does dlsym deal with name mangling?

Re:A good example of a bad summary by knuthin · 2012-12-19 05:54 · Score: 1

this is awful editting

That doesn't sound right coming from a person spelling "editing" wrong.

--
Some apps are WYSIWYG. Some others are WYSIWTF.

Re:A good example of a bad summary by Johann+Lau · 2012-12-19 05:54 · Score: 2

That seems like totally valid criticism to me. So you're saying Qt is equal or inferior in all respects, and uses more resources? You should blog about this, because no amount of googling turns up remotely similar results. As a matter of fact, people seem to be quite happy with Qt, and "shinyness" doesn't even get mentioned in those discussions. Or is shiny just code for "not as fugly" .. ? Please elaborate.

KDE5? by pak9rabid · 2012-12-19 05:55 · Score: 1

How is this going to impact KDE? Will this be the start of KDE5?

Re:KDE5? by Anonymous Coward · 2012-12-19 06:35 · Score: 1

All the development of Qt5 has been public and KDE is well aware of it. KDE5 has been in the plans for some time (more than a year), it will be done eventually.
But we don't have to worry, the transition from 4 to 5 won't be as traumatic as from 3 to 4 because no major changes are required, it will probably be pretty smooth.
Re:KDE5? by NotBorg · 2012-12-19 06:43 · Score: 1

I read somewhere a while back that KDE was going to try to reduce the duplication of effort between KDE and Qt and rely more on Qt. I don't know where they're at with this but I'd like to here more.

--
I want this account deleted.
Re:KDE5? by NotBorg · 2012-12-19 08:40 · Score: 1

I'd like to hear more here, I mean.

--
I want this account deleted.
Re:KDE5? by Grishnakh · 2012-12-20 11:35 · Score: 1

Yes. KDE's major version number has always followed Qt's major version number. Don't worry, however; this isn't going to be like the KDE3->KDE4 transition at all. Instead, it'll look much like the KDE2->KDE3 transition (where they just updated the KDE code to compile against Qt3 instead of Qt2, and there were few major user-visible changes). KDE's only had two really huge revisions, and they were KDE2 and KDE4.

Re:A good example of a bad summary by fredprado · 2012-12-19 05:55 · Score: 1

There is no comparison between QT and GTK+. QT is by far superior in about everything. Only hipsters like you think otherwise.

How is Qt still relevant? by Andy+Prough · 2012-12-19 05:56 · Score: 4, Informative

It's the framework for KDE, which is the excellent, fast UI environment I use on my Linux rigs. Apparently a huge number of other projects either use it currently, or have used it in the past, including a number of well-known projects: Amazon Kindle, Google Earth, Adobe Photoshop, MythTV, Rosegarden, Skype, Virtualbox, VLC media player.

Re:How is Qt still relevant? by Trepidity · 2012-12-19 06:03 · Score: 1

Is it actually used on the Kindle? The only Qt-on-Kindle project I know of was an unofficial port which was abandoned by the maintainer two years ago.

--
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Re:How is Qt still relevant? by darronb · 2012-12-19 06:47 · Score: 3, Informative

Mine, also abandoned. I quickly stopped using the Kindle once it was obvious it was useless for viewing datasheets. http://www.griffin.net/2010/01/hacking-the-amazon-kindle-dx-part-2-qt-and-sudoku.html
Re:How is Qt still relevant? by Andy+Prough · 2012-12-19 06:57 · Score: 1

Nice work Darron - good proof of concept. Looks like some people did get some use out of the project.
Re:How is Qt still relevant? by Vektuz · 2012-12-19 07:19 · Score: 5, Informative

On the business software side, there's also well known applications like Autodesk Maya (2011 and above, they switched TO qt recently!), and also the Perforce client (P4V). I'm seeing more and more of it in the internals of "big" apps like that, even if the user is unaware. I have a feeling its partly because of the LGPL side of things opening up more than anything. Although I'm pretty sure autodesk licensed it commercially.
Re:How is Qt still relevant? by Anonymous Coward · 2012-12-19 09:01 · Score: 1

I'd point out that Qt is a wonderful framework to program for.
I'm not sure so sure about the QML, but Qt widget system is quite wonderful. I expect Digia will go the way of the money, as opposed to Nokia who went... straight towards their own demise.
I did write some tests for QML and I can't claim it was bad, but now that MeeGo is more or less stagnant, it's just pointless. I just don't belive the touchscreen on devices larger than 7" will pick up, because they're too cumbersome and quite frankly, heavy.
Re:How is Qt still relevant? by dotancohen · 2012-12-19 09:35 · Score: 2

It's the framework for KDE, which is the excellent, fast UI environment I use on my Linux rigs. Apparently a huge number of other projects either use it currently, or have used it in the past, including a number of well-known projects: Amazon Kindle, Google Earth, Adobe Photoshop, MythTV, Rosegarden, Skype, Virtualbox, VLC media player.
...Anki, Opera, Calibre, Stellarium, Krita...

--
It is dangerous to be right when the government is wrong.
Re:How is Qt still relevant? by ChunderDownunder · 2012-12-19 12:02 · Score: 2

The 'Burning platforms' memo killed off Nokia's Qt deployment but 2013 will see 3 offerings:
- KDE Plasma Active running on Vivaldi
- Sailfish running on Jolla phones
- BB10 running on RIM phones
(Not to mention Canonical targeting 12.04 on Nexus 7 - Kubuntu on your tablet!)
So QML ain't extinct; it's just hibernating.

A glorious day by mozumder · 2012-12-19 05:56 · Score: 5, Insightful

This really is the best cross-platform Apps framework out there. Far better than HTML5/Javascript.

Re:A glorious day by ikaruga · 2012-12-19 15:20 · Score: 1

I'm sorry but I couldn't see native code in any of these. Maybe for apps that use deals with small amount of text input, simple graphics, no peripheral hardware interfacing, have no intensive background processing and are running on very good cpus then that is okay. But for anything serious, just no.
Plus all these things are designed for webapps that run in a browser. Qt is for desktop apps. Comparing them is just stupid.
Re:A glorious day by Urkki · 2012-12-19 20:02 · Score: 1

Far better than HTML5/Javascript.
I doubt it. Qt is nice but depending on what's being developed, HTML5/JavaScript can be the superior solution.
I think there are very few different cases where HTML5+JavaScript is superior. Online cloud-backed apps running in browsers are obviously one case, removing the need for separate download, and on native side there's the case where HTML+JS is the only alternative supported by all platforms where the application needs to run...
But HTML (any XML) is klunky compared to QML if you want to go the declarative route, and for "real applications" like the much-mentioned Autodesk Maya, they're not even competing because one of them is not an option at all, and will not be for a decade at least.
HTML5+JavaScript will probably get there, once processing power and memory of (mobile) devices goes up a bit more, and once the standard stabilizes (assuming it stabilizes instead of fragmenting...), and mobile networks become faster, and once the JavaScript libraries develop to be more sophisticated, and support for non-networked data storage gets better. A decade, maybe, considering the inertia.

Re:Tablet support? by Unknown+Lamer · 2012-12-19 05:57 · Score: 2

The standard xinput mechanisms have full tablet support now. You can even use use cheap knockoff tablets now thanks to digimend (I got one from monoprice and it's pretty great for messing around with handwriting recognition and I've discovered that image editing with a trackball + tablet is great). Unfortunately all tablets are kind of broken except in the latest release of X.org because of a bug with coordinate transformations (basically, the pointer jumps if you make pressure changes without moving because the code transforms the already transformed coordinates... it also left touchscreens pretty broken; the guy that fixed it caused something like a dozen ubuntu on nexus 7 bugs to be closed!).

--

HAL 7000, fewer features than the HAL 9000, but just as homicidal!

standard compliance? by stenvar · 2012-12-19 05:57 · Score: 2

So, is it fully standard C++ now or do you still have to use their hokey preprocessor?

Re:standard compliance? by loufoque · 2012-12-19 07:07 · Score: 1, Informative

It's still a moc'ery of C++, if that's what you're asking.
And it still duplicates everything that's in the standard library, including containers, threads, files, etc.
Re:standard compliance? by Urkki · 2012-12-19 07:36 · Score: 1

So, is it fully standard C++ now or do you still have to use their hokey preprocessor?
Well, for many things Qt requires reflection features not provided with C++. When/if C++ starts to provide them as part of the language, I'm sure moc will become thing of the past, and be replaced with just translation data extractor, which you can leave out if you do not care about internationalization. But for what it's worth, with the new signal-slot connect syntax it's probably possible to have meaningful programs without running moc, if that makes someone happy.
Re:standard compliance? by Anonymous Coward · 2012-12-19 07:39 · Score: 2

Fixed this for you:
And it still duplicates everything that's NOW in the standard library, including containers, threads, files, etc. for the set of compilers and run times that are compliant.
Re:standard compliance? by suy · 2012-12-19 08:42 · Score: 1

So, is it fully standard C++ now or do you still have to use their hokey preprocessor?
Qt is, and always has been fully standard C++. The "moc" program is not a preprocessor, is just a tool, more precisely, just a code generator that writes for you some files that you have to either include at the end of your ".cpp" or you have to compile and link like other hand-coded files. If you use QMake, or CMake or any other buildsystem that has some Qt support (and most do), is completely effortless.
At a first glance, you see things that might look like an extension to the language, because you see stuff like "protected slots:" in addition to plain old public/private/protected C++. But here "slots" is just defined (using the standard C/C++ preprocessor) to an empty string, so the compiler sees the usual keywords only. Why is needed if is just an empty string? Well, because "moc" will use it when generating code.
Is possible to argue if all this (standard) preprocessor tricks are good or bad practice, but I have to say that it works for me. Qt has attemted to support a wide variety of environments, and the level of C++ support on those environments it's not the same. I even remember when TRUE and FALSE were provided as #defines because not all compilers had it. Right now I'm doing Qt development on an iMX23, and I'm quite constrained by the C++ compiler that Freescale provides, and I'm using Qt 4.8 just fine, the (till today) latest and greatest version.
Re:standard compliance? by vurian · 2012-12-19 09:11 · Score: 2

Well, you might even amend it to "provides much better implementations of things that are in the STL, , including containers, threads, files, lists etc."
Re:standard compliance? by shutdown+-p+now · 2012-12-19 10:04 · Score: 2

How exactly the magic Qt keywords like "slots" is implemented is really an implementation detail. From programmer's perspective, they are language extensions, because they introduce some new and important semantics into the language. The fact that they're handled by a separate codegen tool and stripped out of the code that's fed to the C++ compiler is irrelevant - you could just as well implement them directly in the compiler without changing their meaning, and it wouldn't magically change what they are.
Anyway, what's the difference? Even if they are language extensions, so long as they work and provide a useful feature, who cares?
Re:standard compliance? by stenvar · 2012-12-19 10:23 · Score: 1

OK, sounds like nothing has changed.
Re:standard compliance? by suy · 2012-12-19 19:18 · Score: 1

Yes, luckily good things like Qt didn't change, but unfortunately bad things like bashing Qt without making any point, and spreading misinformation (e.g. telling MOC is a preprocessor) didn't either.

Re:How? by gmuslera · 2012-12-19 05:58 · Score: 4, Insightful

One framework to rule them all, making programs for all platforms, including mobile ones, is a nice goal.

Re:Has it grown to encompass the entire OS yet? by gmuslera · 2012-12-19 06:02 · Score: 2

You build things over it, like desktops (like KDE) or mobile (like the upcoming Sailfish) environments.

Re:How? by Anonymous Coward · 2012-12-19 06:02 · Score: 1

Because all other frameworks suck?

Re:Tablet support? by ameline · 2012-12-19 06:08 · Score: 1

You're being a little Linux biased there -- I think the OP was referring to tablet support on windows. And I believe that it is broken in Qt 5 on windows. (I'd be happy to be wrong on this.)

--
Ian Ameline

Re:A good example of a bad summary by Anonymous Coward · 2012-12-19 06:13 · Score: 2, Informative

You obviously never programmed with QT then. QT API is generally pleasant to work with in that it's well documented, consistent, and not unnecessarily complex with a decent amount of examples.

QT is a larger framework because it does quite a bit more then GTK+ and others. In a Linux environment, that ram usage is shared so you can end up using much less ram in the end with multiple programs running on the same large library. This unfortunately is less of an advantage in Windows (where you see much less GTK+ or QT) but QT is split into several libraries meaning that you don't have to attach the entire framework to your code.

Realistically, QT isn't that large of a library for modern applications. It's definitely not the smallest but ease of programming is something to be said.

Is GTK+ bad? Never said that, but neither is QT. Simply pick the best library that works for you. For me, QT is definitely one of my top choices (though not always) after working with several frameworks.

Re:A good example of a bad summary by AvitarX · 2012-12-19 06:25 · Score: 5, Funny

Even worse, I don't know what "C++" or "project mean"!

--
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg

Re:Finally fit! by Kjella · 2012-12-19 06:25 · Score: 2

You mean to tell me that the old version of Qt were unfit?

Apparently it had far too little buzzword-compliance with their traditional widget-based imperative style GUI, now it's HTML/CSS/Javascript and declarative style GUI that is the "hot thing". I guess the good side is that it's like writing a web app that many developers know how to do but it has pretty much all the bad sides too, personally I find it's a giant step backwards. Or rather if I was going to do it this way I'd probably just go for HTML+JQuery and make it run in a browser against a back-end instead.

--
Live today, because you never know what tomorrow brings

Re:Scintilla? by EvanED · 2012-12-19 06:31 · Score: 1

QScintilla is available for Qt4, though it's probably a separate package.

I can't speak to everything, but I will pretty highly recommend the library. I've used it in both C++ and Python (via PyQt) and both times have been a remarkably pleasant experience. The C++ side's biggest drawback is they have a preprocessing step (the MOC compiler) that means that you won't be writing code which isn't standard C++: they've got a bunch of language extensions. I wouldn't imagine that anything significant would be missing.

Signals and slots by zenyu · 2012-12-19 06:37 · Score: 4, Informative

You can now use any C++ function as the target of a signal using the new QObject::connect() syntax. This is a huge win because with the new syntax the compiler and linker can check that the connections are valid instead missed connections just causing a run-time error.

The moc preprocessor is still required for QObject derived classes, mostly for the translation framework and also to provide support for the old signal/slot syntax which is still allowed. Qt5 doesn't require a C++11 compliant compiler, which is a good thing since there aren't yet any fully compliant compilers. I'm sure if there is a Qt6 it will require C++11 and use those features.

Some of the really cool C++11 features like move constructors aren't necessary with Qt because it's containers implement reference counted copy-on-write, so when you assign a QMap from another QMap no copy is made, and if the old QMap was an rvalue then there is never a need for the copy to be made when the new QMap is modified. One of the big improvements Qt4 made over Qt3 was to make container assignment atomic so this mechanism worked with threaded code and defensive deep copies weren't necessary anymore.

Re:Signals and slots by shutdown+-p+now · 2012-12-19 10:01 · Score: 2

Qt5 doesn't require a C++11 compliant compiler, which is a good thing since there aren't yet any fully compliant compilers. I'm sure if there is a Qt6 it will require C++11 and use those features.
C++11 is not necessary for MOC-less signals/slots - Boost has been offering them for years with all existing compilers.

Some of the really cool C++11 features like move constructors aren't necessary with Qt because it's containers implement reference counted copy-on-write, so when you assign a QMap from another QMap no copy is made
Sure, but what about your own types? Implementing COW is much harder than implementing a move constructor. I do hope that Qt containers use move semantics for elements when available, at least?
Also, COW is not free when it's thread-safe. Those atomic increments and decrements do add up, especially on instances of types that are copied around a lot (strings are a classic example of that).
Re:Signals and slots by Urkki · 2012-12-19 19:18 · Score: 1

Sure, but what about your own types? Implementing COW is much harder than implementing a move constructor.
In case you are genuinely interested, it's not hard, because there's a helper class for that: QSharedDataPointer
Re:Signals and slots by shutdown+-p+now · 2012-12-19 19:38 · Score: 1

That helps. On the other hand, if you use that trick (copying pointer to actual data around), you get the overhead of an extra indirection on every field access, as well as a heap allocation for every instantiated obejct (even if it's instantiated on stack). As I understand, Qt pretty much has to do it anyway for its classes to enable binary compatibility between minor releases via the usual Pimpl idiom, but it's not necessarily desirable for user classes.

Re:Qt Qt Qt by NotBorg · 2012-12-19 06:39 · Score: 1

That's true of any product release by any company. The releaser is always going to make the claim that it's better than before. It's up to you, the consumer, to look at the product and make a decision. If you want to make an informed decision you'll probably need to look at both what its promoters and its detractors have to say about it. This article is obviously about the promotion side of the product. You may find some detractors in the comments but so far they're doing a piss poor job. You'll have to try Google.

You should probably not click on articles that are obviously (from the subject line even) intended to promote a new version. They're going to upset you because they are by nature somewhat one sided. For the rest of us, that's not a major point of contention because we know who's point of view it's from and that we'll have to do some more looking if we want to be wholly informed.

Now sit down and shut up. People will think you're more intelligent that way.

--
I want this account deleted.

Re:A good example of a bad summary by lister+king+of+smeg · 2012-12-19 06:39 · Score: 2

It is not is such a unreasonable thing as to assume basic knowledge of the field. This is a site predominantly amid at compsci people and largely open source/*nix people at that. Knowing what qt is or the ability to find out on your own what qt is, is not unreasonable here. If you think they should have give you a definition of qt then why not ask for a definition for C++ as well as that would be just as nonsensical in this context.

--
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.

Re:Finally fit! by lister+king+of+smeg · 2012-12-19 06:45 · Score: 1

It's an overhaul of the Qt 4.x series and makes Qt fit for the future.

You mean to tell me that the old version of Qt were unfit?

there is a large difference between unfit and not as fit as it could be.

--
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.

Re:A good example of a bad summary by bluefoxlucid · 2012-12-19 06:48 · Score: 1

RAM usage doesn't come from big libraries. It comes from massive data sets being used to instantiate a whole bunch of shit. Libraries, even big ones, are small.

--
Support my political activism on Patreon.

Re:Scintilla? by AvitarX · 2012-12-19 06:48 · Score: 2

I will add that I love their sidebar docking, floating, tabbing, etc (see Eric IDE for a good example).

Eric makes use of QScintilla.

--
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg

You're right. by Andy+Prough · 2012-12-19 06:55 · Score: 2

It's an add-on. My bad. By the way, I think the better port is here: http://www.griffin.net/2010/01/hacking-the-amazon-kindle-dx-part-2-qt-and-sudoku.html

Re:A good example of a bad summary by Just+Brew+It! · 2012-12-19 07:03 · Score: 2

Agreed. I've never developed anything using Qt, but have a pretty good idea of what it is. Even if I'd never heard of it before, a couple of mouse clicks and 3 keystrokes (assuming I've got Google or Wikipedia bookmarked) would've yielded an answer in seconds. Given this, and the fact that most people on /. probably already have at least a vague notion of what Qt does, I don't think it is necessary to explain it every time it comes up.

Re:A good example of a bad summary by Johann+Lau · 2012-12-19 07:15 · Score: 1

I know that... I was essentially asking to be trolled some more :D

Awesome by Vektuz · 2012-12-19 07:17 · Score: 1

QT is about the best "native SDK" I've seen out there. In the company I work at, we dev our internal tools in Qt, and at home my hobby projects are in Qt also. They run on mac, linux, and windows. Other projects that run on Qt include Maya (Autodesk), they recently swapped over to using 4.7.1. Knowing autodesk, in only a couple decades they'll switch to Qt5!

Re:Awesome by pwizard2 · 2012-12-19 08:02 · Score: 1

I'm still using 4.7.4 and I intend to do so for a long time. My main reason is to keep pace with the Debian repositories (4.7 support was recently added to testing, stable still has 4.6). For the past year I've been working on an app that won't build on 4.6 b/c of new features added to 4.7, meaning support in Debian Stable was out unless you roll your own Qt. Anything I write for Qt 4.7 will probably compile fine with Qt5 (if necessary) or run under Qt5 libs so I see no reason to upgrade.

--
"It is a denial of justice not to stretch out a helping hand to the fallen; that is the common right of humanity."

How is Qt Quick? by dannydawg5 · 2012-12-19 07:24 · Score: 3, Interesting

I used Qt Quick briefly. It seems like you get a lot of deep powerful customization, but that comes at a cost. It eventually pissed me off so I went back to QWidget, and my productivity soared.

I would not have completed my project in a reasonable time using Qt Quick. It is not "quick". Sometimes, you just want to drop tables, check boxes, buttons, etc. on to your main window, tie the click event to a slot, and call it done. You are fine with whatever default styling and rendering that Qt and the OS decide is appropriate for the widget's click/hover/etc event.

It seems with Qt Quick, you have to specify all that nonsense. Plus, the Qt Quick editor tool felt complex and confusing. I avoided it and did everything by hand. Qt Designer for QWidgets is a drag-n-drop breeze. I even got my manager on board after he saw me using it. He is an EE, and he really likes it. He is used to spending $500 on Visual Studio Pro to what Qt Designer does better for free.

Maybe I just needed to study Qt Quick more to get past the learning curve, but I knew how to do it the widget way, and I wanted the project done.

Has anybody had success migrating their project from QWidgets to Qt Quick? Unless I see a strong compelling reason, I am sticking with QWidgets. It works really well for me.

Re:How is Qt Quick? by shutdown+-p+now · 2012-12-19 10:07 · Score: 1

My understanding is that the big problem with Qt Quick is the lack of all the usual widgets. There really isn't any particular reason why you shouldn't be able to define QML graphs in terms of "I want this button here and this textbox there", and them assuming the default theme etc.
Re:How is Qt Quick? by slack_justyb · 2012-12-19 12:14 · Score: 2

If you are use to using QWidget and that is what you are comfortable with, then there is absolutely zero need for you to try and pick up Qt Quick. Qt Quick is really good at building one offs that you need for small tasks, think million little widgets here, not database editor. Qt5 is still centered very much around C++ and the people who wrote Qt are very aware that Qt Quick "is not for everyone".

You may find yourself pulling up Qt Quick for implementing a "find dialog" or a "insert criteria dialog", but if you are writing the main window in Qt Quick, you either have a very modular/small project or you are using the wrong tool for the job. The best way I tell others is that Qt Quick is for doing up quick UIs, not complicated UIs. Qt Quick would be excellent for Palsmoids, horrific for an entire email application (unless you have really broken the program down to very small bits.)

As an example, I have a program that we use here in the office to connect to PostgreSQL. The connect to dialog is Qt Quick, the window with all the tables and fields is pure QWidgets. The fill-in-the-form order request window is Qt Quick, the order summary window is QWidgets (mostly because it has all kinds of sort and filter buttons). So keep the Qt Quick stuff small and simple and you will find that it's nice to use for all those one offs that do not need a lot of logic behind the window.

That is not to say that Qt Quick *cannot* do a large application, just that it will be easier to continue to do so with QWidget, and that is the whole point, to make things easier. Also, I strongly encourage you (and for that matter anyone seriously looking at Qt) to pick up some C++11. Qt 5 has been written to make logical use of some of the newer stuff in C++11 and those concepts do very much indeed make your code very, very clean. I will admit that I was quite skeptical at first about that point.
Re:How is Qt Quick? by Urkki · 2012-12-19 20:08 · Score: 1

Has anybody had success migrating their project from QWidgets to Qt Quick? Unless I see a strong compelling reason, I am sticking with QWidgets. It works really well for me.
For an existing project, I think the only compelling reason would be, if you want a bling-bling GUI for touch interaction. Think of flick scrolling, multi-finger zoom&pan, animated transitions. And then it would need to be a complete UI redesign.
But, in 1-2 years, I think almost all new displays even on desktop, and certainly on laptops, will be touch screens. I think this is a good time to start thinking about a full UI re-design for any application, where displaying information is important.
Re:How is Qt Quick? by vurian · 2012-12-19 21:15 · Score: 1

Often it's possible to do both. For Krita, which has been around as a QWidget application for more than ten years now, it was possible to make a Qt Quick-based version in about four months with two people: Krita Sketch, which offers almost all the functionality of Krita Desktop, but touch-enable.

Re:Scintilla? by RoccamOccam · 2012-12-19 07:27 · Score: 2

What about PySide? Is it mature enough to use for full-blown apps? Did PyQT change the licensing to make PySide irrelevant?

Re:How? by rocjoe71 · 2012-12-19 07:39 · Score: 2

Hey, several of my favoruite Windows apps are in Qt (e.g. from my WinXP days: "Launchy", and current versions of TweetDeck and Calibre).

Qt-on-Windows runtime installs much like the Visual C++ runtime, and that, for me, is preferable over any app done in Java/Perl/Python, as I don't have to clutter up my system with RTEs (that are all too often supporting a single app)

...and not one annoying "time to update your runtime... AGAIN" ... ever!

--
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)

Re:Scintilla? by pwizard2 · 2012-12-19 07:55 · Score: 1

Yes, QTextEdit handles both HTML and plain text. If you want to export the current text as a full HTML document, you call toHTML(); and if you want plain text you call toPlainText(); Both methods produce a QString that has the text area contents.

Someone has probably already extended QTextEdit to make a drop-in widget that has better syntax highlighting. I know the same thing has been done for spell check.

--
"It is a denial of justice not to stretch out a helping hand to the fallen; that is the common right of humanity."

Re:Lies. by Anonymous Coward · 2012-12-19 08:15 · Score: 1

QT isn't the company...troll.

Re:How? by TemporalBeing · 2012-12-19 08:38 · Score: 5, Informative

How is Qt still relevant?

Let's see...

It's the only multi-platform development kit that is really as feature complete as most platforms.

It runs on more devices than you'd ever imagine - from small embedded devices to your kitchen appliances to mobile devices to desktops and servers.

It's what KDE is built on.

It's what MeeGo/Mer/Tizen/Sailfish are built on.

It's what Blackberry 10 (BB10) is built on.

AutoDesk is built on it.

CiscoVPN is built on it (well, a really old version at least).

There's plenty more out there; but I'm going to stop there.

--
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)

Re:How? by StripedCow · 2012-12-19 08:39 · Score: 1

One framework to rule them all

But for Android and iOS support, we'll have to wait until late 2013.

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.

Re:How? by Deus.1.01 · 2012-12-19 09:06 · Score: 1

Lighthouse?

--
My -1 Troll is actually a +1 funny. And my -1 flame is actually a +1 insightfull.

Re:Finally fit! by shutdown+-p+now · 2012-12-19 10:05 · Score: 1

Declarative style GUI has been the "hot thing" for half a decade now.

And what's wrong about it? HTML5/JS is not bad because it's declarative. It's bad because HTML was never designed to lay out UI, and JS is just a quirky, horribly designed language. But do declarative UI with an expressive data binding framework, and use C++ (rather than JS) for the model, and it's beautiful.

Re:A good example of a bad summary by ChunderDownunder · 2012-12-19 12:14 · Score: 1

Speak for yourself. Some of us have multiple monitor setups, e.g. 1 in landscape, 1 in portrait. The ability to dynamically attach/detach tabs as separate windows is very handy. IDEs and web browsers make use of this feature.

Re:A good example of a bad summary by smaddox · 2012-12-19 16:41 · Score: 1

I haven't tried to code something like this, but you should check out how Veusz does it, because it works perfectly.

Re:How? by Isaac+Remuant · 2012-12-20 02:03 · Score: 1

For support, kinda. But you can already deploy for android with necessitas.

--
"Science can amuse and fascinate us all, but it is engineering that changes the world. " - Asimov.

Re:Finally fit! by Isaac+Remuant · 2012-12-20 02:15 · Score: 1

It was unfit for the future, yes.

--
"Science can amuse and fascinate us all, but it is engineering that changes the world. " - Asimov.

Re:A good example of a bad summary by Grishnakh · 2012-12-20 11:01 · Score: 1

As someone who's been on Slashdot since the 90s, I think you're tilting at windmills. When was the last time you saw a really good summary on Slashdot? Shitty summaries are the norm here, and they're frequently downright misleading and contradicted by the articles linked. There is NO editorial control here, just sensationalism.

114 of 161 comments (clear)