Slashdot Mirror
Qt 5 Alpha Released
After nine
months of effort, Nokia's Qt Lab has announced the availability of
the alpha
release of Qt 5. Goals achieved for this release include a new platform
abstraction layer, a re-architected graphics stack, and the
inclusion of Qt Quick as a first-class citizen (hitting version 2.0, and using Google's V8 Javascript engine to boot). Quoting Lars Knoll:
"'Qt 5 should be the foundation for a new way of developing
applications. While offering all of the power of native Qt using C++,
the focus should shift to a model, where C++ is mainly used to
implement modular backend functionality for Qt Quick.' I can say that
we came a good way closer to this vision with Qt 5.0. The model is
working nicely on the embedded side of Qt where UIs are full
screen. On the desktop, we have laid most of the foundations required
for this model, but it’ll take us until 5.1 or 5.2 to really take this
into use."
Nokia has posted the the source and detailed release
notes on the Qt wiki.
What's going to happen with Qt if/when Nokia goes down the drain and gets swallowed by (probably) Microsoft?
thegodmovie.com - watch it
Why is everyone heading to this "everything is a web app" model? A scripting languages embedded into an app is find but it should be used for quick mods and customization instead of core functionality, and should be layered on top of the application and not the base that the application is built from.
How can you start that sentence but not finish it thusly:
"After nine months of effort, Nokia's Qt Lab has given birth to..."
When your core users are using your software SPECIFICALLY for desktop C++ development, bastardizing the software in some schizophrenic, hopeless pursuit of an area few of them want is quite the wrong way to do it.
On the desktop, it is an extremely fluid, extensible, quick yet powerful way of developing visual applications in a language that many love (C++).
I would quite like it if I could build applications for the core mobile devices under that exact same setup.
But that isn't what they are aiming for, and you're right, their sights seem set on irrelevancy and failure.
My interpretation is that Qt Quick is not yet suitable for desktop use, while the 'old-style' C++ objects should remain as usable as they are now.
While I'd love to see how Quick could help with improving my workflow, since I only work on desktop interfaces I guess I'll have to wait.
Its not just open source, its an open community. If it doesn't work for you, work with the community to change it to work for you. Its not rocket science. You can't blame people who are open to suggustions and participation for not doing things you want, if you don't talk with them and explain your use cases.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Question is "have they changed this?"
Whats the bug number where they were notified. Why did they refuse to fix it?
AutoIt:
AutoIt has been designed to work on Microsoft Windows 2000/XP/2003, Microsoft Windows Vista, Microsoft Windows Server 2008/2008 R2, Microsoft Windows 7.
So you are complaining about an open-source development toolkit that supports every major OS and several Mobile OSs against a Windows-Only, proprietary application. I really don't think you are going to find many sympathizers here.
They have nowhere near the functionality of Qt. Never mind the handwritten introspections in GTK. You'd think people could use, you know, computers to do the mundane for them. The distaste for using tools other than the holy compiler is awful. You've got all those beautiful resources, yet you choose to be confined to the expressiveness (rather, lack thereof) of C. Yay.
A successful API design takes a mixture of software design and pedagogy.
QML is as close to JSON as it can be while still supporting all the features that are needed for the concept to work. I'm not sure in what way you would like for it to be closer to JSON? I suppose the most major difference is that where JSON is weak typed QML is stronger typed. Properties are pretty strong typed, whereas the included JavaScript in signal handlers and other places is (obviously) completely weak-typed. But even the stronger-typed properties are not as strongly typed as they would be in C++.
For example, objects use introspection to resolve functions, meaning that I can call any exposed method on that object. The same goes for properties on objects. Where the strong typing appears is when you want to assign something to that property - an object property will throw an error when you try to assign an int and vice versa. While I personally appreciate it, I believe this was mainly done to ease the integration between QML and C++, since it becomes easier to optimise method calls if you do not need to parse the type at every call.
Why Qt Quick is "focusing on mobile"? From what I've read about it, it looks like a (long overdue) open source alternative to WPF to me - it espouses largely the same principles with separation of UI markup and code and a convenient syntax to bind two together, with the only difference being that it's backed by C++ rather than .NET (and it's much faster).
Qt supports UI automation via its accessibility framework.
So either it is completely broken or autoit doesn't support it.
And unless someone shows me an official bug report, I think that autoit is more likely to be the problem.
I think the problem is that Qt, like most GUI toolkits, uses its own widgets instead of the windows API. There are pros and cons. And one of the cons is that programs designed only for built-in windows widgets may not work properly. It is probably the case with autoit.
Properly designed C++ applications and frameworks don't have to be any slower than C.
Faster even, because of additional optimization possibilities in cases like method calls and lambdas. Speaking as an inveterate C hacker.
Have you got your LWN subscription yet?
QML will seem like Chinese to anyone without some programming experience, so, if they are going to produce anything interesting, they will do it with UI designer applications, not by programming directly in QML.
Poor unsuspecting C++ programmers will then be given the QML code produced by the UI designer tool and try to dhoehorn it to the C++ application. They will feel tortured, because the QML fed to them will be not that readable (most automated code production tools produce awful code), the UI designers will certainly have programmed many horrible abominations using the UI tools, like copying and pasting the same thing over and over, instead of doing it in an object-oriented fashion, and the C++ programmer will simply have to deal with it.
Personally, I have not seen a web designer that he or she could or would code. They avoid coding like a plague. They just do not like coding, and that is why they chose to be designers. On the other hand, C++ programmers do not like scripting languages much. I seriously doubt QML will be of any use to anyone in any project, other than for toy projects.
Fashion is a double edged sword. If you follow fashion, you will stay relevant and 'in'. But you may accidentally introduce problems, especially if you are a software company.
GObject introspection tool seems to be a recent thing -- that's what I glean from what passes for their documentation. Never mind that the tool itself is not documented within GObject documentation, so don't blame someone who refers to official documentation (not the live crapfest) for not finding it. Various anti-Qt-fanbois have been whining for the longest time about the fact that Qt uses an extra tool (like if that was hard, gimme a break). It was GTK's supposed win factor that you could do everything manually; of course if you feel so inclined you can code up QObject metadata by hand too, what moc does isn't magic.
Suddenly --- boom, GTK has not one but two brand-new tools that generate C code: the introspection compiler, akin to moc, and Vala, a whole new language. I'd hardly call the GObject introspection project innovative in any way, I mean come on, moc has been with us for 15 years or so. Yes, they finally realized that not everyone is a masochist even if they write in C, so good for them, but IMHO it's a bit too little, too late. Oh, and good luck finding it if you don't know it's already there.
As a professional developer, I would not really bother even looking at their stuff, the documentation is so bad. From my viewpoint, the fact that the Gnome project is cut up into so many libraries doesn't help at all, nor does it instill any confidence. The individual libraries are all a crapshoot from integration viewpoint: some use GObject, some don't, the API conventions differ, it seems like a loosely bound mess. When you work with a monolithic framework like Qt, at least you can count on some measure of self-consistency.
A successful API design takes a mixture of software design and pedagogy.