QT 5 Will Be Available For Raspberry Pi 80
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.
Re:Definitely Exciting (Score:5, Informative)
Why expect everyone else to do things for you?
Instead of whinging, why not make the effort and sign up for their mailing list [raspberrypi.org] and they'll email you when its out. (early/mid December is the bookies fav at the moment).
QT is fine (Score:5, Interesting)
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 (Score:5, Interesting)
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: (Score:2)
allowing things like QML to set properties on C++ objects from javascript
This is what confuses me about QT, and Android, and WebOS, and iOS. Why QML (javascript like language)? I mean everyone has essentially created a browser form that parses XHTML/CSS/ but instead of it interpreting javascript they add their own scripting language. This keeps people from reusing code. ie. If I don't like a platform, or get anywhere on a platform, or want to expand to another platform I have to completely rewrite all
Re: (Score:2)
Re: (Score:2)
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 signa
Re:QT is fine (Score:4, Informative)
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: (Score:2)
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.
The QMetaObject is one static object that all objects of that class point to. Doing it in the constructor of every object? Proof you have no idea what you're talking about.
Re: (Score:2)
Huh?
There's no need to make an copy of class (not instance) specific information per instance, but that doesn't change the fact that the constructor is the cleanest place to do it, otherwise you'd need to explicity initialize each type of class before use.
The overhead of in-constructor global initialization is minimal - just test/set a static member initialized flag.
Re: (Score:2)
The moc also does a fair amount more than you seem to assume.
But not anything I want or can't do more elegantly some other way. Such "bundling" is not a valid justification for a design mistake.
Re:QT is fine (Score:4, Insightful)
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: (Score:2)
You have no clue what the other poster is talking about; not a coincidence, perhaps, that you think boost is a good way to program.
No, RTTI is not enough. FWIW, standard RTTI does not even work well across shared libraries when done by fairly mainstream compilers such as g++.
Dynamic invocation and introspection is essential in making things like QML work without lots of tedious manual coding. C++ was never designed to support that. In fact, it was not designed to support many useful features found in a mode
Re: (Score:2)
RTTI is not enough. FWIW, standard RTTI does not even work well across shared libraries when done by fairly mainstream compilers such as g++.
So, RTTI + shared libraries are the issue? Specifics please. And nobody has proved that a preprocessor is the only way to do RTTI-less introspection.
Re: (Score:2)
So, RTTI + shared libraries are the issue? Specifics please.
Google "rtti across shared boundaries", there is enough reading.
And nobody has proved that a preprocessor is the only way to do RTTI-less introspection.
I think the burden of proof should be on the other party: show how standard RTTI is any helpful in providing useful introspection. I have a short answer: it is useless for the purpose.
Re: (Score:2)
Yeah, smack dab in the GCC FAQ [gnu.org].
Re: (Score:2)
Digging a little deeper moderates "doesn't work" to barely works. [gnu.org] This is also true of the MOC. It barely works. It twists up the build situation horribly and breaks the language.
But you avoided the main point: what stops you from embedding a (const char *) string pointer in each QT object and using that for introspection?
Re: (Score:2)
Digging a little deeper moderates "doesn't work" to barely works. [gnu.org]
If you get all the compiler/linker flags right everywhere, yeah.
This is also true of the MOC. It barely works. It twists up the build situation horribly and breaks the language.
What language? C++ is already broken beyond repair. The Qt-approved subset of it, though, works nicely with moc. I don't remember if I ever had issues with it which were not highlighted in Qt Builder as my own errors. One moderately annoying thing is the Q_OBJECT boilerplate in every class which does not trigger an error if missed in some cases, but that's one mandatory token which becomes your second nature after some practice.
But you avoided the main point: what stops you from embedding a (const char *) string pointer in each QT object and using that for introspection?
The fact that it
Re: (Score:2)
Digging a little deeper moderates "doesn't work" to barely works. [gnu.org]
If you get all the compiler/linker flags right everywhere, yeah.
And also, the FAQ item is not a statement, it is a question, to which the answer is "this is what you need to do to make RTTI work with shared libraries". So I do not think you have proved RTTI does not work.
This is also true of the MOC. It barely works. It twists up the build situation horribly and breaks the language.
What language? C++ is already broken beyond repair.
Sorry, that rhetoric is no argument for breaking the language.
The Qt-approved subset of it, though, works nicely with moc.
That does not sound like a ringing endorsement.
But you avoided the main point: what stops you from embedding a (const char *) string pointer in each QT object and using that for introspection?
The fact that it alone is not enough for useful introspection. Every QObject-derived class does point to a type featuring a class string, among many other things provided by moc.
So what else is needed for useful introspection? And why is the MOC the only way to embed a type string in a class?
Re: (Score:2)
And also, the FAQ item is not a statement, it is a question, to which the answer is "this is what you need to do to make RTTI work with shared libraries". So I do not think you have proved RTTI does not work.
I didn't say it does not work, period, I said it does not work well. As in, being usable to developers without much fiddling with details that are extraneous to the task of programming, and not being quietly broken if said details are done in a wrong way.
The Qt-approved subset of it, though, works nicely with moc.
That does not sound like a ringing endorsement.
Why, if you use C++ to Qt coding conventions and don't do any of that metatemplating la-la stuff or, heaven forbid, think that using C++ exceptions brings you any benefits, you can build quite complex projects with Qt and have them work nicely across many p
Re: (Score:2)
Do you mind if I ask you a question? Do you work on QT itself, or are you a QT user?
Re: (Score:2)
I don't work on Qt, I only use it.
Re: (Score:2, Informative)
You might want to take a look at: http://developer.qt.nokia.com/wiki/New_Signal_Slot_Syntax
Re: (Score:2)
You might want to take a look at: http://developer.qt.nokia.com/wiki/New_Signal_Slot_Syntax [nokia.com]
syntax is ugly..
but it's not final. which begs the question.. actually this is the first "qt5 will be available on platform X" thing i've read..
isn't qt _already_ available on raspberry pi? reading their blog you would think so.
Re: (Score:2)
Thanks for that. The proposed syntax does not seem to require the MOC, but the page doesn't have anything to say about that, odd.
Re: (Score:3)
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 d
Re: (Score:2)
Everything I've seen indicates that it will be an Xorg based port. Certainly, if it ends up using Mer as the backend, it'll be X11 with some forward-looking towards Wayland. I've certainly not seen anything using QT Embedded come out in recent years.
Which area of the market? (Score:4, Interesting)
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.
See the lightbulb that went on over my head now? (Score:3)
You mean that if I learn QT, my skills can build a simple NAS doing something incredible like SparkleShare [sparkleshare.org]/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.
Re: (Score:2)
You mean that if I learn QT, my skills can build a simple NAS doing something incredible like SparkleShare [sparkleshare.org]/GIT, and a mobile interface for my cheap Nokia?
yes
Re:Which area of the market? (Score:5, Insightful)
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? (Score:4, Informative)
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.
Re: (Score:2)
Logically, then, you will want an Arduino with your Raspberry Pi. Tie the AVR to the Pi via I2C or something (whatever is most feasible to implement on the R-Pi) and use it for output. And by "Arduino" I mean you get an LED and a button, and the button could be virtual from one of the GPIO pins, and for that matter, so could the LED. So all you should really need is an AVR chip...
Re: (Score:2)
You'd still be stuck with 3.3V on the AVR, because it has to be fed 3.3V in order to interface with the R-Pi.
Uh why? The AVR can read 3.3V signals from the R-Pi and some resistors are enough to make its 5V signals into 3.3V signals.
What you want is a 3.3 V to 5.0+ V buffer chip daughter board.
No, because I don't just want to do digital I/O. The AVR can also read analog values. The appeal of using the AVR (as opposed to just tying an ADC into the GPIO pins somehow) is that it operates as a coprocessor and it can handle realtime hardware interface tasks so that you don't have to try to make Linux behave like a real RTOS.
Re: (Score:2, Insightful)
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 Ar
Re: (Score:2)
+1 on the low power consumption. If you're running from batteries or solar, the ~2W drawn by the Raspberry Pi becomes a big problem compared to the milliwatts that an Arduino uses. Both boards are awesome (and I'll be buying a couple of RPs when they are released) but each board occupies a different niche.
Also, while the Arduino board costs about $30, a bare AVR is more like $3 (cheaper in bulk). So you can design a device with an Arduino and its exposed I/Os and simple IDE, then embed the CPU in other har
Re:Which area of the market? (Score:5, Informative)
http://www.cutedigi.com/product_info.php?products_id=4642&cPath=277#googlebase [cutedigi.com]
$34.00 .NET ;)
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
Re: (Score:2)
I really wish there was something in this price range that uses a SAM9 instead of 7, that would be great. ie:
ARM9 (So you can run Linux, or bare metal)
Atmel (so datasheets are freely available), Philips would be alright too, I don't have much experience with other ARM manufacturers but I'm sure there are others that don't require NDAs and all that. (I think TI and freescale are decent about this too, probably others).
I couldn't care less about arduino shield compatibility, but it's probably worthwhile to ge
Re: (Score:2)
The original Arduino is for 'noobs' as well as knowledgeable geeks, especially new users who are not normally drawn to using electronics and it caters to them unlike some who disrespect them and make entry into hardware hacking something many avoid. Not quite as bad as linux fundamentalist geeks but close. I'm glad for them and every other maker out there.
The Arduino team started with a fairly simple idea and it's working well. There are more powerful versions coming. I'd not realized they have an Arduino D
Re: (Score:2)
This seems like it could blow the Arduino out of the water ... a mature IDE that'll facilitate designing GUIs,
Do Arduino projects have GUIs?
I think the simplicity of Arduino is the key to its success, not the processing power. Most of the Arduino users I've met didn't really have a clue about programming but they managed to hack something together despite that.
The programming chasm between 'Arduino' and 'Linux' is massive. Most people who are cobbling things together on Arduinos simply wouldn't be able to cope.
Plus the PI is a whole new computer whereas the Arduino is a ting on the end of a USB cable. Plus the PI w
Re: (Score:2)
Project ideas (Score:2)
Re: (Score:1)
Re: (Score:2)
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 de
So the system will be called ... (Score:5, Funny)
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: (Score:2)
and this is news... why? (Score:1, Troll)
I don't get why this is news. Is Qt5 so unportable that it requires 400 developers to port it to a new machine? Is Qt5/X11 so slow and inefficient that you can't use it on a 128MB RAM machine that's faster and bigger than high end desktop PCs of a few years ago that used to run Qt just fine, and therefore needs a separate "embedded" version? What's the news here?
Re: (Score:1)
A few years ago? Huh? Having 128MB of RAM hasn't been considered "high end" for well more than a decade.
Closer to two decades.... 128MB RAM machines would have been around at the launch of Windows 95.
The CPU speed isn't too bad but with only 128Mb RAM and SD cards for storage the Raspberry PI is going to disappoint a lot of people in terms of performance. Even if you upgrade to 256Mb RAM and USB hard drives (which drives the price up perilously close to a real PC) I can't imagine many people using it as their main machine if they've got used to even the cheapest modern PC.
I'm not hatin' on the PI, just being
Re:and this is news... why? (Score:4, Informative)
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.
Re: (Score:2)
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.
Yep. You must remember that RAM for the most part was seriously underspec'd on OEM machines. Even if you had 2-4x as much, the average moved much slower.
Re: (Score:3)
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!)
Re: (Score:2)
128MB RAM machines would have been around at the launch of Windows 95.
One of the marketing points of Windows 95 over OS/2 was that Windows 95 would run with 4MB of memory.
Re: (Score:2)
Re: (Score:2)
Sure, but many 486DX2 machines had 8Mb RAM.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
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: (Score:2)
OK...point conceded.
Even so, 1996 is still closer to two decades than one decade...
How is this news? (Score:5, Interesting)
Re: (Score:3)
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.
KDE (Score:1)
Re: (Score:2)
Yes, as long as it compiles on arm and it's happy running in 128Mb (model A) or 256Mb (model B) RAM.
Nokia engineers . . . ? (Score:2)
Nokia announced a while back that they were considering building low-end, cheap Linux phones. Since Nokia seems to be sponsoring this, I wonder if this stuff is somehow related to their Linux phone plans . . . ?
Re: (Score:1)
Re: (Score:1)
Well, one would have to wait a while before OpenRISC cores are manufactured - unless they want to settle for buying FPGAs that are programmed to be OpenRISC. Which is why it makes sense to target cheap hardware.
Or use a CPU from Atmel or TI. They provide excellent documentation on their products. Certainly stay away from the Broadcoms and Sigma Designs and Rockchips of the world. It is nothing but trouble dealing with undocumented chips.
Re: (Score:1)
I think the reason why many of us are excited about this little device is because it's dirt cheap, low power, small enough to cram into all sorts of projects, and open enough to allow you to run Linux or something else. More open hardware would be a bonus (for those wanting to get closer to the hardware) but for the vast majority of us it won't stop us coming up with all sorts of nifty little pet projects.
I don't
Re: (Score:1)