Rumour: Nokia to be split?
-
Oh yes, I have no doubt Qt Quick runs on a hardware accelerated interpreter and JS engine. Just as much as I have no doubt this is a Qt Quick exclusive feature and WP7 takes no advantage of hardware acceleration whatsoever, making it infinitely worse than Qt Quick.
One thing is sure thou - those tiny, low resolution displays will provide a breath-taking, jaw-dropping hardware accelerated QML experience.
Nokia managed to drive Symbian from a market leader to non-existent, and Maemo couldn't even make it to the market in a significant volume, we have every reason to believe in the imminent success of Meltemi.
After all that irony, it would seem that your affiliations continue to cloud your objectivity. But it is understandable, the ONE THING I don't understand is why no body is banning me from this forum? After all your beloved Nokia has censored out my blog comments...
Got to love the hypocrisy, playing it all liberal here in the forum while communism is raging at the LABS and BLOG comment area.
-
Being critical or being misguided is no reason for banning on this forum. Nothing in the "TOS":http://en.gitorious.org/tos/ would justify that. What happens on other blogs, forums (operated by Nokia or not) is not the responsibilty of anyone here.
Note that Lukas is, AFAIK, not affiliated with Nokia other than being another developer working with Qt. The people on this forum who are, are recognizable by a green Troll badge under their name.
Having said all that: I guess everyone gets your point that you think that Nokia's management is bad and untrustworthy, that Qt is heading in the wrong direction and that QML is a misguided attempt to push a propriatory technology that doesn't hold a candle to using C++, or something along those lines. Fine. You are entitled to that opinion. Now, if you don't mind, shall we go back to our work? Perhaps you could spend the energy that you put in writing all those long posts here into something more productive? You could start research into creating a C++ API for the features like Scenegraph that you seem to like, or perhaps you could search for alternatives outside of Qt if you don't think it suits your purposes anymore?
-
[quote author="temp" date="1334648968"]I don't understand is why no body is banning me from this forum?[/quote]
"A fool's mouth is his undoing."
-
#offtopic, deterred by those last two personal posts
[quote author="Lukas Geyer" date="1334650758"]
"A fool's mouth is his undoing."[/quote]
So insults are allowed in quotation form?
@Andre - I've been looking into many alternatives the last week, and my involvement in this place is all about ending it in a natural way, just like a car doesn't stop in an instant (unless you crash into a wall) my momentum needs to wear out, and I feel obligated to do anything in my power to sway Qt in the right direction, as my suspicions the push of QML has nothing to do with technical necessities but corporate politics get more and more confirmation. Don't get that concerned with my long posts - I am quick at typing, and the time "wasted" on expressing my opinion is, at least IMO quite a better investment than the time I truly wasted, spent on learning and promoting Qt with the false idea it will remain dedicated to native C++ programming.
bq. What happens on other blogs, forums (operated by Nokia or not) is not the responsibilty of anyone here.
So it is just an amazing coincidence all my censored comments suddenly popped out, coincidentally after that last forum post, surely it was that "anyone here" who is not responsible and who didn't read my post and got embarrassed or told to un-censor comments from my IP? Here is a news-flash - I am not as stupid as you appear to perceive me to be, and I wasn't born yesterday.
And if my rant can make my censored posts get uncensored, then it must work, so if it can, directly or indirectly contribute to returning development attention back towards native APIs, even a tint bit - then it is time well spent. I am not even pushing to deter Qt from developing QML, just to leave developers the choice not to use it without having to give up on every major contribution to Qt done after the acquisitions.
And it is not like I am pulling your hair to get you off your work - My my crusade against Qt's management is a product of my own will, just as your crusade to defend it is a product of your own will, so feel free to get back to your work at any time.
MODs: Feel free to move the last three posts, this one included, to that other thread, since none of those regard Nokia.
-
Nokia tried a lot of development platforms in the recent years:
Symbian C++ (CodeWarrior) for Symbian OS
Symbian C++ (Carbide.c++/Eclipse) for Symbian OS
GTK+ for Maemo
Qt for Meego
Visual C++ (only for OEMs) for WP7
No one was/is really successful (in the last 1-2 years). Nokia try/tried to jump from one to other. This can confuse the developers (and the consumers too)! I don't like to learn completely different development environments year by year.
I think that the most successful would have been the Meego/N9 line.
The N9 was/is a really good phone. But because the selling dates are not so good (because of Nokia's bad marketing decisions), this line will be disappear.
I can't see the future of Qt... -
[quote author="temp" date="1334667951"]
MODs: Feel free to move the last three posts, this one included, to that other thread, since none of those regard Nokia.[/quote]Which other thread?
-
[quote author="Volker" date="1334678549"]
Which other thread?[/quote] -
At this meta discussion level, it's irrelevant where they are. If you want them to be moved, leave a note please.
-
@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...