QT 5 Will Be Available For Raspberry Pi

New submitter sirjohn writes with the good news that "A small group of ICS and Nokia engineers have started working on a minimal bootstrap to bring fully functional Qt 5" to the Raspberry Pi, writing "Do you want to create the next big thing on embedded devices and have $35 to invest? You can now have a complete development environment with accelerated graphics for basically nothing. I think it's a big deal ..." Plus, Nokia is funding 400 of the boards and looking for ideas (and developers) to use them. The competition is stiff; there are already quite a few impressive ideas listed.

Comments

QT is fine

[Daniel Phillips]

I like QT. It has become my GUI toolkit of choice. It does a lot to help you write rich interfaces with sensible defaults. It is no mean feat to reconcile those two. Recent versions have an awful lot of shiny gizmos under the hood, a full featured animation framework for example. Very few complaints. Except the MOC. Approaches like sigc++ or Boost signals are much better than the half baked preprocessor hackery. Given that QT breaks compatibility badly with each major release anyway, how about putting less effort into justifying that entrenched silliness and think about moving into the 21st century?

Re:QT is fine

[Anonymous Coward]

Qt 5 is about a *minimal* break in compatibility between Qt 4[1], so your suggestion of "breaking compatibility badly" was rather poorly researched.

As for hating on moc... moc is not just for signals! I hear this sort of thing repeated time and time again, and it's clear that every time, people do not do their homework. When you can come up with a solution that can provide at least these capabilities, feel free to suggest it for Qt 6, and better still, offer a patch.

- qobject_cast, a dynamic_cast which works across module boundaries (and doesn't use RTTI)
- the meta object system, allowing you to introspect objects at runtime, think of something like C#'s reflection - take a look at things like QMetaObject[2] and QMetaMethod[3], etc.
    this includes runtime creation of instances of a given class, looking up a method by name and invoking it with random arguments, etc...
- the properties system (Q_PROPERTY), allowing things like QML to set properties on C++ objects from javascript
- signals and slots

[1]: http://labs.qt.nokia.com/wp-content/uploads/2011/05/Qt5.pdf
[2]: http://doc.qt.nokia.com/latest/qmetaobject.html
[3]: http://doc.qt.nokia.com/latest/qmetamethod.html

Re:QT is fine

[Anonymous Coward]

You might want to take a look at: http://developer.qt.nokia.com/wiki/New_Signal_Slot_Syntax

Re:QT is fine

[SpinyNorman]

All you need for a meta object system/etc is an appropriate QObject base class to replace the moc & Q_OBJECT preprocessor kluges. Wanting to avoid standard C++ features like RTTI and dynamic_cast in favor of Qt-specific hacks is a horrible case of no-invented-here syndrome. Just stick to the standard language facilities, please.

One obvious way to cleanly implement introspection without preprocessor hackery would be to have each object's constructor register it's method in an appropriate way with the proposed QObject base class.

When Qt was first implemented it was *perhaps* excusable, given the state of template, STL, etc support in target compilers, to use preprocessor hackery, but for many years now that's been an invalid excuse. Sure it would be considerable work to change Qt into a truly native C++ library and ditch moc, etc, but there's no valid *technical* reason why it couldn't be done.

Re:QT is fine

[Apu de Beaumarchais]

QML despite being Javascript based is used a replacement for HTML not Javascript. QtScript uses a javascript engine and is Javascript as you know it aside from using QML instead of the DOM. I personally prefer the integration of Webkit as HTML / CSS and Javascript can be used with minimal changes on other platforms and you can do heavy lifting and native functions (like changing output monitor / going full screen) with C++ which integrates nicely with the Javascript. On top of that you can create plugins in Qt so features can be added as extensions nicely.

Re:QT is fine

[chrb]

As far as I can see, this is a port of QT embedded (QT with a framebuffer backend). That means it won't be QT as most developers know it, and it won't be capable of running most pre-existing applications without some modification. Qt/E uses its own windowing system, there is no xorg or X11 compatibility layer, which the build systems of many applications expect, and your application will be running as the only software writing the framebuffer, rather than in a desktop environment. Many (most?) existing QT desktop apps aren't going to run on this without having some porting work done. The only app I can think of that does support QT/Embedded is MythTV, but IMHO the QT/Embedded port is run by almost noone, and is buggy. When I played around with it, I eventually gave up and installed xorg and used the QT/Xorg port.

The Pi does sound awesome, and I expect we will see a variety of different environments and graphical/launcher/desktop layers (direct framebuffer, Xorg, Wayland, single apps, multi-apps with launchers, Android, full LXDE/Gnome/KDE/.. desktop etc.) before people come to some kind of agreement as to what works best for this thing.

Re:QT is fine

[okoskimi]

QML is used to specify the UI for an application. It is a declarative language that specifies UI components, their states and animations, etc. The syntax is JavaScript like in that it looks a bit like you are defining JavaScript objects. QML uses JavaScript to specify UI logic and calculations, and if your application is mostly UI (say, a simple game) you can code it entirely in QML + JavaScript (not unlike Flash). Nontrivial applications typically have a separate engine part written in Qt C++. The Qt signals, slots and properties system make it easy to integrate the QML part with the C++ engine part. That is actually a part of the idea with QML: it is easy enough to learn and use (there are graphical tools too) that designers can work with it to design the application UIs (instead of using Photoshop or Flash), and coders can concentrate on the engine part. So the UI design is actually working code, and if the designers get a great new idea and want to redesign the entire UI, instead of groaning (because they have to re-implement everything) the coders can just smile and tell them to go right ahead (because the designers will do the UI implementation themselves, and the engine part will be isolated behind its API).

QML is optimized for writing the kind of fluid UIs that mobile applications favor today, meaning there is a lot of support for animations and other eye candy, and everything is heavily optimized to run smoothly on mobile devices. HTML, on the other hand, is not optimized for writing such user interfaces. So, writing a non-trivial, non-web-page-like user interface takes much less time to do in QML than in HTML (if it is possible to achieve in HTML at all) and the resulting user experience will be much better.

Of course, if your main concern is portability across mobile platforms, then HTML (and something like PhoneGap) is the way to go. Or, like a (fellow) Nokia employee put it: "If you want to go fast, use QML, If you want to go deep, use Qt C++. If you want to go wide, use HTML."

Re:QT is fine

[Daniel Phillips]

moc is not just for signals! I hear this sort of thing repeated time and time again, and it's clear that every time, people do not do their homework.

I did my homework. I concluded that the MOC is disposable. Of the items you mention, only signals and slots are essential. Dynamic cast for example in no way justifies the clumsiness of the MOC. First, you can just use RTTI, I have no idea why this is such a scary thing for some folks. Or if you really really hate RTTI, adding your own simple type tags is trivial, works well, and can be retrofitted to QT objects thanks to multiple inheritance. With these tags you can introspect. Setting properties from Javascript... I don't care about it, but maybe somebody does. Surely this is not the tail that wags the entire dog.

I have already considered those links you supplied long ago. Lots of bogus arguments to support what on the face of it is a clearly bad design decision. Possibly one that could be justified at the time, but not today. Software design has advanced and so have compilers. But this one big fat wart does not for me negate the fact that QT is the best of class in the windowing library sweepstakes. Ijust wish MOC advocates would step back a bit and realize how unimportant the usual justifications are, compared to the major damage caused to build sanity and programming language orthogonality.

Re:Definitely Exciting

[Anonymous Coward]

Why expect everyone else to do things for you?

Instead of whinging, why not make the effort and sign up for their mailing list and they'll email you when its out. (early/mid December is the bookies fav at the moment).

Which area of the market?

[derGoldstein]

This seems like it could blow the Arduino out of the water, at least the higher-end ones (including the ones that are currently being developed). If you can get full C++ and some actual computing power (I mean as opposed to the no-OS MCUs), and a mature IDE that'll facilitate designing GUIs, it would definitely change a few things. The Beagle Board team will also have to start rethinking the current design, since its current cheap model is $90.

And yes, I know that the Arduino as a software platform (and the IDE) isn't going anywhere, and that's great, but their plans to design higher-end models will have a very difficult time competing with a $35, QT-programmable board.

Re:Which area of the market?

[Anonymous Coward]

The difference is Arduino's are fairly forgiving when you throw a funny voltage or analog input at them. the R-Pi has no analog, only 16 GPIO that is designed for short-distance communication on a board. In order to get decent IO you will have to buffer the GPIO in some way, and with this buffer comes the protection that the ATMEL's have already. It will be very easy to break a standard R-Pi without buffering the GPIO, plus compared to an Arduino, there is probably 10x as much code to do the same thing.

Just working with /sys/class/gpio is more work that your average Arduino program.

Re:Which area of the market?

[Anonymous Coward]

It won't blow the Arduino out of the water. For simple applications, like LED and sensor controllers the Arduino's simplicity and low power consumption is a big plus. Linux OS and fat programming layers, such as QT, adds unwanted complexity and overhead. Tasks like interrupt driven programs will be a lot simpler in the Arduino. And one more thing: at least the first versions of Pi don't include GPIOs or ADCs.

Pi will be useful for lots of different embedded apps and it will at some extent overlap with the Arduino. When it is publicly available, I will certainly buy a few, but don't throw my Arduino's away.

Re:Which area of the market?

[mrmeval]

http://www.cutedigi.com/product_info.php?products_id=4642&cPath=277#googlebase

$34.00
It has an AT91SAM7X512 Arduino shield compatible. I've not checked if anyone has added this to the Arduino IDE yet but you can always use .NET ;)

Re:Which area of the market?

[mirix]

I'm not aware of any protection on AVRs, other than clamp diodes maybe? Which is pretty standard, I presume this thing will have them too. Only difference is ARM is usually 3V3 IO, and has a bunch of options (ie whether open drain or not, selectable slew rates) that normal 8bit AVRs lack. I haven't managed to kill either, but I do have more experience with AVR, and it seems fairly robust...doesn't mean that this chip isn't, though.

MMIO is pretty easy, even from userland (via /dev/mem), if you want to flip more than one bit at once, and have some speed at it.

Although we can't really comment on what features the GPIO has or doesn't have without a datasheet, and don't hold your breath for that.

See the lightbulb that went on over my head now?

[SpzToid]

a $35, QT-programmable board

You mean that if I learn QT, my skills can build a simple NAS doing something incredible like SparkleShare/GIT, and a mobile interface for my cheap Nokia?

Disclaimer: I have a Nokia N900 which isn't precisely cheap, but still, I can develop a cheap, simple NAS and extend it to cheap mobile devices with relative ease? Wow.

So the system will be called ...

[KWTm]

Wait, no one has mentioned this yet?

So, with the Raspberry Pi running the QT 5 operating system, of course this combination will be called ...

the QT Pi

Thank you, thank you. I'll be here all week ...

Re:Project ideas

[10101001 10101001]

One idea mentioned is something about encryption. I can think of a handful of more generically useful stuff, such as a USB filter. That is, you could use it to plug in various USB devices and be assured that, for example, something that looks like a flash drive can't act like a HID device and start typing in things or otherwise root your computer by making a small, verified USB stack. Also, you could provide a pass-through for encryption of mass storage devices mapping only a section of a mass storage device so if you don't trust a computer, you can just plugin a keyboard to the Pi and restrict what the computer can access without having to ever give it your password. I'm sure there are other ideas, but those are off the top of my head. Unfortunately, they don't really have anything to do with QT.

Re:and this is news... why?

[X3J11]

Closer to two decades.... 128MB RAM machines would have been around at the launch of Windows 95.

Hardly. The first machine I ran Windows 95 on, circa 1996 was a Pentium 200 MMX with a whopping 32 MB of RAM. I have issues of Maximum PC from 2000 where most mid range systems were advertising 128 MB.

How is this news?

[shish]

Surely any well written software should *already* run on the Pi? It's just a standard linux install, the only problem would be if your code was very hardware-specific, and I'm not sure why a GUI library would be...

Re:How is this news?

[SpinyNorman]

Well, Qt is relatively hardware dependent - both due to assmbler used for low level stuff and needing OpenGL/VG for acceleration. They've done a lot of work in making Qt more portable, but not surprisingly it still takes some work to get it up and running and optimized on a new platform. Don't forget too that the Pi is ARM based.

Re:and this is news... why?

[washu_k]

Closer to two decades.... 128MB RAM machines would have been around at the launch of Windows 95.

The first consumer level Pentium chip-set to properly support more than 64 MB of RAM, the HX, came out in Feb 1996. Even then, the HX was the high end model, most of the Intel chip-sets over the Pentium's life fully supported only 64 MB of RAM properly. You could put 128 MB in them, but that would actually reduce performance as only the first 64 MB would get cached. 128 MB was definitely not common when Windows 95 came out.

Re:and this is news... why?

[theskipper]

Correct, and in early 1995 the price for 16MB (Micron) was around $1000. The price collapsed by over 75% within a few months. (Worst buy I've ever made...and still pissed about it!)