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: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: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 Arduino. When it is publicly available, I will certainly buy a few, but don't throw my Arduino's away.
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.