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
Or does it just look too bad?
Looks like more and more focus on mobile development (Qt Quick, Javascript as your UI) and less and less targeting for desktop systems. Which is too bad, and if they are *publicly* announcing that it won't be until 5.2 that the desktop becomes usable again, it looks like it's time to either fork the 4.8 version or start over with some other product.
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..."
that they have probably waited too late. Nokia is irrelevant now as far as QT is concerned and so what is MS buys them as some point out? MS is pretty much irrelevant as well. We have to remember that the mobile market is in its infancy and Apple and Google are the only ones poised for growth in this market. Just imagine what its going to be like in 3 or 4 years?
QT was nice - but I would like to know what would prompt anyone, any business or anyone else to be compelled to work with QT when you have the SDK from google and apple and all of the support behind it? Just random thoughts
Whoah there... QT is far more popular than Autoit. Autoit is proprietary software, whereas QT is free. If Autoit doesn't work with it, they should work together with QT developers to find a solution that works for both.
Well.. maybe. Or Maybe not. But Definitely not sort of.
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.
Autoit may be closed source but its freely available and its not the fault of autoit that QT masks the interface you create with it. You cannot use autoit with any application using a QT interface. And in that sense who is closed?
... Does QT still break Autoit?
Are you a broken record? Submit a bug or Submit a patch. Complaining to Slashdot about some proprietary automation software is a complete waste time for everyone.
Qt is open-source. You or Autoit can fix whatever problem is hurting it and submit the patch. Your crusade against Qt because of Autoit is misplaced, trolling and off-topic on slashdot.
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.
I just took a look at QML on Wikipedia and the code examples aren't exactly awesome. I wish they would have stuck closer to JSON syntax.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
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.
FYI, I took a look at his link. This isn't the most rational or easily understood poster you'll find. Not worth pursuing any line of argument with him.
Well.. maybe. Or Maybe not. But Definitely not sort of.
"QT created interfaces masks and by intent" Either say something that makes technical sense, or shut up. Thank you.
A successful API design takes a mixture of software design and pedagogy.
QED
Well.. maybe. Or Maybe not. But Definitely not sort of.
Disregard the new 7 digit account troll tibit. He's a noob.
And that's my problem how exactly? You're claiming that Qt is making it intentionally hard for autoit. I'd think you know exactly what the problem is. You know, with your repeated claims that it's Qt's fault...
A successful API design takes a mixture of software design and pedagogy.
ur problem is u r a stupid noob since u ask.
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.
"AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting." "Compatible with Windows 2000 / XP / 2003 / Vista / 2008 / Windows 7 / 2008 R2"
looks like Autoit has the problem, look at their target audience...
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
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.
I searched but only Linux/MacOSX and MSVC are detailed.
AutoIt is designed to work with native windows controls, so it wouldn't surprise me to learn it has problems with manipulating Qt applications, especially if Qt is handleless under Windows (I dunno if it is).
I hope that doesn't mean that QT 5 is x86/amd64-dependent because V8 is. I would hate for QT to be locked into one architecture.
The reason Qt 4.4+ applications do not work with AutoIt, or any other WinSpy-like application, is the so-called "alien widgets":
http://labs.qt.nokia.com/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/
The normal behavior of an application is to create a Window object for every widget (window, button, combobox, etc) on screen. Usually that is done at the very low level, therefore most users (and even developers) do not know about it. This is true for every platform I know: Windows, X11 and Mac. I don't know the details about Wayland but I would be surprised if Wayland used a different approach.
The problem with the 1-window-per-widget approach is it causes a lot of unnecessary refreshes, which lead to flickering and a low performance over remote access protocols such as Remote Desktop, Citrix, etc. The reason is the graphics layer (GDI, X11, Quartz, etc) is responsible for refreshing the widgets and it will refresh the full widget even if only one pixel changed, or even if it didn't change at all and it was only the parent widget which changed.
Since version 4.4, Qt takes a new approach: create ONE (and only one) top level window for the application, then simulate all the other widgets by "drawing" them on screen. This allows the Qt painting system to have a finer-grained control over what needs to be repainted and translates into no flickering without the need for double-buffering.
Given that AutoIt is expecting full-fledged Window objects, it will fail with any application using Qt 4.4 because there is only ONE Window object.
Now that we know why AutoIt fails, we can try to find out what needs to be done.
The first approach is to just tell Qt to use native widgets, i. e. 1-window-per-widget. The Qt documentation, which you have not read, explains how to do this:
http://qt-project.org/doc/qt-4.8/qwidget.html#native-widgets-vs-alien-widgets
As you are very lazy, let me summarize that for you: set the QT_USE_NATIVE_WINDOWS environment variable to 1 and now you can use AutoIt. Performance will degrate a bit, though.
The proper approach, which needs to be implemented in AutoIt, would be to hook into the Qt painting system and "learn" about the internal representation of the emulated Window objects. That way AutoIt would be able to automate any Qt application, not matter if QT_USE_NATIVE_WINDOWS is used or not. This is what GUI testing automation tools such as TestComplete, Squish and others do: toolkit-specific plugins for Qt, Gtk, WPF, DevExpress, Telerik, etc.
That's of course only true for applications using QWidgets. For applications using Qt Quick, there is nothing like QT_USE_NATIVE_WINDOWS and the only possible approach is to create a toolkit-specific approach.