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).
Re:QT is fine (Score:2, Informative)
You might want to take a look at: http://developer.qt.nokia.com/wiki/New_Signal_Slot_Syntax
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: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: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: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.