Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Nokia Announces Qt 5 Plans

Soulskill posted more than 3 years ago | from the eggs-in-a-backup-basket dept.

Open Source 129

aloniv writes "Since Nokia announced its switch to Windows Phone 7, people have been worried about the future of Qt. Well, it turns out Nokia is still going full steam ahead with Qt, having just announced their plans for Qt 5. Some major changes are afoot code- and functionality-wise, but the biggest change is that Qt 5 will be developed out in the open from day one (unlike Qt 4). There will be no distinction between a Nokia developer or third-party developer."

cancel ×

129 comments

Sorry! There are no comments related to the filter you selected.

Dupe? (0)

MrHanky (141717) | more than 3 years ago | (#36116866)

I could swear I read this on Monday.

wtf (0)

Anonymous Coward | more than 3 years ago | (#36116874)

You guys don't think this would have been a good idea to mention sooner!?

Re:wtf (3, Insightful)

eplawless (1003102) | more than 3 years ago | (#36116898)

At this point, Nokia is just tossing stuff out there as they think of it. "Oh man, we pissed off a massive chunk of our developer base. How do we make them less furious at us? ...besides scrapping the Windows Phone thing, I mean."

Re:wtf (1)

somersault (912633) | more than 3 years ago | (#36117106)

No kidding. I tried out Qt for the first time just before the MS deal was mentioned, and subsequently haven't bothered with it. If they're switching to a more open development model that will help to ensure it continues even if Nokia are savaged by MS, and if it's ported to more platforms, then that's enough reason to continue using it.

translation.... (5, Insightful)

metalmaster (1005171) | more than 3 years ago | (#36116904)

"There will be no distinction between a Nokia developer or third-party developer." becomes "Develop it yourselves you lazy bastards, but dont forget to put our name on it too"

Re:translation.... (5, Funny)

Anonymous Coward | more than 3 years ago | (#36116936)

"There will be no distinction between a Nokia developer or third-party developer."

Which will be a disapointment for any Nokia developers hoping to get paid.

Re:translation.... (1)

Chemisor (97276) | more than 3 years ago | (#36117182)

Isn't that basically the philosophy of open source?

Re:translation.... (2)

diegocg (1680514) | more than 3 years ago | (#36117474)

Plans to make QT a real community project already existed before Stephen Elop was made CEO of Nokia. And I would be very happy to see 3rd parties developing big chunks of QT - that would mean it can survive without Nokia.

Re:translation.... (2)

Kynde (324134) | more than 3 years ago | (#36117824)

Plans to make QT a real community project already existed before Stephen Elop was made CEO of Nokia. And I would be very happy to see 3rd parties developing big chunks of QT - that would mean it can survive without Nokia.

QT would have no problems without Nokia. It's the "with" part that people are worried about. And never so much as now that there's another bigger "with" involved.

Re:translation.... (3, Insightful)

suy (1908306) | more than 3 years ago | (#36117676)

"There will be no distinction between a Nokia developer or third-party developer." becomes "Develop it yourselves you lazy bastards, but dont forget to put our name on it too"

Very wrong. Look at the list of maturity and status of Qt modules [nokia.com] . Nokia still is ready to maintain a huge percentage of Qt. They simply deprecated stuff because they think that other alternatives are better (eg. ditch Phonon because there is QtMultimedia). The only piece that Nokia is not interested in maintaining and that the comunity is worried about, is QtSVG, because the alternative, the SVG support in Webkit, is considered too big/slow, or unsuitable for being LGPL only.

This is Qt development frameworks (aka "old Trolltech") being honest in what they are interested about.

Oh, and being even more open in how they develop (they already have public BTS and reports).

Re:translation.... (0)

Anonymous Coward | more than 3 years ago | (#36117976)

No, the correct translation goes:

"Umm... we have a bunch of products. We have NO FUCKING IDEA how all these products relate or compete. Nor do we have any clue who are our friends, or our enemies. We're going to screw our enemies and fuck our friends. Or should that be fuck our enemies? We're going to fuck your phones and... wait..."

Ugh.... (0)

Anonymous Coward | more than 3 years ago | (#36116918)

While the QWidget based classes are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML.

Ugh. No thanks. I don't want to have to write my UIs in some bastardized version of Javascript and all the associated speed issues. Guess I'll be staying with Qt4 instead.

Re:Ugh.... (1)

Elledan (582730) | more than 3 years ago | (#36116988)

I agree. I have looked at QML (I'm a part-time C++/Qt developer), and it looks to me like JS and CSS had a very unsightly baby. QML is also not nearly as efficient or compact as the C++-based widgets. The latter could use a bit of an overhaul to remove some redundancy, but that's another matter again.

Seems like Qt5 will be more buzzword-compliant, though :(

Anyone up for developing a Qt competitor? :D

Re:Ugh.... (1)

gbjbaanb (229885) | more than 3 years ago | (#36117112)

yes, but then you can intermix QML and traditional Qt forms together which is a seriously good thing as you keep the productivity gains for the 80% of common or boring old functionalty and get to work the last 20% in less-rpoductive but mroe functional QML.

Unlike XAML where you have a choice of all or nothing.

Re:Ugh.... (0)

Anonymous Coward | more than 3 years ago | (#36117152)

I'd rather having nothing. I'm using Qt to write C++ code not to be a Javascript monkey. Looks like the Qt are trying to make themselves irrelevant with statements like:

We should expect that over time all UIs will be written in QML. JavaScript will become a first class citizen within the Qt community and we should expect that a lot of application logic and even entire applications will be written in JavaScript instead of C++. The expectation is that many application developers will actually start out with QML and JavaScript and only implement functionality in C++ when required. For those specific use cases, the full power of the C++ APIs offered by Qt can be used to implement time critical and complex application functionality.

Even crap like GTK+ would be preferable over this write it all in Javascript world that Qt people seem to think will happen.

Re:Ugh.... (5, Interesting)

Entrope (68843) | more than 3 years ago | (#36117376)

I came from a Gtk+ background, but am using Qt Quick (QML) in one project. The widget set as of Qt 4.7.2 is woefully anemic, but other than that, it seems like a general improvement over using C++ for the entire UI. At least 90% of user interfaces (averaged over the world's applications; there are a few very graphics-intense apps that bring down the average) do not need the marginal speed improvement you can get by using C++ instead of QML. Qt does a pretty decent job at making it easy to go between native C++ widgets and QML code, so C++ developers get to focus on the parts of the GUI that need performance.

What is in using QML for me? I get to offload most of the GUI development to a UX designer who is better at that sort of thing (and costs my employer less per hour of work). Then I get to focus on the novel and application-specific parts of the interface. I also get cleaner separation between those application-specific bits and the overall skin.

Re:Ugh.... (1)

tibit (1762298) | more than 3 years ago | (#36118560)

Couldn't agree more. I will be getting our designer lady a QML/QMLDesigner tutorial in a week or so. That way I'll be getting ready-made user interfaces, with relevant functionality already built in, and I can focus on providing data models and state management for the application as a whole.

Re:Ugh.... (1)

Kjella (173770) | more than 3 years ago | (#36118602)

I came from a Gtk+ background, but am using Qt Quick (QML) in one project. The widget set as of Qt 4.7.2 is woefully anemic, but other than that, it seems like a general improvement over using C++ for the entire UI.

My impression is that Qt Quick is another one of those things that's going to come full circle. First you go from a huge set of widgets (QWidget & decendants) to html/css (Qt Quick) and eventually you'll want to build the exact same widgets on top of that again for convienience. Oh well..

Re:Ugh.... (2)

DrXym (126579) | more than 3 years ago | (#36117860)

I'd rather having nothing. I'm using Qt to write C++ code not to be a Javascript monkey. Looks like the Qt are trying to make themselves irrelevant with statements like:

Actually QML is there to try to make it easier to develop apps by allowing people to declaratively define their UI and use minimal inline or external language for the binding. It's a perfectly sound practice, variants of which one can be found in various other GUIs, both in thick clients and web development. e.g. Flex,. XUL, XAML, JavaFX etc. For starters it means doing away with a vast amount of boilerplate, faster application prototyping, faster development build cycles, greater portability, less bugs caused by programmer error which ultimately leads to faster time to market and a higher quality product.

I realise if you're too set in your ways to adapt that it might be easier to denigrate such efforts than appreciate their uses, but that's your problem not the platform's.

Re:Ugh.... (1)

Anonymous Coward | more than 3 years ago | (#36118312)

greater portability

Wrong, QML will actually be less portable especially when Qt5 will require at least OpenGL ES 2.0. Kiss goodbye any support for embedded systems without OpenGL support and yes there are many.

less bugs caused by programmer error

In what way?

I realise if you're too set in your ways to adapt that it might be easier to denigrate such efforts than appreciate their uses, but that's your problem not the platform's.

I realise that to you a bunch of buzzwords and bling bling might be important but for those of us writing real desktop and embedded apps where performance is critical, this change is mostly useless. Hell even the Qt Creator guys are admitting they will barely be using QML and mostly sticking to QWidgets. If they won't even eat their own dog food, I'm not buying into it. This isn't even taking into account the dearth of widgets equivalents for QML.

Re:Ugh.... (1)

DrXym (126579) | more than 3 years ago | (#36119758)

QML is in QT 4.7. What QT 5 requires by way of graphics support is irrelevant. As for less programmer error - declarative code and minimal code within a proper garbage collected environment means less errors like point errors, memory leaks, casting errors etc.

It's not about buzzwords. Declarative UIs with bindings are a pattern proven to work elsewhere and it will be proven to work in QT. It doesn't mean it is right for every application but it will do for a lot of apps either in full or partially.

Re:Ugh.... (1)

tibit (1762298) | more than 3 years ago | (#36118518)

That's a silly argument. I don't think you're laying out all the widgets by hand all the time, right? You're probably using Designer to produce .UI files for most of your UI. Guess what: QML designer is pretty much the same thing, but gives you much more expressive power. The QWidget/QLayout systems has inherent constraints that cannot be worked around by simply expanding the API. They needed a brand-new paradigm, and they delivered.

All of the back-end functionality (models!) has to be done in C++ anyway, and you're free do develop custom visual elements in C++. In fact, you likely will end up developing custom visual stuff in C++ where you had complex QWidgets, but not for "silly" stuff.

So far in Qt you had to pretty much subclass controls or widgets and write C++ code for simple UI elements like toggle switches, gages, indicators, etc. With QML, you can get simple controls without writing any code at all and using QML Designer (a plugin in Qt Creator).

For complex views, like say a PCB layout, electrical schematic or a document editor, you'll still code it in good old C++.

At least QML somewhat forces you to do clean model-view separation -- of course seasoned developers who know their stuff will do it naturally, but there's plenty of code out there where data is intertwined with visuals. I applaud that QML promotes clean separation of concerns here.

Re:Ugh.... (1)

glebovitz (202712) | more than 3 years ago | (#36117380)

I don't mean to rain on your parade, but we are developing a lot of QML/JS code and the development time is a fraction of doing the same thing in C++. In addition, we are finding that it is easier to train web graphic designers to use QML then to teach programmers graphic design. There are a lot more JS programmers out there than there programmers who know and use C++.

We are also doing Windows Mobile Phone 7 development and XAML is a really good model. You still have to write code behind in C#. The model works well in separating the design from the code, but you still have to hack XML and C#. I am using both, and QML/JS is a much easier to learn and use.

I read your statements, and they are very similar to what the COBOL programmers were saying to me in the 1980s "Oh this C and SQL stuff is fine for universities and researchers, but it will never catch on in the business world. I heard the same thing from the AS 400 developers in the early 1990s "real business wil run on mainframes, not this Sun server stuff."

Oh and about the comment for a Qt 5 competitor. O am not suret the open source community needs, another C++ framework to dilute resources and add confusion to the community. Maybe a better idea would be to give this a chance and see if it pans out.

Re:Ugh.... (1)

Elledan (582730) | more than 3 years ago | (#36117444)

Maybe QML really is easier... I have been doing some Android development lately, and defining the UI in a separate XML file definitely has its advantages.

As pointed out and as I have discovered during my own research into QML its feature set in 4.7 is pretty aenemic. If they can make it a carbon copy of the feature set of the Qt widgets, then it might be worth looking into :)

Re:Ugh.... (1)

tibit (1762298) | more than 3 years ago | (#36118820)

First of all, reimplementing most if not all Qt widgets in QML takes less code than original Qt widget implementations took, line-wise. And it's by a fairly large factor -- a reduction of 5-10 times. Just look at the Qt Quick Components for Desktop [nokia.com] -- it's pretty amazing stuff when you realize that a table view is about 500 lines long. For your reference, src/gui/itemviews/qtableview.cpp is 3000 lines long, and it's not nearly as modular and tweakable as TableView QML element.

The beauty and power of QML is shown in the fact that the TableView component's [gitorious.org] source code is not only fairly easy to understand, but it's very easy to tweak. I had to add per-column delegates for my project and it was a dozen lines or so, took about an hour without any prior QML experience. Good luck with modifying qtableview.cpp [gitorious.org] . Now I of course realize that there's no full feature parity between the two just yet, but they are alarmingly close. And if you consider source tweakability to be a feature in itself, I think that QML already wins over native Qt views. Even little details make life easier: suppose you want to tweak QTableView and cannot simply derive from it, but you have to modify the source. If you want to copy it over to your own project, you have to at least do a search-and-replace to change the damned class name everywhere. In QML, you change the damn file name and you're done. Add enough of those "little" improvements, and you get something that beats expressibility of C++ by a lot.

Qt could have been much further ahead if they implemented the QML idea back in times of Qt 1.x... And no, I don't buy the argument that the platforms back then were too slow. They'd have had to spend more effort in optimizing things, but there's nothing inherent in QML that makes it slow. All the heavy lifting is done by C++ code or JIT-ed JavaScript anyway.

Re:Ugh.... (0)

Anonymous Coward | more than 3 years ago | (#36119236)

First of all, reimplementing most if not all Qt widgets in QML takes less code than original Qt widget implementations took, line-wise.

Yes, and it will takes numerous man years to reimplement all your QWidgets in QML for what in most cases is negligible to negative impact. Yeah, who cares about bringing updates to your software, bug fixes, etc when you can reimplement the wheel instead for no gain!

They'd have had to spend more effort in optimizing things, but there's nothing inherent in QML that makes it slow.

Yeah, using an interpreted language for your UI glue code couldn't possibly have speed issues! Secondly, if QML is so great why are the only examples little toy programs? And why do the Qt Creator people even admit that they are only going to use QML sparingly? If QML is so great, shouldn't they just be dumping all their QWidgets for it?

All the heavy lifting is done by C++ code or JIT-ed JavaScript anyway.

And JIT-ed Javascript is still slower than C++.

Re:Ugh.... (0)

Anonymous Coward | more than 3 years ago | (#36117556)

I don't mean to rain on your parade, but we are developing a lot of QML/JS code and the development time is a fraction of doing the same thing in C++.

And it'll run dog slow especially with data-intensive UIs. Yes, I have tested this. Your little toy apps may be fine in QML but real apps are going to need something better.

Re:Ugh.... (1)

tibit (1762298) | more than 3 years ago | (#36118388)

I think you didn't look at the code. First of all, QML is NOT Javascript. It is a declarative language that integrates seamlessly with Javascript. As for efficiency: I'd beg to differ. There's nothing inherent in the declarative framework that would make it less efficient than QWidget. QML has expressive power that makes legacy frameworks look almost silly. QML comes with a lot of demos. Try implementing some of them using out-of-the-box pre-QML APIs and you'll understand.

The QLayout system is a complete nightmare -- to get anything that's less-than-trivial, you have to relegate to spreasheet layouting: make lots of extra rows and columns, and then span your widgets across several of them. And good luck if your widget needs to have visible elements outside of its boundary -- and no, it's not only about particle effects, how about highlighting, drag-and-drop/drag-and-clone, etc.

I fully believe that legacy UI framework design decisions (ala GTK, Qt, WxWidgets) have seriously and negatively affected usability of common business applications (ERP systems, I'm talking about you). If you want to design clean, usable UIs using a legacy framework, you are pretty much back to using some sort of a hierarchical canvas (like QGraphicsScene) and laying out everything yourself. QML takes a lot of busywork out of that.

Re:Ugh.... (1)

Desler (1608317) | more than 3 years ago | (#36118652)

I think you didn't look at the code. First of all, QML is NOT Javascript. It is a declarative language that integrates seamlessly with Javascript.

More accurately, QML is Javascript with extensions.

As for efficiency: I'd beg to differ. There's nothing inherent in the declarative framework that would make it less efficient than QWidget.

And yet with a simple search of "QML slow" you can find all sorts of examples of QML running slow. All sorts of people are seeing lagginess, etc in QML apps. The best the Qt people have shown have been little toy examples where there may be no noticeable difference. Get back to me when they have a full blown app that has lots of intensive visualization and show me that it has no efficieny issues.

QML has expressive power that makes legacy frameworks look almost silly.

Examples? It really means little to hear people throw out buzzwords and provide no examples of how it is more this or that.

KDE5 (0)

Anonymous Coward | more than 3 years ago | (#36116962)

Oh, no, now that KDE 4 was almost usable, we'll start over again with KDE 5.

This will kill KDE (1)

VincenzoRomano (881055) | more than 3 years ago | (#36116990)

As kde developers will start thinking about and switching to kde5. I see another wave of bugs and instability, the same that made me switch from kdev4.1 to xfce. These architects get excited by new technologies and loose the focus on stability and usability. Let's see what will happen.

Re:This will kill KDE (3, Interesting)

karper (2017856) | more than 3 years ago | (#36117050)

It's going to be a behind-the-scenes change and it's not as big a deal as the kde3kde4 change. Reference: http://aseigo.blogspot.com/2011/05/relax.html [blogspot.com]

Re:This will kill KDE (1)

Morose (32606) | more than 3 years ago | (#36117054)

I doubt it will kill KDE. Instead it will just return QT to more community development instead of commercial development (which, I seem to recall is one of the reasons people went with Gnome instead of KDE way back when, pre-GPL on QT). QT is completely forkable so there is no reason that if Nokia stops officially supporting it that someone else could come along ala X.org/X86.

Re: switch to xfce (1)

TaoPhoenix (980487) | more than 3 years ago | (#36117070)

Hi.

  I am a potential new linux user and my initial specialty/focus will be on the UI side. I have been considering looking into xfce as well. Do you think it's the new dark horse UI behind Gnome and KDE?

Re: switch to xfce (1)

Tolkien (664315) | more than 3 years ago | (#36117156)

I've used xfce and it's pretty nice. The last time I did It was extremely bare bones, you added only what you wanted. I think that was their design philosophy or something so it's a safe bet, I think.

Re: switch to xfce (1)

horza (87255) | more than 3 years ago | (#36117300)

I enjoy xfce4 but am happy with KDE4. It's not a dark horse, just another alternative. On a standard PC I would recommend Kubuntu, but on a netbook it's a trade-off time vs speed. If you want something that just works then install Kubuntu, though it's a bit heavy and slow, but if you have time to tweak (make sure you install ROX) and want the extra horse-power out of it then install Xubuntu. It is not that one is better than the other, it's just a trade-off. They are both great.

Phillip.

Re: switch to xfce (1)

Tolkien (664315) | more than 3 years ago | (#36117544)

Oh, I didn't mean to imply that Xfce is a dark horse, just that it itself is a safe bet. :)

Re:This will kill KDE (0)

Anonymous Coward | more than 3 years ago | (#36117212)

Oh. I thought KDE4 was supposed to kill KDE.

Re:This will kill KDE (2)

DMiax (915735) | more than 3 years ago | (#36117484)

Relax :) [blogspot.com] (blog post from one of the head developers of KDE)

Re:This will kill KDE (0)

Anonymous Coward | more than 3 years ago | (#36117786)

KDE is still alive?

And I don't say this only due to the death of Qt. Software goes in simple-bloat-simplify pattern.

KDE has been stuck in the bloat phase (along with out of control dependencies) for a long time.
GNOME is there now.

LXDM vs XFCE is the new KDE vs GNOME

There will be no distinction between a Nokia... (1)

Threni (635302) | more than 3 years ago | (#36117042)

> There will be no distinction between a Nokia developer or third-party developer.

Or indeed not being a developer at all.

zeus weapon misfiring badly, minions flee (0)

Anonymous Coward | more than 3 years ago | (#36117052)

the whore of babylon has been rescued by the native elders. she has the papers, & is cooperating wholeheartedly with the disarmament mandate.

Re:zeus weapon misfiring badly, minions flee (0)

Anonymous Coward | more than 3 years ago | (#36117816)

I wish I was high so I could understand this.

Kind of biblical joke (0)

Anonymous Coward | more than 3 years ago | (#36117994)

I think it's a joke. Whore of Babylon = Nokia (went with Microsoft). Native elders = people in Nokia who realised that Elop may have screwed the pooch. They have persuaded Nokia (who controls QT, aka the papers) to release them and co-operate with the Open Source community.

Yes, it's obscure. No, I don't know why the writer did it. Perhaps he's testing some "translate into New testament biblical imagery" software. Or, indeed, he's on something.

Is the lock in that strong? (2)

NtwoO (517588) | more than 3 years ago | (#36117104)

The deal between Microsoft an Nokia has been a big topic with many opinions. The opinion that Microsoft actually needed a strong hardware platform for their OS more than Nokia needed Win Mobile for their phones is a strong contender for me. Maybe having a say in keeping Qt open is a clear signal that this is also truly the case. It could very well be that Nokia was keen for the partnering but is not ready to sell their soul and cut off all options for the future. ~

Re:Is the lock in that strong? (2)

operator_error (1363139) | more than 3 years ago | (#36117630)

The annual (linux) Meego conference is in a few days' time, in San Francisco. Google News (search) reveals that the Nokia N950, the successor to the N900 will be _probably_ be announced at this conference.

Nokia has never backed-off its support for Meego. Well, okay they have hyped and now focused development resources towards their M$ partnership, but to the extent possible given their current business strategies, they still support their prior open-source OS strategy. In other words, they haven't really backed-away from Meego, while they will support WP7 going-forward. (But in lieu of the recent M$ partnership, they need to hype M$, especially following that particular announcement).

http://sf2011.meego.com/ [meego.com]

Vote with your feet folks. Meego is still a very good mobile OS worth buying and developing for; especially if you are developing for your own purposes. Today's news reinforces this.

Re:Is the lock in that strong? (1)

gbjbaanb (229885) | more than 3 years ago | (#36118708)

I guess people are voting with their feet - by not buying WP7 :)

We'll see what happens, I think WP7 will continue to bomb even after the $1bn bung from MS runs out, and then Nokia will at least have the opportunity to ressurect itself with its old ace card, maybe beefing it up for non-phone systems. The danger is that, good though Meego is and could be, Android will steal all its market before it has a chance to shine. That's a problem they'll have to deal with while they attempt to flog WP7 devices.

Re:Is the lock in that strong? (2)

CRCulver (715279) | more than 3 years ago | (#36118872)

Elop has announced that Nokia is trying to hand Meego over to another company like LG and does not believe Meego has a place in its longterm strategy. Also, there's a big controversy that this new "N950" model will feature just Maemo with a few updates applied, and it does not meet the Meego standards. There's plenty of coverage of the controversy over at Maemo Weekly News.

Javascript? (0)

Anonymous Coward | more than 3 years ago | (#36117194)

Said that the code needs to use the GPU. Good.

Then kill that performance with JS?

Re:Javascript? (1)

Entrope (68843) | more than 3 years ago | (#36117432)

The vast majority of user interfaces spend more time waiting for user input than they spend drawing to the screen. Of course, users notice redraw time more when they are the ones waiting. But I've used Qt on a small device (a several-year-old cell phone application processor), and the things that made that UI slow are the animations that were chosen for the UI -- animations that are drawn by the CPU and GPU using compiled code, but with durations that were a little bit too long for impatient users like me.

There is a (mostly overlapping) vast majority of user interfaces that are less responsive than possible because they block the UI during long-latency operations, but that has little to do with the language used to implement the UI, and more to do with how easy it is to kick off background tasks from the UI and push those results back to the UI. (QML has a benefit here because it makes that easier.)

Plus, JavaScript JITters are getting better every few months.

Re:Javascript? (1)

21mhz (443080) | more than 3 years ago | (#36117540)

Then kill that performance with JS?

You surely save a lot of CPU cycles on laying out 100k times per minute all those views and dialogs painstakingly hand-coded in C++. Or wait... may I suggest to optimize what really needs to be optimized, and enjoy the productivity boost in creating the rest, not to mention separation of tasks between UI design and application logic programming?

Re:Javascript? (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#36117802)

may I suggest to optimize what really needs to be optimized, and enjoy the productivity boost in creating the rest, not to mention separation of tasks between UI design and application logic programming?

Of which you can already do now without the need of QML and its overhead. Plus the Qt people keep trying to skirt around the performance issues when people kept repeatedly asking about it and considering how many posts you get about poor performance with QML apps through simple Google searches I can see why. Factor in how many custom widgets people use in desktops apps now and I can't possibly see most people wasting the time and effort to rewrite in QML.

Re:Javascript? (1)

tibit (1762298) | more than 3 years ago | (#36119014)

Porting a QWidget to QDeclarativeItem is so easy that it could be considered a janitorial task in many projects. Plenty of simple custom QWidgets can be reimplemented in QML with a significant drop in code size, so there's actually a good reason to do that. Especially if you have a designer on staff who got Qt Quick training and can provide you with an "endless stream" of custom, appealing widgetry.

There's nothing architecturally wrong with QML. The current implementation surely has performance corner-cases, just like early Qt 4.x series had, especially before 4.4. The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui. Heck, I've found quite a few cases where QLayout-based UIs were stuttering when you resized the windows or dragged splitters -- the QLayout/QWidget infrastructure is seriously broken if you use native widgets, like you had to on OS X for example until very recently.

Re:Javascript? (1)

Desler (1608317) | more than 3 years ago | (#36119280)

Porting a QWidget to QDeclarativeItem is so easy that it could be considered a janitorial task in many projects.

Well then why haven't you ported all the QWidgets over for us by now? It's so quick and easy, right?

Plenty of simple custom QWidgets can be reimplemented in QML with a significant drop in code size, so there's actually a good reason to do that.

That's great if all you ever used were "simple" QWidgets. Many people rely on much more than "simple" widgets for real apps.

The current implementation surely has performance corner-cases, just like early Qt 4.x series had, especially before 4.4.

Thus making it unusable for people who need high performing apps. Most people aren't going to rewrite things in QML just because they are promised that years down the line it will stop being laggier and slower than their current QWidget-based programs.

The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui.

Sure, if we ignore the overhead over interpreted code.

Heck, I've found quite a few cases where QLayout-based UIs were stuttering when you resized the windows or dragged splitters

And you've reported these issues?

the QLayout/QWidget infrastructure is seriously broken if you use native widgets, like you had to on OS X for example until very recently.

In what way?

Re:Javascript? (1)

tibit (1762298) | more than 3 years ago | (#36119524)

The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui.

Sure, if we ignore the overhead over interpreted code.

There's no "interpreted code" anywhere in QML. Whatever parsing there is, is done only once. Javascript is executed by a decently performing JIT-ting runtime -- same one that powers WebKit. Instantiating a QML element does not AFAIK cause any textual source code to be parsed or JIT-ted more than once. Surely there will be some overhead due to parsing QML at application startup, but this can be tweaked by doing lazy instantiation via the Loader.

Windows Phone 7 and Qt... (1)

musicmaker (30469) | more than 3 years ago | (#36117196)

Why exactly are these two things related? Qt is a completely different development line from WP 7, it's a windowing toolkit not a mobile OS. Show me some good news about MeeGo, and I might, just maybe, get a bit excited.

Sure, you could go on about how Qt is at the foundation of MeeGo, but it's at the foundation of lots of other things too, like KDE amongst others. Good news for Qt does not imply good news for MeeGo. In fact, possibly quite the opposite, as I can imagine a scenario where Nokia had left over contracts with outside vendors, and maybe a few Linux oriented staff that didn't get rid off, so they're just redirecting them at Qt and taking them off MeeGo.

Re:Windows Phone 7 and Qt... (1)

CRCulver (715279) | more than 3 years ago | (#36117238)

In a recent interview with Elop (no longer have the link, sorry, maybe someone else does) he said that Nokia is looking to pass Meego to some other company, for example, LG. Nokia's commitment to Meego is finished.

Re:Windows Phone 7 and Qt... (1)

horza (87255) | more than 3 years ago | (#36117324)

Give it to Samsung! They are already streets ahead of Nokia when it comes to hardware, give them Meego and I can see them becoming the number one handset manufacturer.

Phillip.

Re:Windows Phone 7 and Qt... (1)

Microlith (54737) | more than 3 years ago | (#36117798)

Samsung doesn't want to work with MeeGo, at best they'll meet up at the Linaro level. LG has already hopped on the handset working group.

How do you pronounce Qt anyway? (0)

Anonymous Coward | more than 3 years ago | (#36117214)

Is Qt pronounced "Que Tee" or "Cute"? (I think the official pronounciation is "Cute", but how do most people say it?)

Re:How do you pronounce Qt anyway? (1)

Tolkien (664315) | more than 3 years ago | (#36117308)

I personally say Queue Tee. I would say Cute if it were spelt Qute.

Best GUI library for C++ (1)

Script Cat (832717) | more than 3 years ago | (#36117224)

If you're writing software in C++ that's portable, which GUI library would you use at the present time?

Re:Best GUI library for C++ (1)

EdgeyEdgey (1172665) | more than 3 years ago | (#36117280)

For small use FLTK [fltk.org]
Or more options here [dwheeler.com]

Re:Best GUI library for C++ (0, Offtopic)

halfdan the black (638018) | more than 3 years ago | (#36117290)

I take it you've never had the pain of using a QT app on OSX, QT is an absolute disaster on OSX, AND looks pretty dated on Win7. If you want your app to be taken seriously, the UI NEEDS TO BE NATIVE, and thats NOT QT. By native, IU should be WPF on Windows,Win Phone / Cocoa on OSX,iOS and GTK on Gnome and QT on KDE, Java on Android. UIs need to be native, don't short change your users by giving them something that looks completely alien on every platform other than KDE.

Re:Best GUI library for C++ (2)

rwa2 (4391) | more than 3 years ago | (#36117362)

Good call... so in other words, something use something like http://www.wxwidgets.org/ [wxwidgets.org] for cross-platform development while still hooking into native widgets?

Re:Best GUI library for C++ (1)

jopsen (885607) | more than 3 years ago | (#36117488)

Qt on Gnome is great... And qt on Windows Xp was also great... Haven't tried Vista or 7 though...

Re:Best GUI library for C++ (2)

Timmmm (636430) | more than 3 years ago | (#36117634)

I've used Qt on OSX. It works fine. And Qt looks native on all platforms so I have no idea what you're talking about...

Re:Best GUI library for C++ (1)

halfdan the black (638018) | more than 3 years ago | (#36117842)

QT fakes out the look of the native OS with a "theme". On any platform, you can use any theme, for example, on OSX, I can use a KDE theme. Problems are this "theme" might look superficially similar to the underlying toolkit, but nothing really works right. On OSX, text is never lined up, drop boxes are always off, toolbars just look weird and alien, QT basically looks kind of Frankenstieny on OSX and Windows. Its what is called the "uncanny valley" effect, where something looks close, but ends up looking just bizarre because countless small inconsistencies. There is no practical way to deal with all these inconsistencies when you fake out the native OS with a theme. The only way to do it right is to use the native controls, which QT DOES NOT.

Basically what I'm saying is that there is no such thing as a decent "cross platform" UI library, the UI is so closely tied to the user experience on a particular platform that you can't abstract it or fake it away as to treat each OS exactly the same.

For example, take a look at Maya, it is probably the only big commercial app written with QT. They use their own theme on every platform, Maya does not even resemble a standard Windows or OSX app -- they don't want to have the user experience I've described above. There are some other commercial apps that use QT, but ONLY on Linux. Skype uses QT on Linux,Cocoa on OSX, and WPF on Windows.

Re:Best GUI library for C++ (3, Informative)

Timmmm (636430) | more than 3 years ago | (#36117910)

> The only way to do it right is to use the native controls, which QT DOES NOT.

I think you have not used Qt for a long time...

http://en.wikipedia.org/wiki/Qt_(framework)#Use_of_native_UI-rendering_APIs [wikipedia.org]

Re:Best GUI library for C++ (1)

jockm (233372) | more than 3 years ago | (#36118496)

Actually no. Take a look at what they say [nokia.com] :

Qt uses the native graphics APIs of each platform it supports, taking full advantage of system resources and ensuring that applications have native look and feel

They are saying they are using the native drawing layer, not the native controls. There is a huge difference. The last QT App I used still didn't support OSX services. Which it would if it were using native controls.

Re:Best GUI library for C++ (1)

Desler (1608317) | more than 3 years ago | (#36118674)

Qt doesn't use native widgets. They never have. What they have recently changed is using the native drawing APIs. That is not the same thing.

Re:Best GUI library for C++ (1)

tibit (1762298) | more than 3 years ago | (#36119116)

It doesn't "fake" the look. It uses the visuals drawn by native APIs on both Windows XP and up, and on OS X. You can't enable an OS X look in KDE simply because Qt doesn't have the code that implements the look, it politely asks the Cocoa or Carbon API to do the drawing for it.

Use of native controls is something I shun because as soon as you get a lot of them, you run into serious performance issues. Try having a thousand native-widget OS X buttons in your window, and see how fast they respond [nokia.com] . By dropping the native widgets and using a so called alien, styled widget, Qt actually provides better performance than underlying OS X APIs, who'd have thought.

Re:Best GUI library for C++ (0)

Anonymous Coward | more than 3 years ago | (#36118160)

Sorry, but you're very wrong about this, Qt runs native on any operating system, that's the whole point of Qt, it's not a port like Swing (on java), it runs with the Operating system APIs, and It looks native, I have an application running on Linux, Windows 7, XP and OSX (yes Mac) and looks native, even in Mac the integrated menu works as expected, and it merge the Quit options as well,

I think you missed the whole point of the cross platform frameworks, I think you should reevaluate your statement of being taken seriously, a LOT of "serious" applications that are portable used somekind of framework like Qt.

Re:Best GUI library for C++ (1)

Desler (1608317) | more than 3 years ago | (#36118822)

If by "runs native" you mean it has in the last couple of years moved to use the native drawing APIs of the platform, yes, but it doesn't use the native widgets if that is what you are trying to imply. And for the longest time Qt just faked the native look with themes before using the native drawing APIs.

PROTIP (0)

Anonymous Coward | more than 3 years ago | (#36118770)

qtconfig lets you change the "look" of Qt applications, at least on *nix. There are settings to mimic the current GTK theme and engine, and the Windows XP look. Not sure about others, though.

Re:Best GUI library for C++ (0)

Anonymous Coward | more than 3 years ago | (#36117386)

Whatever you find easier to program with and whatever makes you more productive. Qt, Fox Toolkit, Wxwidgets, FLTK and many more.

QT5 should drop MOC and adhere to standards (0)

whiteboy86 (1930018) | more than 3 years ago | (#36117260)

Then we reconsider using it.

Re:QT5 should drop MOC and adhere to standards (2)

DMiax (915735) | more than 3 years ago | (#36117464)

Qt already adheres to standards. MOC is just a boilerplate generator and the actual code is compiled with any standards-compliant C++ implementation.

Re:QT5 should drop MOC and adhere to standards (2)

halfdan the black (638018) | more than 3 years ago | (#36117534)

Don't think it really can drop MOC or something like as still be a viable UI library.

Dynamic dispatch is pretty fundamental in event driven UIs, and not sure if C++ can really provide such a concept. Thats why we need more dynamic languages like JScript/Python/Objective-C/C# for this type of programming.

I'm sure there are things C++ is good for, but its not something as dynamic as UIs.

Re:QT5 should drop MOC and adhere to standards (2)

21mhz (443080) | more than 3 years ago | (#36117670)

We as in who? The "template metaprogramming" weenies who could not understand for a decade why C++ is a train wreck?
Don't bother; "we" the practical developers creating real-world maintainable software don't need you on our projects.

Re:QT5 should drop MOC and adhere to standards (0)

Anonymous Coward | more than 3 years ago | (#36117992)

"Practical developers", who? The "practical developers" who can't use C++ because "it's too hard"; or those, who constantly try to be smarter than they are, and fail with tools that don't babysit incompetent developers? Oh, no, pointers!

Re:QT5 should drop MOC and adhere to standards (0)

Anonymous Coward | more than 3 years ago | (#36118850)

Amen to this. C++ is a damn nightmare which Qt thankfully completely hides away so you don't have to deal with it.

Re:QT5 should drop MOC and adhere to standards (0)

Anonymous Coward | more than 3 years ago | (#36118908)

Well, MOC does generate standard C++ so I don't see why it's such an issue. It would be great if everything would be part of a modern, open and standard languaje, but I can settle for some add-ons in the real world. Just the signals-and-slots mechanism is enough for me to accept MOC, IMHO it's way more readable and simple than listeners, inner classes, function pointers and other alternatives.

Also, the core data structures beat the STL and JAVA in both functionality and, most of all, documentation. So I still don't

Re:QT5 should drop MOC and adhere to standards (2)

tibit (1762298) | more than 3 years ago | (#36119222)

It's not even about template metaprogramming. Template metaprogramming simply does not provide several facilities that are make-or-break for language binding generation. C++ does not have built-in facilities needed by binding generators, this has nothing to do with Troltech/Nokia's developers "ineptness". Guess why swig still exists? Hint: because whoever designs C++ lives on a little cloud-9 where you don't interface with anybody who doesn't use C++. It's a basic deficiency of current C++ spec, and there's no way around it other than running a code generator external to the compiler.

Re:QT5 should drop MOC and adhere to standards (3, Informative)

tibit (1762298) | more than 3 years ago | (#36119172)

C++ simply does not provide the introspection needed for a major application development framework. If it did, you could drop MOC. The way it stands, moc basically generates introspection tables because the out-of-touch [expletive deleted] folks who design C++ couldn't be bothered. That's my take on it.

Every time you interface C++ code with any sort of an interpreted or JIT-ed language, you have to generate "bindings" using an external tool precisely because C++ lacks facilities for code to know about other code. Qt folks were nice enough to maintain such a tool themselves and to make it a core part of their process. I don't consider it a bad thing. QMetaObject system makes it fairly easy to expose QObjects to any other language that's either interpreted or JIT-ed.

Re:QT5 should drop MOC and adhere to standards (0)

Anonymous Coward | more than 3 years ago | (#36119610)

WTF?
It IS standard. The MOC is just a code generator to generate plain C++ code that would be extremely painful to write yourself.

offloading dev costs? (1)

isnotimportant (2038920) | more than 3 years ago | (#36117274)

When they bought trolltec they planned on using qt in their phones. What incentive is there to continue development of qt when they plan on using winmo on their upcoming models? do they plan on utilizing "third-party" developers to drop/reduce development costs on qt?

Re:offloading dev costs? (0)

Anonymous Coward | more than 3 years ago | (#36117414)

They provide commercial support for it.
http://qt.nokia.com/support/

fraud? (0)

Anonymous Coward | more than 3 years ago | (#36117420)

In other hand, Nokia is now controlled by MS. And MS has been successful in making people believe MS is really supporting something (open standard for Office, Java, Moonlight, HTML5) but in reality digging grave for them.

Why is Nokia spending money doing this? (2)

mr crypto (229724) | more than 3 years ago | (#36117552)

As much as I'd like to believe that it's because they are good people doing good things, why are they putting money into this, and how long can we expect them to keep doing so?

Re:Why is Nokia spending money doing this? (0)

Anonymous Coward | more than 3 years ago | (#36118072)

Keep your enemies close. What OS do you think Nokia's best engineers work on? Use QT as a training/proving ground, and pick the best of the litter for your commercial dev group. Double benefit: employee training/filtering, and a competing OS remains relatively ragged and slipshod compared to your commercial offering. Side benefit - you can always fall back to plan B if plan A blows up in your face. Cynical? Yes. But if I can imagine such a strategy in five minutes, imagine what executives who think about stuff like this all day come up with.

Re:Why is Nokia spending money doing this? (-1)

Anonymous Coward | more than 3 years ago | (#36119188)

I imagine a well hung dude eating out my asshole while I fuck a hot asian chick doggy-style.

I haven't been worried about it (1)

trawg (308495) | more than 3 years ago | (#36117562)

I've written it off as more or less completely irrelevant

Re:I haven't been worried about it (0)

Anonymous Coward | more than 3 years ago | (#36118938)

Just like the world never worried about you or your opinion in the first place.

Re:I haven't been worried about it (1)

mr_da3m0n (887821) | more than 3 years ago | (#36119662)

Parent is slightly harsh but it is true. just because you think Qt is irrelevant doesn't make it so at all. Qt is still a hugely used toolkit, and in my humble opinion, one of the best. Just because you don't use it doesn't mean it is irrelevant.

Missing entry in list (0)

Anonymous Coward | more than 3 years ago | (#36117748)

1. Re-architecture our graphics stack
2. Base all Qt ports on Lighthouse
3. Modular repository structure
4. Separate all QWidget related functionality into its own library

5. Publish a revised version of the QT4 Dance [youtube.com]

The future of Qt (1)

maestroX (1061960) | more than 3 years ago | (#36117998)

Ow gawd. Styling of Qt quick resembles Symbian.

Re:The future of Qt (0)

Anonymous Coward | more than 3 years ago | (#36119264)

How exactly?

So long as the new proprietary base is there (0)

Anonymous Coward | more than 3 years ago | (#36119832)

So long as the new .net proprietary base is in place, you can develop for any microsoft target you like.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?