Rumour: Nokia to be split?
-
@temp: You seem very passionate about Qt and yet very disapointed, because of Qt moving route.
Some people fear that they are investing their time and energy, and that Qt may disapear, and will have to start over with something else new and diferent. I think we shouldn't worry too much about the future and live for the present. Qt isn't going anywhere soon, even if Nokia would drop it, Digia is still working on it, and a lot more companies and the open governance. And don't you worry about not having big Nokia around to support it, did you forget that all it took was 2 trolls to start it ?
One good example of what I'm trying to say is OpenGL, the old fixed pipeline was easy and pleasent to work, but that will be gone soon and we will have to learn the new hard way, the programming shaders. More time and energy to start again and learn all the new things, because they are not even backwards compatible.
And about Qt, even if it was moving to some route that pleased you, sonner or later you would have to spend lots of time and energy learning new stuff, because in the IT industry things change very fast. C++ just have changed to a new level. For the moment, do you see any feature about Qt that has been removed that you really need it ? Because Qt widgets are still there, and C++ is still there. And nobody told they were going away. When OpenGL masters said fixed pipeline was going to be deprecated, they gave some years and some compatibility versions for people to learn the new way.
If a day comes when Widgets and C++ are to be deprecate from Qt, they are not going to disapear in a day, and we will have time to learn the new way, or if we don't like it just move away and learn new things. Meanwhile, since all the goodies are there why not stick a round for the moment, make peace with Qt and keep on enjoying it ? That's just my humble opinion.
-
@john_god - Digia is still "working on it" but that work is concerned mostly by bug fixes and commercial support, I don't see Digia rushing to implement a native C++ frontend to Qt Quick, which is what Qt needs.
OpenGL IS backward compatible, and the introduction of a programmable pipeline did not enforce a new language standard, virtual machines and interpreters, glue code and all that nonsense, it just offered more flexibility while retaining the good old C style syntax and API.
As for the rest, there is an ocean of a difference between "something is still supported" and "something is actively developed and improved on", and the fact of the matter is a native frontend to Qt Quick and the SceneGraph is totally doable, but then again, that would give the option not to use QML, not to have glue code, nor the overhead of interpreting and a JS VM, which for some reason Nokia thinks is a bad thing. QML has NOTHING TO DO with improving technology, and even a child can tell you that you will get superior performance and efficiency, combined with deeper access to APIs by keeping to a native development pipeline. And if QML was about improving technology, the logical move would have been to offer it as an alternative to C++, so that people could compare the QML and C++ frontend to Qt Quick and decide whether they want the overhead of QML or whether to keep it native, but there is no native frontend to use the C++ backend that sits behind QML, to deliberately make it impossible to compare the two and realizing native development is superior in most of the aspects.
-
bq. ... which is what Qt needs.
I think that therein lies the point of contention. While you feel (and quite deservedly have the right to believe so) that this is completely and totally necessary (for whatever reason anyone chooses to argue,) the vast overwhelming majority of developers and users would appear to disagree, simply by the merit of how many developers have happily jumped onto the QML train and are reaping the benefits and rewards of it.
Please don't get me wrong, as I'm not criticizing your thesis. I'm just pointing out that, for no matter what reason that there isn't a C++ front end to the QML-based stuff, generally people are ok with it and are flexible enough (and content enough) to adapt.
With that said, if you can rally the troops enough to get a groundswell of support for the types of features you desire, then I'm sure that developers -- both commercial and private -- would jump on the bandwagon and start pushing forward on those features. But, unfortunately, the fact of the matter is that developer resources are limited and tend to be thrown at things that are viewed as having the highest priority.
There can be a valid arguments made for wanting a C++ front end, and you have been voicing those arguments very clearly. (Kudos to you for that!) But, so long as the big majority of designers and developers are ok with using QML as an alternative, then there probably isn't going to be a lot of attention given to those arguments, no matter how well-spoken or loudly-shouted they may be.
That's unfortunate sometimes -- especially when you're passionate about something as you obviously are -- but sometimes it can't be helped.
The holdup to C++ bindings has never been some closed-door cigar-smoking panel of executives somewhere making decisions on what the proprietary or non-proprietary nature of the toolkit will become, but instead has been from the global acceptance and adoption of the QML solution that the Qt developer community has adopted, backed, and continued help design, shape, and implement.
-
@mlong: Is that "disagreement" of the masses with my point the reason my thread about Qt's commitment to C++, that is buried in this obscure portion of the forum, has more views and more thumbs up than the announcement of of Qt5 Alpha, which is displayed all over the Qt project site and also has a day head start?
Surely, I agree that many programming gurus disagree with me, and indulge in the unnecessary mixing of technologies when a single one suffices. The point of the matter is - QML is good for small, toy apps, and as the number of custom elements and logic grows, it becomes an ugly and tedious task to design C++ elements and interface them to QML. At this point, developing any SERIOUS (and I mean SERIOUS) application in QML is UNTHINKABLE, not because it is not possible, but because it is not worth the effort.
So you are left with the dilemma - spend tedious efforts on gluing your C++ objects to QML or spend tedious efforts on making QWidget look adequate to the time we live in, and not like last century (LITERALLY) application. Well, isn't the point of Qt to make development easy and as many of the people here like to call it "cute"? This is not cute at all, it is straight UGLY.
After those few points, I hope you DO UNDERSTAND why Qt needs a modern native GUI API, because this is what Qt lacks and the implementation of which will contribute to Qt SIGNIFICANTLY.
I EMPLORE you, get in contact with those who manage the front page, and add in a little poll in a place that it is visible to people, something like:
bq. Does Qt need a modern C++ GUI API?
1 - No, I am perfectly happy with QML, JavaScript, interpreters, virtual machines, glue code, glue abstract and proxy objects
2 - Yes, I'd like the option of 100% native development without being left behind with a last century GUI APIThis way we can get some solid numbers on what developers actually want, so Qt development can focus on what people want to use, not what Nokia thinks we must use. It is only fair.
-
Ok. "Here you go.":http://qt-project.org/forums/viewthread/16465/
To make sure you didn't feel like I was trying to slant the results, I even left your original wording in place, though I don't feel it's exactly "neutrally-worded."
Don't mince words because it's not on the front page. This is a good as polls get around here.
-
Well, it still beats nothing, but I think it will not be that indicative of what users want, since most people who visit the lounge are Qt insiders, which seem to conform themselves to accept corporate decisions as correct. At least there is hope that some of them might afford honesty in a more anonymous form.
Thanks!
-
I hope no. But, it's sadly what happen with Meego.
-
I'm tempted not to comment on the "Qt insiders" aspect of it, because it's a pointed comment. However, this is not some kind of conspiracy. You'd probably call me a "Qt Insider" but I have no strong ties to Nokia. I've just been using the Qt Toolkit since 1998 or so. Since version 1.2. My use of Qt predates Nokia's involvement by a very long time. I'm a fan.
I use it because -- in my humble opinion -- it is the best toolkit for what I want to do. It makes development relatively pain-free. I can do cross-platform desktop development, and I can do mobile development to some extent. I was a pure C++ developer with Qt for many of those years.
However, I'm proud to have had the opportunity to write the MeeGo AccuWeather app which Nokia liked enough to bundle on the N9. It's a piece of software that I worked extremely hard on and put a lot of love and effort into. Not just because it was my job to do it, and not because of any corporate demands (aside from my company saying "Hey, we should write an app for this new MeeGo phone thing), and not because of any pressure or demands from Nokia. Does this make me a "Qt Insider"? You'd probably say so, but I say I'm just a passionate Qt Developer who has the fortune to write software that I'm proud of. I'd venture that most of us who choose to use Qt are that same way.
Now, when I was first evaluating how to write this app and deciding what technologies to use, QML was just becoming available. And, after a little bit of guidance and instruction, I looked at it, decided that it was straightforward enough to do what I want to do, and jumped in and used it. I didn't get pulled in screaming and hollering. I didn't anguish the fact that I had something new to learn. I took it as an exciting new opportunity to push forward and do things that I couldn't do before. I didn't have to throw out my C++ knowledge. I just picked up some new tools and skills. That's part of being a developer. That's part of having a passion for one's trade.
And the greatest part is that I thoroughly enjoyed it. It was simple to lay out my interfaces. It was easy to make changes. It was easy to change the entire look and feel of the app on the fly. It forced me to write solid code which separated the business logic of my app from that of the interface.
A good way into the development of the app, I got a stack of notes from some designers in our company which requested some major changes to the look and feel and functionality of the app's interface in order to bring it closer in line with some other apps we've made across different platforms. Since I was using QML, I was able to make every change they requested in just a day or two. Could I have done that with C++? Probably, but having done app development for more than a decade using QWidgets and QGraphicsView, I can at least attest that my changes were far easier to make with QML than they've ever been with the other technologies. It would have taken longer than a couple of days. In short, it just worked for me.
The app isn't insignificant. It's about 6000 lines of C++, and about 2000 lines of QML. It took months to develop and refine. It went through about 3 or 4 major overhauls along the way.
All I can say is that in my personal experience. I didn't feel restrained by the use of QML over C++. I personally felt empowered and was given flexibility which I wouldn't have had otherwise.
You can call me some kind of Nokia Shill if you want, but that's your own misperception if you do. I'm just saying all of this to counter your assertion that QML is impossible to use in a larger application. It is possible and it's not a Big Deal.
I don't give a farmer's flip about the politics of Nokia. Or what they want to do with mobile. Or MeeGo. Or Symbian. Or Meltemi. Or Windows Phone. Or whatever. Because honestly, Qt has momentum which far exceeds anything that Nokia can easily control. It has had that momentum from its origins with two developers at TrollTech, and it has carried on through Nokia's ownership. And it continues to be carried forward into Open Governance. All development nowadays is completely open and completely transparent. It a meritocracy of sorts. QML has merit, no matter how much you despise it.
Now, you can speak for yourself and however many unspoken masses you perceive yourself to be representing. I wouldn't dream of trying to censor you or deny your right to. But, I'm just saying that you seem to have a bad case of knocking something without trying it.
Calling the people who disagree with you "Insiders" or something along those lines is a cheap shot, and is self serving in the sense that it's a easy and tawdry way to discount and brush aside anyone who might make a dissenting argument. Make your points, but make them fairly. Don't resort to name calling, and don't draw artificial lines.
-
Hehe, take it easy, you have put quite a lot of effort in passionately justifying QML, and on many of your points I agree. But you, like most other people seem to miss my point, I have no problem, no quarrel or whatsoever with QML, at least a dozen of times I've stated it is neat and it has its application. And I honestly don't see a reason for you to defend QML, I don't want it dead in favor of C++, I want C++ NOT dead in favor of QML. There is a huge difference between what I want and what you act like I want, and as illogical as this is, there is a good, reasonable and logical explanation.
The human mind is an area I have taken great interest in and dedicated far more time than I've dedicated to programming so far. What I imply is I know the influence communities have on the perceptions and convictions of people. I don't mean to say that you or anyone else does not have a personal opinion, and instead conform to Nokia's views, I merely imply that being a member of a community is equal to taking a side, and quite often community members support each other because they are a community, for matters they would not support each other if they were not a community, simply because it is the right thing to do. It doesn't even have to be on purpose, the human mind is like an iceberg, and the conscious mind is just the tip of it, what you perceive is just the product of lots of processes that occur in the subconscious without ever crossing the threshold of awareness. It all boils down to objectivity, and when communities are involved, objectivity is often clouded.
It is like a lesser version of a family, family members will often protect each other knowing that they are wrong, often remaining blind to a fact, on purpose or subconsciously, and while you are in that situation often you cannot even tell that you are biased and look at things through a distorting prism, which is only apparent to third person observers.
So if you've come this far, perhaps you've realized by insiders I didn't mean just the trolls, because lets face it, it is their job, whether they are passionate about it or just do it.. is entirely their option. By insider I mean someone that is passionate, someone who looks at Qt as more than a lump of code, a piece of technology to use, a dedicated community member. That is what clouds the judgement, not being a member of the development team. And it doesn't have to be on purpose, most of the times it is beyond your control and oblivious to your perception.
Qt Quick is far more than just QML, it is a paradigm, a programming concept, whose benefits I DO SEE and ACKNOWLEDGE, that is why I'd like to see those benefits available natively as well, QML is not the essence of that idea, it just happens to be the frontend interface it is exclusive available through. I don't mind QML, I mind the downplaying of C++ QML turns into a vessel of, which could be avoided if Qt Quick opens to C++ natively.
And last but not least, it doesn't take people to conspire for a conspiracy to take place. Any group of people is a super-organism on its own, a higher order entity we are mere cells of. Most of the people I know are unaware that super-organisms have a life and will of their own, and they make plans and decisions and execute those through what appears as random, unrelated actions from our perspective. It takes lots of time and skill to be able to abstract your mind to a perspective high enough to encompass the processes that take place above us and apparently out of our control, but the fact is there is no such thing as random, everything happens for a reason, even if it slips out of the range of perception. I see an unmistakable pattern here and I am concerned with the direction its "random" iterations will lean into.
-
Ok, so that's well and good. I'll grant you that you are not saying that QML should go away.
However, what is the specific change that you are trying to effect? Is it to spur someone in a "position of power" to step up and say in a godlike, melodramatic voice "Behold! Here is the plan for implementing the C++ interface to Qt Quick." If so, I don't know who's going to do that.
If you and others are truly passionate about having those changes made, then the best solution is to organize and produce. While you might say "I'm only one person and don't have a chance in hell of making that kind of difference" someone has to start somewhere. Even if it's a wiki post or a thread soliciting ideas or requests for comment on concepts on how that can practically be implemented. It doesn't have to be a final solution. It doesn't have to be solid. It just has to be something that gets like-minded people interested in exploring a solution. If that can get a toe hold, then the possibilities are endless.
I fear, though, that just being a mouthpiece yelling for something to be implemented is counterproductive. Your arguments are well-spoken, and aren't necessarily falling on deaf ears. The problem arises in the perception that there are demands without suggestions.
In an odd way it's not that different of a scenario than when people post a chunk of undocumented source code, or pose a vague question on the forums and then demand: "Tell me what to do!" Without something that has some semblance of a seed of an idea of how to proceed, there's not a lot that can be done to move along productively.
-
I have the capacity to somewhat mimic QtQuick through a C++ frontend. And if I do it, I can only do it using the old GUI API, I don't have the capacity to hook it into the SceneGraph.
What I imply is the people who designed the SceneGraph and QtQuick, those are the people that should open those to a native C++ frontend, not because I want to but because it is the right thing to do (that's why I want it), only they have the advantage of not simply knowing the API structure but being the minds behind it. For anyone else it will be exponentially harder to do the same, and without putting a major workforce behind that endeavor, an individualistic effort to do it is UNTHINKABLE.
Do you really think if I could do it I wouldn't have done it already? When I need something done I do it if I can, that is why I bothered learning how to play several musical instruments, that is why I learned how to record and engineer audio, that is why I learned graphics design and 3D, and that is why I am learning programming now, I like creating, but I know my limitations, I have looked at the source code and I am well aware I am not up to that challenge. As I've stated in another thread, it will probably have it easier doing it all from scratch and I have actually been building on it, but it will take many months to reinvent that many wheels. Heck, if I had a million Euro lying around, I'd immediately hire professionals to implement a state of the art API with the best possible hardware integration and many fail safe fall backs to make it as versatile and accessible as possible. Developers need a good and up-to-date C++ framework, and as "luck would have it" Qt comes closest to that description but it is drifting away from it. So hopefully you understand my motivation.
-
I'm not saying that you, personally, should do it all yourself.
I'm just saying that if those who would be the preferential people to do it aren't doing it, then someone should step up and try to move forward with some discussion to see how the crowds could apply their distributed knowledge to it.
But the unfortunate answer is that most likely those that you would will to do it have already done their design work and have already started moving in that direction and are unlikely to step back and refactor and redesign things. I seriously doubt that yelling with any loudness of voice is likely to change that.
I completely understand your passion, but as a bystander, I fear that the approach that is being taken is more than likely to alienate those who could help, rather than endear them to your cause.
And with that, I think I've probably said all that I have that's worth saying...
-
Do you really think that volunteers can MOVE Qt? This is not fixing bugs and implementing minor features, this is something huge.
I direct your attention to this image:
!http://labs.qt.nokia.com/wp-content/uploads/2011/12/contributions_by_domain.png(comits)!
Do you see the ratio between volunteer contributors and the trolls (now presented as Nokia for some reason)? Heck, even Digia, which supposedly has the capacity of providing commercial support is just a drop in the sea.
I know Qt has the status of an open source framework and that people are free to pitch in, and many invitations have been done in this spirit to people, but even if all the volunteer contributors to Qt pitch in on this challenge I don't see it happening. Not because those aren't good and proficient programmers, but because of the sheer volume of code they have not designed and are not "intimately" familiar with.
Going through other people's application code and going through other people's API code is a totally different thing, I've experienced that first hand.
-
[quote author="temp" date="1334784917"]
Do you see the ratio between volunteer...[/quote]From Lars Knoll post:
"Yes, the Qt Widgets module we have in Qt 5 is right now marked as ‘done’, which means we don’t have anybody actively working on new features for the module at this point in time."Hm...
-
@temp: Do you have a source for this chart? It is quite an interesting one. Thanks!
-
-
Interesting graph, but I'm wondering how a more recent one would look. It is not fair to expect that non-nokians will have a large number of commits only a few weeks after open governance going live in week 43. Note that the Qt 4 branch opened up on open governance even later, and that is where Digia is putting most of its effort.
-
Well, they've contributed "hundreds of error corrections for Qt 4.8":http://www.digia.com/en/Blogs/Qt-blog/Tuukka-Turunen/Dates/2012/2/Digia-Contributes-200-Qt48/ in the past six month and although they are contributing to Qt 5 as well, they are "still placing substantial R&D resource power on the development of Qt 4.":http://www.digia.com/en/Blogs/Qt-blog/Tuukka-Turunen/Dates/2012/3/Working-Together-for-Qt-5/.
For those who have missed they've also released an "article":http://www.digia.com/en/Blogs/Qt-blog/Sami-Makkonen/Dates/2012/1/2012/ on how to create Windows 8 Metro-style applications using Qt Quick (QML) and the Graphics View and Animation Framework (C++).
-
@Lukas - no one said it can't be done, just that the underlying framework is not designed for that kind of stuff, unlike the SceneGraph. And there is a huge difference between doing it with a few identical objects an an example that it can be done and a big and fully fledged application. I have actually downloaded the example, and even thou I am running it on a reasonably powerful desktop machine, it is not fluid, it is jerky (even thou it utterly simple and light example), something that does not show on the example video. I don't have Qt5 on this machine so I can' compare, but from the performance numbers for the SceneGraph declared by the development team behind, I am willing to assume it will be more fluid. My tegra2 tablet, which has a tiny CPU and GPU is actually more fluid, even thou it is no more than 1/10th of the desktop machine performance, just for tapping better into the hardware resources.
-
hopes that recent news about Nokia Windows Phone succes and feature phones also ... will have a negative impact on Qt future :(